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

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

Installation of Win32-applications using Odin - Part 2

By Herwig Bauernfeind © October 2001, Translation: Philhard Ackermann

As a modification of the agenda announced in the first issue of the sequel of articles concerning  »Manual installation of Win32 programs using Odin« for some special reason I would like to cover another topic today, one that has been recently discussed on the ondinusers forum, and which might be more important right now than manual unpacking and moving all the files to the right place (which I will cover next time).

Excursion: Self-expanding installation packages based on InstallShield, the problems they introduce and how these problems can be solved (mostly).

Many of these packages (eg. Adobe Acrobat Reader 4.0 and 5.0, InstallRite 2.5) are shipped as single 32-bit .EXE-files that can be started flawlessly using Odin, but which then generate an error message like the one below

or Odin's Could not execute ..., not a valid Win32 file, perhaps 16bit? or Failed to start W16 session or something similar, then terminate without further messages (but without generating an exception). In general these programs could be installed faultlessly, if we only knew what these packages do and why they fail.

Here's some explanation on the subject: These packages have been packed twice; first, there's a 32-bit routine which only unpacks the actual installation package to some directory within the system's directory for temporary files (the one the environment variable TEMP or TMP points to; let's simply call it the 'TEMP directory')

The problem is that it calls a program named SETUP.EXE in that directory afterwards (at least in all the packages I know of). The drawback: This routine is a 16 bit windows program that Odin can't execute, so we get some error message like the ones mentioned above. If you confirm that message the 32 bit routine deletes the newly created directory and everything that's inside.

Well, as many of us know there's a package out there containing the programs used in InstallShield installation packages, but as 32 bit versions: SETUP.EXE, SETUP.DLL and _ISDEL.EXE. There's an archive containing recent versions of these programs available in the files section of the odinusers forum at YahooGroups, and in my opinion the chances for a succesful installation have drastically increased with these newer versions.Now the best solution would be to somehow integrate these 32 bit routines into the InstallShield package. Unfortunately this is impossible for the average user (like me).

Here's the trick to still make it work: The starting point is the error message. At the moment it gets displayed the whole package has been neatly unpacked into the directory within the TEMP directory mentioned above.  Now you have to leave the error message on the screen and by no means confirm it. At the moment it's confirmed everything gets deleted at once and you'll have to start over from the beginning. The name of the directory that's generated inside the TEMP directory is rather cryptical (eg. pgf001~tmp) and doesn't allow any clue towards its contents. Normally you wouldn't see it at all because it gets deleted anyway after the installation process, regardless of its success.

You can't help inspecting your TEMP directory directly until you've found the directory containing the unpacked portion of the package (this always reminds of searching through a storage chamber - as long as it doesn't get cleared up regularly, it's a terrible mess). Same goes for the TEMP directory. Your best chance is to look after your directories' creation date and time. Usually the most recent one is the right place to go!

Now you should write down that directory's name and copy all of it's contents (including any subdirectories it might contain) to some secure spot on your disk. Making these files read-only isn't of much help as some of them will be open at that time and I even encountered some package which still managed to delete the whole bunch inspite of any read-only attributes I had set.

After having copied the packet you may confirm the error message and everything gets erased. Now you can restore the former contents from that secure spot to exactly the same directory they have been before.

Next you should replace SETUP.EXE, SETUP.DLL and ISDEL.EXE by their 32 bit versions and start SETUP.EXE. Bingo! Some installation routines now run flawlessly, resulting in an exemplary OS/2 installation of a Win32-program. Unfortunately the executability of the installation process doesn't reveal anything about the executability of the program itself.

Some times there are still other problems concerning these installation packages: A common misbehaviour in the Windows world is that some foolish installation packages surmise it to be necessary to replace parts of the operating system even without any versioning, just like that and, in most cases, absolutely unnecessarily. Especially some routines of the OLE subsystem are well known candidates for this behaviour. Unfortunately they also act like that on OS/2 and Odin and thus guarantee to render your nice Odin installation completely useless because ODIN's system dll's get replaced by some (possibly overaged) Windows versions.

Thus,  after an installation you should make sure that Odin still has its own files by reinstalling the latest Odin build. What's more: some installation packages already use those replaced dlls even while the installation is still running, which will of course lead to an exception (and a disrupted Odin installation!) at once.

I have tried to replace these new dlls with the Odin versions while the installation was in progress, but this requires nimble handwork and an OS/2 shell in the foreground. I've been successful this way at times, but it's a rather stressful experience and sometimes it took 2 or 3 attempts to make it work. Even read-only attributes don't work here because either the installation packages don't care, or if they do, they crash with an error message.

In addition the chances are good that programs which bring along parts of the operating system do not restrict themselves to the functions Odin provides,  and especially in the area of OLE, there aren't many implemented yet.

So much for that at this point. The part about manually putting all the files to their proper locations that was promised in the last article will be covered next time.


The Netlabs Odin Project -
Odin Weekly Builds -
Odin Daily Builds -
The Odin User mail list on Yahoo! -

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