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

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

Author	Message
-Ed #1 / 25	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

Keith G. Murph #2 / 25	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

Gary Karn #3 / 25	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. I think it's a legal issue. If MS included the run-times in Windows and their other products, then competitors can claim they are getting an unfair advantage. The programming tools, Apps & OS groups are supposed to act like seperate companies. So if they did this then they would have to also include run-times or Delphi, PowerBuilder, etc.. Gary --- Gary Karnik Lucent Technologies, formerly AT&T
Fri, 10 Sep 1999 03:00:00 GMT

Jonathan Woo #4 / 25	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

Jim Crossle #5 / 25	Visual Basic 5.0 .EXE's and the various DLL's it needs writes 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. >I think it's a legal issue. If MS included the run-times in Windows and their >other products, then competitors can claim they are getting an unfair >advantage. The programming tools, Apps & OS groups are supposed to act >like seperate companies. So if they did this then they would have to >also include run-times or Delphi, PowerBuilder, etc.. >Gary >--- >Gary Karnik >Lucent Technologies, formerly AT&T I've just got back from the London DevDay (so you can discount anything I now say as I've been brainwashed) and the speaker at the VB5 presentation was asked about this and he said that the VB runtime DLL WOULD be distributed with IE 4.0. -- Jim Crossley
Sat, 11 Sep 1999 03:00:00 GMT

Robert de Bo #6 / 25	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

Mark Nevill #7 / 25	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

Robert de Bo #8 / 25	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

Joel Bierlin #9 / 25	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

-Ed #10 / 25	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

RonM #11 / 25	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

John Arkin #12 / 25	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

Jim Dompie #13 / 25	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

Robert de Bo #14 / 25	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

John Arkin #15 / 25	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

Page 1 of 2

[ 25 post ]

Go to page: [1] [2]