Visual Basic 5.0 .EXE's and the various DLL's it needs 
Author Message
 Visual Basic 5.0 .EXE's and the various DLL's it needs

Hi,

I have heard a lot of comment made about the fact that VB5.0 exe's,
although truly compiled, still need a DLL that must be shipped with
the application. I may be over simplifying the issue, but why do
Microsoft not include these DLL's in the release of Explorer 4.0 or
any other new software?, indeed does anyone know whether they are to
be included ? I know this doesn't solve the problem, since you cannot
be sure that a user is running explorer 4.0, but surely the
proliferation of the DLLs needed at run time would be a good thing ?
I always wondered why microsoft did not do this with VBRUN300 and 400.

Ed
Freed Information Systems
Specialists in bespoke software development,
and consultancy to the media industry.

See our website (currently under construction) at :-
http://www.*-*-*.com/



Fri, 10 Sep 1999 03:00:00 GMT  
 Visual Basic 5.0 .EXE's and the various DLL's it needs



Quote:
> Hi,

> I have heard a lot of comment made about the fact that VB5.0 exe's,
> although truly compiled, still need a DLL that must be shipped with
> the application. I may be over simplifying the issue, but why do
> Microsoft not include these DLL's in the release of Explorer 4.0 or
> any other new software?, indeed does anyone know whether they are to
> be included ? I know this doesn't solve the problem, since you cannot
> be sure that a user is running explorer 4.0, but surely the
> proliferation of the DLLs needed at run time would be a good thing ?
> I always wondered why microsoft did not do this with VBRUN300 and 400.

How is it a "good thing" if it "doesn't solve the problem"?  Seems to me
that when a user loaded (or downloaded) Explorer, they'd be losing time and
disk space getting some files they may not ever use.  Whereas when YOU
distribute them you know they're needed (and make Microsoft's doing so
redundant).

However, this would make it more likely that Microsoft would "upgrade" your
DLLs, for good or (probably) ill.



Fri, 10 Sep 1999 03:00:00 GMT  
 Visual Basic 5.0 .EXE's and the various DLL's it needs

Ed,

Quote:
> I have heard a lot of comment made about the fact that VB5.0 exe's,
> although truly compiled, still need a DLL that must be shipped with
> the application.

Correction, VB5 requires about half a dozen DLLs.

Quote:
> I may be over simplifying the issue, but why do
> Microsoft not include these DLL's in the release of Explorer 4.0 or
> any other new software?, indeed does anyone know whether they are to
> be included ? I know this doesn't solve the problem, since you cannot
> be sure that a user is running explorer 4.0, but surely the
> proliferation of the DLLs needed at run time would be a good thing ?
> I always wondered why microsoft did not do this with VBRUN300 and 400.

I don't think it is necessarily a good thing. First, as you point out, not
all users would have these DLLs. Since you must distribute them, then, with
your app, where is the advantage here? Also, the proliferation of various
DLLs that VB does use is causing more problems than anything else with
regards to component conflicts during installation of your apps.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com



Sat, 11 Sep 1999 03:00:00 GMT  
 Visual Basic 5.0 .EXE's and the various DLL's it needs

Quote:

>Ed,

>> I have heard a lot of comment made about the fact that VB5.0 exe's,
>> although truly compiled, still need a DLL that must be shipped with
>> the application.

>Correction, VB5 requires about half a dozen DLLs.

Half a dozen? If you believe the VB5 setup wizard,yes. The wizard
included some big OLE*.DLL's into my setup program for no reason.

I included the MSVBVM50.DLL and 2 OCX's only, and the program runs
fine on a computer of a friend of mine. At this time I don't know
why the VB Setup Wizard includes so many OLE DLL's when the
program doesn't need them...

Bye

Robert



Sun, 12 Sep 1999 03:00:00 GMT  
 Visual Basic 5.0 .EXE's and the various DLL's it needs

The only runtime file needed to run a VB5 application is MSVBVM50.DLL. As
this DLL is 1,303KB in size it makes sense to include this with IE 4 and
Microsoft have said that this is what they will do. But would it not make
even more sense if the VB compiler only linked the runtime functions that
your application actually used and thereby created a much smaller runtime
DLL.

Mark Neville
Nanotec



Quote:

> >Ed,

> >> I have heard a lot of comment made about the fact that VB5.0 exe's,
> >> although truly compiled, still need a DLL that must be shipped with
> >> the application.

> >Correction, VB5 requires about half a dozen DLLs.

> Half a dozen? If you believe the VB5 setup wizard,yes. The wizard
> included some big OLE*.DLL's into my setup program for no reason.

> I included the MSVBVM50.DLL and 2 OCX's only, and the program runs
> fine on a computer of a friend of mine. At this time I don't know
> why the VB Setup Wizard includes so many OLE DLL's when the
> program doesn't need them...

> Bye

> Robert



Sun, 12 Sep 1999 03:00:00 GMT  
 Visual Basic 5.0 .EXE's and the various DLL's it needs

Quote:

