Posted on

How to install (or remove) a third party MSI using InstallAware

Hello everybody! In this post I’m going to show you how to install third party MSI files using InstallAware. We’ll achieve this functionality using the (Un)Install MSI Setup and File Bag MSIcode commands.

First, what does the File Bag command do? Think of it as an extended support files mechanism. While support files (also called Creatives in the InstallAware IDE’s visual designers) are a great way to add temporary files to your setup, they lack the ability to recurse into multiple folders. Support files also cannot be placed inside a web media block – they always go inside the main setup.exe file. So File Bag is essentially a fix for these two problems – this command lets you add temporary files to your setup which are only available while setup is running (and not permanently installed on the end-user system), is web media block friendly, and also supports recursion.

Next, what does (Un)Install MSI Setup do? As the name implies, it can install or uninstall an MSI based setup. The beauty of this command, as opposed to using another built-in command like Run Program to install third party MSI files, is that it captures native progress as well as the final error/success state of the installation, along with any textual error description text if applicable. This makes your setup look more professional: even the progress of external setups will be displayed in your own custom dialogs at install time, and you can provide very effective error handling and troubleshooting.

Now that we’ve gotten the preliminaries out of the way, lets get to work. A good example of to use the File Bag command is in our own pre-built setup script for the Microsoft .NET Framework 3.0. You can add this runtime to your setup and then switch to the MSIcode view to investigate how we’ve used the command.

The File Bag MSIcode statement:

And the File Bag command window:

The pre-defined compiler variable #IADIR# simply returns InstallAware‘s main installation folder, which is the parent folder of the setup files for the .NET 3 Framework. In this field, you can enter any path you like, or just a single file name – as long as it points to the file(s) you want to add to your setup as a temporary resource.

The other interesting field in this command window is the NET30_FILEBAG variable. You may enter any custom variable in this field (as long as you pre-initialize it using the Set Variable command to an empty value). You should always provide a variable in this field, because the temporary location where File Bag makes your “bagged files” available at runtime will always change from machine to machine and setup to setup. So unless you provide a variable in this field, you won’t be able to access your bagged files at runtime, which beats the whole purpose of using File Bag in the first place!

Next lets take a look at the command window for the (Un)Install MSI Setup plug-in.

The Action tab indicates the installation/uninstallation mode and passes additional command line parameters to setup:

When installing an MSI file, you typically enter ADDLOCAL=ALL here, to install all of the features that are provided with the MSI. When uninstalling, you typically enter REMOVE=ALL. You are free to set any other MSI properties using this field, to install precisely those features that you require, or perform a customized MSI installation.

The Package tab specifies the MSI package to use, by filename (used when installing) or by package GUID (used when uninstalling):

When installing, you’ll want to specify the full path to the third party MSI file. The path will always be composed of the variable populated by File Bag, followed by the subfolder (if any) and the MSI file name. When uninstalling, you may again reference the MSI file by its full file path; alternately you may simply reference it by its unique package GUID (the GUID may be found by opening up your MSI package in Orca, navigating to the Property table, and copying the full value, including the squiggly parenthesis, corresponding to the ProductCode property). Using the GUID can be more advantageous when uninstalling, since you won’t need to provide access to the MSI file (often inconvenient to do at uninstall time – you hardly want to prompt your end-users for a setup CD when they’re just trying to remove your product).

Here’s an MSIcode snippet that shows the proper placement of the (Un)Install MSI Setup command for use at uninstall time:

And this is how the Action tab would look for the command when uninstalling (again, feel free to add additional properties):

So now, you know all you need to add temporary files to your setup, and to run third party MSIs, even natively capturing their native setup progress, to install or remove them 🙂

One last thing worthy of mention is the Setup Decompressor. This is a very handy tool that InstallAware originally built for Microsoft in 2005, to optimize the compressibility of their then-current .NET 1.1 Framework. This tool works with MSI (and a few other file types) and decompresses their data. However, it doesn’t just “extract” data like unzipping a ZIP file. What it does is, it first extracts the data, then re-inserts it back into the original file, in unmodified form – only uncompressed this time (think of it like re-creating a ZIP file with “stored” compression, so the files inside the ZIP archive are not compressed but just stored as-is).

Why would anybody want to do this? Data Compression 101: No matter how good a compression algorithm is, it cannot recompress data that has been compressed before. So for example, lets say you have a 10 MB file, and when you ZIP it, it goes down to 5 MB, and when you CAB it, it goes down to 3 MB…you might think that when you CAB the 5 MB ZIP, it would again come down to 3 MB…but that’s not the case. You still get a 5 MB CAB – because the 5 MB ZIP has already eliminated redundancies in the original uncompressed data stream (even though it did a worse job at it than the CAB).

