vb6.0 app distribution and dll hell


While shipping out a vb6 application that targets many versions of windows (98 to XP) one of the major problem is to ensure the right version of the dlls for the different platform. e.g. the msvcrt.dll from xp, when installed on 98 can unsettle the win98 system.

Following microsoft site is a good reference for checking out the versions of dlls.

however there is no place to download the dlls (all version) that you need. The only way seems to be to actually copy these files from respective installations of windows versions.

Is there a place where you can get to download different versions of these files?


ps: www.dll-files.com have some collection of dlls but that's restricted to only the most recent version available to them!
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

What installation software are you using? Many of the windows system files are available as Merge Modules from Microsoft, and include their own logic whether they should be deployed or not, depending on the target OS.

I am currently using InstallShield Developer 8, and this is ideal to avoid OS version conflicts with MS dll's, as all I have to do is include the Merge Module in the InstallShield project.
It appears that you are not using an Installer to deploy your applications. You cannot simply copy the EXE and any other files your applicaiton uses to target machines as it will not always work (as is your case).

The installers make sure that you have the associated DLL's also installed when installing your application on a target machine and that they are the same or newer than the ones used by your application. This prevents errors where you copy your application to a machine that does not have the required DLLs (or older versions).

We are using InstallShield Express 5.0 (around 349 Euros) to deploy our VB applications.

InstallShield Express 5.0 is pretty good for simple deployments, but we needed the full development environment.

I think that ISDev8 was about 600 dollars when we bought it - check the website at http://www.installshield.com. We also have the western language pack (for multi-lingual installations) which was about 300 dollars.

Avoid using the PDW (package and deployment wizard) unless you absolutely have to.

Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

I have always found the the best MULTI-PLATFORM development strategy is to develop on the 'LOWEST COMMON DENOMINATOR' syste,.  That is, if I plan to support Windows 98 and ABOVE, then I MUST develop on Windows 98.  As you correctly point out, the newer versions of DLLS that are NAMED the same ARE NOT backwards compatible.  But it is ALMOST universally true the the earlier versions of those DLLS ARE upward compatible - eiter you can safely install the older version on the newer O/S, or the New version DLL, already present on the O/S will support that coding required by the older version code in your program.  Most installers will NOT over-ride an NEWER version of a DLL - already installed, with an OLDER version - from your package, but almost ALL will over-write on OLDER version with a NEWER one, and that is what leads to DLL hell.

I am using Inno setup which is absolutely free from jrsoftware.org. As Authur_Wood correctly pointed out, you may not get DLL hell problem unless you are installing in the 1st version of Windows 98.
graceworksAuthor Commented:
I forgot to mention that i use setup factory 6.0
sf6 have some merge modules for vb6sp5, mdac2.7, jet4sp3 and dcom95.

however these are currently not updated. e.g. the jet4sp3 merge module looks for mdac2.6

in any case sf6 does not have direct support for version checking of the core files such as comdlg32.ocx, msvcrt.dll, mfc42.dll that can play havoc when overwritten with the wrong version.

I have not tested InstallShield8.0 for its handling of these issues. But i am sure the problem must have been handled by someone (hopefully ms support) compiling a list of of all these troublesome files and their dependencies for various versions of windows (and are we forgetting the service pack ?? ;-)

I'd appriciate if anyone has a link to any such resource
"jet4sp3 merge module looks for mdac2.6" this is becuase later releases of MDAC dor NOT include the JET, and JET is now considered to be 'obsolete' technology, and Microsoft has indicated the intention to stop supporting JET in the near future.

YOu should be investigating ADO, to replace DAO/JET.

graceworksAuthor Commented:
I agree on down-with-jet line of action!

i use ado with jet oledb to connect to mdb....which is still an easy database format to include in the app, distribute, copy etc.


ps: can anyone suggest a resource (url, app, article...) that tells me in one place about the various combinations of dlls that i need to include in the distribution to avoide dll problem (see the original post of this thread...thanks!)
Ok. This is a problem that i face every time that I deploy my app, also because I have 1 priority: the app must work from w95 to winxp the same, without special adaptations more than ADO or maybe IE version.
Do you want to know how do I solve it? I just correct the legend on the error message. Instead of the ugly "access violation" i chage it to something like "This file is already in your system but is in use, so you can ignore the copy of it with safety".
Mainly because there's no problem caused by pressing ignore.

There's another solution but I didn't tryed it (my customers don't pay that much), and it is, in the PDW source code, you can search the very line where the error is raised and jump its execution if the file is msvcrt. So, nobody will notice it... ;)

I hope that this can give you another point of view, when the situation is that a customer won't pay enough as to make us solve microsoft's bugs and for this I will raise a quotation from the microsoft website for this very problem
suggested solution: "you may want to consider the possibility of using a thinrd party application"

Regards, Mauro
Moderator, my recommended disposition is:

    Save as PAQ -- No Refund.

Dan Rollins -- EE database cleanup volunteer
PAQed - no points refunded (of 250)

Community Support Moderator

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.