Fog Creek Software
Discussion Board

Installing VB 6 apps "in the wild". Problems?


I write shrinkwrap software in VB 3. Really.  Ok, stop laughing. 

My first programs back in 1995 were in vb 3 and all of my other programs reused a lot of that code, so I stuck with 3.0.  Now I'm ready to rewrite.

Has anyone has much experience with installing vb 6 apps as shrinkwrap or shareware, so that it's installed on PCs you have no control over? 

If so, have you had any versioning conflicts with the basic VB 6 dlls.  (I know that there are problems with some of the database components, but I'm not concerned about that. We don't use 'em)

If so:
Roughly how many installs?
How many versioning problems?


I'm at a crossroads, trying to decide which language to update all of our programs in: VB 6,, or Delphi.

(For more sordid details on that choice and the reasons for the rewrite, see:  )

I think VB 6 might be a very good option. It does everything we need and I'm very familiar with it.  HOWEVER, I'm concerned about the possibility of version conflics in the base dlls that VB 6 uses.

These apps are very simple, so we should only need the .dlls and .tlb that you'd need for a "hello world" app.

I'm trying to quantify this risk.


Tuesday, June 3, 2003

Clay, based on your *excellent* summation of the issues in your other shrinkwrap thread, I'd have to say give Delphi a try.

VB5 and its close cousin, VB6, originated the phrase "DLL Hell" - they were on the tip of the sword when the dotcom world was flooded with billionaire wannabes. Net result? You have no idea what you'll be facing on an install machine...

In addition, the VB6 runtime is over 1MB.

I'll have to agree if you're seeing a significant number of people download your product, go with the smallest install that allows you the features you need, and Delphi fits that description.


Tuesday, June 3, 2003

You can work out your projects dependencies as follows :

* All DLLs and EXEs referenced in "Project->References". (This will always include the VB runtime library and OLE Automation)
* All OCXs references in "Project->Components"
* Any DLLs that are contained within a "Declare" statement

VB6 ships with a "Package and Deployment Wizard" that can handle this - though it has numerous defects, particularly when uninstalling. It does, however, provide an easy way of listing all dependencies.

Better Than Being Unemployed...
Tuesday, June 3, 2003

Oh, and actually answering the question in hand...

Most installers will only install a file if there is not an existing copy of the file with a matching or later version. I use this policy and have deployed numerous VB apps without any problem.

Better Than Being Unemployed...
Tuesday, June 3, 2003 ? :-)

Frederic Faure
Tuesday, June 3, 2003

In practice, we now never have this problem. We use Wise to generate the initial scripts. The whole thing is sufficently painless that DLL hell feels like a thing of the past.
It was worse 3 or 4 years ago, but it seems to be a huge lot better now.

Peter Ibbotson
Tuesday, June 3, 2003

I use MS Visual Studio Installer. I created an MSI package for all the base VB6 DLLs. I place application specific DLLs in the application directory. This also removes the DLL hell headache. Oh, and test the install under VMWare of course.

John Ridout
Tuesday, June 3, 2003

Before you start building install kits for VB6 applications, make sure you install Service Pack 5 for VB6 (or Visual Studio 6) on the machine where you are building the install kits, available at:

This installs the latest versions of the runtime DLLs (and others such as the common controls) and fixes some DLL compatibility problems.

I also recommend that you use a "clean" machine (with the oldest operating system that you intend to support) as your "build" machine. That is, for your build system, use a system with only the operating system (and any necessary operating system patches and security fixes) and Visual Basic (or Visual Studio) installed - don't install any later versions of Internet Explorer, or any other software.

Philip Dickerson
Tuesday, June 3, 2003

John wrote: "I place application specific DLLs in the application directory. "


What if the user then installs a program with NEWER DLLS to the system directory and the user tries running a program with the NEW dlls and concurrently running YOUR app, which will use the OLD dlls?

Since only one instance of the DLL can be in memory, won't there be a hard to trace version conflict?

Tuesday, June 3, 2003

"Since only one instance of the DLL can be in memory, won't there be a hard to trace version conflict?"

No, since the DLL in the app folder and the one in the system folder are not the same. They can both be in memory at the same time because they're physically two separate files.

Frederik Slijkerman
Tuesday, June 3, 2003

John said that he installs *application-specific* DLLs in the application directory, so presumably this shouldn't happen because no other application will use them. Which leads to the question as to why they're DLLs at all if they're not shared but maybe they contain non-VB code, I don't know.