InstallAware‘s compression algorithm is far better than the compression used in MSI files, but if you feed it pre-compressed data (such as “off-the-shelf” MSI files, which are always compressed using CAB), it won’t be able to reduce file sizes any further. For this reason, you want to run the Setup Decompressor on your MSI files before packaging your setup with InstallAware. Since Setup Decompressor is non-destructive, it will never harm your MSI files or change the files they contain in any way – other than reversing their compression. And this way, InstallAware is free to work miracles in compressing your MSI files!

Just take a look at .NET Framework sizes, when packaged natively (as by Microsoft) and with InstallAware (after pre-processing by the Setup Decompressor). Typical size savings are 40% over the already compressed size of the native Microsoft files, and sometimes as high as 67% (as in the case of the .NET Framework 1.1 with SP1 inlined). You’ll be pleased to know that the Setup Decompressor also works with other file types – such as CAB, MSM, MSP, and even some kinds of EXE files. Just try it out!

To open the Setup Decompressor tool, click the Decompress button in the Tools group on the Design tab of the InstallAware IDE:

All you have to after this is click the Browse button and select the MSI file you want to decompress. Click Decompress and the fully automated Setup Decompressor gets to work for you – and provides live status update as it investigates the various archives and streams inside your MSI file. I also recommend checking the Backup original file option – just in case you run into a bug that we haven’t encountered yet 😉

So, that’s it for now. In my next post, we’ll cover a related topic, “How to run a third party EXE using InstallAware“. Until then!

Thank you,

Panagiotis Kefalidis
Software Design Team Lead
InstallAware Software Corporation

Posted on

Online Serial Key Validation with InstallAware, the Database Part (final)

In this last installment of the serial validation series, we’re taking a look at the database structures used by the web side scripts. You’ll need to know some SQL-92 or T-SQL basics, if you don’t already please visit http://www.mysql.com/ and www.microsoft.com/sql/ to get acquainted.

First, some database design. We’ll keep serial data on one table and user data on another table.

The serials table columns:
id (bigint) , productname (nvarchar), serial (nvarchar), activated (tinyint)

The users table columns:
id (bigint), firstname (nvarchar), lastname (nvarchar), username (nvarchar), password (nvarchar)

During validation we can use the SQL SELECT statement to make sure the serial number has not been used before and has not been activated yet:
SELECT id FROM serials WHERE serial=@serial AND activated != 1

This is a T-SQL compliant query, where @serial is the parameter containing the serial number being queried. If this query doesn’t return a value, that’ll mean that the serial number specified is either invalid or has already been activated.

Otherwise, we can go ahead and activate this serial number. The T-SQL statement for this activation is:
UPDATE serials SET activated=1 WHERE serial=@serial

Now, all that remains to do is to add an entry in the users table:
INSERT INTO users(firstname,lastname,username,password) VALUES(@firstname,@lastname,@username,@password);

My suggestion for you is to implement all of the above statements as separate stored procedures and not stand-alone “injected” queries lying around inside multiple web script files. It’s better that way since code maintenance overhead is reduced – just like replacing all separate Run Program statements with a common Label statement like we did earlier for the MSIcode update script.

So as you can see, in a few simple lines, we’ve implemented the business logic/workflow of our application, in an integrated fashion with InstallAware. You’ve probably noticed that there isn’t any directly InstallAware related content in this post, but we’ve had a lot of requests for samples of web server back-end behavior for things like serial activation, so we hope this helps!

Thank you and we’ll be back soon,

Panagiotis Kefalidis
Software Design Team Lead
InstallAware Software Corporation

Posted on

Online Serial Key Validation with InstallAware, the Code Part

Hi all! It’s been a few days since my last post about wrapping our update mechanism around your application and it’s time for some web server code samples; but first, I wanted to make an enhancement to the update script.

If we want to change our “Run Program As” commands, we’ll have to edit multiple parts of the update script. At best, this is tedious; typically it will introduce errors with forgotten or misplaced commands. The solution is simple: we’ll use the Label and GoTo Label MSIcode commands to create a re-usable region of code. This way, we’ll remove all pairs of existing “Run Program As” and “Terminate Installation” commands, replacing them with a GoTo Label command that points to a new “Label” called “RunProgramSection“, with the “Run Program As” and “Terminate Installation” commands underneath.

becomes:

