MSVBVM50.DLL
in [Visual Basic]
|
From: Jason Keats on 3 Jul 2010 03:05 Nobody wrote: > "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. > > Thanks, Nobody. In the above I was just trying to clarify what Kevin seemed to be saying. Let me explain... David Kaye said: "The inherent controls come from within MSVBVM." Kevin Provance said: "That is incorrect." "The inherent VB controls are classes in the VB6.OLB". "Those controls do NOT come from within it (VBxMSVBVM.DLL). I said: "Is that speculation, Kevin?" Kevin said: "Actually, it is not." Now you're saying that Kevin was wrong? Maybe we'll have to wait for Kevin to explain what he really meant.
From: Nobody on 3 Jul 2010 10:07 "Jason Keats" <jkeats(a)melbpDeleteThis.org.au> wrote in message news:i0mnfk$3ra$1(a)speranza.aioe.org... > Nobody wrote: >> "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. >> >> > > Thanks, Nobody. > > In the above I was just trying to clarify what Kevin seemed to be saying. > > Let me explain... > > David Kaye said: "The inherent controls come from within MSVBVM." > > Kevin Provance said: > "That is incorrect." > "The inherent VB controls are classes in the VB6.OLB". > "Those controls do NOT come from within it (VBxMSVBVM.DLL). > > I said: "Is that speculation, Kevin?" > > Kevin said: "Actually, it is not." > > Now you're saying that Kevin was wrong? > > Maybe we'll have to wait for Kevin to explain what he really meant. Kevin remarks "Those controls do NOT come from within it." could be interpreted as either "VB6.OLB" or "MSVBVM60.DLL". You added "(VBxMSVBVM.DLL)" which mean that you assumed that he was talking about the latter. I realize that he could have added more words to clarify his point, but I think he meant "VB6.OLB". I have done similar thing in the past, using "it" because I already typed too much and I thought what I meant is already clear, but in some cases it was not.
From: Jason Keats on 3 Jul 2010 10:40 Nobody wrote: > > Kevin remarks "Those controls do NOT come from within it." could be > interpreted as either "VB6.OLB" or "MSVBVM60.DLL". You added > "(VBxMSVBVM.DLL)" which mean that you assumed that he was talking about the > latter. I realize that he could have added more words to clarify his point, > but I think he meant "VB6.OLB". > Well we know VB6.OLB is a type library and doesn't need to be distributed - so the controls can't be instantiated from code within it. That leaves MSVBVM60.DLL as the source of controls, but Kevin says "That is incorrect." So what does that leave us with? I'm sure Kevin will explain all.
From: NadCixelsyd on 3 Jul 2010 11:38 > > Windows 7 does have the VB6 runtime installed. > I am the OP. I circumvented the problem by upgrading to VB6 (which I was lucky to already have in my possession). The program is known to run correctly on XP, W7, Vista without any distribution setup.
From: NadCixelsyd on 3 Jul 2010 11:45
> > 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? Dan |