Monday, November 20, 2006, 12:03:00 AM
A few days ago I installed Vista RTM on my main development laptop machine and it went well. I’ve been using Vista since Beta 2 exclusively and my last install comes of RC1. RTM is a big step up from RC1 both in performance and overall polish of the UI and so far I haven’t run into any issues.
There are however a few UI oddities with all of my Visual FoxPro applications. I’ve found that many forms that are child windows of other forms are not properly sizing or losing their borders inconsistently when running under Aero. In many of my applications like the Message Reader and Help Builder I frequently have non-interactive message windows that pop up to indicate progress information and messages. For some reason all of these windows are mis-sized and show with their borders corrupted.
Here’s an example:
This is a dynamically resized dialog. The form is brought up and then resized. I've played around with additional refreshes and DOEVENTS, but nothing helps.
It looks like this is a problem with Aero – turning off Aero renders this dialog properly. Unfortunately I can’t really test this out with another video driver since Aero won’t run with the VGA driver <s>. Maybe somebody running the message reader can check and see if they’re also seeing this behavior with Vista and Aero. Use a long date range for the download date range to see the dialog more than a second <s>.
Unfortunately it’s not isolated to windows that are resized. Occasionally I see this behavior on just plain child windows. Thankfully it’s only child windows that exhibit this behavior but it’s still annoying. I have no workaround for this at the moment, but being cosmetic it’s not exactly a show stopper.
.NET 3.0 Runtime Gotcha
The good news is that I’ve got all of my applications installing and running great on Vista otherwise. Help Builder required a few fixes for Vista specifically in relation to the .NET 3.0 runtime availability which screwed up the .NET version checks. Microsoft really screwed us with this bogus version numbering - .NET 3.0 is not really a new version of the .NET framework as it depends on the .NET 2.0 installation and there’s really no such thing as ‘running’ a .NET 3.0 application. I have a set of runtime checks in my application that detects the latest version installed and it failed with 3.0 but of course none of the runtime files can actually be found there so this was a problem. Here’s an updated .NET runtime version check:
* wwUtils :: IsDotNet
*** Function: Returns whether .Net is installed
*** Optionally returns the framework path and version
*** of the highest installed version.
LOCAL loAPI as wwAPI, x
lcVersion = ""
lcFrameworkPath = ""
loAPI = CREATEOBJECT("wwAPI")
lcWinDir = loAPI.getSystemdir(.t.)
*** Assume .NET 2.0
lcVersion = "v2.0.50727"
lcWinDir = loAPI.GetSystemdir(.T.)
*** Try to find the largest version number
lcFrameworkPath = lcWinDir + "Microsoft.NET\Framework\"
lnCount = ADIR(laNetDirs,lcFrameworkPath + "v?.*.*","D")
FOR x = lnCount TO 1 STEP -1
lcVersion = laNetDirs[x,1]
lcTPath = ADDBS(lcFrameworkPath + lcVersion )
IF FILE(lcTPath + "regasm.exe")
lcFrameworkPath = lcTPath
*** Strip of the build number and replace with 0
lnAt = AT(".",lcVersion,3)
IF lnAt > 0
lcVersion = SUBSTR(lcVersion,1,lnAt) + "0"
lcFrameworkPath = loAPI.Readregistrystring(HKEY_LOCAL_MACHINE,"Software\Microsoft\ASP.Net\"+lcVersion,"PATH")
lcFrameworkPath = ""
lcFrameworkPath = ADDBS(lcFrameworkPath)
* wwUtils :: IsDotNet
This code basically looks at the .NET paths and then reads backwards from the highest version until it finds RegAsm.exe which is one of the binaries that comes with .NET. .NET 3.0 doesn’t have this since it’s only a library version so it won’t be included in this check. IOW, this code only returns the ‘real’ runtime version <s>…
Program Files and User Account Control
Another more serious issue that will affect many applications is the default security environment and User Account Control. By default the Program Files Folder is off limits for writing files to local users. This means if you have applications that write in this directory things are going to work a little differently and maybe uh – unpredictably.
First the issue is that the default user by default has no write rights in the Program Files folder so if you install any applications there that require writing files – any files like configuration files or data files – that won’t work like it did under XP.
Now Vista does something here that will make MOST (but not all) applications run anyway even though the active user can’t write in this directory. Vista virtualizes the Program Files folder so when the application tries to write to disk it sticks the output user specific folder virtual folder in your user profile.
This will make your application work as long as it’s meant to be a single user application. Ah – but this will break your application if you need to have multiple users access the file either on the same machine with different user accounts or simultaneously via drive mapping.
If you need to share files between users either on the same machine or a different machine you’ll want to make sure that you install your data files in a separate location. This is nothing really new I suppose – Microsoft’s been harping on these guidelines for some time, but Vista enforces it.
Disable Admin Approval Mode
You can also get around for your own machine (but probably not for your customers <s>) by disabling Administer the ‘User Account Control: Run all Administrators in Admin Approval Mode’. With this option disabled are back to being Master of your Domain and get almost full control of your machine.
You can find this option with: Run gpEdit.msc. Then: Local Computer Policy | Computer Configuration | Security Settings | Local Policies | Security Options. The User Account Control options are at the end of the list and you can turn most of that crap off if you’re tired of the constant sleet of approval dialogs. But be aware that this will diminish some of Vista’s security if you’re the paranoid type and don’t take care of your machine <s>…
One of the big reasons for using Vista if you’re doing Web development is IIS 7. IIS 7 in the Ultimate and high end business SKUs for Vista provide a full version of IIS that has no limitations. You can create multiple Web sites and you can stress test at full throttle. There are no connection limits. The non-high end skus still have connection limitations but instead of being hard errors these will just queue effectively throttling IIS rather than throwing the annoying Too many connections that XP did. All versions of Vista include IIS although Home Basic and Starter don’t have any way to configure it. So we’ll have to wait and see how that works for development if at all. I have to set up a VPC to check that out.
IIS 7 has many improvements including a new pipeline that allows getting rid of ISAPI and replacing it with a much more streamlined pipeline that can create Web server extensions with either .NET code or Win32/C++ code. The programming of these interfaces is MUCH easier than ISAPI was providing an ASP.NET like architecture so it’s much easier to create complex code and take advantage of features. I’m a good ways into a rewritten handler for the Web Connection low level interface and it’s a pleasure updating to this code from the nasty ISAPI C++ code. But this is not real critical, since ISAPI still works just fine in IIS 7.
The biggest issue is that IIS 7 doesn’t install by default – you have to install from Windows Components. When you do make sure to enable IIS 6 Configuration compatibility which is required for just about any Web Application that has automatic installation. This includes Web Connection and anything related to Visual Studio’s Web projects. So make sure that these options are checked.
The installer by default also has many common modules disabled. For example, Windows Authentication, Basic Authentication, ISAPI, ASP.NET, ASP and many other common operations are all off by default. You should take a close look at the configuration settings.
Good news is that as far as Web Connection is concerned everything works without any issues. Installation works with the exception of the Visual Studio configuration (looking into that – but you can manually add the controls to the toolbox and configure the editor script mapping via the documentation).
I’ll have a more detailed post and a doc update soon with more detailed installation steps for IIS 7. But even without that Web Connection 5.15 should install without any fanfare on Vista.
Eventually I need to migrate the configuration routines to use the new WMI provider. Many configuration settings now are actually stored in the web.config file in the virtual root directory so the setting made there immediately become portable and application specific. This is a huge feature for any kind of Web application you need to move/update or install on many machines! The management console automatically writes changes into this file too so there’s nothing special that has to be done to do this.
Ok, that’s it for the moment. I’m glad to see that there’s relatively little impact to applications on the surface. I’m sure as time goes on we’ll find more issues we’ll need to deal with, but overall a big thumbs up from my end.