So now, instead of making changes all over the place in the MSIcode script, I only have to make one change under the Label command. That way, I can re-use this code block in other projects:

I can also build in more sophisticated behavior, adding more MSIcode commands. Lets say you want to run two programs – one might be a tray application and the other one the “real” application.

Quite easily done. Extensibility and scalability are everything these days!

And now for some server side code. First, please make sure you’re familiar with a server side scripting language like PHP or ASPX. Please visit www.asp.net and www.php.net if you need a jumpstart. I’ll assume that you’ve done your homework and that you can follow the simple scripts provided below.

First some PHP. If you remember, I pass some parameters from my MSIcode InstallAware setup/client script to the web/server script as URL parameters. In PHP, URL parameters are stored inside a predefined variable called $_GET, which is a global array. If you want to read a user’s serial number and your parameter is called serial, you can try the following:

$serial = strip_tags($_GET[‘serial’]);

Now, the PHP script variable $serial has our parameter’s value. Let’s see if the serial number provided is actually valid:

if ( CheckIfLegimitate($serial) )
return “1,”.srand(time());
else
return “0,”.srand(time());

If the serial is valid, the PHP script above returns “1”, or “0” otherwise. Either way, the return value is appended with a comma delimited random number. Back on the InstallAware setup/client side, I read this value using the “Download File” MSIcode command, and I then parse it using Parse String; which lets me obtain both the status code (“1” or “0”), and of course the random number.

Next post: Database schema scripts and more code. It’s going to be the last post from these series so, stay tunned!

Panagiotis Kefalidis
Software Design Team Lead
InstallAware Software Corporation

Posted on

Online Serial Key Validation with InstallAware, the Updates Part

A question we get a lot here is how exactly our update mechanism works. It’s actually very straightforward. You define your existing software update packages inside our IDE, which saves that information inside an updates.ini file. You then upload both the update installers (patches, single exe’s, whatever you like) and the updates.ini file, overwriting the old INI if any, and you are good to go! The next time a scheduled update check runs, your users will be automatically notified by the InstallAware Web Update Client that new updates are available for download. But what if you want to check for updates each time that your application is launched, and automatically install them if any are available?

As I am fond of saying, InstallAware is extremely flexible. There’s a very simple way to do this. To get started, open the updates script at the MSIcode tab – this is found under the “Include Scripts” heading of the Project Manager which is normally docked to the left of the IDE in the MSIcode tab.

and then

The updates script creates shortcuts for the InstallAware Web Update Client wrapper. If you look at lines 24 and 26 of the standard update script, you’ll see that these shortcuts point to the $UNINSTALLLINK$ pre-defined MSIcode variable. This pre-defined variable points to your setup.exe file as cached on the target system, which acts both as your setup driver, and also the web update client.

Now, in your main setup, instead of creating a shortcut for your application’s EXE file (ex: C:\Program Files\My Software\My Application.exe), create a shortcut for $UNINSTALLLINK$ instead (type this inside the Shortcut to File field), and specify the “/update” command line parameter for the shortcut, which will start setup.exe in web update client mode (instead of the regular maintenance/uninstallation mode).

Also, remember to change the shortcut icon to your application’s icon, so your users won’t be confused with a setup icon in their Start Menu.

Now, every time a user clicks your application’s shortcut in the Start Menu, the web update client will launch, and check for updates! But of course, we still need to fix the web update client so it’ll know to launch the main application after checking for updates. Otherwise, users have no way of running the application, since the Start Menu shortcut doesn’t even point to your application anymore.

This is easy too. Again, on the MSIcode tab, navigate to the updates script.

Search for the “Terminate Installation” command throughout the updates script. I recommend typing Ctrl+F and searching for “Terminate“, and then repeating the search by typing F3. That way you won’t miss anything.

Before each “Terminate Installation” command, insert a “Run Program As” command with the target being your main application file (such as “$TARGETDIR$\my application.exe”), and also setting the working directory to “$TARGETDIR$“.

Copy-paste this command before each “Terminate Installation” command inside the updates script. With this simple trick, your application will launch any time the web update client exits – be it upon user abort, failure, or successful update installation. You’re fully covered since you addressed each script termination point.

What if you want to check if this end-user has not paid her subscription fees and thus updates are not to be made available for her? It’s easy. Set up a web page and call it like I described on my previous post using Download File and Parse String – to find out if your user is eligible for updates. I do this by passing her serial number as a parameter to my custom check_updates.aspx page on the server, and then I read back the response. If the response is “1” the end-user can update but if the response is “0“, the end-user is denied access to the update. When the response is “0” you can place another “Run Program As” and “Terminate Install” command pair, in order to make your program run directly without checking for updates. You should place all of these MSIcode commands at the very top of the updates script, before any actual web update client code runs.

