Your full service technology partner! 
-Collapse +Expand
Search DBA Group:

-Collapse +Expand DBA Store

Prestwood eMagazine

April Edition
Subscribe now! It's Free!
Enter your email:

   ► KBDesktop Data...   Print This     
  From the February 2008 Issue of Prestwood eMag
DBA Desktop Databases:
MSI Installers: Whats Up with These?
Posted 12 years ago on 1/24/2008
Take Away: For a while, now, Windows has supported a new mechanism for installing applications: MSI. This is quite a bit different than the familiar setup.exe, and here we begin exploring the differences - and the significance of MIS installations.


Let’s start with a brief review of the history of installing applications.

Not too many years ago, installing a new program could be as easy as copying an executable file to some location (up to you) on your hard drive, then running it.  Or, if the program was more complex, you might have to extract the contents of a compressed archive to some location, and then run the executable.

That still works, but, as our operating systems became more complex, it doesn’t come close to handling all the arcane, little housekeeping tasks necessary to install a program properly, ensure that it can be updated in a manner fairly simple for the end user, and, finally, uninstalled reliably.

Clever developers began creating setup programs to install their applications.  Their necessity, and complexity, created a market for several commercial, shareware, and freeware setup building systems.  The ubiquitous SETUP.EXE was born, and it’s been a standard, or sorts, for years.

Sometime during the life of Windows XP, Microsoft came up with a newer way to manage the deployment of applications.  It’s called “MSI,” for Microsoft Installer, and a program to run MSI installations is included with Windows.

Creating proper MSI installations is no piece of cake.  Where our old setup builders were usually script-based (procedural), MSI is “declarative.”

The deployment file, typically named something like “MyProgramSetup.msi,” is comprised of a database.  The database, in turn, includes many tables. Records in those tables specify elements of your installation.

When the end user runs your setup.msi, the Windows Installer queries the database in your msi file to determine what needs to be done.

There a couple of ways to create MSI installations:

One is to use Microsoft’s MSI SDK.  It’s a free set of documents and tools that you use to populate the various database tables to construct your MSI file. 

Using it, to me, is about as much fun as chewing on broken glass.

The other way is to use one of the available MSI “builder” programs.

Microsoft’s Visual Studio 2005 and 2008 include templates for MSI projects, and an IDE to help relieve some of the pain.

Visual Studio works, but it has limitations, particularly when you need to defeat Vista’s virtualization feature: it has no facilities for specifying file and folder permissions.

InstallShield, a commercial product, is much nicer, and easier to use.  Even the “Express” version of InstallShield that’s bundled with late versions of Delphi, is easier – and a little more capable than Visual Studio MSI projects; it does offer a permissions editor.

There are other commercial installers that support MSI projects, as well as some inexpensive shareware, or trialware products.

The old setup.exe is not gone, however. But it has a different role. When you build an InstallShield MSI project, it produces a setup.exe, a MSI file, and, depending on the options you choose, some other files as well.

In fact, if you have InstallShield create an autorun.inf file for you, you’ll notice that it invokes setup.exe, not the MSI file.

So what’s going on, here?

Setup.exe does a couple things. It checks to see if the MSI install program is present on the target machine, and, if it isn’t, it can install it.  Only then does setup.exe invoke your MSI file.

Can you get away with a “conventional” setup.exe instead of going to MSI?

Yes – for now, anyway.  Future versions of Microsoft operating systems may eventually insist on MSI only, so it’s prudent for developers to bite the bullet and begin learning about MSI installs now.

Another reason to switch to MSI is to avoid that scary dialog that XP and Windows will display if your installation is not digitally signed.  Your programs will still install without being digitally signed, but that dialog might alarm your end users.  Incidentally, on Vista, the dialog is more prominent, and more alarming than it is on XP.

More Info

KB Post:  Application Manifests, Revisited for Vista


Share a thought or comment...
Comment 2 of 2


Right off, let me state that I'm not a Paradox developer.  So take the following with a grain of salt.

In my opinion, the jury is still out on MSI installers.  I think the best evidence that they lack maturity is Microsoft's own, freely downloadable,  "Windows Install Clean Up" utility.

I stumbled upon it while trying to sort out some problems installing Visual Studio 2008.  Long story short, one of Microsoft's articles about the errors I was encountering suggested downloading and trying the clean up utility. I guess you can think of it like Add/Remove Programs on steroids.  It's supposed to do a more complete uninstall of programs (like the .NET Framework) that were installed via MSI.

It seems that even Microsoft isn't yet creating error-free MSI installers.

We've found that the old fashioned "setup.exe" business works just fine on Vista, provided that either you don't have to do anything fancy - or that the setup builder you use is capable of some fancy stuff.

My guess, then, is that the Paradox Distribution Expert should continue to work fine.  Unless and until you find out it doesn't.  Surprised

Posted 12 years ago

Comment 1 of 2

What about Paradox Distribution Expert. How does it stand with Vista? So far I have not experienced problems using it with XP, but I'm yet to try it with Vista.

What do you advice?


Posted 12 years ago
Write a Comment...
Sign in...

If you are a member, Sign In. Or, you can Create a Free account now.

Anonymous Post (text-only, no HTML):

Enter your name and security key.

Your Name:
Security key = P162A1
Enter key:
Article Contributed By Wes Peterson:

Wes Peterson is a Senior Programmer Analyst with Prestwood IT Solutions where he develops custom Windows software and custom websites using .Net and Delphi. When Wes is not coding for clients, he participates in this online community. Prior to his 10-year love-affair with Delphi, he worked with several other tools and databases. Currently he specializes in VS.Net using C# and VB.Net. To Wes, the .NET revolution is as exciting as the birth of Delphi.

Visit Profile

 KB Article #100817 Counter
Since 4/2/2008
Sales Website: Or visit our legacy sales site:

©1995-2020 Prestwood IT Solutions.   [Security & Privacy]