Rexx / SysINI

(DE) System, Installation, Konfiguration, Hardware, Treiber, Netzwerk, Virtualisierung, etc.
(EN) System, Installation, Configuration, Hardware, Drivers, Network, Virtualisation, etc.
User avatar
DonLucio
Posts: 658
Joined: Sun 29. Dec 2013, 01:14
Location: Hamburg

Rexx / SysINI

Post by DonLucio »

In den OS/2-INI-Dateien lassen sich ja auch Bitmaps abspeichern (mittels Rexx-Funktion SysINI).

Nun muß ich feststellen, dass das offenbar seine Grenzen hat. Wie groß darf maximal eine Bitmap-Datei sein?

In der RexxUtil.inf finde ich keinen Hinweis auf irgendeine Größenbeschränkung. In der Praxis aber klappt's mit kleinen Images, aber nicht mit großen. Gibt's da bekannte Limits? Oder muß ich mich byteweise da herantasten (-testen)?

Danke,
Lutz W.

aschn
Posts: 1157
Joined: Wed 25. Dec 2013, 22:47

Post by aschn »

Die max. Größe eines Iniwerts ist 64 KB. Kann gut sein, dass das hier auch gilt.
Andreas Schnellbacher

User avatar
LotharS
Posts: 781
Joined: Sun 29. Dec 2013, 20:07
Location: Düsseldorf

Post by LotharS »

Wie wäre es in OS2.INI mit einem Key = Pfad auf eine echte *bmp-Datei? Je nachdem wie Du's baust, könnte es ja auch ein relativer werden. Oder legst ganz OS/2-treu für jede Bitmap ein Objekt an und referenzierst dieses...

User avatar
LotharS
Posts: 781
Joined: Sun 29. Dec 2013, 20:07
Location: Düsseldorf

Post by LotharS »

DonLucio wrote:
Wed 21. Apr 2021, 12:50
In den OS/2-INI-Dateien lassen sich ja auch Bitmaps abspeichern (mittels Rexx-Funktion SysINI).
Die INIs sind nach meinem Verständnis nur zur Aufnahme von "Schlüsseln" bestimmt, deren "Werte" irgendwelche "Anwendungs"-Einstellungen wie Kennzeichen, Namen, Koordinaten, o.dgl. bedeuten, aber niemals echter Datei-Inhalte.
Und vergesst nicht, die INIs werden bei jedem Systemstart komplett geladen und können recht empfindlich sein (wie dieses Forum manchmal erzählt... :shock: ). Small is beautiful, eigentlich ;)

User avatar
DonLucio
Posts: 658
Joined: Sun 29. Dec 2013, 01:14
Location: Hamburg

Post by DonLucio »

LotharS wrote:
Wed 21. Apr 2021, 15:17
Die INIs sind nach meinem Verständnis nur zur Aufnahme von "Schlüsseln" bestimmt, deren "Werte" irgendwelche "Anwendungs"-Einstellungen wie Kennzeichen, Namen, Koordinaten, o.dgl. bedeuten, aber niemals echter Datei-Inhalte.
Hmm ... In der RexxUtil-Prog.Ref. steht zu lesen: es könenn drei Typen von Daten eingespeichert werden: (1) Strings (also 0-terminiert), (2) Zahlen sowie (3) beliebige binäre Daten ("arbitrary binary data").

Ich weiß nicht, welchen "typischen" Einsatzzweck die INI-Erfinder sich vorgestellt haben. In der Praxis jedenfalls hat sich dieses INI-System als ausserordentlich vielseitig erwiesen. Nicht umsonst kursiert ja auch der Terminus von den "INI-Datenbanken".

