VOICE Home Page: http://www.os2voice.org
[Newsletter Index]
[Previous Page] [Next Page]
[Feature Index]
|
VOICE Home Page: http://www.os2voice.org |
December 2001
[Newsletter Index]
|
| By Herwig Bauernfeind © December 2001, Translation: Philhard Ackermann |
In principle the registry is a data base which is used to store information about
a PC's hardware, operating system and applications.
Windows' registry basically offers many more possibilities than the .INI files
OS/2 uses. That's the reason why IBM decided to provide OS/2 with a registry when
they introduced the Open32 (aka DAX) API (though the OS/2 registry is used by the
Open32 interface only, OS/2 itself keeps storing its settings in OS2.INI and OS2SYS.INI).
Today Odin is based on Open32 (aka DAX), because in many respects Odin has grown
to something Open32 had in fact been intended to be.
Thus the OS/2 registry is exclusively used by Open32 based OS/2-programs. Besides
Odin the only relevant ones that come to my mind are Lotus SmartSuite, Acrobat
Reader 3 for OS/2, the Opera 5.1x-beta and Mozilla in all of its variants.
So windows programs now running on OS/2 with Odin believe the platform to be
Windows (NT 4.0 or Windows 98) and therefore they all (potentially) use the OS/2
registry.
As on windows the OS/2 registry files are SYSTEM.DAT and USER.DAT
in the x:\OS2\SYSTEM directory and BOOT.DAT and REGISTRY.DAT
in the root directory of the boot drive.
What follows is a detailed description of my approach to get around this problem.
In doing this I usually try to stick to the utilities the two systems provide by
default (and besides that I use what I described in my first
article).
First I boot up Windows, then start regedit.exe and export the whole
registry to a text file. Note that the Windows 2000 / Windows XP registry editor
produces a unicode file (16 bit characters) by default, something neither older
Windows versions nor Odin can deal with. It is possible to make the W2K/XP regedit
create regular (8-bit) files. Alas, because of my lack of experience with these
systems, I can't tell how this can be achieved.
After that I install the desired program package on windows. Then, before it
gets started for the first time (but after the usual reboot) I start regedit.exe
once again and export the whole registry to a text file (with some other name).
At that point the differences between the two files reflect exactly the changes
the installation process introduced to the windows registry.
Now I build a valid .REG file out of these differences. This might be a lengthy
process at present, because I only use PMDiff, which shows both files in separate
windows, the text mode version of HyperView (very handy to copy lines to the clipboard)
and some editor (eg. E.EXE or EPM.EXE).
The basic format of a .REG file is not too complicated, even for a newbie (at
least on the surface). In any case it's not too hard to build a valid .REG file
(it somehow reminds me of playing with LEGO bricks - you get a quick image of a
given structure without exactly knowing how it is composed). Here's an example (out
of the ODBC registry entries, my current 'playground'):
As you can see a .REG file starts with the string REGEDIT4, after which there are the names of the registry keys in square brackets followed by value expressions in seperate lines of the format "name"=type:value oder "name"="value". There are also value expressions like the one below, where only an @ sign can be found left of the equal sign:
Now you'll have to compose a valid .REG file out of all those new or changed registry snippets, and, especially when dealing with some larger program packets, this can be a quite exhausting and lengthy process.
After you have put all the snippets together you shouldn't forget to adjust paths
and directory names to suit your needs (something I already did in the first example),
because as you can see the registry also contains links to files an programs, and
if the program package is to work properly all those links must be customized so
that the program is also able to find all its components when started with Odin.
The whole process also provides valuable hints to which files the program has
put into C:\Windows and C:\Windows\System or which files it expects
to find there.
Hint: It is not a good idea to let those links point to the original locations
in case your original windows partition should be accessible from OS/2 (eg. by using
Henk Kelders FAT32.IFS) just to save some harddisk space, because some programs
store configuration files inside their home directories and this almost certainly
means that the original windows installation and the Odin based one mess each other
up.
So be sure to always copy the respective files to x:\Odin or x:\Odin\System32
and adjust the registry links accordingly!
Now that you've completed your .REG file and adjusted everything fine you'll
only have to import it into the OS/2-Odin Registry. Here comes another obstacle:
You should never use OS/2's Regedit2.EXE to import such a .REG file, always
use a windows Win32 registry editor instead!
The file format of the .REG files OS/2's Regedit2.EXE reads and writes
is almost the same as the one the windows registry editor uses. Well, almost -
but not exactly, and those minor differences will render any import process completely
useless! And, by the way, the windows registry editor can be flawlessly used with
Odin.
There is no danger in a test run, because if the .REG file is not valid in any
respect the registry editor simply refuses to import it. In that case you'll have
to search your .REG file for errors. It might be useful to split up your .REG file
into several smaller ones in that case and import them separately. Of course, each
and every one of them will have to start with a line containing REGEDIT4!
Another hint: If you find something about aThreadingmodel inside
your newly composed .REG file and the value is anything other than Appartment
you can simply give up here, because Odin is only capable of Appartment and
so the program will most likely refuse to work!
It's worth a try, by all means; you only have to take care that the copy operation
is really complete (which, again, leads to the manual installation scheme mentioned
in the first two articles), and you'll still have to customize the registry.
The most familiar 'by-product' (yet not the only one), that has even become a
part of the weekly Odin builds is OdinBug (the Odin bug report generator) which
should be public knowledge already.
In addition I will provide current versions of all links and references, because
some of those mentioned in my first article have already become invalid. If you
should have difficulties to find some of these utilities in the mean time, contact
me - I'm always ready to help you out!
References:
|
[Feature Index]
editor@os2voice.org
[Previous Page] [Newsletter Index] [Next Page]
VOICE Home Page: http://www.os2voice.org