Random Rants & Raves

I’m updating my blog after a long time since I’ve been tied up in doing a large number of Windows 7 Application Compatibility workshops all across India with a number of Independent Software Vendors (ISVs) for their products. We’re basically testing out their products on the Windows 7 RC to see any issues that might surface and what they need to do to resolve them.

Most application run just fine on Windows 7. However, in the cases where there is an issue, it almost invariably turns out that the product has not been tested on Windows Vista and therefore it also fails on Windows XP. Vista and 7 have a tighter security mechanism called UAC that needs to be addressed in applications – and is something that many developers face problems with.

So here are two of the biggest issues that I’ve seen and their solutions:

Installers Using BAT/CMD/WSH scripts

Many applications perform certain install steps using DOS batch commands or in VBScript/JScript WSH files. Normally when Windows detects an installer running, it automatically elevates the installer so that the process has the necessary privileges to write into the %ProgramFiles% and %SystemRoot% folders and the registry at HKLM. However, if the installer is based on a script like the ones mentioned, they do not get elevated. Due to this, any file writes they do to protected folders or registry gets virtualized by Windowss. When the application starts up, it can’t find the required entries and fails.

Ideally the installer should use just the install process itself to do these tasks. However, if you do need to keep some part of it as a batch file or WSH script, you will need to elevate them. You can achieve this by using the ELEVATE.EXE tool from Wintellect available here. Download and extract the EXE from the Release folder and include it as part of your install. Now whenever you want to elevate a batch file issue the command:

ELEVATE File.bat

In the case of a WSH script, you will need to elevate the CSCRIPT file itself as in:

ELEVATE cscript.exe file.vbs

Writing settings on Application startup

There’s actually nothing wrong in doing this – in fact it’s recommended. What many products do wrong is the location to which they write these settings. A lot of apps try to write application or user level settings to their install folder under %ProgramFiles% or %WinDir% or %SystemDrive%. These are now protected areas and not allowed for writing. Most of these will also cause file virtualization to kick in and the settings file getting saved in the current user’s VirtualStore folder.

To avoid this, follow the simple rules given below:

Follow these rules and you will never have any issues with folder privileges and virtualization.