VB6 Application Failure on Win 7 Box

[steven54]

VB6 will not install my programs on a Windows 7 machine.

I tried using the default deployment package that ships with VB6 and it fails.

I tried the Inno software deployment package and it generates the same error.

The entire day was spent trying to get past this. There has to be a way!

This is what I get:

Thanks in advance!

When a door closes another door should open, but if it doesn't then go in through the window.

 

[dilettante]

The PDW was replaced for most purposes by Visual Studio 6.0 Installer 1.1 back in 1999 or so. Of course Microsoft no longer hosts the free downloads making up this tool so you snooze you lose.


Both of these libraries are unsafe to deploy. They are shipped and serviced as part of Windows just as they have been for a very, very long time (almost as far back as Win98 or so). You are expected to know this as a developer.

If you have been doing this (or attempting to) just stop. It is best to add them to the [Do Not Redistribute] section in:

[tt]C:\Program Files\Microsoft Visual Studio\VB98\Wizards\PDWizard\VB6DEP.INI[/tt]

You are responsible for updating this file because its contents are considered target OS dependent. If you are still targeting ancient versions of Windows such as WinXP, Win2K, Win9x you would ideally maintain several copies you rotate among as needed. However for these two libraries it is probably safe to just exclude them no matter what OS you are targeting.

You can also manually exclude them when the PDW picks them up because you failed to keep the directive files (VB6DEP.INI, many .DEP files) up to date.


As for "no-no setup" all bets are off. As far as I know it doesn't have the brains to look at VB6DEP.INI or .DEP files associated with libraries and leaves you to succeed or fail on your own.


What's more alarming is that you are seeing these access violation errors. Clearly your setups are not running elevated as they should be.

Normally elevated legacy scripted setups such as these are allowed to go ahead and make a mess, then Windows System File Protection catches the faulty deployment and repairs things silently. Better not to make a mess in the first place though.

Ideally you'd just move to proper Installer packages (.MSI) and stop using obsolete approaches, but with proper caution they can still be viable. But even then you need to know what DLLs to avoid trying to deploy. This is covered in numerous MS KB articles from 1998 to present.


As an example of the complexity of the deployment story for msvcrt.dll see:

PRB: A Required .DLL file, MSVCRT.DLL, Was Not Found

Cause

The version of files MSVCRT40.DLL and OLEPRO32.DLL in Windows 2000, Windows NT 4.0, and Visual C++ 4.2 are wrapper DLLs that call functions in a new file, MSVCRT.DLL. The file MSVCRT.DLL is included in Windows 2000, Windows 98, and Windows Me, but not in Windows 95 or Visual Basic 4.0.

So to target Win95 your setup must make sure msvcrt.dll has been installed, but after Win95 it is part of the OS and your setup should never try to deploy it.

 

[strongm]

>Visual Studio 6.0 Installer 1.1

This is still available from a number of locations, but here it is from an old copy of the Microsoft MSDN site:

http://web.archive.org/web/20080513102621/http://msdn.microsoft.com/en-us/vstudio/aa718352.aspx

But as dilettante suggests, make sure you educate yourself about application deployment

 

[steven54]

Thanks for the reply!

After spending a couple days researching this I decided to retire all my VB6 programs for sharing.

Been dabbling in Visual Studio 10 C++ for a while and it is about time I get serious with it.

For the small programs I develop VB6 got the job done. The programs were very reliable and the customers never cared what language they were developed in. I can see there is a security risk with continuing down the VB6 path.

I did learn there is a new version of VB coming out this spring or summer. VB 15 or VB 16, not sure on the number. Some say it is just moire .Net Framework Time will tell.

Thanks again for your help!

When a door closes another door should open, but if it doesn't then go in through the window.

 

[dilettante]

VB6 hasn't really been useful for non-professional use for a long time. UAC was just the last straw, but even on Windows NT 4.0 most programmers seemed to limp along relying on appcompat and making everybody an admin so they could pretend they were on Win9x.

After VB5 Microsoft dropped the "Standard" SKU entirely to reflect this.

But if VB6 is causing you grief I can't imagine how moving to C++ is going to help you.

And no, there was no VB after VB 6.0, only a long and growing list of pretenders that are all actually VB.Net.

 

[strongm]

>Some say it is just moire .Net

Yes, it is. It's Visual Basic 14, which is coming - perhaps confusingly - as part of Visual Studio 2015

 

[tedsmith]

I have had no problems with installing vb6 and service pack 4 on a number of Windows 7 machines.
Are you sure you have a genuine VB6 disk (or a copy of one) or do you have one that has been copied without all the files?
When you install it make sure you don't overwrite any existing system files. Maybe that is what you did in which case you might have to reinstall Windows 7

The only problems I have had are with Windows 7 64 bit, some of the old DLLs and OCXs don't work and some of the versions of the various references don't work.
Also I get a flickering of text when changing label.captions at run time so I always use a rich text box instead of a label if I want one to change during run time (such as showing the time of day seconds in a "digital clock").

Running in compatibility mode and as an administrator seem to give less trouble.

Comments about professional use of vb6 I suspect are a little boastful. There are still many simple uses of computers that don't need anything better.
Because it is often much quicker to use vb6, the product could also be cheaper and is often just as quick to run on a modern fast computer.
Not all computers are mounted in spacecraft or hooked up to the internet.

Who knows - it might even attain vintage status and become more valuable again so don't throw away your disks yet!

 

[dilettante]

His problem comes from trying to deploy libraries that cannot be redistributed. But the errors he posted images of above look like an unelevated install attempted on a machine with UAC completely disabled - so he doesn't even get to the fundamental error. Windows successfully protected itself in this case.

 

[tedsmith]

Did you make and compile the program on a machine running WINDOWS 7, XP, 2000 or even 98?
Some time ago I had some problems running an old prog I had complied in XP. When I recompiled with VB6 loaded in the Win7 machine (being careful not to overwrite any existing system files) it ran OK in the Win7 machine - don't ask me why! Maybe something do do with registering the DLLs or with dependencies? Also some old DLLS won't run in 64 bit WIN 7.

I notice there are many articles on this subject, one in particular from Microsoft is that you should never have the particular DLLS you are having trouble with listed as dependencies and it should never be updated when you install a new program anyway.
With PDW you might simply try un-tick them in the dependencies list when you make the setup files?