httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Costello <>
Subject RE: DLL Base addresses (was: .dsp link options)
Date Thu, 01 Jan 1970 00:00:00 GMT
On Wed, 19 Apr 2000, William A. Rowe, Jr. wrote:
> I'm mostly concerned though, that the original addresses in
> the exports .lib file may not be touched... are they?  What

There are no addresses in import libraries. Import library format is described
in section 8 of 
Imports are done either by name - decorated or otherwise - or by ordinal 
(determined by the import name type). 

In our example from the other day, the import library for kernel32 says 
something along the lines of "at run-time, get the address of the function 
called _GetFileAttributesExA@12 from the library in the file KERNEL32.dll, but 
strip the leading _ (or ?, or @) and everything after and including the 
trailing @."

> happens to module authors presume that the export libraries
> are authoritative, and aren't rebased in that editbin pass?

See above. I am a module author and have been linking against aprlib and
apachecore for several weeks now without any issues. 

> And, does Apache.exe now need fixups?

Hmm. Apache.exe itself should never need fixups applied. When the process is 
created it is the first thing to be mapped into memory, so it is never 

It may be useful to read
which discusses the things that happen when a dynamic link library is loaded.
Although it discusses dynamic loading (ie. explicit calls to LoadLibrary), the 
sequence of events is similar.
discusses copy-on-write page protection in Windows NT.

> Can I suggest a small modification for legibility (I didn't see
> aprlib in there on the first scan), provide this facility in all 
> builds (including debug, it doesn't hurt anything) and change 
> !MESSAGE to echo, since !message doesn't emit when expected?

The changes sound good - thanks for reviewing the patch. 

And from another email:

> Scuttle the proposed patch from Tim (and my revision).
> I agree this is more work, but at least it's in one place!

I still don't like something that people have to manually calculate and update.

I guess I was working with the assumption that the number of output files 
produced wouldn't be changing very often, but that the size of each output file
would be quite volatile. 

This message was sent through MyMail

View raw message