Lessons from history.

Winston Churchill (he remembered for his iconic bulldog and cigar the size of a forest log) summed up the state of software (although he did not know it then) when he quipped (to paraphrase): it is a riddle wrapped in a mystery inside an enigma. I remember attending a lecture back home in the dusty frontier town of Johannesburg, South Africa by the then chairman of Anglo American’s Gold and Uranium division, Clem Sunter. He, like Churchill (he did not know it then) summed up the state of software when he described it as taking the high road to success or the low road to failure. Neither of these great gentlemen was of course alluding to software but that’s of no consequence here. What they did say though, could represent the state-of-the-nation address about what software has become.

So what exactly has this to do with IA? First principles, that’s what. I am a recent convert to IA. Like many IA users I cut my teeth on that other product. The one thing I noticed was that when I danced to the merry tune of that product, each version seemed to complicate the dance steps and added more complex reels and jigs to the beat. Given that all I wanted to do was produce quality installation packages I sometimes found the complexity overwhelming. Yes, I do agree that you need a broad spectrum of features to make software more usable but at what cost? Microsoft no longer (to the best of my knowledge) herald that “we have added 1800 more features to our Word application.” Jolly good too. If someone told me that I had 1800 more things to use at my fingertips I’d feel a sort of obligation to learn many of them. Not because I need those features but possibly because without them I’d feel that I was not leveraging the best from the application. There’s the rub. When an application needs to be updated to keep pace with the other horses we have to draw a line between the thoroughbred and the dressage horse

I am as guilty as anyone when it comes to developing software that outlives its original purpose and design. So often I’ve added a riddle wrapped in a mystery inside an enigma all concealed as a new feature disguised as a bug. I have code I authored and am working on at this time that resembles an unfortunate cyclist’s bicycle inner tube – full of patches. How it manages to get me home each day is remarkable. Even moreso for our hapless users. When asked how the next release was progressing, I somewhat insensitively told the project manager “well, it compiles clean, so let’s go live and put it in production.” I sometimes wonder if that is not such a unique thought after all. I would never think of doing such a thing but in the endless cycle of effectively giving less that’s usable for more money, I think I, like the other company has reached that place where the original product has now become diluted. It’s still useful but less usable.

I know little about the birth pains of IA. What I do know is that it is not a hack of what went before it. They took a new look at what an installation package should do. It was designed from the perspective of first principles. It does not resemble a tin roof stuck on a concrete slab sticking out from the support of a rotten piece of swamp wood and then covered with white paint to make it look like something new, but concealing what exactly, within? I’d previously have had to use maybe 50% of lots of things to do the 15% I was trying to do. IA has met my design challenge of letting me use 10% to do 80% or 15% to do 90% although the ratios are irrelevant. The point I’m making is that by getting back to first principles I can do most things using the minimum I need but still giving me enough in reserve for the rest. For certain, much of that is due to IA handling the complex details out of sight down in the engine room. Should software play catch-up just for the sake of catch-up? There is nothing wrong with that. Time and again, we’ve seen products get better if there is an ever changing yardstick to compare it to. By the same measure it can work against a product. I think IA affords an excellent and extendable product. I’ve no idea what the next major version will offer and I hope that IA will not start to take it down the rocky path like some applications I’ve used. Compared to the other product, IA has achieved – by embracing first principles – divergence. IA is now charting its own course and destiny. The other ship not only has to contend with stormy waters but it has to keep a weather eye open for IA sailing alongside in the fresh wind of healthier latitudes. One industry analyst described IBM as a heavily laden ill-balanced tramp-steamer, reluctant or unable to change course without needing miles of open sea to do so and then compared it to that nippy speedboat called Microsoft that cuts and thrusts over waves and wake. I’m no industry analyst but I can see identical sailing conditions between IA and you-know-what.

That brings me back to what Clem Sunter offered: low road or high road. I’ve a good idea what one they are taking.

Kind regards

Peter Hamilton-Scott

Extending MSI command line switches

Hi there! Today I’m going to show you how to extend your InstallAware setup packages to support custom command line switches. A frequent question we get is “why don’t standard MSI command line switches work?” The answer is really simple – InstallAware has its own bootstrapper and the command line parameters it accepts are well documented under the help topic “Setup Command Line Parameters“. In a nutshell, /s makes setup run silently, /l=<full path to log file> turns on logging, and you can pass variable values using the form “TARGETDIR=<path value>” (including the quotes, if you are specifying values with spaces in them).

