Re: DLL and external references
From: Victor Bazarov (v.Abazarov_at_comAcast.net)
Date: 07/15/04
- Next message: Carl Daniel [VC++ MVP]: "Re: DLL and external references"
- Previous message: Marc Elliott: "Re: deadlock on SMP machines - perhaps caused by wldap32.dll?"
- In reply to: alias.name: "Re: DLL and external references"
- Next in thread: Carl Daniel [VC++ MVP]: "Re: DLL and external references"
- Reply: Carl Daniel [VC++ MVP]: "Re: DLL and external references"
- Reply: alias.name: "Re: DLL and external references"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 15 Jul 2004 17:16:19 -0400
alias.name wrote:
> Thank you, I was trying mimic the shared library behavior from Unix, but
> since DLL are essentially EXE's and not just shared objects since it won't
> work for my purpose.
I am not sure I understand that statement about shared objects. In order
to use shared objects on Unix, you still need to link them in. Each .so
object serves as its own import library. On Windows a DLL is not its own
.LIB, that information is pulled into a different file, that's all.
So, mimicking Unix behaviour is what Windows does with DLLs.
>
> A little more description of what I was trying to do:
>
> I was trying to convert a static library into a DLL. The static library is
> used to build an application. The "static library" uses functions from some
> other static libraries. So to convert just that static library to a DLL I
> would essentially have to resolve all external calls, which gets quite
> involved and intricate and creates a huge DLL (the original EXE, almost).
>
> Is my understanding correct?
Yes. In order to prevent that, you need to create all those libraries
into DLLs.
The negative thing about static libraries mixed with DLLs is that if
your EXE uses a bunch of static library functions and your DLL uses the
same (or almost the same) set of library functions, those function will
be linked in twice, once into the DLL and the other time into the EXE,
after which the EXE will link to the DLL's import library and resolve
the few links DLLs provides.
Think of plain inheritance versus virtual inheritance in C++. In case
with static library used by both the DLL and the EXE, a copy of those
static library routines is placed into both EXE and DLL during linking.
That's why it's commonly recommended that if you have a project that
creates some DLLs and an EXE, you'd be much better off if the run-time
library is used as another DLL because in that case the code for all
the functions in the run-time library is not duplicated in those EXE/DLL
modules but pulled in during run-time.
Oh, if you happen to care, perhaps you will find it possible not to
top-post next time... Thanks.
>
> Victor Bazarov <v.Abazarov@comAcast.net> wrote in
> news:eWauhnpaEHA.3892@TK2MSFTNGP10.phx.gbl:
>
>
>>Not sure I understand this question. An EXE is essentially a DLL.
>>So, when a DLL is built, all external references need to be resolved.
>>If the function uses static binding (comes from a static library),
>>the library has to be supplied at the time of linking. If the symbol
>>(function) uses dynamic binding (comes from a DLL), the _import_
>>library needs to be supplied at the time of linking.
>>
>>Basically, there is no difference in linking a DLL or an EXE. The
>>latter doesn't produce the import lib (usually), and has a different
>>file extension. The inner format and ways to resolve symbols are
>>essentially the same.
>>
>>Victor
>
>
-- Please remove capital As from my address when replying by mail
- Next message: Carl Daniel [VC++ MVP]: "Re: DLL and external references"
- Previous message: Marc Elliott: "Re: deadlock on SMP machines - perhaps caused by wldap32.dll?"
- In reply to: alias.name: "Re: DLL and external references"
- Next in thread: Carl Daniel [VC++ MVP]: "Re: DLL and external references"
- Reply: Carl Daniel [VC++ MVP]: "Re: DLL and external references"
- Reply: alias.name: "Re: DLL and external references"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
