This is the mail archive of the
mailing list for the Cygwin project.
Re: Cygwin Python/PIL TCL/TK fork rebase solution
- From: Robin Walker <rdhw at cam dot ac dot uk>
- To: cygwin at cygwin dot com
- Date: Tue, 16 Jan 2007 11:37:46 +0000
- Subject: Re: Cygwin Python/PIL TCL/TK fork rebase solution
- References: <firstname.lastname@example.org>
- Reply-to: Robin Walker <rdhw at cam dot ac dot uk>
--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
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
email@example.com http://www.queens.cam.ac.uk/ Tel:+44 1223 335528
Description: S/MIME cryptographic signature