Virtual OS/2 International Consumer Education
VOICE Home Page:
December 2001

[Newsletter Index]
[Previous Page] [Next Page]
[Feature Index]

Manual installation of Win32-applications using Odin - Part 4

By Herwig Bauernfeind © December 2001, Translation: Philhard Ackermann

4. Registry issues - how do I find out what belongs into the registry?

As usual, an important note before we get started: I have no intention to pretend that I posess an extensive knowledge of windows and the internals of the registry. I have learned much by struggling with refractory programs running on Odin and by comparing registry entries from windows and Odin and drawing my conclusions.

At first, what is this registry anyway?

The windows registry is quite comparable to OS/2's x:\OS2\OS2.INI and x:\OS2\OS2SYS.INI, but as time (and windows versions) went by it has also taken on the role of windows' x:\CONFIG.SYS more and more.

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.

Which entries have to be put inside the registry and how do they get there?

As already mentioned in the last part of the series I do consider a manual installation without a native Windows system to be possible, but, especially when dealing with any larger program package, quite impracticable.

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'):





"MS Code Page Translator"="Installed"


"SQL Server"="Installed"
"Microsoft Access Driver (*.mdb)"="Installed"
"Microsoft Text Driver (*.txt; *.csv)"="Installed"
"Microsoft Excel Driver (*.xls)"="Installed"
"Microsoft dBase Driver (*.dbf)"="Installed"
"Microsoft Paradox Driver (*.db )"="Installed"
"Microsoft Visual FoxPro Driver"="Installed"
"Microsoft ODBC for Oracle"="Installed"
"Microsoft SQL Server"="Installed"

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!

Nothing works any more, the registry is messed up, what can I do now?

In case you've messed up the OS/2 registry you'll have to delete exactly the 4 files mentioned before (still after having made backup copies), reboot OS/2 (without shutting down the system, just CTRL-ALT-DEL), and when OS/2 comes up it will automagically create a new registry. Don't try to do anything with Odin at this point unless you've started OdinInst.EXE before because the new registry is quite basic and rudimentary and OdinInst.EXE creates and amends a lot of entries that are essential for commonly used windows programs.

Copying instead of installing, could this work at all?

If the "genuine" installation fails (for any of those reasons mentioned in the previous parts of this article series), could it then be possible to simply copy the directory tree of the original windows installation to OS/2-Odin to make it run?

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.

What's left?

In the next article, which will conclude the series, I'll cover some of the by-products of my involvement in the manual installation of windows programs for Odin and share some of my experiences that didn't yet fit into one of my former articles.

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! 

Finally, a personal matter: Though I am writing in German I still posess a good  knowledge of the English language (my French and Spanish have become a little bit 'rusty' as time went by). I appreciate any feedback, either German or English (French and Spanish are also possible, but that might make for some funny conversation...)


The Odin project on Netlabs -
Weekly Odin Builds -
Daily Odin Builds -
Mailing list for odin users at Yahoo! -

[Feature Index]
[Previous Page] [Newsletter Index] [Next Page]
VOICE Home Page: