Classic VB Corner

Vista Versus VB

Microsoft's pledge to support the VB 6.0 runtime via Vista may not be as promising as it seems -- here's what you really need to know.

• By Karl E. Peterson
• 09/14/2007

The Visual Basic team's goal is that Visual Basic 6.0 applications that run on Windows XP will also run on Windows Vista. The Visual Basic team is also committed to the Visual Basic 6.0 development environment running on Windows Vista. As detailed in this document, the Visual Basic 6.0 runtime will be supported for the full lifetime of Windows Vista, which is five years of mainstream support followed by five years of extended support.

On the surface, that sounds wonderful. Full support for the next 10 years! At least on Vista. In reality, if you run into any anomalies, Microsoft will quickly tell you that the IDE isn't actually supported. This column outlines what I've found necessary to get the IDE up and fairly functional.

As in older NT-based systems, it's generally necessary in Vista to install software as an administrator. In Vista, unlike older systems, even when logged into an administrative account, you have to take extra steps to ensure this happens. When you first insert the VB6 CD -- or mount an ISO image of it if you're using Virtual PC -- Vista will ask you whether you want to "Run SETUP.EXE" or "Open folder to view files." Choose the latter. A Windows Explorer instance will pop, open to the root of the CD. Right-click SETUP.EXE and choose "Run as administrator," an option that isn't available under AutoPlay.

Here's where our normal installation path really forks from the past. By default, a new Vista "feature" called User Account Control (UAC) is enabled, the stated purpose of which seems somewhat at odds with how most users "experience" it. The idea behind UAC may be noble, but in implementation it just seems to be one of paternalistic protection. Remember that old Tip of the Day, "Don't run with scissors"?

Vista's assumption is that all admins are machete-wielding track stars. For the time being, I've chosen to run with UAC enabled, just so that I might better appreciate how this OS is treating folks. My most common observation so far? Almost invariably, when I mention to an acquaintance that Vista "won't let me do!" something anymore, I'm told: "Works fine, without UAC on." More on that, below.

Unidentified and Incompatible?
Back to running the setup. If you have UAC enabled, you'll now be told (Figure 1) that "An unidentified program wants access to your computer." You'll want to consent to allowing this program to run, of course, given you just started it.

[Click on image for larger view.]

Figure 1: Needless Dialogs. Vista just heaps abuse upon the administrator who takes it upon himself to actually install software. Accept it and move on. Or, turn off UAC and never understand why your users complain so much. Your choice.

Undaunted, Vista ups the ante (Figure 2) by invoking its Program Compatibility Wizard, which tells you, "This program has known compatibility issues." (Hmm. A moment ago, it was an "unidentified program.") You can choose the "Check for solutions online" button, if you're appreciating this MS Humor, but just punch the "Run program" button and move along.

[Click on image for larger view.]

Figure 2: Unidentified, Unknown Publisher, Yet Incompatible? You make the call. One is left to wonder, though, just how much the folks up in Redmond were laughing as they dreamed this stuff up.

Finally, the old familiar VB6 setup program will begin, and you can start answering the more benign prompts you're already well-accustomed to: name, organization, CD key and so on.

Oops, dang it -- seems setup spawns another program (ACMBOOT.EXE) with "known compatibility issues" as well, and you'll have to punch that "Run program" prompt again. Back to the familiar. Choose all your installation options and let it rip. Restart Windows when prompted. Install MSDN following pretty much the same pattern as above.

If you're following the standard "least privileged" advice and not planning to always run as an unencumbered administrator, the last step in the initial installation will be to do a little touch-up on the shortcut that starts VB. In the Start menu, right-click "Microsoft Visual Basic 6.0" and select "Properties." On the "Shortcut" tab, press the "Advanced" button, check the "Run this program as administrator" and press OK. While you're there, you may want to set the "Start in" folder to wherever you keep your code. Still in the Properties dialog, on the "Compatibility" tab, again select "Run this program as an administrator" (if you'll be running VB from multiple log-ins, do this last step after pressing the "Show settings for all users" button). Press OK as many times as it takes to close the Properties dialog. Accept the now-perfunctory slap in the face, saying you need admin privileges (you do, of course -- duh) to make this change. You'll be asked again (Figure 3a and 3b, below) if you really truly meant to do this. No kidding.

Patching Things Up
The last step you'll probably want to take is bringing your installation up to whatever level you consider current. As with most things programming, of course, there's the usual disagreement on this point. Microsoft "supports" Service Pack 6 (SP6) on Vista, and that's it. Installing SP6 is actually very straightforward, other than the obligatory UAC "are you sure?" meddling.

Installing Service Pack 5 (SP5), which a great number of users consider the latest/greatest, is another can o' worms. Part of the SP5 installation is checking to make sure an up-to-date version of MDAC is present. In Vista, MDAC is now WDAC, so this check is all fouled up. Your task becomes patching the patch, so the SP5 setup ignores what it's been programmed to do.

You'll need to extract the entire SP5 distribution to a temporary folder and modify a single line in the STF file that ships with the update. This file goes by several names, depending on whether you have the entire Visual Studio or Visual Basic-only service pack bits. Regardless, there's only one STF in the distribution, so open it in a text editor. Search for a line that contains "CheckForMDAC." It, and the line above it, should look something like:

32 Depend "27 ? : 33"
33 IsWin95 CustomAction "sp598vbo.dll,CheckForMDAC"

Note the line number immediately preceding the "CheckForMDAC" line -- in this case, it's 32. Now search backward through the file for a line that has the word "Group" in it, followed by a long list of numbers:

13 Group	28 32 34 29 30 26 27 14 25 17 15 35 21 22

Edit this line to remove the previously referenced line number:

13 Group	28 34 29 30 26 27 14 25 17 15 35 21 22

Save the STF file, pop over to Windows Explorer, right-click SETUPSP5.EXE and select "Run as administrator." Bow to the now ritual UAC abuse. The MDAC check will be skipped, and SP5 should install without a hitch.

Today's Reason To Hate UAC
I know, I know, it's supposed to be "good for you." And I do try to run with UAC enabled, just so I can more fully appreciate the unending chorus of howls over this wonderful new way Microsoft has invented to protect us from ourselves. So you tell me -- just how helpful is this?

With UAC enabled, you can no longer drag and drop files from Windows Explorer into the Visual Basic Project Explorer. I do this all the time, day in and day out! Yes, all the little pop-ups are irritating, but the restriction from simply loading files into a running application is ludicrous.

Actually, it's worse than that. UAC only prevents this ease-of-use feature if you've started up VB using one of the "Run as Administrator" methods (as advised above). I guess the theory is that administrators can wreak far more havoc upon their own machines, should some rogue script (presumably already authorized by said administrator -- remember UAC is enabled!) start dragging files around the desktop, so Vista ought to force you to click a half-dozen extra times instead if you really  want to add a file to your project.

And so ends today's UAC rant. (I sense this will become a recurring topic, though.)

Parting Shot
If you'd like to toggle UAC on or off, one of the simpler ways to do it is to Start-Run-MSCONFIG. Scroll down on the Tools tab, find the options for "Disable UAC" or "Enable UAC," select the one you'd like, then press the "Launch" button. You won't be prompted, but the system will need to be restarted for the change to take full effect.