This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cygwin Python/PIL TCL/TK fork rebase solution


--On 15 January 2007 15:42 -0800 Ross Patterson wrote:

But I'm also curious about rebase and to understand more about how one
chooses what base address and offset to use.

My curiosity is deeper than that. I would welcome some instruction or elucidation on this issue.


My understanding (please correct me if I get this wrong) of normal Windows DLLs is that, when they need to be loaded into memory (or mapped into an address space), if their preferred base address and range is not free, then Windows will slot them in elsewhere and automatically fix-up all the embedded pointers in RAM to be consistent with the actual assigned run-time DLL base.

So, usually, no-one need be too concerned about DLL base addresses: DLLs just work, even if their preferred base is not available. Things are more efficient if the preferred base is free, but they still work, albeit slower and less efficiently, if the preferred base is not free.

So, what is it about Cygwin DLLs that makes them apparently sensitive to base address in a way that normal Windows DLLs are not?

What is it that Cygwin "rebase" does, that Windows dynamic run-time rebasing cannot or does not do?

--
Robin Walker (Junior Bursar), Queens' College, Cambridge CB3 9ET, UK
rdhw@cam.ac.uk  http://www.queens.cam.ac.uk/  Tel:+44 1223 335528

Attachment: p7s00000.p7s
Description: S/MIME cryptographic signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]