Image of Navigational Map linked to Home / Contents / Search Where never the twain should meet?

by GUI Computing Staff
Image of Line Break

Is VB6 That Bad?

Despite the tales of doom we've heard from some quarters (like :- "Don't install VB6!"), our experience with VB6 is pretty positive overall. That's not to say it's perfect (it ain't!) and not even to say that we'd be shipping our next mega-app using an unreconstructed VB6 Initial Release as the basis for it (we wouldn't!). But MS have provided a number of patches - see http://msdn.microsoft.com/vbasic/technical/support.asp for details of the (too long) list - and generally things aren't as bad as some paint them. What issues remain in the product itself should be addressed in the SR-1 patch (out RSN).

Our experience with VB5 and VB6 co-existing is, perhaps, less happy. There are definitely some gotchas that developers need to take into account. These aren't necessarily VB6 bugs per se, but more the result of the increasingly-complex interactions between Microsoft products as a whole. We document some here, and if you have any you'd like to see added to the list, please drop us a line.

Breaking Installations (1)

If you have installed VB6, and then compile a VB5 install on your machine, there's every likelihood that your previously-perfect install just won't work anymore (on a non-VB6 machine, at any rate).

What you'll get after the install completes "successfully" is something like :

"The Jet VBA file (VBAJET.DLL for 16-bit versions, or VBAJET32.DLL for 32-bit versions) failed to initialize when called. Try reinstalling the application(s) that returned the error."

The problem would appear to be that VB6 upgrades DAO - no real surprise there. But the new version of DAO is dependent upon EXPSRV.DLL, so naturally enough you'll need to add this file to your install.

Breaking Installations (2)

Those developers using WISE (at least, those not using the super-dooper new version, reviewed this issue) should be careful when they first cut a VB6 installation.

Obviously, since Wise version 6 has no VB6 run time support 'out of the box' you need to use the vb6.wse and vb6check.wse now available from Wise. However, vb6.wse has a small bug that can really catch you out. At least, it looks like a bug...

In vb6.wse, the source path for MSVCRT40.DLL is noted as :

Install File  Source=%_VB4WIN32DIR_%\SetupKit\KitFil32\Sys32\Msvcrt40.dll

whereas all the rest of the DAO support files are noted as :
Source=%_SYS_%\<filename>

Changing that line to be similar :

Install File  Source=%_SYS_%\Msvcrt40.dll

... means no problems!

Breaking Installations (3)

We have at least one reported instance of a SourceSafe 6 only installation installing DLLs which subsequently "broke" an installation which was working. Which DLLs? Who knows.

Bottom Line : Do not install any components of Visual Studio 6 on any workstation still used to generate VB5 installs - no matter what installer you use.

Breaking Workstations (1)

Never install office 97 after VB6, as this will hose your Windows Common Controls. In fact, it can seem like just about every OCX on your system has decided to take early retirement! And worse, reinstalling individual controls seems to have no effect.

The most obvious advice is to try to install such software in order of release...
For example: NT4, Service Pack 3, Office 97, NT Option Pack, VB6, SQL 7.

Of course, coming up with exactly the right sequence isn't all that easy . And it doesn't do much to address the "but what do I do now?" problem.

Another option which seems to work is to :
Reinstall VB6. This will fix things like Windows Common Controls
Install Office 97 Service Release 1. This should fix the rest. It should be noted that you don't have to run all of the Office SR1 update, you just need to start it. At least, that appears to be the case. Or perhaps you just need to go to the Office Updates web page. Or maybe the Moon must be in the Seventh House. Who really knows any more?

Breaking Workstations (2)

So, you have a perfectly operational VB6 workstation. Then you install a utility written in VB6. Hey, what harm can that do?

Well, plenty as it turns out... try not being able to access any controls from the design environment!

The culprit here is a rogue version of COMCAT.DLL.

The version which comes with VB6 is 4.71. From somewhere (no idea where just yet, but we'll track the dang thing down eventually!) we had managed to get version 5.0 of the same DLL onto the machine from which the install was cut.

This version refuses to load controls, preferring the much more interesting error :

System Error &H80004002 (-2147467262)  No such interface supported.

Luckily (once you figure this out) the solution is easy. Simply unregister the version 5.0 DLL, replace it with the correct version 4.71 off the VB6 CD and re-register.



Written by: GUI Staff
October '98

Image of Arrow linked to Previous Article Image of Arrow linked to Next Article
Image of Line Break
[HOME] [TABLE OF CONTENTS] [SEARCH]