Oh man, I’m going to REALLY hate Vista from an application installation and configuration perspective for custom applications.

To make a long story short, pretty much none of my Windows applications run under the default Vista security configuration. In fact, none of the ASP.NET apps install either at least not without manual configuration.

Let’s start with Html Help Builder which is a FoxPro standard Desktop application. It’s a developer tool and as such interacts with a variety of other components installed on the system. The good news is the app installs without any problems. However, there are a number of problems that I can’t see any good workarounds for.

First directory security issues. By default an installed app in Program Files has no rights to write files in Program Files or the install folder. A Program Files has Administrators with full access and Users with Read/Execute only. By default Vista installs the main user as a 'pseudo-administrator' which is not really an administrator, but that is part of the Administrators group. Basically the user is an administrator by name only meaning you are part of the group and any security settings at the file system (or registry) ACL permissions apply against the administrators group. Administrator does have read/write access in the install directory. A normal, just user only has read access.

What this means is if you have configuration files that are programmatically changeable and stored in your startup folder that won’t work. This includes writable .Config files BTW, which is a common scenario last I checked. I suppose the place to put this stuff then in Documents and the folder set up for the application, but this doesn’t account for global all user settings that should be shared. Same goes with any application that stores files in the install directory. Like load data tables. Ouch!

That one’s painful, but it gets worse. The next issue is that the account running the application itself can’t launch other applications. So in Html Help Builder I have a number of things that shell out, most importantly it shells out to the HTML Help Compiler which does not have an InProc or COM API and can only be running by executing an EXE. I’m screwed on that one and can’t think of a workaround. It works if I run in the pseudo Administrators, but not as a plain user.

Same with the auto-update routine. Html Help Builder has a routine that automatically checks for updates and can download the update and hotswap the files. There are MANY problems here. The download actually succeeds, but the downloaded file is named wwhelp_Update.exe. And guess what anything that has Update or Setup in the Exe file name gets treated special by Vista. It treats it like a Setup program and tries to elevate the permissions to run as Administrator. Well, since I’m shelling out to do this no elevation prompt occurs and the update fails with some obscure error (actually I’m getting file not found which is clearly not the error).

The problem however, is not just from shelling out. The Internet downloaded file also won’t run if I explicitly try to run the EXE EVEN IN THE PSEUDO ADMIN mode. Again the problem is Vista trying to be  fucking helpful and asking me to elevate permissions to run this SETUP program. Fine. But even with raised permissions the extraction of the ZIP file fails! Thanks. I have to rename the file and THEN it works.

This is easily fixable by choosing a different name, but that just tells you how lame this feature is. If you can bypass whatever this feature is trying to accomplish then this isn’t security. Incidentally I’m not clear of what this mode is supposed to accomplish. It was my understanding that the Setup mode was supposed to prompt and let you know that something is getting installed and then allow you to elevate permissions to allow a setup to succeed. Neither of these things seem to be happening – quite the reverse in fact.

So I think the only way I can fix this is to abandon this code I’ve used for nearly 10 years and uses a perfectly normal mechanism of an external application to handle code for me. Instead I’ll have to use an internal zip tool. That’s no big deal to fix, but of course it breaks the entire upgrade chain – people will need a new EXE – ie. A full install – before the new tools can be used. Big fun…

The greater problem here is that when you shell out you have no control over the EXE you’re executing and it may or may not work. With the Help Compiler as it turns out the compiler fails because the file permissions for it to generate the help file fails. With WinZip the same issues might apply. When you shell out you don’t get the UAC popup that asks you about this behavior so it just plain fails. If whatever shellout app requires special rights elevation you're out of luck

Next on my list was Web Connection which is another Fox application but it’s a developer tool that during installation heavily configures IIS. A while back I spent a bit of time making sure that Web Conenction properly works with Vista/IIS 7 at least in Metabase Compatibility mode.

However I run into the same SETUP.EXE problem mentioned earlier. SETUP.EXE fails and bombs straight out at the first attempt trying to access IIS Admin objects. And when I mean bombs out – I mean hard crash C5 – no nice trappable error like say Access Denied.

If I run the app in ‘normal’ mode it doesn’t crash, but it also doesn’t work – presumably because permissions aren’t there to access the IISAdmin objects and I can gracefully recover from that, which makes reasonable sense.

But this leaves me wondering? How am I supposed to log on to this app to actually get the appropriate rights?

1. I can’t configure IIS without Administrator permissions
2. But the Run as Administrator feature doesn’t properly elevate the application either (oh yeah and it crashes hard)

And this is just the first hour of screwing around with this stuff.

If you have a custom application that runs under XP, chances are it’s going to need some work to run right under Vista.

I think the Program Files permissions in particular are going to cause a heap of problems. And it seems we’ll need to move anything writable into the Documents virtual folder. Which is not so bad I suppose, but given that some data is not user specific this becomes an exercise in duplication (or storing the data in a true central store like a Database – making it harder for the developer and the user!).

This has been a frustrating afternoon and I’m not sure what to make of this. I got my work cut out for me working around this crap.

So much for backwards compatibility.