InstallAware Blog

Howdy InstallAware Community!

Visited our online ordering pages recently? If not, a pleasant surprise awaits you. We have partnered with Avangate to bring you our new, second online store.

Why have two online stores, do I hear you ask? That’s a great question. We have been partners with Cleverbridge for several years now - they have been our e-commerce provider for a long, happy time. Fantastic company, great people. Unfortunately the one thing they cannot do for us is a 30 day unconditional money back guarantee.

Even though we have had fully unlimited 30 day trials since the release of InstallAware 2.0 in April 2004, some of our users still ended up thinking that we are not willing to stand behind our product - just because we did not offer a money back guarantee. Oh, we are fanatical about our product and support - and yes, we do host at Rackspace

The reason we could not offer a money back guarantee was the hard costs incurred on each order, which Cleverbridge would not refund us. For a trial that’s already free it just did not feel right paying money out of our own pocket. However, we realized that our trial does not contain a go-live license (you cannot build setups with the trial version and distribute them legally). So - we decided we have to offer our customers the ability to go live with their InstallAware setups, in a sort of extended, paid trial.

Enter Avangate. With their help, we are now able to offer an unconditional, no questions asked, 30 day money back guarantee. This effectively doubles the trial period for all versions and editions of InstallAware to 60 days. You now have 30 extra days to use our product in full production. Did I mention we are fanatical about our product?

All you have to do is visit our online store, check the new Check Here to Enable 30 Day Money Back Guarantee check-box, and place your order. Your choice - order through Avangate for the money back guarantee, or through Cleverbridge if you are happy with the sale being final and non-refundable.

Of course, our prices remain exactly the same regardless of which store you choose. We are happy to have this opportunity to partner with Avangate in bringing you our new money back guarantee.

Now go and get hooked on InstallAware!

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

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
end

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

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.

Hello everyone, I hope you’ve all been well!

This post’s topic: How to customize your setup at build time. This could be used for different products, when only very few things change between them, and having a unique setup project for each one turns into a major copy and clone nightmare. It’s really a quite common scenario to have similar products using similar setup routines. At InstallAware, we actually ship a single installer that contains all four of our product editions - allowing users to choose at runtime which version they want to install. We might cover that in a later post; for now we’ll look at how to customize your installations at build time - emitting multiple “flavors” of a setup, if you will. This is where Compiler Variables come into play.

Compiler Variables are defined inside the Project Options window. To bring up this window, click the Project Settings button, found inside the Manage group of the Design tab.

Choose the Compiler Variables section and you’ll see three buttons, Add, Edit and Delete. This is where you define and set the initial values of your Compiler Variables. These variables are accessed using the #COMPILER_VARIABLE_NAME# format inside your MSIcode script. You may use these variables anywhere inside your script. Even MSIcode command fields which do not ordinarily accept variables will take compiler variables, since compiler variable values are “burnt-in” at build-time, and do not change at runtime.

In addition to replacing literals with values injected at build time, another use of compiler variables is to conditionally include/exclude parts of your MSIcode script. Use the Compiler Variable If, Compiler Variable Else and Compiler Variable End MSIcode commands to include/exclude parts of your setup project at build time. This adds a lot of flexibility to how you can build setups at runtime - you can take out whole blocks of MSIcode script, completely changing your setup logic and files - all at build time, and without needing to use complex automation.

Here’s a short list of what you can customize with compiler variables, among other things:

1. Product name
2. Product version
3. Product code
4. Files being installed
5. Features being built

Take look at the code below to see what I mean:

As you can see, one of my compiler variables is “MYPRODUCT” and its defined/initialized on the Compiler Variables section of the Project Options window. The above code builds some files and features if the compiler variable “PRODVERSION” is equal to “Enterprise” but excludes one file if the compiler variable “SUBVERSION” is not equal to “Full”.

You might also want to take a look at the pre-defined compiler variables that already exist in InstallAware. There are two kinds of pre-defined variables - pre-defined compiler variables and pre-defined script/runtime variables - so don’t get confused between the two. Both of these pre-defined variable kinds come in real handy for lots of things, like figuring out the execution path of your setup. I’d definitely encourage you to take a look at them. Just search for pre-defined variables and pre-defined compiler variables in the help index.

