Re: VB6 - why isnt a straight Win32 DLL offered as a project type?
- From: "Ralph" <nt_consulting64@xxxxxxxxx>
- Date: Mon, 16 Jul 2007 14:57:11 -0500
"Mike Williams" <mike@xxxxxxxxxxxxxxxxx> wrote in message
news:u08xbe9xHHA.988@xxxxxxxxxxxxxxxxxxxxxxx
"mayayana" <mayaXXyana1a@xxxxxxxxxxxxxxxx> wrote in messageI
news:ptOmi.7578$rR.1695@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
It's actually fairly easy, but unorthodox. You have
to bypass VB's "hellpfulness".
www.jsware.net/jsware/vbcode.php3#vdll
Okay. I'll bite. Being a simple hobbyist I never get involved in these
things, but in layman's terms what exactly is the difference between an
ActiveX DLL and a "normal" Win32 DLL. Is it something to do with a normal
DLL not requiring to be registered, or is it deeper than that? Also, when
use functions in a DLL myself I do so either because I am calling standardand
functions provided by Windows that would otherwise be difficult to code or
because I am calling a function in a library that has been written in C or
perhaps ASM and that does its work faster than I would be able to do it
myself in compiled VB code. So, why would I want to create a DLL in VB6
call the functions it provides when I can simply write those functions ina
standard code module that I can pull into my projects and that are goingto
execute at the same speed? In other words, what is the advantage ofcalling
a function in a VB6 compiled DLL as opposed to calling an exactly similaranything
function in a standard code module. What am I gaining by doing so? Does it
perhaps enable me to more easily use multiple threads? I don't know
at all about writing DLLs in VB and I think it's about time I learned howto
do it (and, just as importantly, why to do it) ;-)
Mike
The type of DLL Stephen is talking about is simply a shared library that can
can be linked into a program's address space at runtime (dymanic linking).
If shared libraries were not supported then each application would have to
be statically linked to 'shared code' at compile time.
In the simple example of using the WinAPI, static compiles make programs
rather large. It also causes problems should a program be ported to another
or upgraded OS. All programs would have to be recompiled to run on the new
OS. This is inconvenient, thus 'shared' libraries' were created.
While vitally important to apps that access universal items such as the
WinAPI, it is less useful to home-brew applications unless those apps are
part of suites that share a lot of code. Even then, it is usually more
useful to share objects not code, thus an ActiveX component is more useful.
-ralph
.
- References:
- VB6 - why isnt a straight Win32 DLL offered as a project type?
- From: Stephen Howe
- Re: VB6 - why isnt a straight Win32 DLL offered as a project type?
- From: mayayana
- Re: VB6 - why isnt a straight Win32 DLL offered as a project type?
- From: Mike Williams
- VB6 - why isnt a straight Win32 DLL offered as a project type?
- Prev by Date: Re: Singles to Doubles
- Next by Date: Re: Printer.Print and underscore character
- Previous by thread: Re: VB6 - why isnt a straight Win32 DLL offered as a project type?
- Next by thread: Re: VB6 - why isnt a straight Win32 DLL offered as a project type?
- Index(es):
Relevant Pages
|
