On Wed, 7 Jun 2006, Igor Tandetnik wrote:
[EMAIL PROTECTED] wrote:
"Igor Tandetnik" <[EMAIL PROTECTED]> wrote:
On Windows, the loader works in a very different way. Basically,
export/import connections are established at link time, not at load
time. The loader does not perform a symbol search over all the DLLs,
the import tables in the executable image (emitted by the linker)
tell it exactly where to look.
The disadvantages to the windows approach are obvious.
Before I add this characteristic to the ever-growing
list of reasons why I hate windows and especially hate
programming for windows, I should be fair and ask if
there are any advantages to the windows way of doing
things that I have overlooked.
From http://www.iecc.com/linker/linker10.html :
"The runtime performance costs of dynamic linking are substantial compared to
those of static linking, since a large part of the linking process has to be
redone every time a program runs. Every dynamically linked symbol used in a
program has to be looked up in a symbol table and resolved. (Windows DLLs
mitigate this cost somewhat, as we describe below.)"
Wow. That philosophy has diminishing returns as machines get faster. What
foresight!
This is one of the most painful aspects of Windows programming (among
many) but can be somewhat mitigated by doing away with .def files:
http://msdn2.microsoft.com/en-us/library/3y1sfaz2.aspx
Basically, wrap the above in a macro, something like:
#ifdef WIN32
#define EXPORT __declspec( dllexport )
#else
#define EXPORT
#endif
Then declare functions as
EXPORT int foo( int bar );
On UNIX and other sane environments, it does nothing as nothing is
required. On Windows, an export symbol (or whatever it is) is created
without the need for a .def file. Don't know if it'll work on .exe's,
mind.
You may have to dllimport the required function from the .exe to the dll.
I don't know for sure.
Igor Tandetnik
Christian
