From: Nobody on
"NadCixelsyd" <nadcixelsyd(a)aol.com> wrote in message
news:202c20f9-13fc-4bca-80d2-217e9876c325(a)y11g2000yqm.googlegroups.com...
> Why install multiple versions of DLLs when only one is
> needed?

Normally, the file is part of a set of files that needs to be applied as a
whole, because these files interact with each other. See this article for
the list of files:

INFO: List of Visual Basic Run-Time Files Installed by Product
http://support.microsoft.com/kb/187282

Both VB5&6 use 6 runtime files having the same file name, except for one
file: msvbvm50.dll for VB5, and msvbvm60.dll for VB6. Because the runtime
files are shared, you will only need to install or update msvbvm50.dll in
OS'es with the VB6 runtime preinstalled. However, the proper thing to do
which also covers the case when the VB5/6 runtime are not installed or
included on the OS is to supply an installer that upgrades(or installs if
not there already) all the six VB5 files. The installer should check for the
version and only update if the file version being installed is newer,
otherwise you get what's called DLL Hell. One modern installer you could use
is InnoSetup. the instructions on how to use it with VB are at the link
below. Just edit the "60" into "50" in "msvbvm60.dll", and it should be
fine.

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

However, for inhouse use or for families and friends, you may want to
redirect them to run this VB5 runtime installer, which updates/installs all
6 files. I am not sure if it works with the latest version of Windows
though:

FILE: Msvbvm50.exe Installs Visual Basic 5.0 Run-Time Files
http://support.microsoft.com/kb/180071




From: ralph on
On Sat, 3 Jul 2010 08:45:09 -0700 (PDT), NadCixelsyd
<nadcixelsyd(a)aol.com> wrote:

>>
>> I don't have a Win7 machine handy, but jeez, what's the problem? ´┐ŻNobody in
>> their right mind distributes a VB application without an installation program
>> anyway, and the intall program automatically installs the dependencies
>> including the VM. ´┐Ż
>>
>I consider myself in my right mind, but you're entitled to your
>opinion.
>
>I prefer the KISS approach. Why make the user go through the install
>process when an EXE module can be moved into directory in the PATH
>statement? The uninstall is just as quick: delete the module.
>
>Since my original post, I've upgraded the program from VB5 to VB6.
>VB6 run-time modules are already (I believe) part of the operating
>system. Why install multiple versions of DLLs when only one is
>needed?
>

In the replies it was apparent that several ppl forgot you were
talking about VB5 and not VB6. The VM for VB5 is NOT commonly included
with newer O/Ss or SPs. If delivering a VB5 app then including the 5.0
VM is advisable.

What you are calling a KISS approach is not always the best way. To
paraphase Bruce McKinney famous quote - "It doesn't matter how fast it
is (or simple) if it doesn't work."

Windows applications are best installed through an Installer for
several reasons which may or may not apply depending on your target.
1) To make sure the target has all the components. (Already discussed
to death.)
What components to include would once again depend on the target.
For a known box, probably very little.
For an unknown box, probably the world. :-)
2) To make insure any initial configuration is setup correctly.
All Users
A single user
Profile?
Machine specifics
etc.
3) To insure the program is located in a consistent and logical (and
known) location.
4) To insure the app appears as an uninstall option, and that an
uninstaller is available.
5) To simply make it easier for the user - one click install, run.

But, again, it depends on your target.
In a shop/corporate environment I often provide two install packages.
One for initial setup for admin to insure proper location and
configuration, and setting up a standard image, and a second for
updates (often a simple xcopy-type).
[Actually the former is more often two packages - one for the box/net,
and other for the user.]
For friends 'n family I'll probably email the program with simple
instructions and stand by with IM open to handle the questions.
For a shrink-wrap package (or remote corporate sites) I'd likely build
a rather bulky include all, handle all, package.

But always somewhere is a formal installer lurking. You can get away
with a simle copy quite often - until it goes bad. IMHO it WILL always
go bad sooner or later, as you discovered. <G>

-ralph
From: Tony Toews on
On Fri, 02 Jul 2010 22:08:14 GMT, sfdavidkaye2(a)yahoo.com (David Kaye)
wrote:

>I'm thinking that this newsgroup is too nitpicky for my taste.

I'm just lurking on this discussion but it seems to me that this is a
highly technical newsgroup. Thus being a nitpickier and nitpickied
is necessary to fully understand what is going on bheind the scense.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
From: Karl E. Peterson on
Tony Toews formulated on Saturday :
> On Fri, 02 Jul 2010 22:08:14 GMT, sfdavidkaye2(a)yahoo.com (David Kaye)
> wrote:
>
>> I'm thinking that this newsgroup is too nitpicky for my taste.
>
> I'm just lurking on this discussion but it seems to me that this is a
> highly technical newsgroup. Thus being a nitpickier and nitpickied
> is necessary to fully understand what is going on bheind the scense.

Man, I love nothing better than having my ideas nit-picked! How else
do you find the flaws in them?

--
..NET: It's About Trust!
http://vfred.mvps.org


From: Karl E. Peterson on
on 7/3/2010, ralph supposed :
> What you are calling a KISS approach is not always the best way. To
> paraphase Bruce McKinney famous quote - "It doesn't matter how fast it
> is (or simple) if it doesn't work."

Yeahbutt, "work" is just so subjective...

You can *measure* fast! <gd&r>

--
..NET: It's About Trust!
http://vfred.mvps.org