Apache/Win: DLL exports

[Alexei Kosut <ak...@organic.com>]

I knew there was something else bugging me about exporting DLLs in the
source vs. a .DEF file.

Actually, it's more about the nature of DLLs themselves, when implictly
linked: There is a .lib file that contains stub symbols for all the
exports in the DLL. When the file is run, it finds the DLL, and maps all
the symbols so they match.

Does anyone know how this is done? For example, it might be done by
having the import library's functions map to the addresses of the
functions in the DLL. This would be simplest. However, it would also mean
that any time the addresses of the pointed-to symbols changed, the file
linking to the DLL would stop working. This would mean that any time we
changed any function in Apache, whether exported or not, there would be a
good chance DLL modules would stop working. This seems unlikely, as it
(obviously) would prove rather annoying, and defeats at least one purpose
of a shared library.

The other extreme would be if it linked by name. This would mean that we
could do basically anything we wanted, as long as we didn't change the
exported functions' prototypes and names, and it would still
work. However, this also seems rather unlikely, as it would be
inefficient.

The way I *think* it works, although I can find no direct proof,
is somewhere in the middle: I've seen some evidence that DLLs export
functions ordinally. In other words, rputs(), say, is the 43rd function
exported from ApacheCore.dll. When ApacheCore.lib is linked, and you try
and access rputs(), ApacheCore.lib loads ApacheCore.dll and maps its
rputs() to the address of the 43rd exported function in
ApacheCore.dll. This would mean that as long as we don't mess with
exported functions or their order (or the order the files are linked), we
can change Apache and things will still work. Since these changes would
be accompanied by a bump in MODULE_MAGIC_NUMBER, the modules would stop
working anyway, and life would be good.

Can anyone confirm/deny/confuse this issue?

-- Alexei Kosut <ak...@organic.com>

Re: Apache/Win: DLL exports

[Dean Gaudet <dg...@arctic.org>]

On Mon, 14 Jul 1997, Alexei Kosut wrote:

> The way I *think* it works, although I can find no direct proof,
> is somewhere in the middle: I've seen some evidence that DLLs export
> functions ordinally. In other words, rputs(), say, is the 43rd function
> exported from ApacheCore.dll. When ApacheCore.lib is linked, and you try
> and access rputs(), ApacheCore.lib loads ApacheCore.dll and maps its
> rputs() to the address of the 43rd exported function in
> ApacheCore.dll.

This is how the OS/2 and WIN 3.1 formats work.  I'm pretty sure NT is the
same.  You can probably find the executable format documention on microsoft's
site somewhere.  In your microsoft compiler package there's probably an
object dumping or executable dumping program from which you can probably
figure out the format.  Or maybe they don't ship those... I should have one
with the WATCOM compiler package I've got around here somewhere.

Dean