>The only runtime file needed to run a VB5 application is MSVBVM50.DLL. As
>this DLL is 1,303KB in size it makes sense to include this with IE 4 and
>Microsoft have said that this is what they will do. But would it not make
>even more sense if the VB compiler only linked the runtime functions that
>your application actually used and thereby created a much smaller runtime
>DLL.

Yes, but that way you would create a new DLL for every program. I
think it's still better to use one 'shared' DLL for all VB5 programs.

Or, like in the good old QuickBasic days, a real standalone EXE-file
without DLL's . But that's almost impossible with a system designed
like Win95.

Bye

Robert



Mon, 13 Sep 1999 03:00:00 GMT  
 Visual Basic 5.0 .EXE's and the various DLL's it needs

Quote:
> I included the MSVBVM50.DLL and 2 OCX's only, and the program runs
> fine on a computer of a friend of mine. At this time I don't know
> why the VB Setup Wizard includes so many OLE DLL's when the
> program doesn't need them...

> Bye

> Robert

Sure, it runs on your friends computer now, but what about when Microsoft
comes out with other versions of the files that you are not including in
your install and your program fails to run?  There are numerous problems
installing VB4 apps with dll's that don't appear to be necessary either,
but if the computers got the wrong or older version of the dlls that you
are not including, your program will break.  What you are doing might work
since VB5 is just out, but as soon as you start using newer versions of the
dlls then your clients might have you will run into problems.

-Joel

 <//////////////=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=\\\\\\\\\\\\\\>
 / Joel Bierling                                                     \
 / President of Abstraction,   Phoenix Data Systems                  \
 / Calvin College's CS Club     -Middle Eastern Archaeology:         \

 / www.calvin.edu/~jbierl00/    www.calvin.edu/~jbierl00/phoenix.htm \
 <//////////////=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=\\\\\\\\\\\\\\>



Tue, 14 Sep 1999 03:00:00 GMT  
 Visual Basic 5.0 .EXE's and the various DLL's it needs

Quote:

>> I included the MSVBVM50.DLL and 2 OCX's only, and the program runs
>> fine on a computer of a friend of mine. At this time I don't know
>> why the VB Setup Wizard includes so many OLE DLL's when the
>> program doesn't need them...

>> Bye

>> Robert
>Sure, it runs on your friends computer now, but what about when Microsoft
>comes out with other versions of the files that you are not including in
>your install and your program fails to run?  There are numerous problems
>installing VB4 apps with dll's that don't appear to be necessary either,
>but if the computers got the wrong or older version of the dlls that you
>are not including, your program will break.  What you are doing might work
>since VB5 is just out, but as soon as you start using newer versions of the
>dlls then your clients might have you will run into problems.
>-Joel

Hi,

        In practice this is quite correct, what annoys me however, is
the lack of backwards compatibility you sometimes see in these DLL's.
The theory goes that apps should work fine with the new dll's because
they are backwards compatible. The practice is that often they are
not. Anyone who has tussled with ole and MS office will know this. The
reason for packaging the DLL's outlined above, can also be looked at
in another way. Say I send out an app, and package all the dll's that
the setup wizard tell's me to. Later that week, the user installs
explorer 4.0 which replaces all my DLL's with newer versions and my
APP stops working. It's one of these situations where you are caught
between a rock and a hard place. I would advocate distributing the
DLLs where possible, since then you know that the *majority* of your
user base are using the same files.

Ed.
Freed Information Systems
Specialists in bespoke software development,
and consultancy to the media industry.

See our website (currently under construction) at :-
http://www.freed.demon.co.uk



Tue, 14 Sep 1999 03:00:00 GMT  
 Visual Basic 5.0 .EXE's and the various DLL's it needs

Quote:
>Hi,
>        In practice this is quite correct, what annoys me however, is
>the lack of backwards compatibility you sometimes see in these DLL's.
>The theory goes that apps should work fine with the new dll's because
>they are backwards compatible. The practice is that often they are
>not. Anyone who has tussled with ole and MS office will know this. The
>reason for packaging the DLL's outlined above, can also be looked at
>in another way. Say I send out an app, and package all the dll's that
>the setup wizard tell's me to. Later that week, the user installs
>explorer 4.0 which replaces all my DLL's with newer versions and my
>APP stops working. It's one of these situations where you are caught
>between a rock and a hard place. I would advocate distributing the
>DLLs where possible, since then you know that the *majority* of your
>user base are using the same files.

>Ed.

I wonder what should you do when you install one program with new dll's,
and let's say MS office doesn't work any more, then you reinstall that,
and your program doesn't work any more...could this happen where 1 but
not both programs can work?


Tue, 14 Sep 1999 03:00:00 GMT  
 Visual Basic 5.0 .EXE's and the various DLL's it needs

Robert,

Quote:
> Or, like in the good old QuickBasic days, a real standalone EXE-file
> without DLL's . But that's almost impossible with a system designed
> like Win95.

Well Delphi for example make single executables unless of course you
call make own DLLs or buy custom ones. MS could at least reduce the
number of required DLL's. I'm pretty tired of having to use a Setup
program like Wise or InstallShield and doing version checking for even
my simplest VB 4.0 apps. Now from some rumblings I'm hearing I am
wondering if those apps are going to break when VB5 apps or Office 97
are installed on those machines.

