Ages ago, when I was working on the Toy Story Animated Story Book, we had to whip together an installer. We bought a version of InstallShield for Windows 3.1, and all was right with the world.
Okay, maybe not everything was right, I still had to write a stub program to deal with the autoplay stuff, and the uninstaller did a pretty lousy job so I ended up writing some extra stuff to get aggressive and leave less lying around, but it worked okay, and let us slap together an install relatively quickly, and when internationalization time came around we had few hassles changing it..
Recently I've had to learn InstallShield for the Windows Installer 1.1. I want to preface these comments with the observation that the InstallShield folks are probably extremely competent and most of these complaints are actually with the underlyng Microsoft infrastructure, so unless you're one of the people who worked on the latter, don't get too offended.
With that caveat: InstallShield for Windows Installer sucks.
Want to insert a dialog box? Well, open a new project, strip all but the control buttons and header image out export it, and import it. If you don't strip out the other stuff you risk having to deal with the gawdawful string editor, and overwriting string resources that you can't change the targets of, especially for controls that reference filenames and not strings.
Now you've got to put it in sequence with all the other dialog boxes. This is a doubly linked list on the behavior of the "Next" and "Previous" buttons, and be extra special careful on the off-chance that you've actually got conditional behavior, 'cause then you'll have to change this in multiple places.
Speaking of conditional behavior, you'd think that the conditions on the controls might have some sort of order of execution concept? Nope, if you want a control to go to one of several dialog boxes you have to specify boolean logic that precludes the behaviors you don't want, not just enables the behaviors you do. Woe to those who think "I've specified all my dialog behaviors, but now I just want a default so I'll give it a condition of "1"...
And, of course, the properties that you use to control behavior have different meanings depending on their case. Although they say that the properties only have to be upper case if you want them changeable for unattended installs, but beware, there are some weird-ass interactions between the install system and the scripting system if they're not all upper case.
Error messages have a number, often a number that doesn't show up in the documentation, in the Microsoft help system documentation (whose brilliant idea was it to split up those two documents in a seemingly arbitrary manner so that searching them involved two deifferent indices?), or even in the InstallShield online knowledge base. Often the only way to figure out what's going on is to insert an error, wait for an interminable full rebuild, and see if the cryptic message helps a bit. And who knows how you get the debugger to trigger, I've managed it a few times, but I've no idea how.
Make friends with the "Power Editor", you'll need to be able to manipulate many of these structures without the "help" of the IDE.
So, IDEs: If you're going to force me to use an IDE rather than my favorite editor, the IDE should enforce structure on me. It should help, rather than taking a million years to fill out a pull-down box and then letting me type whatever the hell I want in anyway. It should check my statements for syntax validity.
And if it's an IDE, it knows what bloody well changed, so a rebuild should be incremental, and not take so long that I can walk three blocks to the coffee shop, get myself a half-caff mocha, walk back, and catch the tail end of the build.
And the build should stop if there's a compile error in the script files.
(Nobody's got a clue about how it actually updates the files to be installed inside the build tree, that's a total mystery.)
Speaking of script files, how about that language: No arrays, so you're pretty much out o' luck if you want to do anything like, maybe, store tabular information that can be easily edited. Nope, but it in comments and build some editor macros to rebuild the code, and be very, very careful 'cause the IDE is gonna try to stomp all over the disk version.
Make damned sure that you close the project and copy the .ism file elsewhere occasionally, it has a tendency to randomly corrupt files. And the dialog editor crashing can be a real hoot, although all of the windows have gone away the processes are still running, so either reboot or use the task manager to close all the processes and pray that it saves your changes correctly.
I suppose that right now it's the only option, but if I have to do any more Windows Installer stuff ("Oh. Please. God. Nooooo!!!") I'm going to look at the underlying structures and see if I can write some Perl to automate the process.
Thursday, September 14th, 2000 danlyke@flutterby.com