Und tatsächlich ist die Implementierung einer (kleinen) Datenbank-Anwendung mittels INI in manchen Fällen derjenigen mittels DB-Schwergewichten wie DB2 oder MySQL (oder auch dBase) vorzuziehen. Jetzt werden sich sicheriich bei manchen Experten die Fußnägel hochkrümmen, bei diesem Vegleich. Sicherlich liegen da Welten dazwischen. Aber ich plädiere dafür, die Möglichkeiten der INI-Technik nicht zu unterschätzen (eine weitere Ausführung würde aber wohl diesen Thread überlasten).

LotharS wrote:
Wed 21. Apr 2021, 15:17
Wie wäre es in OS2.INI mit einem Key = Pfad auf eine echte *bmp-Datei? Je nachdem wie Du's baust, könnte es ja auch ein relativer werden. Oder legst ganz OS/2-treu für jede Bitmap ein Objekt an und referenzierst dieses...
Das mit dem Referenzieren ist so eine Sache ... Man schafft damit Abhängigkeiten, die von aussen nicht leicht zu erkennen sind. Und wie schnell ist da mal eine kleine BMP-Datei weggelöscht, weil deren Verwendungszweck nicht ersichtlich ist.
LotharS wrote:
Wed 21. Apr 2021, 15:17
Und vergesst nicht, die INIs werden bei jedem Systemstart komplett geladen
Stimmt nur für die System-INIs. Meine eigene Anwendung lädt die zugehörige INI ja nur bei Bedarf.
LotharS wrote:
Wed 21. Apr 2021, 15:17
und können recht empfindlich sein (wie dieses Forum manchmal erzählt... :shock: ). Small is beautiful, eigentlich ;)
Ja, davon habe ich auch schon gehört. Insbesondere die System-INIs scheinen etwas unzuverlässig zu sein. Z.B. ist das Problem der "verrutschten" Icon-Positionen in den Folder-Views wohl immer noch nicht gelöst. Ich bin aber nicht sicher, ob die Ursache dafür wirklich in der INI-Technik an sich steckt.

Ich persönlich habe über die Jahrzehnte beste Erfahrungen gemacht. Probleme fangen erst jetzt an, wo ich versuche, in meiner INI das zu speichern, was bei "richtigen" Datenbanken "BLOB" heißt ("binary large object"). Wie gesagt: Technisch ist das im INI-Konzept vorgesehen! Die Frage ist nur: Wie groß darf das "L" (large) in "BLOB" sein?

aschn wrote: Die max. Größe eines Iniwerts ist 64 KB. Kann gut sein, dass das hier auch gilt.
Das ist doch schon mal eine Aussage :P

Das werde ich gleich mal ausprobieren.

Bleibt noch zu fragen, wie groß darf die INI-Datei selbst sein? Gilt da die normale Begrenzung von Dateien, also 2 GB?

Gruß,
Lutz W.

User avatar
DonLucio
Posts: 658
Joined: Sun 29. Dec 2013, 01:14
Location: Hamburg

Post by DonLucio »

aschn wrote:
Wed 21. Apr 2021, 14:23
Die max. Größe eines Iniwerts ist 64 KB. Kann gut sein, dass das hier auch gilt.
Yip! Hat sich bestätigt :)

Bis exakt 65.535 Bytes Dateigröße läßt sich jede Bitmap INIsieren.

Es freut sich und sagt Danke!
Don Lucio.

User avatar
LotharS
Posts: 781
Joined: Sun 29. Dec 2013, 20:07
Location: Düsseldorf

Post by LotharS »

DonLucio wrote:
Wed 21. Apr 2021, 17:28
Hmm ... In der RexxUtil-Prog.Ref. steht zu lesen: es könenn drei Typen von Daten eingespeichert werden: (1) Strings (also 0-terminiert), (2) Zahlen sowie (3) beliebige binäre Daten ("arbitrary binary data").