My favorite compiler variables are the following:

1. LOADOLDDATA: Instructs the setup engine to migrate feature selections from older versions.
2. PROJDIR: Resolves to the project directory on your system.
3. LOADOLDDATA: Instructs setup to change the way in which localizations are applied at runtime (see the help file for details).
4. BUILDMODE: Resolves to CD, SFX, WEB, or PATCH based on your setup build mode.
5. TITLE: Resolves to the name of the setup project.

Thank you,

Panagiotis Kefalidis
Software Design Team Lead
InstallAware Software Corporation

Hi. Many of you have asked if InstallAware supports detecting the newly released Windows Server 2008. It’s very easy by using the code below:

Set Variable SERVER2008 to FALSE
Get System Setting Service Pack 1 into SP1
Get System Setting Windows Vista into VISTA
Get System Setting Windows with Server Features into SERVER
if Variable VISTA Equals TRUE
     if Variable SP1 Equals TRUE
            if Variable SERVER Equals TRUE
                  Set Variable SERVER2008 to TRUE
           end
    end
end

After this code runs, if the variable SERVER2008 is TRUE, then OS hosting your installer is Windows Server 2008. You can add this piece of code somewhere inside your main setup script, or inject it as a requirement inside the “Check Application Requirements” code folding region to prevent your installation from running at all if the target OS is not Windows Server 2008.

You can also check for Windows Vista with Service Pack 1 using the same script but by removing the “if Variable SERVER Equals TRUE” evaluation.

You can download the script from here.

Thank you,

Panagiotis Kefalidis
Software Design Team Lead
InstallAware Software Corporation

Hello everyone, I hope you’ve all been well!

One extremely useful feature in the latest releases of InstallAware - assuming of course that you’re a sadistic developer and/or have a legal department with torturous inclinations - is detecting the scroll state of your license agreements. I’m sure you’ve seen those pesky setup programs which check whether you’ve scrolled all the way to the bottom before enabling the Next button. Well, now you can build those pesky setups in InstallAware also We’ve recently added (7.5 and 7 R2) the capability to detect the scroll state of text boxes and richedit boxes - the two dialog controls which are likely to host your license agreement files in InstallAware.

Of course, in the good InstallAware tradition, thanks to our generic implementation, you can even force the scrolling of your readme files, or any other custom files. Joy to the hearts of those who find this a useful feature When a Memo or RichEdit dialog control gets scrolled to the bottom, it now automatically sets its MaxLength property to 214783647 (that funny number is actually MAXINT from the Platform SDK). So if you want to check/enforce such scrolling, you just make use of this property. Let’s now go through a walkthrough of this:

First, you want to open up your license agreement dialog in the InstallAware Dialog Editor. One way of doing this is selecting the Design tab on the InstallAware IDE, clicking the Dialogs and UI button in the Views group, choosing the Dialogs page which lists all available dialogs in your current setup project, and then double clicking “licensecheck” - which is the default dialog that is used for showing license agreements. Of course, feel free to open any other dialog that you’d like to add this behavior to.

-

Once the dialog is open, double-click any control on the dialog until you see the Object Behavior window come up.

Go to the “Object Rules” tab to add two new rules, one to disable the Next button when scrolling has not occurred, and the other to enable it when scrolling has indeed occurred.

First, the rule that disables the Next button if the scrolling has not yet occured:

And second, the rule that enables the Next button when the scrolling has occured:

So, your rules should now look something like this:

The ordering is important when you have multiple rules. Always make sure that the disabling rules come first and the enabling rules come last. While in this example we only have one set of rules, observing the disable first/enable last rule of thumb becomes necessary when the Next button has multiple constraints upon it (for example, both a check-box and the scroll condition). You can always re-sort rules after having already added them using the Up/Down buttons located at the lower left corner of the Existing Rules listing.

Remember that you can always add more rules to fit your requirements! For instance, you could just as well enable/disable the proverbial I Agree check-box, instead of manipulating the Next button directly. Just use the simple logic demonstrated here: check whether the MaxLength property of the LicenseText control is equal to 2147483647 yet or not.

