MSVBVM50.DLL
in [Visual Basic]
|
From: David Kaye on 2 Jul 2010 18:08 Paul Clement <UseAdddressAtEndofMessage(a)swspectrum.com> wrote: >Talk about confusing people. Actually he is right in what he said, but I'm sure >you've been corrected by now. The intrinsic controls have always been in the >Visual Basic runtime, all the way back to version 1.0. I'm thinking that this newsgroup is too nitpicky for my taste. What I had meant to say (and thought I did say) was that the virtual machine contained the intrinsic controls and that the olb is used to compile the classes into the finished product. Jeez, let's just get back to the basics here, shall we? If you're gonna run a VB program you're gonna need the virtual machine. It comes with some flavors of Windows and doesn't with others. The safest bet is to simply create the installer and be done with it.
From: Mayayana on 2 Jul 2010 18:40 | Jeez, let's just get back to the basics here, shall we? If you're gonna run a | VB program you're gonna need the virtual machine. It comes with some flavors | of Windows and doesn't with others. The safest bet is to simply create the | installer and be done with it. | That seems worth nitpicking about a bit. The safest bet is to know what you're shipping and know what your dependenices are. The runtime doesn't just come with "some flavors of Windows", as some sort of willy nilly addition to the system files. This runtime-shipping thing seems to be a pet peeve of yours. It's fine if you like to be thorough and ship the runtime, but if you're going to tell other people to do so, you should at least be straight with them and tell them the facts. It is only needed if you plan to ship to Win98 where no VB6 software has ever been installed. There are later versions of the runtime, but even the last version (SP6) is quite old now. XP service packs always have the latest copy. The last version before 6 -- SP5 -- has a runtime dated 2000. And according the the MS docs there are no notable changes in SP6. (The SP6 docs say something vague about fixes for the runtime that are "mostly already in XP".) I haven't shipped the runtime for years. I used to put a note on my download pages for people using Win95/98, but I also dropped that some time ago. (Anyone installing software on Win98 these days surely knows about dependency issues.) I get an average of 500 visitors (400 "real" visitors) on a weekday, many of whom download software, AX components, or standalone EXEs from my site. I have *never* had anyone send an email saying, "Hey, I'm getting a message that MSVBVM60.DLL is missing."
From: David Kaye on 2 Jul 2010 19:15 "Mayayana" <mayayana(a)invalid.nospam> wrote: > This runtime-shipping thing seems to be a pet >peeve of yours. Huh? I think you have me confused with someone else. I build the installer with all dependencies including my own, and give that to my clients. The dependencies are so small that it's not worth arguing over. I have no "pet peeves" about anything regarding VB except that it doesn't work in Linux, MacOS, etc.
From: Jason Keats on 2 Jul 2010 22:00 Kevin Provance wrote: > > Jason Keats wrote: > : > : Is that speculation, Kevin? > > Actually, it is not. > I believe I now understand what you meant, Kevin. That is: - that my executable does not create inherent controls by instantiating them from classes in either VB6.OLB or VB6MSVBVM.DLL - that VB6.OLB is, or contains, a type library - that at compile time the information required to generate inherent controls is extracted (or generated?) from the VB6.OLB file and embedded in my executable - that VB6.OLB, being a type library (which is only required at run/design time), does not need to be distributed - that VB6MSVBVM.DLL still needs to be distributed to support other functionality Thanks for the clarification.
From: Nobody on 2 Jul 2010 23:57
"Jason Keats" <jkeats(a)melbpcDeleteThis.org.au> wrote in message news:FQwXn.45$Yv.23(a)viwinnwfe01.internal.bigpond.com... > Kevin Provance wrote: >> >> Jason Keats wrote: >> : >> : Is that speculation, Kevin? >> >> Actually, it is not. >> > > I believe I now understand what you meant, Kevin. > > That is: > > - that my executable does not create inherent controls by instantiating > them from classes in either VB6.OLB or VB6MSVBVM.DLL Remove the "not" word above and it would be correct. > > - that VB6.OLB is, or contains, a type library > Yes. > - that at compile time the information required to generate inherent > controls is extracted (or generated?) from the VB6.OLB file and embedded > in my executable The type library itself is not embedded in the EXE, only the information in it are used, like class or control names and GUID, and properties and methods used, but not the code that actually generate the control, or the code behind properties and methods. That code resides in the VB runtime, probably MSVBVM60.DLL. The same is true for other type libraries, they just contain the information, and the implementation is elsewhere(another DLL/OCX/ActiveX EXE). > - that VB6.OLB, being a type library (which is only required at run/design > time), does not need to be distributed Correct. > - that VB6MSVBVM.DLL still needs to be distributed to support other > functionality Yes, but it's also needed to support the intrinsic controls functionality. |