Ich weiß nicht, welchen "typischen" Einsatzzweck die INI-Erfinder sich vorgestellt haben. In der Praxis jedenfalls hat sich dieses INI-System als ausserordentlich vielseitig erwiesen. Nicht umsonst kursiert ja auch der Terminus von den "INI-Datenbanken".
Naklar, letzlich wrd alles binär dargestellt :lol: Einsatzzwecke könnten zum Beispiel "binäre Schalter" sein, ansonsten wimmelt es z.B. in den Objekt-Values von "unlesbar" binären Strings. Oder das bekannte hex(00) als Teminator :)
Während die Linuxer absichtlich ihre *conf's extern lesbar halten, setzt OS/2 auf komprimiert binäre Settings und damit geringere Größe und höhere Geschwindigkeit (vor 30 Jahren noch ein Top-Kriterium). Ich glaube, auch Standard-Icons stehen voll in OS2.INI, aber die sind ja nicht soo groß.
Das mit dem Referenzieren ist so eine Sache ... Man schafft damit Abhängigkeiten, die von aussen nicht leicht zu erkennen sind.
Jo, das haben Datenbanken i.d.R. so an sich. Mit gepflegter Doku ist's aber halb so schlimm. :)

Meine eigene leichte relationale Datenbank besteht aus einigen miteinander verknüpften csv-Dateien, php-lesbar...

Deinem Projekt viel Erfolg! :D

aschn
Posts: 1157
Joined: Wed 25. Dec 2013, 22:47

Post by aschn »

DonLucio wrote:
Wed 21. Apr 2021, 17:28
Bleibt noch zu fragen, wie groß darf die INI-Datei selbst sein? Gilt da die normale Begrenzung von Dateien, also 2 GB?
Es gibt eine max. Größe aller geladenen Inis. Das ist eine Schwäche der Prf-Funktionen. Abhilfe sind andere Inifunktionen, die die Prf-Funktionen nicht nutzen.

Z.B. war es mir mit einer älteren WarpIN-Version nicht möglich OOo zu installieren. Etwa zu der Zeit hat Paul Ulrichs xPrf-Funktionen statt der Prf-Funktionen eingebaut, so dass die Installation dann mit der nächsten Version ging. Yuri hat die so geladenen Inis auch von WarpIN-REXX aus sichtbar gemacht, was aber leider nie eingebaut wurde.

