What are all the basic runtimes needed by VB6?

[esposito]

Hello, MS has often stated that, presumably, the next version of Windows will not be shipped with the VB6 basic runtimes.

Now, since I am still developing in VB6, I would like to create setup packages "ready for the future", i.e. installation files containing all the necessary libraries needed by VB6 applications to run.

So, my question is, what are the basic runtime files needed by VB6 apps to run?

Please do not consider any OCXs or third-party DLLs: just the libraries that would enable a "Hello-World"-type application to function under a Windows version that does not ship the VB6 runtimes.

Moreover, I would very much like to know whether these basic runtimes need to be registered in the Windows Registry or not. I know for sure that MSVBVM60.DLL does not require any registration, but I don't know about the other DLLs.

Any help will be greatly appreciated.

[Keithuk]

Just run P & D Wizard on a basic VB6 app, all the necessary files will be in the cab file.

[esposito]

Just run P & D Wizard on a basic VB6 app, all the necessary files will be in the cab file.

Thanks for your reply.

Since I currently Use Inno, I have removed the P&D Wizard from my PC.

Do you have a list of those files at hand? And do you know if they need to be registered?

[MartinLiss]

Moved.

[Logophobic]

This from the dependency file created by P&D Wizard for "Hello World", an app containing a single MsgBox call from Sub Main.

Uses1=MSVBVM60.DLL
Uses2=OLEAUT32.DLL
Uses3=OLEPRO32.DLL
Uses4=ASYCFILT.DLL
Uses5=STDOLE2.TLB
Uses6=COMCAT.DLL

[randem]

If you also use ********** they are installed in the folder where you installed **********. You should be aware that you do need to have a select version number for each file. Using the ones found on your PC may not be advisable...

You can also use the Universal VB Runtimes SP and install them that way.

[jcis]

Read this
http://www.jrsoftware.org/iskb.php?vb

[esposito]

Thank you, everybody, for your help.

So, if I have understood well, the basic runtime files needed by VB6 are the following:

1. MSVBVM60.DLL
2. OLEAUT32.DLL
3. OLEPRO32.DLL
4. ASYCFILT.DLL
5. STDOLE2.TLB
6. COMCAT.DLL

As I said, I know for sure that MSVBVM60.DLL does not need to be registered. This means that if you place it in the app folder, your app will work just fine.

What about the other DLLs? Do they have to be registered or not? Is it enough to place them in the app path or is it necessary to create a setup package to register them?

Thanks again.

[jcis]

All your App files should be installed using a Package Installer, all DLL files go to [WindowsFolder]\[System32 Folder] , not your App folder. If the DLL need to be registered you can do it like it's done in the previous Link, if not, your installer should just copy them to System32 folder. The same for OCX files. Be carefull on what you deploy, some files like comctl32 shouldn't be deployed, it could create serious problems if it's not the correct version. Take a look at these Inno Setup FAQs: http://www.jrsoftware.org/isfaq.php there they explain how to install many things. Also, Inno Setup has many different sample packages in its folder.

[randem]

Look at a script created by **********. You will have all the answers you need...

[esposito]

Thanks again, you've been crystal clear.

Now, I have just downloaded and used Dependency Walker to analyse the dependencies in one of my applications developed in VB 5.0. Interestingly, the resulting list of dependencies only includes the following DLLs:

MSVBVM50.DLL
USER32.DLL
GDI32.DLL
ADVAPI32.DLL
OLE32.DLL
OLEAUT32.DLL

Why are ASYCFILT.DLL, STDOLE2.TLB and COMCAT.DLL not there? Are they not needed by VB5 applications?

[esposito]

To sum up, it seems to me that, as far as VB5 applications are concerned, the only DLLs needed by them are

MSVBVM50.DLL
USER32.DLL
GDI32.DLL
ADVAPI32.DLL
OLE32.DLL
OLEAUT32.DLL

Since USER32.DLL, GDI32.DLL and ADVAPI32.DLL are an Integral part of the operating system (please correct me if I am mistaken), I don't think that MS is going to remove them from the next version of Windows.

What I don't know is whether the other two DLLs (OLE32.DLL and OLEAUT32.DLL) are only necessary to VB5/6 applications or they are somehow needed by the operating system itself. If the latter option is true, in the future I would only have to distribute MSVBVM50.DLL with my exe and it should work.

So, my question is, do you know if OLE32.DLL and OLEAUT32.DLL are only needed by VB5/6 applications?

[jcis]

VB5 Runtimes:
Msvbvm50.dll, Oleaut32.dll, Olepro32.dll, Stdole2.tlb, Asycfilt.dll, Comcat.dll

See this:
http://www.isocalc.com/support/vb5/index.htm
http://support.microsoft.com/kb/q180071/

EDIT: These files below (in red)are not VB Runtimes, but your App uses them, that's why you see them in dependency walker. But you shouldn't deploy these files, they are all OS system files (where APIs live), do you use APIs in your App?

USER32.DLL
GDI32.DLL
ADVAPI32.DLL
OLE32.DLL

Also, it's clear that your dependency Walker is showing your App dependencies but not VB Runtimes, but you need VB Runtimes anyway.

[esposito]

VB5 Runtimes:
Msvbvm50.dll, Oleaut32.dll, Olepro32.dll, Stdole2.tlb, Asycfilt.dll, Comcat.dll

See this:
http://www.isocalc.com/support/vb5/index.htm
http://support.microsoft.com/kb/q180071/

