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.

Microsoft has suggested, in a somewhat backhanded way, that the VB6 development environment (IDE) will be supported for the lifetime of Vista. Here's their latest summation of the future of Classic VB support:

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.

Figure 1
[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.

Figure 1
[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.

Figure 1

Figure 1
[Click on images for larger view.]

Figure 3a and 3b: Yes, I Really Meant It. Perhaps, as programmers, we can sympathize more than nearly anyone with this lunacy. Or perhaps not -- I don't know. It's just ever so irritating to be continually asked, "Did you actually mean to press that?" This sort of paternalism will ultimately make error dialogs even less-read than software licenses, since users will just mindlessly select the course of least resistance. And, as programmers, we really need to fear that day, when "doesn't work" becomes the best-case trouble report we can expect.

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.

comments powered by Disqus

Reader Comments:

Tue, Mar 23, 2010 Amriner Singh India

I have developed an application using VB6 in which drag and drop functionality is implemented. Its working fine on XP but on Vista when UAC is disabled then its not working. Is any suggestion so that it can also work on Vista without enabling UAC??????

Wed, Dec 23, 2009 Jim Huffman Bella Vista, AR

Once again, Karl, many thanks dude! You've bailed me out of jams quite a few times! Really glad to see the Classic VB Corner come back. The tips and code is great and commentary even better.

Sun, Nov 22, 2009 Vikram Australia

I developed one application in VB6 with ms access. Now I have to install it in other system. I am using vista. But If I install my application in other system as admin then it install ok. But when I start tha application just as user I mean by doubl click then it asking for database connection provider and database.... But If I run as admin then works alright. It should run without admin because every time run application as admin is not a way... So, can you suggest me some thing what can be the problem ????

Tue, Nov 17, 2009 Van Texas

The only reason Microsoft wants to move forward is to sell more period. Just say yes because we all know that. I'm on Win 7 64 bit running my VB6 with a few problem's but have always been able to get around things so far. I need to stick with VB for some time because where I work we just last year went to XP for all the systems and you can see the date I posted this. Yes some companies are slow to adopt new OS but why mess with new when the old works. XP was a good OS as is this Win 7. Have quite a few VB apps doing their massive chores daily from running machines to running high voltage tests.

Mon, Jul 27, 2009 nick

Some folks in the ms design team believe all softwares must be Microsoft. He asks "who are those injuns who want to deploy software" ?

Fri, Jun 5, 2009 Thomas Barnett Las Vegas

I think Microsoft has to move forward like any other business in the technical development industry. I still have VB6 on my XP computers, but I have migrated to VB 2008 on my Vista computers. It really doesn't take long to figure out the differences between VB6 and VB 2008 (VB.Net). As an example of string manipulation, in VB 6 you would use Mid$(Text, 13, 6) in VB 2008 you would use Microsoft.VisualBasic.Mid(Text, 13, 6). Give VB 2008 a try, you may find it just as intriguing as VB 6.

Tue, Mar 17, 2009 PeterB

Good comments on UAC.

I'm working on Server 2008 and it's nearly impossible.

Tue, Apr 8, 2008 Shiromal Sri Lanka

Dear Sir,

I am VB Beginer, like to have some free cd's or magazine about Vb language.

Best regards,
Chaminda Shiromal

Fri, Mar 7, 2008 B.Srinivasan India

No Microsoft should not stop supporting the VB 6.0 issues. Since it was / is one of the famous tool language during their life time

Thu, Feb 21, 2008 Jason

Let it die for pete's sake. Seriously.

Tue, Feb 12, 2008 John

No dead yet...

Wed, Dec 5, 2007 C.A. Brown Syracuse NY

I write programs in many different languages and they all seem to have their place. I use C#.NET and VB.NET but VB6 works extremely well for many new issues as well as legacy solutions. Many lines of COBOL are written in top business every year - despite being around for 30 some years - because it works and IT knows how to use it.

Sun, Dec 2, 2007 Anonymous Anonymous

couldnt agree more

Tue, Nov 20, 2007 Rob Crombie Australia

Karl, the (VB6) world is a better place, because you are on it.


Add Your Comments Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Please type the letters/numbers you see above

.NET Insight

Sign up for our newsletter.

I agree to this site's Privacy Policy.