Rich hat eine ähnliche verbesserte Bibliothek geschrieben mit REXX-Schnittstelle dazu: rwIni auf Hobbes. Das bietet sich immer an, wenn es nicht um die beiden Systeminis geht und gleichzeitig eine der folgende Bedingungen zutrifft: Die externen Inis sind größer oder es geht um Schnelligkeit beim Schreiben (ähnlich wie Dennis' FastIni, heute kein wirklicher Grund mehr).
Last edited by aschn on Sat 24. Apr 2021, 16:15, edited 2 times in total.
Andreas Schnellbacher

User avatar
DonLucio
Posts: 658
Joined: Sun 29. Dec 2013, 01:14
Location: Hamburg

Post by DonLucio »

aschn wrote:
Wed 21. Apr 2021, 18:32
Es gibt eine max. Größe aller geladenen Inis. Das ist eine Schwäche der Prf-Funktionen.
Äh ... kannst du das bitte erläutern? Meinst du "Eine Gesamtgröße aller zum selben Zeitpunkt gleichzeitig geladenen INIs" ?

Und was sind Prf-Funktionen ?


Danke,
Lutz W.

aschn
Posts: 1157
Joined: Wed 25. Dec 2013, 22:47

Post by aschn »

DonLucio wrote:
Wed 21. Apr 2021, 18:58
Meinst du "Eine Gesamtgröße aller zum selben Zeitpunkt gleichzeitig geladenen INIs" ?
Ja. Die Grenze kenn ich nicht.
DonLucio wrote:
Wed 21. Apr 2021, 18:58
Und was sind Prf-Funktionen ?
start view pmref Prf

Das listet auf:
PrfCloseProfile
PrfOpenProfile
PrfQueryProfile
PrfQueryProfileData
PrfQueryProfileInt
PrfQueryProfileSize
PrfQeryProfileString
PrfReset
PrfWriteProfileData
PrfWriteProfileString
Andreas Schnellbacher

User avatar
DonLucio
Posts: 658
Joined: Sun 29. Dec 2013, 01:14
Location: Hamburg

Post by DonLucio »

aschn wrote:
Wed 21. Apr 2021, 21:56
DonLucio wrote:
Wed 21. Apr 2021, 18:58
Und was sind Prf-Funktionen ?
start view pmref Prf
Ergebnis auf meinem AOS-PC 5.0.4: "Datei nicht gefunden".

In welchem Verzeichnis sollte die *.inf-Datei denn stecken?
Ich vermute mal, das sind API-Funktionen vom OS/2-Presentation Manager für C-Programmierer?
Last edited by DonLucio on Wed 21. Apr 2021, 22:35, edited 1 time in total.

aschn
Posts: 1157
Joined: Wed 25. Dec 2013, 22:47

Post by aschn »

Toolkit installieren/auspacken.
Andreas Schnellbacher

User avatar
DonLucio
Posts: 658
Joined: Sun 29. Dec 2013, 01:14
Location: Hamburg

Post by DonLucio »

aschn wrote:
Wed 21. Apr 2021, 22:33
Toolkit installieren/auspacken.
Ok, danke.
Hab's glaub ich noch auf einer alten Datensicherung.

aschn
Posts: 1157
Joined: Wed 25. Dec 2013, 22:47

Post by aschn »

Ich hab für das Toolkit und für rxtt folgendes in der CONFIG.SYS:

Code: Select all

SET CPREF=CP1.INF+CP2.INF+CP3.INF+ADDENDUM.INF
SET GPIREF=GPI1.INF+GPI2.INF+GPI3.INF
SET PMREF=PM1.INF+PM2.INF+PM3.INF+PM4.INF+PM5.INF
SET WPSREF=WPS1.INF+WPS2.INF+WPS3.INF
SET PROGREF=CP1.INF+CP2.INF+CP3.INF+ADDENDUM.INF
SET TCPREF=TCPPR

SET CLIBREF=XPG4REF.INF
SET rxtt36=I:\Download\dev\Rexx\rxtt36\rxtt36.INF
Dann klappt der View-Aufruf von überall. Für die eigentliche Programmierumgebung benutze ich Skripte, die dann auch PATH usw. erweitern.
Andreas Schnellbacher

Andi B.
Posts: 574
Joined: Tue 24. Dec 2013, 16:40

Post by Andi B. »

Im Zusammenhang mit den .ini Funktionen, kommen ein paar unangenehme Erinnerungen hoch -
  • in der Toolkit-Beschreibung ist zumindest ein Programmbeispiel falsch und funktioniert nicht
  • wenn dem System Ressourcen ausgehen (welche weiß ich nicht, Speicher oder WPS oder PM Interna), dann können diese nicht mehr (richtig) geschrieben werden
  • schon kleine Fehler (Bit) in den inis führen oft zu katastrophalen Programmabstürzen die schwer zu finden und zu debuggen sind (Erfahrungen mit XWLAN)
Zusammengefasst, ich hab eine gewisse Abneigung gegen OS/2 .inis ;-) Auch ich meine, die Gründe warum das damals vor 30 Jahren gut und sinnvoll war, stimmen heute so ziemlich alle nicht mehr bzw. interessieren niemanden mehr. Ob im 4kByte Block auf JFS eine 200 Byte ini Datei oder eine 2kByte Textdatei liegt ist egal. Ich vermeide .inis wo es geht.

User avatar
DonLucio
Posts: 658
Joined: Sun 29. Dec 2013, 01:14
Location: Hamburg

Post by DonLucio »

