Month: April 2007

A followup to MSI

My last post about MSI generated some nice responses, amongst them the lengthy blog post on Legalize Adulthood.

Judging from the two track-backs on the MSI posting and especially after reading the linked post above, I come to the conclusion that my posting was very easy to misunderstand.

I agree that the workarounds I listed are problems with the authoring. I DO think however that all these workarounds where put in place because the platform provided by Microsoft is lacking in some kind.

My rant was not about the side effects of these workarounds. It was about their sole existence. Why are some of us forced to apply workarounds to an existing platform to achieve their goals? Why doesn’t the platform itself provide the essential features that would make the workarounds unneeded?

For my *real* problems with MSI from an end users perspective, feel free to read this rant or this on e (but bear in mind that both are a bit oldish by now).

Let’s go once again through my points and try to understand what each workaround tries to accomplish:

  1. EXE-Stub to install MSI: MSI, despite being the platform of choice still isn’t as widely deployed as the installer authors want it to be. If Microsoft wants us to use MSI, it’s IMHO their responsibility to ensure that the platform is actually available.

    I do agree though that Microsoft is working on this, for example by requiring MSI 3.1 (the first release with acceptable patching functionality) for Windows Update. This is what makes the stubs useless over time.

    And personally I think a machine that isn’t using Windows Update and thus hasn’t 3.1 on it isn’t a machine I’d want to deploy my software on because a machine not running Windows update is probably badly compromised and in an unsupportable state.

  2. EXE-Stub to check prerequisites: Once more I don’t get why the underlying platform cannot provide functionality that is obviously needed by the community. Prerequisites are a fact for life and MSI does nothing to help that. MSI packages can’t be used to install other MSI packages but Merge Modules, but barely any libraries required by todays applications actually come in MSM format (.NET framework? Anyone?).

    In response to the excellent post on Legalize Adulthood which gives an example about DirectX, I counter with: Why is there a DirectX Setup API? Why are there separate CAB files? Isn’t MSI supposed to handle that? Why do I have to create a setup stub calling a third-party API to get stuff installed that isn’t installed in the default MSI installation?.

    An useful package solution would provide a way to specify dependencies or at least allow for automated installation of dependencies from the original package.

    It’s ironic that an MSI package can – even though it’s dirty – use a CustomAction to install a traditionally packaged .EXE-Installer-Dependency, but can’t install a .MSI packaged dependency.

    So my problem isn’t with bootstrappers as such, but with the limitations in MSI itself requiring us developers to create bootstrappers to do work which IMHO MSI should be able to do.

  3. MSI-packages .EXE’s: I wasn’t saying that MSI is to blame for the authors that repacked their .EXE’s into .MSI packages. I’m just saying that this is another type of workaround that could have been chosen for the purpose of getting the installation to work despite (maybe only perceived) limitations in MSI. An ideal packaging solution would be as accessible and flexibly as your common .EXE-installer and thus make such a workaround unneeded.

  4. Third party scripting: In retrospect I think the motivation for these third party scripting solutions is mainly the vendor-lock-in. I’m still convinced though that with a more traditional structure and a bit more flexibility for the installer authors, such third party solutions would get more and more unneeded until they finally die out.

  5. Extracting, then merging: Also just another workaround that has been chosen because a distinct problem wasn’t solvable using native MSI technology.

    I certainly don’t blame MSI for a developer screwing up. I’m blaming MSI for not providing the tools necessary for the installer community to use native MSI to solve the majority of problems. I ALSO blame MSI for messiness, for screwing up my system countless times and for screwing up my parent’s system which is plainly unforgivable.

    Because MSI is a complicated black box, I’m unable to fix problems with constantly appearing installation prompts, with unremovable entries in “Add/Remove programs” and with installations failing with such useful error messages as “Unknown Error 0x[whatever]. Installation terminated”.

    I’m blaming MSI for not stopping the developer community to author packages with above problems. I’m blaming MSI for its inherent complexity causing developers to screw up.

    I’m disappointed with MSI because it works in a ways that requires at least a part of the community to create messy workarounds for quite common problems MSI can’t solve.

    What I posted was a list of workarounds of varying stupidity for problems that shouldn’t exist. Authoring errors that shouldn’t need to happen.

    I’m not picky here: A large majority of packages I had to work with do in fact employ one of these workarounds (the unneeded EXE-stub being the most common one), none of which should be needed.

    And don’t get me started about how other operating systems do their deployment. I think Windows could learn from some of them, but that’s for another day.