Now that we’ve gotten the basics out of the way, let’s talk about how to extend this behavior. For instance, you  might have some real difficult customers who have this irrational insistence on sticking to standard MSI command line parameters. Or, more legitimately, you might be wanting to define your own custom command line parameters to do whatever you feel like doing with.

The $CMDLINE$ pre-defined script variable contains the exact command line passed to your installer. You can investigate what this variable contains using the If script command together with the Contains expression. This will make it very easy for you to test for the presence of custom command line switches. For instance, take a look at the following code snippet:

if Variable CMDLINE Contains /quiet
Set Variable SILENT to TRUE

This snippet uses the pre-defined script variable $SILENT$ to turn on silent installation mode when /quiet, a standard MSI command line parameter, has been passed to your installer. Easy enough!

For more complex evaluations, you can assign the $CMDLINE$ pre-defined script variable to a custom variable and then use the Parse String command to extract exactly whatever you need without destroying the contents of the original command line variable.

Talk to you soon!

Michael Nesmith
your friendly support engineer

So who needs the automation interface?

Hello everyone, this is my first official blog item, anywhere, and thanks to Candice Jones at IA for given me the official invitation. When I say it’s my first ever blog item, I mean it. As much as I know how to use the internet I know very little about how to do the internet so this blog malarkey is new ground. New ground? That sort of leads me on to what I want to write about. I come from an InstallShield background and about three weeks ago I discovered IA and it’s been a chaotic time ever since. Not chaotic in the sense of how do I do something but more like, how do I undo what I was used to doing? Don’t get me wrong, I am not here to knock InstallShield. But since I’ve been using IA I’ve come to appreciate how much nicer it is to achieve similar functionality, but much, much easier.

What I’m really referring to here is the automation interface. InstallShield offers a rich subset of COM classes. Yes, COM! I had raised a ticket requesting a fully .Net-managed version be made available. We use the automation interface to create new projects from a template project and use an XML file to describe the features, components, and filenames to be installed. The first reason I designed it like that is because in theory, anyone could add or remove files from a build by editing safe-ground XML data. The second reason, and the most pressing to solve, is that the alternative is that I would have to teach people how to copy a template project and then add new files and do this and do that and what have you. That’s the crux of the problem, being forced to employ the automation interface to solve a problem that could not easily be solved without it. Now, in my period of time evaluating IA I never got round to demonstrating the automation interface in the Admin Studio edition. So how could I really sit here and write giving the impression I was comparing eggs to eggs?

This is the best bit: I did not have to. The ease of use afforded by IA meant I could take a project template containing most of my InstallShield template. Instead of using my automation interface program, I was able to prove that given access to the IDE machine, we could copy a project for a new installation, load it in the IDE and within a very short time change the project to use the new files or other facilities we wanted to include in it. One of the most complex issues I had to solve in InstallShield was needing to fix the occasional buggy record in the MSI tables and getting mega-confused deciding does something go in this sequence at such a position or elsewhere in another. True, that was not often required but how do you pass that kind of shoot-from-the-hip knowledge to someone else who, arguably, just wants a new installation with the minimum of fuss?

That’s what IA has achieved. Minimum fuss. Maximum do. I’m sure there is a place for the IA automation interface. I’ve trawled through the user forums looking for posts and I’ve seen precious few, if any reasons to use it. This proves my case – my opinion alone – and that is the automation interface is not called upon widely because there is not really a need to do so. IA has solved many installation problems by burying the complexity under-the-hood. So is the automation interface really required then? Well, you can bypass it by using compiler variables and use those in the MSIcode. This is an area where IA scores very highly. With one script you do everything that an install or uninstall requires and using compiler variables lets you wrap your runtime specific requirements in one easy to get at location. The compiler variables let you steer your project build along different roads. Compiler variables do not banish the automation interface and the interface does not banish the variables. Think of them as different toys brought to the party and that’s the power of IA. It joined the best of many breeds and took the concept of building installations right back to first principles and built a new castle on the hill.

My wife likes jewellery shops and what they sell, mostly gold for some reason (sigh!). She has no interest in digging through tonnes of ore looking for it. I look upon IA for the same reason. The ease of use means I and others can pick something off the shelf. Does that mean we can throw the shovels away? No, but we can put them back in the shed and work on doing things differently. If I’ve had to unlearn topics I was used to it’s because there is another paradigm. What IA does it does very well. Now that I can put the automation interface problem away for now and using compiler variables means I can now focus on doing what I do well, and that is…buying my wife more jewellery.

Kind regards. Peter Hamilton-Scott.