John Topley (
Tuesday, June 3, 2003

Better THan Being Unemployed wrote...

"You can work out your projects dependencies as follows :

* All DLLs and EXEs referenced in "Project->References". (This will always include the VB runtime library and OLE Automation)
* All OCXs references in "Project->Components"
* Any DLLs that are contained within a "Declare" statement"

We have a winnar!  ;)  That's pretty much what I was going to suggest.

Tuesday, June 3, 2003

Federick - diferent versions of the same DLL cannot be in memory at the same time - the only exception is if they are the newer .NET ones.

John(s) -  there are lots of reasons to split up your application into separate dlls instead of having one massive exe

My thoughts are -

absolutely get a clean install of various OSes you want to support (using VMware or ghost to image them) to test the installs

use Depends.exe and other tools to find out the dependances also read any runtime requirements for any third-party controls

get the lastest service packs of everything

use an reliable installer (WISE, Installsheild, INNO) to make sure you don't overwrite any newer DLLs

It not that bad if you are organized and methodical :-)

Tuesday, June 3, 2003

DJ wrote:-

use an reliable installer (WISE, Installsheild, INNO) to make sure you don't overwrite any newer DLLs

Which is fine until a less reliable installer does just the thing you carefully selected your installer to avoid.

Dlls are one way or another things to avoid in shrink wrapped software. Every shrinkwrapped program I've written (well internet downloaded application) has ended up with the same issues and requirements. Number 1 is don't touch stuff unless you really have to, so self-containment has been the name of the game.

Ben Thompson
Tuesday, June 3, 2003

Some people have an incredibly soft idea of what 'hell' constitutes, most 'dll hell' scenarios turn out to be easily resolvable and not worth all the hot air.

It's only the hacks that have problems, then they make themselves feel better by using term such as 'dll hell' to justify incompetence.

Wednesday, June 4, 2003

"most 'dll hell' scenarios turn out to be easily resolvable "

Hmmm... you may be right, I've never had DLL problems with vb3, but it's a "dead" language.

I wonder why MS is making such a big deal out of .net doing away with DLL hell, then?

Wednesday, June 4, 2003

"DLL Hell" is the result of a leaky abstraction.

DLLs are good because they allow you to partition work up into modules, and stop you from having to recompile an entire monlithic app from scratch. I'd like to see you run a project with more than one developer without them.

The abstraction leaks when you update one module but not another dependent one.

I don't have a problem with "DLL Hell", but then again I work through issues methodically, and always do a full installation test on "clean" (fresh OS install) and "dirty" (take a clean PC and install any random software lying around) PCs.

I'm sure .NET DLLs will have leaky abstractions of their own that people will run into soon enough...

PS : Do people get "shared library hell" in UNIX? At least there it's standard to include the version number of the library in its name.

Better Than Being Unemployed...
Wednesday, June 4, 2003

How are DLLs an abstraction?

Wednesday, June 4, 2003

I'm getting a little sick of the "leaky abstraction" phrase being trotted out as an explanation of just about anything, but I'll try to tackle this one...

The DLL is an optimization. The basic idea is this:

1) Several different programs all use identical code

2) Since the code is identical, each program having its own copy is a waste of space

3) Therefore, if we dynamically load this shared code, then we can save disk space.

The problem is the assumption in part one. The library may LOOK identical from the outside, but unless it's bit-for-bit identical, something's going to be different, and that difference is going to break somebody's program.

As a result, we get into the nightmare around VC++ 5 with multiple different, incompatible versions of the MFC runtime all named MFC42.dll, or the many different versions of msvcrt.dll.

And the truly obnoxious part of this problem is that technology has made the initial assumptions obsolete - 200 GB drives are less than $300 these days. Who needs to save disk space?

On Unix systems, they have DLL problems, but the bigger problem is dependency hell - not knowing what libraries an app depends on. Or if you do know, finding out that it will only work with one particular old version of that library that isn't compatible with your C runtime library or something stupid like that.

The .NET solution improves on things by:

1) Preferring private rather than public libraries, so you've got a well-defined place to put your dll's.

2) Strong naming so that libraries aren't just identified by a name - the version number, culture, and originator are all in the library and cryptographically signed so you can specify EXACTLY what version of a library you need, right down the to exact set of bits.

3) Side by side deployment, so if you DO used public (as opposed to private) dlls, you can have multiple versions of that dll on your machine simultaneously.

4) Strong metadata, so all dependencies are included directly in a DLL. You can walk up to any arbitrary DLL or EXE in .NET and find out what all the dependcies are fairly easily.

Chris Tavares
Wednesday, June 4, 2003

*  Recent Topics

*  Fog Creek Home