Altering the terminal title bar in Mac OS X

After one year of owning a MacBook Pro, I finally got around to fix my precmd() ZSH-hack to really make the current directory and stuff appear in the title bar of Terminal.app and iTerm.app.

This is the code to add to your .zshrc:

case $TERM in
    *xterm*|ansi)
		function settab { print -Pn "e]1;%n@%m: %~a" }
		function settitle { print -Pn "e]2;%n@%m: %~a" }
		function chpwd { settab;settitle }
		settab;settitle
        ;;
esac

settab sets the tab contents in iTerm and settitle does the same thing for the title bar both in Terminal.app and iTerm.

The sample also shows the variables ZSH replaces in the strings (the parameter -P to print lets ZSH do prompt expansion. See zshmisc(1) for a list of all variables): %n is the currently logged on user, %m the hostname up until the first dot and %~ is displaying the current directory or ~ if you are in $HOME. You can certainly add any other environment variable of your choice if you need more options, but this more or less does it for me.

Usually, the guides in the internet make you use precmd to set the title bar, but somehow, Terminal wasn’t pleased with that method and constantly kept overwriting the title with the default string.

And this is how it looks in both iTerm (above) and Terminal (below):

Windows Installer – Worked around

I’ve talked about Windows Installer (the tool that parses these .MSI files) before and I’ve never really convinced that this technology really does its job. Just have a look at these previous articles: Why o why is my hard-drive so small?, A look at Windows Installer and The myth of XCOPY deployment

Yesterday I had a look at the Delphi 2007 installation process and it dawned me that I’m going to have to write yet another blog entry.

It’s my gut-feeling that 80% of all bigger software packages in Windows can’t live with MSIs default feature set and they have to work around inherent flaws in the design of that tool. Here’s what I found installers doing (in increasing order of stupidity):

  1. Use a .EXE-stub to install the MSI engine. These days this really doesn’t make sense any more as 99% of all windows installation already have MSI installed and the ones that don’t, you don’t want to support anyways (Windows Update requires MSI).
  2. Use a .EXE-stub that checks for availability and thereafter installs a bunch of prerequisites – sometimes even other MSI packages. This isn’t caused by MSI-files unable to detect the presence of prerequisites – it’s because MSI-files are unable to install other MSI files and the workaround (using merge packages) doesn’t work because most of the third party libraries to install don’t come as merge packages.
  3. Create a MSI-file which contains a traditional .EXE-Setup, unpack that to a temporary location and run it. This is what I call the “I want a Windows-Logo, but have no clue how to author MSI files”-type of installation (and I completely understand the motivation behind that) which just defeats all the purposes MSI files ever had. Still: Due to inherent limitations in the MSI engine, this is often times the only way to go.
  4. Create MSI-files that extract a vendor specific DLL, a setup script and all files to deploy (or even just an archive) and then use that vendor specific DLL to run the install script. This is what InstallShield does at least some of the time. This is another version of the “I have no clue how to author a MSI file”-installation with the additional “benefit” of being totally vendor-locked.
  5. Create a custom installer that installs all files and registry keys and then launch the windows installer with a temporary .MSI-file to register your installation work in the MSI-installer. This is what Delphi 2007 does. I feel this is another workaround for Microsoft’s policy that only MSI-driven software can get a windows-logo, but this time it’s vendor-locked and totally unnecessary and I’m not even sure if such a behavior is consistent with any kind of specification.

Only a small minority of installations really use pure MSI and these installations usually are installations of small software packages and as my previous articles show: The technology is far from fool-proof. While I see that Windows should provide a generalized means for driving software installations, MSI can’t be the solution as evidenced by the majority of packages using workarounds to get by the inherent flaws of the technology.

*sigh*