Andi B. wrote:
Thu 22. Apr 2021, 12:01
Zusammengefasst, ich hab eine gewisse Abneigung gegen OS/2 .inis
Die von dir genannten Gründe für deine Abneigung kann ich aus eigener Erfahrung nicht bestätigen. Liegt vielleicht daran, dass ich seit gut 20 Jahren aufgehört habe, C-Programme zu schreiben (anders ausgedrückt: Nicht mehr die API-Funktionen des Toolkit zu benutzen).

Und aus der Sicht eines <schäm> Nur-Rexx-Programmierers stellt sich manches deutlich einfacher, und ich möchte sagen: idiotensicherer dar. Ich gebe zu: Die SysINI-API ist in ihrer Philosophie gewöhnungbedürftig. Ich selbst bin auch schon mal hart gelandet, weil nicht wußte, dass ein weggelassener Paramter bedeuten kann, eine ganze INI-Hierarchie zu löschen ( :o ).

Insgesamt aber ist meine Erfahrung gut: Wenn man's richtig macht, kommen sehr stabile Anwendungen mit INI heraus. An Platzsparen habe ich dabei noch nie gedacht, das ist - da hast du völlig recht - kein Thema (mehr).

Vor allem aber: Was ist die Alternative? Csv/Txt-Dateien machen deutlich mehr Arbeit, wenn man eine auch noch so kleine Struktur implementieren möchte. Dbase (Rexxbase) käme infrage, ist aber ebenfalls aufwendiger. Von "echten" Datenbanken ganz zu schwigen.

Nur so meine Meinung :-)

Lutz W.

User avatar
Frank Wochatz
Posts: 1010
Joined: Sun 22. Dec 2013, 22:04
Location: Berlin

Post by Frank Wochatz »

Moin,

ich nutze Inis für einige Datenbanken (Adressen, Passwörter) und alle Programmeinstellungen. Es funktioniert eigentlich sehr gut. Ich hatte auch mal eine kaputte Ini, sehr wahrscheinlich lag das an etwas anderem als der Initechnik selbst, aber ich will nicht spekulieren.

Der Hinweis mit dem Limit pro Eintrag ist gut, ich werde das mal in meiner Passwortverwaltung überprüfen, da man dort auch Keyfiles in die Datenbank (ini) einfügen kann. Ich weiß garnicht, ob ich das damals berücksichtigt und eine Überprüfung eingebaut habe, manche Sachen hab ich inzwischen auch vergessen... :)

Ansonsten wäre die schnellste Methode heutzutage bei den SSD Festplatten und aktuellen RAM Größen, die man unter OS2 nicht mehr auslasten kann, Plain Text bzw, zB. CSV o.ä.. Reicht locker für mehrere Hundert oder Tausend (oder noch viel mehr) kleinere Datensätze aus und so eine Datei kannste dir im Bruchteil einer Sekunde komplett in den Speicher laden. Selbst die Bearbeitung mit Rexx ist bei den heutigen Prozessoren kein Problem. Das ist natürlich nicht so elegant wie ein Datenbankformat. Binäre Dateien wie größere Bilder würde ich im DIY-Bereich immer extern speichern und Links setzen. Hat den Charme, dass es robuster ist und man von außen / anderer Seite auch dran kommt.

Grüße
Frank

aschn
Posts: 1157
Joined: Wed 25. Dec 2013, 22:47

Post by aschn »

Nur falls die Datenbanken größer werden, rate ich dringend zu rwIni. Sonst kann es sein, dass die Datenbank nicht mehr geöffnet werden kann (vgl. oben).
Andreas Schnellbacher

User avatar
DonLucio
Posts: 658
Joined: Sun 29. Dec 2013, 01:14
Location: Hamburg

Post by DonLucio »

aschn wrote:
Sat 24. Apr 2021, 16:13
Nur falls die Datenbanken größer werden, rate ich dringend zu rwIni.
rwini führt alle Operationen im Memory aus. Ist das nicht gerade ein Grund dafür, bei größeren Datenbank *nicht* rwini zu nehmen?