Coming up next: It’s about time to look at some .php and .aspx code, and also MySQL and MS SQL database scripts, for the server back end! Don’t miss it! 🙂

Panagiotis Kefalidis
Software Design Team Lead
InstallAware Software Corporation

Posted on

Online Serial Key Validation with InstallAware

I’ve spent a lot of time thinking about my next blog post. I’ve had some really crazy ideas like creating a plug-in to run my own scripting language on top of InstallAware’s MSIcode. Yeah, I know it sounds crazy but it’s doable. InstallAware sets no limits on your imagination. After getting down to earth, I combed our community forums for ideas and voila! This one gets a lot of requests so I’m going to show you how to create your own online serial key validator dialog/script with InstallAware. This post will be the first in a series in which we’ll make an online serial validation mini-suite for your applications. At the end of the series, we’ll have complete MSIcode, ASPX and PHP scripts and a sample project with dialogs. My examples will be simple but once you get the idea, you’ll be able to modify my scripts or create your own from scratch easily.

My basic approach is as follows: In the setup wizard, I prompt the end-user to key in their serial number. After the serial has been entered, I connect to my web server using the Download File MSIcode command, and I ask my script (residing on the web server) to validate the serial number live. If the serial is valid, the web script returns “1” along with a random number, if it’s not, it returns “0”. Note that there are lots of different approaches you can take when validating the serial number. You may, for example, first check if the serial number exists in your database. If it doesn’t, you can run your serial number algorithm to determine if it’s legitimate and then add it to your database, along with some other registration data, like user name, email address, company name, and so on. Alternately, even if the serial number already exists in your database, you can run additional checks to make sure its not a pirated key that has been going around for some time. You could for instance bind each serial to a unique installation ID, or what have you.

Getting back to my particular scenario: When my web server script returns a “1” followed by a comma delimited random number, I parse that string in InstallAware’s MSIcode to get the random number part (I use the Read from Text File and Parse String MSIcode commands). I then query the web server again with that value to dynamically determine what product version the end-user is licensed for, and which setup features should be enabled/visible on his/her “Components Tree” dialog. So again using Download File, I pass two parameters to my web script. The first is called ticket and is the random number that is valid for this session only. The second parameter is called component and is the name of the setup feature that I am validating for this particular end-user. On the server side, the script runs its validation against the database and returns a 0, 1, or -1 as a result. -1 means that this feature is disabled and invisible, so the end-user doesn’t even know it exists (this can be useful for trial version installations), 0 means that the feature is disabled but visible, so the user knows it exists but cannot select it (useful for licensed products on the lower-end of your product edition spectrum), and 1 means that the feature is enabled and visible, so the user is fully licensed for that feature. As I evaluate the results using If commands in MSICode, I dynamically enable or disable the relevant setup features using the Set Component Choice and Set Component Visibility MSIcode commands. In case you’re wondering why I use a random number ticket, I use it as a unique temporary key, to query my web server/database and find out which setup features should be enabled. A “security” pre-caution if you like.

In my next post, you’ll see how to wrap InstallAware’s update mechanism around your application. I’ll extend the built-in update functionality to use my online serial key validation mini-suite and check if the end-user actually has the rights to make updates – and allowing them only if (s)he bought a software subscription plan. Stay tuned!

Panagiotis Kefalidis
Software Design Team Lead
InstallAware Software Corporation

Posted on

InstallAware and Microsoft launch coupled MSI 4.5 beta

Rumors have been going around for a while, but now its official. As of tomorrow, InstallAware and Microsoft are launching the coupled MSI 4.5 beta.

As I wrote earlier, we’ve got a new MSI Transaction plug-in, as well as a new Windows Installer 4.5 runtime. Get them both here: http://www.installaware.com/msi45plugin.asp.

You’ll also need the actual MSI 4.5 beta binaries during setup. Download them at: http://connect.microsoft.com. We cannot bundle the binaries as yet – because this is a coupled beta, you’ll need to download the binaries directly from Microsoft and the InstallAware enhancements directly from us. Of course, as soon as Windows Installer 4.5 is launched, we’ll be bundling the binaries normally.

Stay tuned for the press release going out tomorrow and we’ll talk soon! 🙂

Panagiotis Kefalidis
InstallAware CCP — DataFire Software, Greece

Posted on

InstallAware goes Aero with Vista Glass component