EDIT: These files below (in red)are not VB Runtimes, but your App uses them, that's why you see them in dependency walker. But you shouldn't deploy these files, they are all OS system files (where APIs live), do you use APIs in your App?

USER32.DLL
GDI32.DLL
ADVAPI32.DLL
OLE32.DLL

Also, it's clear that your dependency Walker is showing your App dependencies but not VB Runtimes, but you need VB Runtimes anyway.

Yes, I use plenty of API calls, since I have to compensate for the OCXs that I can't use (most of my apps must be launched from a shared folder, so I can't install them on the client machines).

I am very disappointed with Dependency Walker. It comes highly recommended but it looks like it is unable to detect VB runtimes.

So, all I can do is keep my fingers crossed and hope that MS will not remove those DLLs from the next version of their OS.

Thanks for your help.

[horazio]

I make little programs that I distribute thru my website or I send them to my friends I only make the EXE file and I never ever had problems.
None of my friends have VB6 installed.
So,my conclusion is : if you don't add extra controls your EXE will work 99% of the times on Win XP machines

[esposito]

I make little programs that I distribute thru my website or I send them to my friends I only make the EXE file and I never ever had problems.
None of my friends have VB6 installed.
So,my conclusion is : if you don't add extra controls your EXE will work 99% of the times on Win XP machines

Yes, I know it perfectly. The problem is THE FUTURE. From Windows 98 to Windows XP, the VB5/6 runtimes had been shipped with the OS. In Server 2003 and Vista, the MSVBVM50.DLL library was not included, but you can still find MSVBVM60.DLL.

If you program in VB5, all you have to do is distribute MSVBVM50.DLL with your exe and it will work fine under Server 2003 and Vista as well as under the old versions of the OS.

But what if, in the next version of Windows, MS decides to remove all the basic VB6 runtimes from the OS? This was the reason why I started this thread. How can we prepare self-sufficient installation packages which are ready for the future?

The answer seems to be, you must include SIX basic runtime libraries together with your exe, hoping that they will still be compatible with the new version of Windows...

[jcis]

I make little programs that I distribute thru my website or I send them to my friends I only make the EXE file and I never ever had problems.
None of my friends have VB6 installed.
So,my conclusion is : if you don't add extra controls your EXE will work 99% of the times on Win XP machines

From 2nd Link in post 13:

"I have a 'new' version of Windows; do I need to download and install the libraries?
If you have Windows 98SE, Windows NT4 SP6, Windows 2000, or Windows ME, the run-time libraries should already be installed. However, Microsoft have removed the libraries from Windows XP, so you will have to download and install them if you are running XP. You will soon know if they aren't."

[esposito]

From 2nd Link in post 13:

"I have a 'new' version of Windows; do I need to download and install the libraries?
If you have Windows 98SE, Windows NT4 SP6, Windows 2000, or Windows ME, the run-time libraries should already be installed. However, Microsoft have removed the libraries from Windows XP, so you will have to download and install them if you are running XP. You will soon know if they aren't."

As far as I know, MS has removed the VB5 libraries starting from Windows Server 2003. So, the only versions of the OS that are not shipped with the VB5 runtimes are Server 2003 and Vista. Try to believe.

By the way, when we say "the VB5 runtimes" we only refer to MSVBVM50.DLL since all the other libraries are exactly the same as those used by VB6, so there's no problem at all with them.

[bzelbob]

I am a former Microsoft Certified Solution Developer who has been working with VB extensively since version 3. I would like to make a few points that I think will help everyone:

1) Dependency Walker works. I have never had a problem with this tool. The difficult part is learning to use the tool and understanding the different issues surrounding the various ways dependencies can develop in your app. Your first reaction if dependency walker doesn't appear to work is to assume that you do not know how to use it correctly. Not trying to be mean here, just trying to help us all save some time.

2) You do not normally need to worry about USER32.DLL, GDI32.DLL or ADVAPI32.DLL when developing/installing VB6 apps. These DLLs are a part of the OS. Should Microsoft change much in these DLLs, they would probably break the majority of all apps written for windows.

3) To the best of my knowledge, the best practice concerning installing VB6 apps has always been to install ALL of these basic runtime file based on version checking each of the separate dll files. Otherwise your app has no chance of working on older machines that do not include the VB runtimes (especially the Win9x versions of the OS.) [Installing extra non-base things like comctl is a more difficult matter.]

4) The worst mistake I have seen made by novice programmers is include an entire OCX or DLL in their VB project just because they needed one function. What they failed to realize that the OCX they included also was dependent on 3 other DLLs each of which was also dependent on other Dlls and so forth. I've spent Lord only knows how much time cleaning up the mess from this. It is primarily caused by laziness and ignorance. Plan to keep your apps lightweight by analyzing dependencies ahead of time and actively working to keep your apps lean and mean.

5) As time goes forward, Microsoft has done many things to try to help, but that actually made the situation for developers more and more difficult. Windows file protection is just the first example of this. Ostensibly, it is a great feature that helps protect the system, but it caused lots and lots of problems for installation developers. (I've done this as well - mostly Installshield and the built in VB packaging stuff which has never worked right)
Also Windows Vista apprears to have done many things to make things even worse. This being said, it is absolutely vital that you check the Microsoft knowledge base for official windows info. Don't try to reverse engineer the knowledge yourself unless you find a problem with the official MS documentation (which does sometimes happen.)

Thanks,

Bob B.