John



Wed, 15 Sep 1999 03:00:00 GMT  
 Visual Basic 5.0 .EXE's and the various DLL's it needs

Quote:

> >Hi,

> >        In practice this is quite correct, what annoys me however, is
> >the lack of backwards compatibility you sometimes see in these DLL's.
> >The theory goes that apps should work fine with the new DLL's because
> >they are backwards compatible. The practice is that often they are
> >not. Anyone who has tussled with OLE and MS office will know this. The
> >reason for packaging the DLL's outlined above, can also be looked at
> >in another way. Say I send out an app, and package all the DLL's that
> >the setup wizard tell's me to. Later that week, the user installs
> >explorer 4.0 which replaces all my DLL's with newer versions and my
> >APP stops working. It's one of these situations where you are caught
> >between a rock and a hard place. I would advocate distributing the
> >DLLs where possible, since then you know that the *majority* of your
> >user base are using the same files.

> >Ed.

> I wonder what should you do when you install one program with new DLL's,
> and let's say MS office doesn't work any more, then you reinstall that,
> and your program doesn't work any more...could this happen where 1 but
> not both programs can work?

Anything is possible at this point, I have had numerous problems lately
with installing new versions of Office and VBCCE, and having it hose
several apps. I finally formatted my drive, installed everything again,
and I'm still hosed!

Microsoft is rushing things out too fast, because of their obsession to
dominate the Internet.

I know that as a programmer, I am not supposed to do this but, I almost
want to start installing system files into my home directory so that my
app will work (or should) no matter what.

--
Jim Dompier
IslandSoft

http://www.lava.net/~islesoft/



Wed, 15 Sep 1999 03:00:00 GMT  
 Visual Basic 5.0 .EXE's and the various DLL's it needs

Quote:

>I know that as a programmer, I am not supposed to do this but, I almost
>want to start installing system files into my home directory so that my
>app will work (or should) no matter what.

That doesn't work, because Windows always checks your system directory
first for DLL's or OCX's. If not found, it checks the application
path.

Bye

Robert



Thu, 16 Sep 1999 03:00:00 GMT  
 Visual Basic 5.0 .EXE's and the various DLL's it needs

Robert,

Quote:
> That doesn't work, because Windows always checks your system directory
> first for DLL's or OCX's. If not found, it checks the application
> path.

My experience has been the opposite. The approach of putting files in an
app's home directory fails anyway if another app has already loaded
different version of same DLL's from another location.

John



Fri, 17 Sep 1999 03:00:00 GMT  
 Visual Basic 5.0 .EXE's and the various DLL's it needs



Quote:

> >I know that as a programmer, I am not supposed to do this but, I almost
> >want to start installing system files into my home directory so that my
> >app will work (or should) no matter what.

> That doesn't work, because Windows always checks your system directory
> first for DLL's or OCX's. If not found, it checks the application
> path.

Didn't it used to work with 3.1 and MS changed it with Windows 95?  Seems
like that was my experience...


Fri, 17 Sep 1999 03:00:00 GMT  
 Visual Basic 5.0 .EXE's and the various DLL's it needs

Just a note:

I purchased the win95 upgrade less than three weeks ago and installed it.
After doing so I installed several new win95 programs (installed and
uninstalled VB5).

After a system crash tonight, I had to reinstall 95 with the option to
ONLY replace files that were missing.

The new install reported that several ocx and dll files were present on
the system and the 95 install versions were OLDER. The 95 install
recommeded that I keep the newer files.

I recognized the name of many of these files from those reported as
needed for a VB5 compiled exe program install. This indicates that usoft
changed files distributed with a VERY NEW 95 purchase for something
added to VB5! They then expect developers to distribute the new files!

It's clear that usoft has the responsibility to distribute such files and
to maintain them, as it, until a new major release. Ok, so a change to
one of the files may have added a neat feature to VB5. This feature IS
NOT worth the hassel of each distributed VB5 program having to distribute
the DLL (or whatnot) file. usofts present policy puts an undue burden on
developers and end users.

Gary



Sat, 18 Sep 1999 03:00:00 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Visual Basic 5.0 .EXE's and the various DLL's it needs

2. Visual Basic 5.0 .EXE's and the various DLL's it needs

3. Visual Basic 5.0 .EXE's and the various DLL's it needs

4. Tool for Debugging DLL's in Visual Basic 5.0

5. Looking: Dan Appleman's Visual Basic 5.0 Programmer's Guide To The Win32 API

6. Various DLL's needed

7. Calling Visual C++ 5.0 DLL Functions From Visual Basic 5.0

8. How to write Visual C++ DLL's and call them from Visual Basic

9. Visual Basic 5.0 and Audio CD's

10. Word '97 and Visual Basic 5.0 Prof.

11. Ben's Visual Basic 5.0 Page!

12. Extracting Icons from Exe's Dll's Ico's into a ListImage Control

 

 
Powered by phpBB® Forum Software