Hello again. I’d promised myself to make at least one post per week here, but the last two weeks, boy, have been a hell of a time for me – I almost broke my leg and then got a real bad cold that’s still bothering me. Now I know how Walt Disney’s Donald Duck feels about his bad luck. Anyway, my leg is better, it doesn’t hurt so much anymore and I’ve decided that its time to get back on this blog and post some new stuff. Some cool stuff, like the Vista Glass component on InstallAware’s forms designer.

The Vista Glass component gives the glass feeling (Aero) to your setup UI, making window regions appear “glassy” like Windows Media Player on Windows Vista. Although still in beta, it works like a charm. In this post, you’ll find info about how to use it, what it does, what the drawbacks are, how to overcome them and you’ll get a push on creating your very first InstallAware Theme with Vista Glass support. Amazing, isn’t it? And it gets better.

Getting Started

In order to start exploiting InstallAware’s Vista Glass features, you’ll want to create a new project (you could also use an existing project, but this is just experimentation so I suggest creating a new one). Then, in the visual designers, go to the “User Interface” section and click on the “Dialogs” option.

You get a list of the dialogs in your project sorted by the order they appear during install procedure. Highlight the “Welcome” dialog and get a preview of it, before beginning to apply Vista Glass effects.

 

When you double click a dialog, the form designer pops up, allowing you to change anything you want on your form, from simply re-arranging elements (textboxes etc.), to creating scripted events and reading/writing variables to interact with MSICode.

Let’s Go Glass!

Finding the Vista Glass component is really easy. Click the “Win32” tab and the right-most control on the palette is “VistaGlass”, the one we’re looking for.

Click the component icon and then click anywhere on the dialog form. The VistaGlass component icon appears on your dialog. Click it to edit it’s properties: change the “GlassEnabled” and “SheetOfGlass” properties to “True”. Just by doing this, you get a VistaGlass (Aero) dialog!

 

To preview your achievement, click on the Test Dialog toolbar button (the one with the thunderbolt icon).

Next Steps

You might be wondering if it’s really that simple. Basically, yes! You now have full Vista Aero Glass effects on your dialog. Due to the beta nature of the component however, some controls render awkward. We can make it all look better with some tricks. Instead of glassing the entire dialog, lets focus on glassing a targeted region first. We need to change two properties for this one. The first is called “SheetOfGlass” – change it from “True” to “False”. The second is “GlassBottom”, which sets the pixels occupied by the glass effect, counting up from the bottom of the dialog. With the “Official Theme”, try setting“GlassBottom” to “301”. Now our UI looks much better!

Pro’s and Con’s

It’s obvious that by using VistaGlass on your setup UI, you’re giving your users a richer setup experience. They get the “wow” before even having used your product for the first time, giving you a clear advantage over your competition just by using the right setup tool. Also, don’t worry if your setup needs to run on versions of Windows earlier than Vista. The VistaGlass component auto-detects the end-user’s Windows version, and disables the glass effect on legacy operating systems automatically, without any error messages or other undesirable UI artifacts.

The only issue is that some controls don’t render correctly, but you can easily overcome those issues (even at this beta stage). InstallAware’s flexible MSICode lets you do anything you want. For example, I’ve manually calculated the TotalRequiredSpace value using MSICode, because the static label showing TotalRequiredSpace renders incorrectly on Glass, as a black rectangle.

 

I used the MSIcode functions “Get Component Space” to get the total bytes required, “Mathematics” to convert those bytes into KB or MB, and then “Set Variable” to concatenate the string “KB” or “MB” at the end of the value – finally displaying the result in a regular label, which does render correctly.

Conclusion

I’ve said this before but I’m going to say it again. By leveraging the Aero Experience on your setups, you impress your customers – on every single trial download! Give them the “wow” feeling right from the beginning…with your setup! You can also create your own themes by using the VistaGlass component and building on top of empty dialogs, or based off of an existing theme. You could even replicate, for example, the look and feel of Office 2007 installations using the tab component!

That’s all for today. Stay tuned people, more to come.

Panagiotis Kefalidis
InstallAware CCP — DataFire Software, Greece

Posted on

Get ready, because we’re launching.

