Mail Archives: cygwin/2007/01/16/13:13:47
Robin Walker wrote:
> Thanks for the explanations. So, if I've understood things correctly, the
> difficulty boils down to cloning a parent process's address space layout
> within that of a child, which includes ensuring that DLLs appear at the
> same base within both processes.
Note that the "cloning" that is happening in the case of Cygwin is done
entirely in userspace without any co-operation from the OS/kernel,
essentially by faking it -- spawn another copy of the binary and hope
that it takes the same layout. Note that Cygwin can do some fixups on
things like file handles and things that were allocated under its
control, but it's totally at the mercy of the operating system for
things out of its control like where DLLs get loaded.
> For this to be the problem it appears to be, I'm guessing that there must
> be some shortcoming in the Windows APIs in this area when compared with
> facilities available within other Posix-compliant OSs.
It's not so much a shortcoming, it's just a fundamental difference in
how the two operating systems were designed. The core of process
management on Win32 is CreateProcess(), which spawns a new process from
scratch, whereas the core of process management on posix systems is
fork(), which makes a duplicate copy of an existing process.
> How does Linux deal with the same issues of having libraries (or whatever
> are logically equivalent to DLLs) potentially linked at different bases in
> the two address spaces?
The "issue" does not even exist on posix systems, as fork() is simply a
kernel syscall. You ask the kernel to make a copy of the process and it
does. By definition the child has the exact same memory layout as the
parent, because the kernel memory manager arranges it so.
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -