[omniORB] Win32 Installer version for VC++ MS6, MS7, MS8

[Dietmar May]

Hi Duncan,
> It's a pretty enormous file. Would it be hard for you to split into
> separate installers for the different VC++ versions?
Finally done - separate installers for MSVC 6, 7.1, and 8.0. Plus, a 
full installer for all 3 compiler versions. All installer packages are 
in self-extracting WinZIP archives for software distribution (the 
self-extractor will launch SETUP.EXE, so it's a one-button operation to 
kick off the install). Note that these files should replace the previous 
4.07 installer package.

Turns out that the DLLs for 7.1 and 8.0 didn't have usable debugging 
info; and I needed to be able to debug some code. So, I've modified the 
mk/platforms files for ms6, ms7 and ms8 to build .PDB debug info. (From 
the VC8 docs "It is not possible to create an .exe or .dll that contains 
debug information. Debug information is always placed in a .pdb file").

While I was in there, the compiler flags that were in win32.mk have been 
copied to platform/_ms6.mk (which is now renamed to be consistent with 
_ms7 and _ms8.mk). win32.mk still has compiler flags; but these are only 
used if not defined by the including makefile (presumably for Win95 and 
NT 3.5 builds).

PDBs are created for both debug and release versions; these are handled 
as a separate installer selection. PDBs are installed into the 
windows/system32 directory, along with the DLLs. COS files (DLLs, LIBs, 
and PDBs) are no longer separate, but are included with the program 
files, development files, and debug files selections of the installer. 
The default for each compiler is to install all files, including source 
code.

omninames.exe appears to be created using runtime library (.DLL) 
imports, rather than static link libraries; and the one included with 
the installer is the MSVC++ 6.0 version. Therefore, the MSVC 7.1 and 8.0 
installers also install the omniORB407_ms6_rt.dll and 
omnithread32_ms6_rt.dll files. Because of this, when building for the 
installer (all compiler versions), MSVC 6.0 MUST BE THE LAST PROJECT 
BUILT, or the omninames.exe will reference a couple of missing DLLs in 
two of the three compiler installs. (Sorry, I found this too late to 
change it; and I'm out of time to invest on this right now). I'd suggest 
that, in the future, omninames.exe be built with static libraries 
instead, even though it would create a larger EXE file.

I've done a diff against the omniORB 4.07 tree, and have isolated the 
files that have been changed (no patches, just a copy of each updated 
file). Hopefully this will make it easier to merge into the code base 
for 4.10.

I haven't tested all of the permutations of all of the compiler 
versions. The MS6 and FULL versions have been most thoroughly tested 
(but I didn't do things like install only source code with no program 
files (DLLs) or dev tools (PDBs)); MS7 and MS8 had full installs plus 
perhaps a couple of other options tested. So far, everything looks OK.

The installs are built using the MS Visual C++ 6.0 Installshield special 
(free) edition; so anyone that owns VC98 should have a way to build the 
install packages. The install directory should be copied into the 
omniORB root directory (eg. c:/program files/omniORB4/install).

Note that Installshield scrambles the files pretty badly. Right now, (at 
least) the file groups  have been manually edited and files sorted, so 
that they can be more easily maintained. However, as soon as an 
Installshield script is compiled (and maybe if media is built) from 
within the Installshield IDE, some of the files get badly mangled. 
Therefore, I STRONGLY suggest that updates to these files be made using 
- argh! - a text editor in a clean directory; files should then be 
copied to the actual working directory. It's a nasty side effect of 
Installshield. Maybe they've updated their newer versions to be 
friendlier to the user's installer command files.

Two other notes on the installer. For some reason, it seems that opening 
the files from the Installshield icon view doesn't change the working 
directory; therefore, the file links (which are all relative - ie 
../bin/x86_win32, ../mk/platforms) reference missing files. The trick is 
to use the File / Open command from the menu; Installshield will warn 
about not being able to add the icon to its workspace, but the project 
will open properly. Also, Installshield doesn't warn about missing 
files: it just churns away merrily for a little while and reports 
success, even if some or all of the files were missing! Always check a 
few of the file groups to be sure that files have been found. There is 
also a log file generated in the Media/---/Log Files directory, which 
does actually contain a list of missing files - be sure to check this 
before releasing installer packages.

Finally, the gnuwin32 lite files from yesteryear probably should be 
updated. I have an Athlon X2 system; and kept getting random hangs and 
crashes while trying to build omniORB. I downloaded a copy of the latest 
Cygwin (as of a few days ago), and copied the corresponding files to 
create an updated gnu-lite. Everything worked so much better - not a 
single hang.

Files have been posted to upload.sourceforge.net. They are as follows:

gnuwin32-lite_060724.zip - copy of my updated gnu-lite files; from cygwin
omni_msX-diffs.zip - file tree of different MK files, to allow building 
packages with _msX naming
omni_msX-install.exe - self-extracting ZIP with installer config files 
(./install tree)
omniORB407_ms6.exe
omniORB407_ms7.exe
omniORB407_ms8.exe
omniORB407_ms-full.exe - installer self-extracting ZIPs, ready to post

Finally, there is a dead file omniORB407_msvc.exe that should be trashed 
- it's a leftover from an aborted ftp put.

A few of the filenames should probably be changed before posting them to 
the omniORB download pages.

That's it! Hope this is helpful. Please let me know if there are any 
questions.

Dietmar May