It’s been a while since the last time we wrote something here, almost 5 months. We have been quite busy working on our products :)During this timeframe, we shipped InstallAware 7, the latest and greatest version of the industry’s premier setup authoring tool; and also a new beta for our exciting WiX IDE, WiXAware 2.0. But that’s not all!I believe this lack of posts and activity on our blog has been really worth it, because not only did we improve our products and launched two new major versions, but we’re now also announcing support for the upcoming version 4.5 of the Windows Installer engine! This makes us the first installation vendor to support Windows Installer 4.5, the same way we’ve been the first to support SQL Server 2005, .NET 3, as well as .NET 2.0. Unlike some other vendors (you know who you are), we’re making these updates available free for everyone just days after Microsoft publishes them 😉 So we’ll be releasing the free update for Windows Installer 4.5 as soon as a Go-Live license from Microsoft for it becomes available.

We’ve already built the Windows Installer 4.5 runtime for InstallAware’s Application Runtimes designer, as well as a new plug-in for leveraging new Windows Installer 4.5 functionality. As soon as Microsoft lets vendors redistribute the new Windows Installer 4.5 runtime, you’ll be only a few hours from taking advantage of all its new features, and start exploiting the much anticipated Chained Transactional Installs!So, what are Chained Transactional Installs? It’s pretty self explanatory, really. You can now officially chain multiple MSI installations one after the other, as part of a single atomic operation. If there is an error in one of the chained installs, or the end-user cancels the installation someplace in between, the entire transaction can be rolled back in a single operation, returning the computer to the same state it was in before the entire transactioned installs began. Of course, if everything is kosher, just commit the changes normally, and all changes made to the system are finalized in a single pass.

MSI Transaction Example Usage

InstallAware has always provided the most advanced bootstrapper technology of the Windows Installer industry, for instance you could already chain multiple MSI installs as part of a larger setup, monitor and natively display their progress in your master setup dialogs, and so on ever since our first release almost 4 years ago. And now, with the engine level fortifications Microsoft has made to Windows Installer 4.5, InstallAware further enhances the reliability and resiliency of chained MSI installations. The good news is you do not have to make any major changes to your existing setups! Just add two lines of MSIcode leveraging the new MSI Transaction plug-in, creating transactioned installation blocks around your runtimes and/or any other MSI files that you are installing, and you’re set!There’s no need to worry about compatibility issues as packages and patches authored by previous MSI versions are fully supported by the MSI 4.5 engine. Also, packages targeting MSI 4.5 contain some new tables and actions for the new features, but when you run an MSI 4.5 package on an older engine, such as MSI 3.0, everything will still work smoothly by ignoring the new tables/actions. Of course, any new features and functionality based on MSI 4.5 won’t work, but your setups will still install properly without throwing unwanted errors. Our new MSI Transaction plug-in won’t fail either when MSI 4.5 is not available, instead it returns a descriptive error code back to your MSIcode script, letting you handle the condition as you see fit (for instance, by forcing the installation of the new Windows Installer engine, or by discarding transaction support).I was quite amazed by the speed improvements during installation. It’s much faster and much more stable, without strange failures during installs and unexplained messages even at this beta stage. Just imagine what the RTM version will be like, if the beta “flies” like this!Currently this beta version of the MSI 4.5 engine runs on most recent versions of Windows, starting with Windows XP SP2 and Windows 2003 SP1, and of course including Windows Vista. While MSI 4.0 was not supported on older platforms, Microsoft is now making this “down-level” support available for MSI 4.5, a welcome improvement. MSI 4.5 will be embedded into Windows Server 2008 (Codename Longhorn Server), and it is planned to be included in Windows Vista SP1 as well.

MSI 4.5 will be available as a stand-alone update from the Microsoft Download pages. If you want to give it a try, you’ll have to register at Microsoft’s Connect page, where the beta is available. After completing the registration process you’ll be able to download any necessary files MSI 4.5 needs to install, as well as updated documentation. Please note that we can’t redistribute runtime files during their beta stage because this is prohibited by Microsoft, but if you already have the MSI 4.5 runtimes, just drop us an email and we’ll make our new runtime installer package and the new MSI Transaction plug-in available for you, free of charge 🙂

Windows Installer 4.5 Runtime Installation MSIcode

Of course, InstallAware’s new Windows Installer 4.5 runtime takes care of installing this update for you in just a single click. It’s actually a fairly complex process on Windows Vista. Vista features a new update mechanism, called the Windows Update Stand-Alone installer, along with a new kind of system update file format. Updates are no longer served as independent EXE’s that we were used to working with on the down-level platforms. The bug with the Windows Update Stand-Alone installer is MSI 4.5 cannot be silently installed, complicating the delivery process and ruining the end-user experience. A hot fix for this bug must be installed beforehand (unfortunately, it’s not automatically pushed to client machines through Windows Update). The good news is, our new Windows Installer 4.5 one-click runtime install correctly handles this case and installs this hot fix when necessarySo you’ll have unsurpassed reliability and deliver your end-users with the best installation experience, in the good InstallAware tradition.Once again we’re bringing you the latest technologies, beating any other vendor to it!Keep watching this space as we’ll have more helpful tips, how-to guides, sample scripts and other time saving tricks posted here regularly (no matter how aggressive our product release schedule is). I’m here to make your time spent with InstallAware more fun and enjoyable!

