Prev: VB6 Data missing when writing to a text file.
Next: Run Time Error 3265: Item cannot be found in the collection
From: Tony Toews [MVP] on 20 Jan 2010 22:11
Frank Rizzo <none(a)none.net> wrote:

>Anything you build in VB6 is dependent on the VB6 runtime.

I wonder why the DLLs would require the runtime? I would've thought
they would be the same as other DLLs such as C++.

And for that matter why is there even a VB6 runtime?

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/
Granite Fleet Manager http://www.granitefleet.com/
From: Ralph on 20 Jan 2010 23:48
Tony Toews [MVP] wrote:
> Frank Rizzo <none(a)none.net> wrote:
>
>> Anything you build in VB6 is dependent on the VB6 runtime.
>
> I wonder why the DLLs would require the runtime?

Anytime you have VB code it has to have access to the VB functions and the
VB library is located in the VBRuntime.

> ... I would've thought
> they would be the same as other DLLs such as C++.
>

Other development platforms ARE exactly the same - including those created
by C/C++. The difference is VC++ provides static libraries or optional
external runtime DLLs. MS could have provided static libraries for VB but
they didn't.

Many VC++ applications are compiled against and need a external VC runtime
DLL. So are Fortran, Pascal, Java, dotNet, or any other platform where a
static library is either not available or the developer opts to use a shared
DLL.

VB is NOT unique.

> And for that matter why is there even a VB6 runtime?
>

For two closely related reasons, or rather you might say - the VB runtime
wears two hats.
1) The VB language, that portion used as the scripting front-end or
interactive interface, is parsed and converted to intermediate pcode. Thus a
VM engine is necessary.
2) When pcode, or native compiled pcode, runs it needs access to the
'common' VB library.
(When run as pcode then the VM is also necessary. Less need when pcode is
converted to native code. However, note that as some 'services' are managed
by the "VM" portion of the runtime - in practice - no clear division of
labor is actually present.)

MS could have created separate components ). For example a 'parser' and a
'runtime' (and even static libraries), but that was bound to get ugly -
instead they opted for a single runtime/library Dll.

-ralph


From: Tony Toews [MVP] on 21 Jan 2010 02:42
"Ralph" <nt_consulting64(a)yahoo.com> wrote:

>Other development platforms ARE exactly the same - including those created
>by C/C++. The difference is VC++ provides static libraries or optional
>external runtime DLLs. MS could have provided static libraries for VB but
>they didn't.

Ah, ok. I've seen the msvcrt.dll file. I hadn't realized what it
was.

Thanks for the explanation.

The above all said Delphi does package everything up into one exe. Or
so my understanding goes.

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/
Granite Fleet Manager http://www.granitefleet.com/
From: Nobody on 21 Jan 2010 04:29
"Tony Toews [MVP]" <ttoews(a)telusplanet.net> wrote in message
news:schfl5psb17u2bto6h0jtivgdu06gl3rgu(a)4ax.com...
> And for that matter why is there even a VB6 runtime?

Besides what Ralph suggested, in some cases a language must have a common
runtime separate from the binary(EXEX/DLL/OCX) if users of the language
would share objects implemented in the runtime, otherwise the language maker
must maintain binary compatibility for these built-in objects. This is not
limited to VB, but applies to every language, including C/C++.

For example, if you have made a DLL(ActiveX) that exposes one of the objects
built-in in the runtime, such as Collection object to other components or
the EXE(all made with VB6), then the Collection object implementation is
identical because all are using the same interface for the object being
passed around.

If MS allowed you to compile everything inside the EXE/DLL/OCX so VB6
runtime aren't required, then your compiled DLL with VB6+SP1 may not work
with other components or EXE built with VB6+SP2 or any other hypothetical
service pack, because the Collection object may not be identical in both
binaries(same properties and methods in the same order), and as a result,
other components or the EXE would misbehave or crash. This is only a problem
if you share or pass references to objects that are implemented in the
runtime. This includes the built-in controls, such as TextBoxes, but not
controls that were implemented as OCX. If you avoid exposing these built-in
objects, then compiling everything inside the EXE/DLL/OCX would work;
however, for MS it would mean extra work because they have to explain how to
avoid these extra crashes and deal with tech support calls related to the
issues above, not to mention that some developers would see VB6 as
unreliable.

The same applies and is being done even when someone use VC++ exclusively.
If an object is being passed around, the interface must be the same. So if
you have a VC++ project consisting of one EXE and 10 DLL's, then all must
use the same interface. If all but one file used a different method, then
things may go wrong. Things might seem to work at first when both the static
and the non-static version(in a separate runtime DLL) are the same, but once
you update the runtime, there could be a mismatch if changes were made to
the interface. Recompiling all static versions so they are up to speed would
fix the problem until the runtimes are updated again. The ultimate solution
is to use either all static, or all dynamic(in a DLL). If using all static,
there is one drawback: when you update a file, you need to update all files
as a set. If you used the all dynamic method, then you can just update files
individually.

The above is one of the reasons for DLL hell. Another is that MS used the
same runtime files for their OS'es as a product they made, VC, so third
party product updates meant OS updates. If they have used the prefix "os"
instead of "ms" in files such as "msvcrt.dll", then things would have gone
smoother.






From: Ralph on 21 Jan 2010 08:02
Tony Toews [MVP] wrote:
> "Ralph" <nt_consulting64(a)yahoo.com> wrote:
>
>> Other development platforms ARE exactly the same - including those
>> created by C/C++. The difference is VC++ provides static libraries
>> or optional external runtime DLLs. MS could have provided static
>> libraries for VB but they didn't.
>
> Ah, ok. I've seen the msvcrt.dll file. I hadn't realized what it
> was.
>
> Thanks for the explanation.
>
> The above all said Delphi does package everything up into one exe. Or
> so my understanding goes.
>

Delphi provides both static and dynamic library options:

"BPL vs. DLL; Packages vs. Dynamic Link Libraries in Delphi programming"
delphi.about.com/od/objectpascalide/a/bpl_vs_dll.htm

-ralph


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: VB6 Data missing when writing to a text file.
Next: Run Time Error 3265: Item cannot be found in the collection