Let me know if you have any questions! Until my next post, have a great week! Now, go and make your users suffer

Panagiotis Kefalidis
Software Design Team Lead
InstallAware Software Corporation

In my last post, we covered using InstallAware to install or un-install a third party MSI package. In this post we’ll cover a related task, running a third party EXE setup package, using the Run Program As command.

What does Run Program As do? As the name suggests, it runs a program (an EXE file) or pretty much any other kind of document/file that is recognized by the system and has a registered viewer/editor. The Run Program As command is very similar to the Run Program command - it has a few extra bells and whistles, so we’ll cover that one instead of the simpler Run Program command here. But remember that you are free to use either one that suits your needs…

As we did for the MSI setup, we’re going to place our Run Program As command just before the Apply Install command. Before moving further, also find out what command line parameters your EXE setup takes. Most EXE setups have fairly standard switches, such as “/s” or “/q” to indicate (without the quotes, of course) a silent installation. Other optional command line switches may also be available/necessary. Since this is different for each EXE setup, you’ll have to research this one on your own. Try running the setup file with a “/?” or a “/h” command line switch and see if it provides documentation on its proper usage. It’s also always a good idea to check the website of either the software vendor or the maker of the setup authoring toolkit, as one of the two is very likely to have their command line switches documented somewhere.

Let’s assume that the EXE setup we’re running today takes a parameter named “/install” to indicate an installation and uses “/uninstall” to indicate removal. So configure the Run Program As command window as in the screenshot below. If you want to run the EXE setup silently - probably a good idea - also add its silent installation parameter to the command line. I’ll also to catch the result of execution inside a variable called “RUN_ERROR“. If you haven’t defined this variable before, Run Program As will automatically define it for you. Of course, you’ll again need to check with your vendor documentation to find out what the return values for this EXE setup program are. Most EXE based setups return 0 to indicate success and 3010 to request a reboot (notably, Microsoft’s EXE setups). Your own experience may vary, based on the kinds of EXE files you’re trying this out with.

You probably want InstallAware to wait for your EXE setup to finish installing before moving on to the main installation. Running two setups on the target system simultaneously may not be that great of an idea after all Check the “Wait for Program to Finish” check-box to enable this option. Also note that unless you wait, the RUN_ERROR variable will not hold the actual value returned by your EXE setup, and it will only be useful in determining if the EXE setup was actually successfully launched.

As for the uninstall, the process is very similar. We again call Run Program As, but this time with the “/uninstall” parameter. Place the command right before Apply Uninstall to make sure it’s being run at the right time in our MSIcode script, which in this case becomes right before the un-installation of our own product.

And yet again, I use the RUN_ERROR variable to catch any errors. A simple If command can later test the value of RUN_ERROR for me and determine if everything is kosher.

Well, that’s about it for running programs! While we’re at it though, another useful bit of information: You may also use Run Program As to execute your own main program file after your own setup finishes installing. By default, all InstallAware themes have a “Run Program Now” kind of checkbox in the setup finished wizard step, but even if your end-user checks it, that won’t do anything unless you let InstallAware know what to run here:

Replace the “Comment: TO-DO: Insert command that starts your application here” line with your own Run Program As command, specifying a target path like “$TARGETDIR$\yourexenamehere.exe“. Please note that most .NET applications today DO NEED their working directory field set to “$TARGETDIR$“, otherwise they will silently exit or raise strange startup errors. A well-authored application should never make assumptions about its startup folder, but some of us still do

The Run Program command, by the way, automatically sets the startup folder to the same folder as the program being run - so no need to manually enter a directory in there, if you used that command instead.

And for that matter, the Run Programs visual designer in the InstallAware IDE lets you do everything we did above graphically - even choosing the scheduling of the program being run:
a) Before Install
b) After Install
c) Before Uninstall
d) After Uninstall
e) Finish Dialog

 
Completely visually. But hey - it was fun to learn how to do it in script too, wasn’t it And if I had told you that at the beginning, you might not have read this far At least now you know what MSIcode script the Run Programs visual designer emits in the background for you

Well have a great month and talk to you soon!

Panagiotis Kefalidis
Software Design Team Lead
InstallAware Software Corporation

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

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