Panagiotis Kefalidis
InstallAware CCP – DataFire Software, Greece

Posted on

Elephants and User Interface Design

I’ve always had a fascination for antique software. Perhaps its because I miss the simplicity of the Windows 3.1 days…and its incredibly simple WinAPI, which could be mastered in its entirety by a single developer. That was when I first started Windows programming. My tool of choice back then was Borland Pascal with Objects 7.0, which is still available today in incarnations as CodeGear Delphi. Even though InstallAware also uses C++ and C# for some of our projects, Delphi is still my personal tool of choice today. But in 1992 we didn’t have even Delphi 1.0. So software was written the hard way…lack of visual designers, no matter how simple the API, is always a pain.

But why the fascination for antique software then? To be honest, I’m not really sure. Maybe I’m just into antiques after all 🙂 I must admit I get a huge kick out of building and maintaining antique Windows boxes. Around 2001 (wow!, even the turn of the century is now almost a decade old), I had to collect real antique hardware to build an antique Windows box. An ISA video card, ISA sound card, ISA modem, PS/2 keyboard and mouse, along with an old processor were necessary. Otherwise, Windows wouldn’t recognize your devices, plain and simple. Today, thanks to the “virtues of virtualization”, one doesn’t need to shop around for old (and hard to find) hardware anymore. Of course, VMware has been around for a while…delivering near-native performance for virtual machines. VMware owes most of this performance to its native drivers for guest operating systems…which provide high performance video display, for instance. However the one drawback of this approach (which really doesn’t matter in the real world anyways) is that if VMware doesn’t have drivers for your operating system, you’re stuck. So even though one of the first things I tried on VMware was to build a Windows 3.1 virtual machine (on top of good old DOS 6.0), it had no sound, 16 color graphics, and 640×480 resolution only.

Virtual PC to the rescue! Virtual PC takes a different approach – instead of implementing custom drivers for video, sound, and so on – it emulates old cards, cards that are old enough that Windows 3.1 recognizes them. The real-world drawback is that Virtual PC can be slower because its emulating old hardware, instead of passing calls directly to the underlying hardware. However with Virtual PC, I was able to build a Windows 3.1 virtual machine that had high color display, sound, networking – practically everything! I was even able to play old DOS games like Flight Simulator 5 (the first version of the family to support textured graphics and digitized/synthesized sound). It was antique software heaven 🙂

Even today, I maintain a fully-configured Windows 3.1 virtual machine, ready for usage at a moments notice. I’ve installed a full set of browsers, email clients, FTP clients, compilers, IDEs, Office programs, games, and what not. I’ve also got some real gems that my contemporaries from that era will recognize – After Dark screensaver (can anybody really forget those flying toasters?), Stacker disk compression (the first company that *I* know of to win a patent infringement lawsuit against Microsoft), Norton Utilities and PC Tools, just to name a few. Watching PC Tools or Norton defrag the hard disk in native DOS mode…moving all those character-drawn blocks around…still looks more convincing to me than my native Windows defrag tool 😉 You *know* the thing has direct access to hardware and is *making full use* of that privilege 😉

Working in this virtual machine is very refreshing in many ways, and contains invaluable lessons for software development from a historical perspective – you get a broad overview of ideas that survived, and those that failed. And maybe the ultimate lesson is the realization that nothing has fundamentally changed since those days in the computing world. Sure, we now have fancy graphics cards, jazzy on-screen effects, way more processing power – but ultimately, in your day-to-day use, you still have the same email client, the same word processor, and the same spreadsheet; which require direct keyboard input, learning the program, and regular crashes. Sure, Windows 3.1 did crash a *little* more frequently at the kernel level, but most real-world software seems to be equally unstable these days. About 30% of the time I open Internet Explorer 7, it hangs. Vista, despite dramatically multiplying resource requirements and reducing performance thanks to its DRM focus, is even buggier – every time I view an MSN video in the browser, the Desktop Window Manager (DWM) crashes! Makes you really wonder if we’d all be better off reverting to Windows 3.1 – at least, it would run at lightning speed on today’s machines 😉

