Think ahead when creating operating system conditions
There's a pitfall that I see people falling into from time to time: operating system conditions. Such conditions can be useful as launch conditions to enforce system requirements or used with features, components or custom actions to install different versions of files or run actions depending on the Windows version.
If the developer tells you that the application will run on Windows XP SP2, Windows Server 2003 and Windows Vista, you could create a launch condition like this:
(VersionNT=501 And ServicePackLevel=2) Or (VersionNT=502) Or (VersionNT=600)
But that’s probably not what you really want, because your setup would be blocked on XP SP3 (which is expected to be released later this year), on Windows Server 2008, and in general on any future version of Windows. In my opinion you should only block if you are sure that your application will not work on these Windows versions (unless of course you have a business model of charging your customs again for the same piece of software with the condition removed <wink>).
In general I guess your system requirements actually are: Runs on Windows XP but requires at least SP2; runs on Windows Server 2003 or Vista or any future version of Windows. That results in the following condition:
(VersionNT=501 And ServicePackLevel>=2) Or (VersionNT>=502)
Note that VersionNT is 501 for XP, 502 for Server 2003, and 600 for Vista. On Windows Server 2008 it might also be 600 but I wouldn’t count on that. If necessary you can differentiate client and server versions using the MsiNTProductType property.
The Windows SDK lists all the predefined operating system properties and also has a reference table of OS versions and property values.
Here’s a trick if your conditions tend to become complex, unreadable and hard to manage, for instance if they additionally involve the operating system language. Use custom actions of type 51 (“set a property”) to set properties with intermediate results and use those to build your final condition.
A reminder in case you’re using operating system conditions on components: make sure to set the msidbComponentAttributesTransitive flag in the Component table, in case users update their operating system; in InstallShield this means switching the Reevaluate Condition setting of the component to yes.
I’ll close with a general recommendation for launch conditions (not for component conditions!): Either condition the LaunchConditions action with “Not Installed” in all sequences (InstallShield does this for you by default), or append “Or Installed” to your conditional expression. This ensures that your setup can be uninstalled even if the machine no longer meets the system requirements, maybe because a prerequisite software has been removed.