eWorld.UI - Matt Hawley

Ramblings of Matt

Standardized Installers

June 21, 2004 23:15 by matthaw

As I typed the title, I just had a flash back of ACT, SAT, CAT (I think) tests that we all knew and loved back in our early days of schooling. Standardized Testing, oh how great it was, and made it nice for the schools to accurately judge our abilities.

However, as long of a post that could be, I'm not going to be talking about testing, but rather installers...specifically Microsoft Installers. I find it quite humorous to see that each application team at Microsoft has their own Installer. No, I'm not talking about the files contained with in them, but rather the look, feel, and structure of the various installers. I find it odd that a company that has created the Microsoft Installer, doesn't even have standards for their own installers. Sure, they may all use MSI as a base, but as an end user, having different UI's for installers can just get plain confusing.

To compare on contrast, you see installers for Office products that all have the same look & feel. Its a wizard type of UI that (I feel) all installers should follow. Why? Well, its simple, easy, intuitive, and common amongst a lot of applications installers in the market. However, on the contrary, installers for VS.NET, MSDN Help, Windows Media Player, DirectX (to just name a few), all have their own “look” to them. Sure, in a sense, they all have that base “wizardry” to them, but its convoluted by the pretty graphics and interesting ways of displaying information to them. I wouldn't actually mind seeing some sort of standardization come across Microsoft's installers, but who am I to speak. I'm a lonely voice in the world where I have no say against MS standards.

Just my thoughts..I don't expect you to agree or disagree, however it would be nice to have a good conversation on this topic.

Categories: General
Actions: E-mail | Permalink | Comments (1) | Comment RSSRSS comment feed


June 22. 2004 15:49

I would like to see applications distributed as single files containing a filesystem containing the files needed by the application (think .zip or .iso). Within this "brick" would be a manifest declaring the applications requirements, capabilities and interactions with the operating system.

The manifest would be used by the operating system to dynamically alter the user's environment. For example, the manifest might state that the application is capable of viewing .gif files. The os would then add it to the list of available viewers. If new commands for the command line are declared, it adds them to the list of available commands (replacing PATH altogether).

The point here is that the REGISTRY IS GONE. It is replaced with a synthetic or virtual registry constructed from application manifests. This makes uninstalls, application upgrades and operating system upgrades easier. It also improved security by limiting what the application has access to that declared in the manifest. If can also help ease distribution issues by allowing you to cache the application bricks from a central (or hierarchical) location.

One note, some form of administrator application configuration document is needed to impose constraints on permitted applications. Configuration documents might also be used to configure multiple independent instances of the same application (ever try to install SQL server 5 times on the same machine?).

The manifest can also provide resource limitations or guidance so that multiple applications on the same machine don't trample each other. It also helps detect resource leaks.

The filesystem object itself would be mounted on a cannoncal virtual drive such as APP: (notice the multiletter drive names!). Processes in general would only be able to see the "drives" they should have access to. Other areas, such as operating system files and other applications, would not be accessible.


Comments are closed

Copyright © 2000 - 2021 , Excentrics World