VOICE-Homepage: http://de.os2voice.org
Inhaltsverzeichnis
< Vorherige Seite | Nächste Seite >
Artikelverzeichnis
|
VOICE-Homepage: http://de.os2voice.org |
September 2004
Inhaltsverzeichnis
|
| Von James J. Weinkam, D.Sc. © September 2004, Übersetzung: Marckus Kraft |
Profile und Registry sind mehr oder weniger synonyme Begriffe für die Datenstruktur, die von einem System verwendet wird, um Konfigurationsinformationen zu speichern, die das System und/oder Anwendungen, die unter ihm laufen, dynamisch manipulieren können und die bestehen bleibt, wenn das System heruntergefahren wird. OS/2 tendiert zur Verwendung des Begriffes "Profil", während Windows den Begriff "Registry" verwendet.
OS/2 verwendet zwei Standard-Profile, die Profile "System" und "User", in denen das System bestimmte Informationen gepseichert werden, besonders solche, die mit dem Presentation Manager und der Workplace Shell zu tun haben.
OS/2-Profile sind als Gruppe von Wertepaaren organisiert, die nach den Anwendungen gruppiert sind. Der Name der Anwendung und die Schlüssel sind immer nicht terminierte Zeichenketten (nul terminated strings). Die Werte können frei wählbare Binärdaten sein; in manchen Fällen sind sie aber auch nicht terminierte Zeichenketten. Besonders das Profil "System" enthält die Anwendung "PM_Objects", die den Schlüssel "ClassTable" enthält, dessen Werte eine Tabelle sind, die das Verhalten der "Workplace Shell" mit den dazugeörigen DLLs registriert.
Da der Inhalt der Profile weiterbestehen muß, wenn das System nicht läuft, wird er in Dateien gespeichert. OS/2 speichert die Profile in Dateien mit der Endung INI. Sie sind in einem standardisiertem Binärformat organisiert, das weiter unten beschrieben wird.
Die Ini-Dateien von OS/2 sind die Dateien, in den das Betriebssystem die Profile "System" und "User" speichert, wenn der Rechner heruntergefahren wird. Namen und Speicherort der beiden Standard-Ini-Dateien werden in den Umgebungsvariablen "SYSTEM_INI" und "USER_INI", die in der Datei CONFIG.SYS gesetzt werden, festgelegt. Normalerweise sind das b:\OS2\OS2SYS.INI bzw. b:\OS2\OS2.INI, wobei b: das Systemlaufwerk ist.
Neben dem Betriebssystem selbst speichern verschiedene, zusammen mit OS/2 vertriebene Anwendungen, wie EPM oder PMSEEK, aber auch einige Anwendungen von Dritt-Herstellern, wie PMView oder Mozilla, Informationen zur Konfiguration in den Standardprofilen.
Verschiedene Systemkomponenten und auch Software von Dritt-Herstellern verwenden für das Speichern der Konfigurationsdaten andere Dateien (als die Standardprofile), die aber das gleiche Format und auch die Endung INI haben. So speichert z.B. der OS/2-Dialer DOIP seine Konfiguration in der Datei b:\MPTN\ETC\TCPOS2.INI. Ähnlich verhält sich WarpIN, das seine Konfiguration und seine Datenbank der installierten Software in der Datei "DATBAS_D.INI" im gleichen Verzeichnis wie WARPIN.EXE speichert; zudem speichert WarpIN den Pfad zu diesem Verzeichnis im Profil "User" unter "application" WarpIN und "key" Path.
Um die maximale Verwirrung perfekt zu machen, speichern manche Anwendungen, wie z.B. Papyrus die Informationen zur Konfiguration in Binärdateien mit der Endung .INI, die aber nicht das Standard-OS/2-Format haben. Außerdem verwenden einige Teile von OS/2 selbst Textdateien mit der Endung .INI, wie z.B. DIVE.INI und MMPM2.INI.
Die Folgenden Informationen zum Format stammen aus Untersuchungen und Experimenten mit Kopien verschiedener aktueller Ini-Dateien von OS/2 und verschiedener anderer, für diesen Zweck erstellter Ini-Dateien. Es gibt eine Reihe von offensichtlich ungenutzten Feldern. Es ist möglich, daß einige dieser Felder für Zwecke benutzt werden, die während der Untersuchungen nicht entdeckt wurden. Alle Offset-Angaben sind in Bytes vom Dateianfang gerechnet. Alle Offset-Werte und Längen sind "unsigned integers" (Ganzzahlen ohne Vorzeichen).
Datei-Deskriptor / File descriptor (Beginn: offset 0):
32 bit integer Signature? FFFFFFFF 32 bit integer Offset of first app 00000014 32 bit integer File size ssssssss 32 bit integer Unused? 00000000 32 bit integer Unused? 00000000
Anwendungs-Deskriptor/Application descriptor
32 bit integer Next app aaaaaaaa 32 bit integer First pair pppppppp 32 bit integer Unused? 00000000 16 bit integer Name length mmmm 16 bit integer Name length mmmm 32 bit integer Offset of name nnnnnnnn mmmm bytes App name Name followed by nul
Paar-Deskriptor/Pair descriptor
32 bit integer Next pair pppppppp 32 bit integer Unused? 00000000 16 bit integer Key length llll 16 bit integer Key length llll 32 bit integer Offset of key kkkkkkkk 16 bit integer Value length uuuu 16 bit integer Value length uuuu 32 bit integer Offset of value vvvvvvvv llll bytes Key Key followed by nul uuuu bytes Value Value
Das Design ist erheblich redundant. In allen untersuchten Beispielen folgt auf den ersten Anwendungs-Deskriptor unmittelbar der Datei-Deskriptor, jedem Anwendungsnamen folgt sofort der korrespondierende Anwendungs-Deskriptor, jeder Anwendungspaarliste folgt gleich der Anwendungsname und jedem Paar aus Schlüssel und Wert folgt sofort sein Deskriptor. Daher werden die Offset-Felder eigentlich nicht wirklich gebraucht. Genauso sind die Längen der Namens-, Schlüssel- und Wertefelder ohne ersichtlichen Grund zweimal gespeichert.
Werte können, müssen aber nicht mit Null (zero hex value, z.B. 0x00.) terminieren. Die Namens- und Schlüsselfelder müssen eine terminierende Null haben. In alle Fällen, mit Ausnahme einer speziellen Situation, enthält die Länge die terminierende Null, wenn eine vorhanden ist. Die Ausnahme ist, wenn ein Anwendungsname oder -wert mit einer Größe von mehr als 65535 Bytes gespeichert wird. In diesem Fall wird der gesamte Name oder Wert in die Datei kopiert, aber die Felder mmmm oder uuuu werden auf die äußerst rechten 16 Bits der aktuellen Länge gesetzt. Abhängig davon, welche Änderungen danach gemacht werden, können die nicht wiederauffindbaren Bytes eleminiert werden. Der Versuch, einen Schlüssel größer als 65335 Bytes einzugeben, hängt das System auf.
Der Wert 00000000 wird benutzt, um eine Anwendungsliste und jede Anwendungspaarliste zu terminieren.
Das Wertefeld wird immer mit einer Länge von uuuu Bytes angenommen, selbst wenn mehr Byte gespeichert werden. Fügt man auf der anderen Seite mit einem Hex-Editor eine Null vor dem mmmm-ten Byte eines Namensfeldes oder dem llll-ten Byte eines Schlüsselfeldes ein, terminiert diese Null den Namen oder Schlüssel, das Längenfeld wird entsprechend angepaßt und die zusätzlichen Byte werden gelöscht, wenn die Datei das nächste Mal geschrieben wird.
Die API-Aufrufe führen nicht zu weiteren Restriktionen der Inhalte der Namens- und Schlüsselfelder, außer das die Verwendung von ASCII-Werten zwischen 1 und 31 einschließlich oder größer als 127 in diesen Felder eine Herausforderung in bestimmten Situationen, besonders beim Export oder Import, darstellen können.
Informationen über den "Typ" der Wertefelder werden nicht gespeichert. Die API-Aufrufe erlauben, daß Werte, als Zeichenketten oder Binärwerte gespeichert und als Zeichenkette, Binärwert oder als 32-Bit-Integer abgefragt werden.
Manche OS/2-Anwender verwenden 16-Bit-Windows-Anwendungen unter Win-OS/2 oder 32-Bit-Anwendungen unter Odin oder Open32. Entsprechend enthält OS/2 die Datei b:\os2\mdos\winos2\reg.dat, eine Registry-Datei für Windows 3.1, und b:\os2\system\system.dat sowie b:\os2\system\user.dat, eine Registry-Datei für Windows 95/98.
Da das Format der verschiedenen Windows-Registries unter www.wotsit.org abrufbar ist, werde ich hier nicht darauf eingehen.
Wie dem auch sei, es ist jetzt angebracht, einige qualitative Unterschiede zwischen den Herangehensweisen an die Verwaltung der Registries von OS/2 und Windows aufzuführen.
Der am meisten offensichtliche Unterschied ist, daß die Windows-Registry ein Wald ist, der eine Liste von Schlüssel-Wert-Paare an jedem Knoten ("node") haben kann, während ein OS/2-Profil eine Liste der Listen von Schlüssel-Wert-Paaren ist.
Ein anderer Unterschied ist, daß zu jedem gespeicherten Wert in der Windows-Registry der Typ (Zeichenkette, Binärwert oder Doppelwort) gespeichert wird, während die Werte im OS/2-Profil im Wesentlichen ohne Typ sind.
Auch wird das Format der Windows-Registry alle paar Versionen geändert, dagegen ist die Struktur der OS/2-Profile noch immer so wie bei der Einführung. Die letzte Windows-Version, verwendet unter Windows NT und 2000, wird nicht von OS/2 unterstützt, was dazu führt, daß Programme, die die zusätzlichen Datentypen in der Registry von Windows NT oder 2000 erwarten, unter Odin vermutlich Schwierigkeiten machen.
Die Dateistruktur, die verwendet wird, um verschiedenen Versionen der Windows-Registries zu speichern, ist denkbar komplexer als die für das Speichern der OS/2-Profile. Besonders, da alle Windows-Formate verschiedene Blocktypen innerhalb der Datei verwenden, um die Verbindung zwischen Informationen, die Strukturen abbilden, von den Namen und Werten zu trennen.
Werden Einträge aus einem OS/2-Profil gelöscht, verschwinden die entsprechenden Einträge aus der Ini-Datei. Werden Einträge in der Windows-Registry gelöscht, werden die Einträge von der Datenstruktur entkoppelt, verbleiben aber in der entsprechenden Ini-Datei, bis der Speicherplatz wiederverwendet wird.
Ein Problem, das OS/2-Profile und Windows-Registry gemeinsam haben, ist, daß sowohl Betriebssystem als auch Anwendungen manchmal nicht mehr benötigte Einträge einfach aufgeben, statt sie zu löschen. Im Laufe der Zeit sammeln sich die nutzlosen Eintragungen an, verschwenden Platz auf der Festplatte und im Arbeitsspeicher genauso wie Rechenzeit, die für die Verarbeitung (Abfrage oder Bearbeitung) der umfangreicheren Dateien benötigt wird.
Progamme wie "checkini" oder "cleanini" analysieren die Ini-Dateien und löschen diese nutzlosen Einträge. Ein entsprechendes Programm gibt es auch für Windows.
Die Manipulation von Profilen ist möglich durch die Anwendung der entsprechenden API-Funktionen, egal ob standard- oder anwendungsspezifisch. Die Funktionen sind detailliert im "Presentation Manager Programming Guide and Reference" in der Dokumentation zum "Toolkit" beschrieben.
Es folgt eine kurze Übersicht über diese API-Aufrufe. Eine ins Detail gehende Erörterung würden den Rahmen dieses Artikel sprengen.
PrfCloseProfile PrfOpenProfile
Das abzufragende oder zu aktualisierende Profil wird über einen "handle" identifiziert, der beim Öffnen des Profils angelegt wird. PMSHELL hat immer die Profile "System" und "User" geöffnet. Will eine Anwendung diese Profile abfragen oder modifizieren, muß sie sie selbst öffnen. Nach der Bearbeitung des Profils muß der "handle" geschlossen werden. Während ein Profil geöffnet ist, wird sein Inhalt in einer internen Datenstruktur gehalten.
Wird ein API-Aufruf verwendet, um einen Wert zu ändern oder einen neuen hinzuzufügen, ist die Änderung beim nächsten Zugriff sofort sichtbar, selbst wenn die dazugehörige Ini-Datei noch nicht geändert wurde. Ungefähr alle fünf Minuten schreibt das Betriebssystem den aktuellen Status jedes geöffneten Profils in die entsprechende Ini-Datei.
PrfQueryProfile PrfReset
Bestimmte Anwendungen, wie zum Beispiel Anmelde- oder Abmelde-Programme müssen evtl. die Ini-Dateien verändern, die von den Profilen "System" und "User" verwendet werden.
PrfQueryProfile beschafft die Namen der Profile "System" und
"User", die gerade aktiv sind.
PrfResetProfile wechselt zu neuen Profilen und benachrichtigt alle offenen
Programme von diesem Wechsel. Anwendungen müssen darauf reagieren, indem sie
die neuen Profile abfragen und ihre Konfiguration entsprechend ändern.
PrfWriteProfileData PrfWriteProfileString
Werte können für eine Anwendung und einen Schlüssel in einem Profil können entweder als zusätzlicher Binärwert oder als terminierender Null (asciiz) -String geschrieben werden. Existieren die Einträge bereits, werden die alten Werte durch die neuen ersetzt. Daten von beliebiger Länge können geschrieben werden, aber es gibt keinen Mechanismus, um mehr als 65335 Bytes abzufragen.
In Wirklichkeit ist die Gesamtanzahl der geschriebenen Bytes (einschl. der terminierenden Null bei PrfWriteProfileString) n, alle n Bytes werden in der Ini-Datei gespeichert, aber die gespeicherte Länge, die die Anzahl der Bytes, die abgefragt werden können, bestimmt, ist mod(n,65536).
Durch die Verwendung geeigneter Kombinationen von Null-Anwendungen,
Schlüsseln und Wertezeigern zusammen mit der Länge Null, kann die Funktion
PrfWriteProfileData dazu benutzt werden, Schlüssel einer Anwendung oder die
gesamte Anwendung zu löschen, sogar um das komplette Profil zu leeren.
PrfQueryProfileSize
Da die abzufragenden Werte bis zu 65535 Bytes lang sein können, ist es sinnvoll, vor der Abfrage des Wertes herauszufinden, wieviel Speicherplatz (buffer space) benötigt wird.
PrfQueryProfileData PrfQueryProfileString
Diese Funktion kann entweder dazu benutzt werden, den Wert für eine spezifische Anwendung und den Schlüssel abzufragen oder eine Liste aller Schlüssel für einen Anwendung zu erhalten (indem ein Nullschlüssel bereitgestellt wird) oder eine Liste aller Anwendungen (indem eine Nullanwendung bereitgestellt wird).
Bei einer Werteabfrage sendet PrfQueryProfileString uuuu Bytes in den
Speicherpuffer,
mit uuuu als Länge des im Profile gespeicherten Wertes, selbst wenn einige
Werte Null sind, vorausgesetzt die Größe des Speicherpuffers ist größer als
uuuu. Ist die Puffergröße l kleiner gleich uuuu, sendet PrfQueryProfileString
l-1 Bytes, gefolgt von Null.
Trotz ihres Namens garantiert die Funktion PrfQueryProfileString nicht, daß
der zurückgegebene Wert eine nullterminierte Zeichenkette ist.
PrfQueryProfileInt
Wenn der Wert eine bestimmten Anwendung und der Schlüssel eine nullterminierte Zeichenkette sind, die ein Integer (integer in character form) enthält, kann der Wert auch als 32-Bit-Integer abgefragt werden.
Ist der Wert nicht in der oben angegebenen Form, wird 0 zurückgegeben.
Anwender können Profile auch mit REXX über die Funktion SysIni
bearbeiten.
Diese Funktion kann dazu benutzt werden, jede mögliche Funktion der API zu durch passende Angabe von Parametern zu nutzen. Eine vollständige Beschreibung finden Sie in der Online-Dokumentation zu REXX.
Eigentlich war meine erste Erfahrung beim Manipulieren von Ini-Dateien der Einsatz von REXX, um APL-Tastatur-Anpassungen von einem System zum anderen zu transferieren. APL2 ist ein extrem anpassungsfähiges Tastaturkonfigurationsschema von IBM; allerdings ist das Erstellen eines kompletten Layouts eine ermüdender und zeitraubender Prozeß.
Ted Edwards und ich haben in den frühen 90ern ein Tastatur-Layout für APL2 für DOS entwickelt, das folgende Charakteristiken aufwies:
In der DOS-Implementierung von APL2 sind die Tastaturlayout-Informationen direkt für ein laufendes APL-Programm verfügbar, daher ist der Transfer einer Anpassung von einem System auf das andere kein Problem. In der OS/2-Implementierung werden die Spezifikationen für alle vom System oder vom Benutzer definierten Tastaturlayouts im Profil "User" gespeichert und APL2 verfügt nicht über einen direkten Zugriff auf die API-Funktionen des Profils.
1998 habe ich mein APL2 einige Monate vor Ted von DOS auf OS/2 umgestellt und als er Upgraden wollte, war das Problem, die Anpassungen, die ich sorgfältig erstellt hatte, von meinem System auf seins zu transferieren, ohne sie von Hand einzugeben. Das folgende REXX-Programm, mergeapp.cmd, war ursprünglich zur Lösung dieses Problems geschrieben worden und hat sich seitdem weiterentwickelt.
/* JJW 19990927 -- mergeapp.cmd */
/* Merge or copy one or ALL: applications from one ini file to another */
/* (c) 1999, James J. Weinkam, All rights reserved. */
call RxFuncAdd 'SysIni','RexxUtil','SysIni'
parse arg APP','FROM','TO','COPY
TO=strip(TO); COPY=','||strip(COPY);
if APP='ALL:'
then do
if 'ERROR'=SysIni(FROM,'ALL:','app.')
then do
say 'Error reading ini file' FROM
exit
end
end
else do
app.0=1
app.1=APP
end
do j=1 to app.0
if 'ERROR'=SysIni(FROM,app.j,'ALL:','ky.')
then say app.j 'not found in' FROM
else do
if pos(COPY,',,COPY,copy,Copy')>1
then call SysIni TO,app.j,'DELETE:'
do i=1 to ky.0
call SysIni TO,app.j,ky.i,SysIni(FROM,app.j,ky.i)
end
end
end
exit
Das folgende Script, saveapl.cmd, wurde dazu verwendet, die Anpassungen aus den Ini-Dateien meines Systems zu extrahieren:
call mergeapp APL2 KEYBOARD,%1:\os2\os2.ini,%2 call mergeapp APL2 SESSION MANAGER,%1:\os2\os2.ini,%2 call mergeapp APL2 OBJECT,%1:\os2\os2.ini,%2
Dies wurde duch das Kommando saveapl d a:\saveapl.ini ausgeführt.
Die Installation der Anpassungen auf dem anderen System war noch einfacher:
mergeapp ALL:,a:\saveapl.ini,d:\os2\os2.ini,copy
REGEDIT2 ist ein PM-Programm, welches mit OS/2 mitgeliefert wird. Es kann beliebige OS/2-Ini-Dateien anzeigen und bearbeiten, solange diese im Standardformat vorliegen. Die Standard-Ini-Dateien von OS/2 werden identifiziert als HINI_SYSTEM_PROFILE und HINI_USER_PROFILE, andere geöffnete Ini-Dateien über ihren Namen.
REGEDIT2 kann auch dazu verwendet werden, 32-Bit-Windows-Registry-Dateien anzuzeigen und/oder 32-Bit-Windows-Registry-Dateien, die mit OS/2 mitgeliefert werden, um Windows-Programme laufenzulassen, anzuzeigen. Diese Dateien sind b:\os2\system\system.dat und b:\os2\system\user.dat.
Ungleich den OS/2-Profilen mit zwei Ebenen (Anwendung und Schlüsselwert), sind die Windows-Registry-Dateien von einer Baumstruktur mit beliebiger Tiefe.
Die Windows-Registry-Dateien heißen HKEY_LOCAL_MACHINE und HKEY_USERS; REGEDIT2 kann beliebige .dat-Dateien, mit der Windows-Struktur, nicht öffnen.
Zusätzlich zeigt REGEDIT2 die Kennungen HKEY_CLASSES_ROOT, Bezeichnung für HKEY_LOCAL_MACHINE\SOFTWARE\Classes und HKEY_CURRENT_USER, Bezeichnung für HKEY_USERS\.default an.
Das Fenster von REGEDIT2 kann über den Menüpunkt Vertikal teilen im Menü Anzeigen in zwei Teile aufgeteilt werden, die horizontal oder vertikal angeordnet werden können. Beim Start von REGEDIT2 werden die Standard-Ini-Dateien in einem Teil des Fensters angezeigt. Über den Menüpunkt Profil öffnen im Menü Datei kann man aber jegliche Ini-Datei einlesen. Durch Klicken auf eine verfügbare Ini-Datei werden die Anwendungen als Ordner dargestellt. Durch Klicken auf einen Ordner werden die dazugeörigen Schlüssel-Werte-Paare im anderen Teil des Fenster angezeigt.
REGEDIT2 klassifiziert jeden Wert in einem OS/2-Profil als String, Dword oder Binärwert. Wenn das letzte Byte eines Wertes Null ist und alle anderen Bytes zwischen ASCII 32 und ASCII 127 (einschl.) liegen, wird der Wert als String angesehen. Ist dem nicht so und ist der Wert 4 Bytes lang, wird er als Dword angesehen. Andernfalls wird der Wert als Binärwert betrachtet.
Die Tatsache, daß REGEDIT2 und nicht die API den Typ festlegt, kann durch eine Reihe von Experimenten mit REGEDIT2 und einem Hex-Editor demonstriert werden.
Um zum vermeiden, daß die aktuelle Ini-Dateien beschädigt werden, öffnen Sie besser eine Test-Ini-Datei. Wählen Sie eine Anwendung und öffnen Sie diese. Ergänzen Sie eine Zeichenkette mit beliebigen Namen und geben Sie als Wert "ABC" ein. Die Zeichenkette wird nun als Typ Zeichenkette angezeigt.
Ändern Sie jetzt den Wert. Löschen Sie das C und geben Sie den ASCII-Wert 01 über das Nummernfeld ein. Halten Sie dabei die ALT-Taste gedrückt. Schließen Sie die Anwendung und öffnen Sie sie wieder. Die neue Zeichenkette ist jetzt vom Typ Dword.
Ändern Sie den Wert von 01 auf 43. Schließen Sie die Anwendung und öffnen Sie sie wieder. Der Wert ist nun wieder vom Typ Zeichenkette.
Ändern Sie den Wert ein weiteres Mal, diesmal setzten Sie den ASCII-Wert 01 zwischen A und B. Schließen Sie die Anwendung und öffnen Sie sie wieder. Jetzt wird der Typ als Binärwert angegeben und die terminierende Null ist Teil des Wertes.
Verwenden Sie außerhalb von REGEDIT2 einen Hex-Editor um ein Zeichen in einer Zeichenkette auf einen Wert zwischen 32 und 127 (einschl.) zu setzen. Starten Sie REGEDIT2 und öffnen Sie die Ini-Datei. Öffnen Sie die entsprechende Anwendung. Sie werden feststellen, daß die Zeichenkette nun vom Typ Dword oder Binärwert ist, abhängig ob die Länge des Wertes vier ist.
Diese Experimente zeigen, daß der "Typ", wie von REGEDIT2 angezeigt, nicht eine Eigenschaft des Schlüssel ist, sondern von REGEDIT2 zugeordnet wird, indem der Wert selbst analysiert wird.
Mehr noch, REGEDIT2 hat eine engere Definition der Zeichenkette als die API. Nichtsdestotrotz erlaubt es, daß in eine Zeichenkette Zeichen eingefügt werden, die es nicht als gültige Zeichen ansieht, wobei diese Zeichen nach Dword oder Binärwert konvertiert werden. REGEDIT2 bemerkt diese Änderungen nicht, solange die Anwendung geschlossen und wieder geöffnet wird.
REGEDIT2 sollte eigentlich auch die Fähigkeit haben, ganze Ini-Dateien oder ausgewählte Anwendungen zu im- und exportieren. Leider ist dies nur in einfachen Spezialfällen möglich. Wie es aussieht, ist dafür ein größeres Re-Design notwendig. Glücklicherweise decken die einfachen Spezialfälle die vielen, wenn nicht sogar die meisten, Situationen ab, die vorkommen können.
REGEDIT4 [file] [file\application1] key1=value1 ... keyn=valuen ...
wobei:
Zeichenkette und Binärwert (Hex) können über beliebig viele Zeilen verteilt sein, wobei alle Zeilen außer der letzten mit \ terminieren müssen.
Beispiel für eine exportierte Datei
REGEDIT4 ["E:\PLI\TESTINI.INI"] ["E:\PLI\TESTINI.INI"\App One] String1="ABC" String2="12564" Binary=hex:32,33,34,35,36,37,38 Dword=dword:675bcd15 Long String="Eine richtige lange Zeichenkette, die mehr als zwei Zeilen m Export-Format"\ " benötigt. Um das zu erreichen, folgt hier noch ein wenig mehr Text, damit die"\ "nötoge Anzahl von Zeichen zusammenkommt." Long Binary=hex:01,02,03,04,05,06,07,08,09,0a,0b,0c,0d,0e,0f,10,11,12,13,14,15,\ 16,17,18,19,1a,1b,1c,1d,1e,1f,20,21,22,23,24,25,26,27,28,29,2a,2b,2c,2d,2e,2f,\ 30,31,32,33,34,35,36,37,38,39,3a,3b,3c,3d,3e,3f,40,41,42,43,44,45,46,47,48,49,\ 4a,4b,4c,4d,4e,4f,50
Mit der API-Funktion PrfQueryProfileInt werden die Werte von
String1, String2, Binärwert und Dword als 0, 12564, 0 und 0 ermittelt.
REGEDIT2 kann auch aus der Windows-Registry exportieren bzw. importieren.
Hierzu muß file durch einen der Schlüssel HKEY_CLASSES_ROOT, HKEY_CURRENT_USER,
HKEY_LOCAL_MACHINE oder HKEY_USERS ersetzt werden und die
Zeilen [file\application] durch Zeilen in folgendem Format:
[file\folder1] [file\folder1\folder2] [file\folder1\folder2\...\foldern]
Ordnern mit Schlüssel-Wert-Paaren folgen sofort Listen derselben. Der spezielle Schlüssel @ wird dazu verwendet, um einen Standardwert zu spezifizieren.
Der Export funktioniert korrekt mit den Eingeschränkungen durch das Format.
Frühe Versionen von REGEDIT2 importieren nur richtig, wenn nur eine Anwendung zu importieren ist; es gibt keine Problem mit bestimmten Zeichen in den Schlüsseln oder Zeichenketten. Binärwerte oder Zeichenketten können nicht über mehr als eine Zeile verteilt werden.
Folgende Zeichen bereiten in Schlüsseln Schwierigkeiten: =, ", CR und LF und vermutlich noch andere. In Zeichenketten ist der Übeltäter das Zeichen ".
Erscheint die Kombination =" im Schlüssel eines Zeichenkettenpaares, wird sie mit dem Zeichen = verwechselt, welches die Schlüssel von den Werten trennt und dem Zeichen ", das die Werte abgrenzt.
Gleichfalls macht das Zeichen quot; Schwierigkeiten in Werten von Zeichenketten, da keine Verdoppelung oder Escape-Mechanismus verwendet wird.
Ist ein Binärwert oder der Wert einer Zeichenkette mehr als eine Zeile lang, ersetzt REGEDIT2 die Zeichen n \ durch zufälligen Werte und löscht die letzten n Bytes anstatt die Zeichen n \ einfach zu löschen. Daher ist zwar die Länge richtig, aber die Daten sind defekt.
Die Version von REGEDIT2, die zusammen mit dem letzten Convenience Pack (MCP2) und/oder dem Convenience Pack Fixpack (XR_C004) ausgeliefert wird, importiert Zeichenketten und Binärwerte, die sich über mehr als eine Zeile verteilen, korrekt, ist aber immer noch nicht in der Lage, problematische Zeichen in Schlüsseln zu behandeln. Sie kann auch mehr als eine Anwendung aus der gleichen Ini-Datei importieren. Ich weiß nicht genau, wann dieser Fix zuerst eingeführt wurde.
REGEDIT2 scheint die API-Funktionen für das Update eines Profils korrekt anzuwenden, kommt aber gelegentlich nach einer Reihe von Änderungen mit der Bildschirmanzeige durcheinander. Dies Lösung für dieses Problem ist, entweder über das Menü Anzeigen den Menüpunkt Aktualisieren (Strg-K) aufzurufen oder das Programm zu beenden und neu zu starten.
Artikelverzeichnis
editor@os2voice.org
< Vorherige Seite | Inhaltsverzeichnis | Nächste Seite >
VOICE-Homepage: http://de.os2voice.org