But what about the place of elephants in user interface design? Enter OS/2. After perfecting the Windows 3.1 antique VM, I decided to take the challenge to the next level – another contemporary of the Windows 3.1 times, OS/2. I had never actually used OS/2 in the real world – my only memory of it was drooling at a high-school demo of it (I lacked the hardware capable of running it at the time). So I soon found out that OS/2 also ran just great under Virtual PC…and had several versions of OS/2 virtualized 🙂 This is where the elephants come in. OS/2 had some “artistic” elements in its user interface, namely elephants in wizard screens:

Yes, IBM indeed built a product with this sort of “artistic” license 🙂 The elephant even changes its pose on the different screens! How’s that for a user interface concept?

In retrospect, its interesting to note that OS/2 didn’t survive, and Windows 3.1 did (although, we’ll never know how much of that owes to Stacker-esque business tactics on Microsoft’s part, and how much to the elephants). Its more interesting to note that despite dramatic improvements in hardware performance, the way you use the computer today hasn’t really changed – and nor has its reliability. The user interface still employs the same metaphors from the Windows 3.1 era – windows (doh!), menus, context menus, buttons, more menus, keyboard input, and so on. I even find myself craving the ugly Windows 3.1 “window themes” – if I could find a skin like that for my current Windows, I’d use it in a heartbeat! I’m not so sure Vista’s maximize/minimize buttons are all that better. Ultimately, what’s the *most* fasctinating to me is, while people debate whether Vista is worth the upgrade from Windows XP or not, they don’t even realize that in their day-to-day usage, even XP isn’t all that different from trusty old Windows 3.1 😀

Well, I just got my hands on a copy of Borland C++ 3.1 for OS/2. Its time for some more antique software fun! I was actually thinking of taking the LearJet on a spin in the latest Flight Simulator 10…but seeing that it runs even slower than how fast Flight Simulator 5 ran on its *original introduction*, I’m really thinking older might be better 😉

Posted on

My Good Friend Anthony

Until recently, I was very fond of British Airways. They have awesome full-flat beds in business class, as well as nice lounges where you can wine and dine yourself to your heart’s content. Sure, their staff could be friendlier – I once had an airline attendant “quiz” me on the location of the nearest security exit after the “security presentation”. I should have asked her if she would like me to blow in the vest as well 😉 But overall, it was good value.

Until recently. The last time I was flying, British Airways lost my luggage. Needless to say the love-hate slider between myself and BA made a little more progress towards the hate end that day. Brilliantly, I had also put my cell phone in the suitcase, which was also lost now. The first thing I did out of SFO was to buy a new temporary cell phone. I gave BA the number so they could keep me up to date on the “property irregularity report”.

The next day in the middle of an important meeting, my temp phone rang. I excused myself, saying I just had to take this call – really didn’t want to miss it if it was the airline. So the voice at the other end spoke:

“Anthony?”

“Um…excuse me, who?”

“Is Anthony there?”

I wished so badly for them to be calling from BA. I “figured” maybe she has the wrong name or something:

“Where are you calling from?”

“??? San Francisco!”

Turns out it was the wrong number, plain and simple.

Sadly, I did not get a call from BA for the remainder of that day (even though I had been promised one). However, I did get a call from Anthony himself 🙂

“Hey dude…have you been getting calls for Anthony?”

“Yes.”

“That’s me.”

“OK…”

“Look dude, I change phone numbers a lot, and I move around a lot. If somebody calls me, tell them you don’t know me, you don’t know who I am, you don’t know where I am, and you don’t know my new phone number. Just tell them you don’t know anything about me and hang up.”

WOW! Now this was entertaining 😀

“Man, how would I know who you are or where you are anyways?”

“OK thanks dude, I gotta run!”

As Anthony had predicted, a lot of people did try to get in touch with him. There were lots of calls that started like this:

“This is not a sales soliciation. This call contains important information about your account…”

There were also some strange text messages:

“Im home gogo ?!gangsta go da rnb thug!”

(Don’t ask me what that means – although I imagine Anthony might know)

Overall, during the course of the next weeks, I held on to the phone just to see what else I might find out about Anthony. I found out his last name through a friend who called, as well as the numbers of some of his friends. But Anthony himself remained elusive, even though I kept getting lots of his traffic 🙂

And BA? They were in the process of actively losing my luggage when I made a trip to SFO two days later. My bag was sitting right there at the terminal and for some reason, they had not scanned it upon arrival. The unhelpful staff were now apologetic. I guess that’s it for flying BA and their business beds 😉