VOICE Home Page: http://www.os2voice.org
[Newsletter Index]
[Previous Page] [Next Page]
[Feature Index]
|
VOICE Home Page: http://www.os2voice.org |
October 2001
[Newsletter Index]
|
| 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.
References:
|
[Feature Index]
editor@os2voice.org
[Previous Page] [Newsletter Index] [Next Page]
VOICE Home Page: http://www.os2voice.org