SCOUG-Programming Mailing List Archives

<< Previous Message <<

Date:	Wed, 16 Jul 2003 23:59:39 PDT7
From:	"David LaRue" <Huey.DLL@GTE.Net >
Reply-To:	scoug-programming@scoug.com
To:	< "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject:	SCOUG-Programming: button challenged

Content Type: text/plain

Hi Peter,

On Wed, 16 Jul 2003 16:44:40 PDT7, Peter Skye wrote:

>David LaRue wrote:
>>
>> The OS/2 installer I've used most allowed for
>> versioning and the ability to back out an upgrade.
>
>Hmm. Which installer, David? Sounds like the programmer did some
>thinking.

Okay, I've dug through my archives and think I've found the one we were using
at MCI and IBM. It is labeled "Software Installer v1.3" and has an install
directory of .\IBB. My recollection is that it worked on OS/2, AS/400, and
quite possibly Windows 3.x, and perhaps a few other systems. I had used it on
OS/2 and AS/400.

You described 'packages' of files and how to install them. There wasn't a
pretty GUI front end like InstallShield has. It was all done with PKG (text)
files. I found it quite easy to use.

You could make self extracting installers, installers that read from files,
tapes, or mount points.

Depricated files were taken care of by adding a description of the file in
the target area and instead of specifying the new file contents from the
install package, a delete action was inserted. So if v1.3 went over v1.2 and
certain files changed location or were no longer needed, the installer could
take care of that.

I believe files were identified by name, size, and contents.

You could create an install with many packages in them. The top level
packages might be things like applications. There could be other dependancy
packages like support libraries. I believe this was the standard IBM OS/2
installer for several years. Then IBM went to that silly Web Installer and its
never seemed to work for me since.

Version control was handled by the install package. Since you also described
depricated components it knew all the files and where to get them. If it found
a previous version during an install it asked if you wanted to create a backup
of the current installed products. I think the backups were kept in
directories off of the main package directories. It could handle installing
over locked files. If it found newer versions of a package it asked what to do
- nothing, backup, install older version.

It seems to me this would be a very useful concept today, especially for the
nightmare of Windows DLL Hell (tm). I'm not sure why Microsoft never addressed
a proper install methodology.

I can dig out more details if you like. Now that I've found the installer
again, perhaps I can find some programs I installed with it. They have a
sample install package that appears to use all the features I've described. I
could send that to anyone interested or perhaps even compile up the sample
install package so we could see what it is like.

>- Peter

David

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 16 | July | 2003 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.