Message-ID: <47D7EFEC.122C76AE@dessent.net>
Date: Wed, 12 Mar 2008 07:59:56 -0700
From: Brian Dessent <brian@dessent.net>
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: Bug: C-prog from Win dies in fork; gdb.exe also won't run
References: <47D4A7E4.5070509@tlinx.org> <47D4B7D2.1F78DADB@dessent.net> <47D4E892.1090305@tlinx.org> <47D50BB6.EFB28302@dessent.net> <47D6056B.6000805@tlinx.org> <47D610C2.EECE7EE9@dessent.net> <00b601c8843a$d94fe2c0$2708a8c0@CAM.ARTIMI.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: cygwin@cygwin.com
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

Dave Korn wrote:

>   The native API, to the very best of my knowledge, exports exactly the same
> set of interfaces to every subsystem.  Can you explain exactly what you're
> talking about here?

Microsoft Windows Internals, 4th. Ed (Russinovich & Solomon), p. 60:

> Because POSIX.1 compliance was a mandatory goal for Windows, the 
> operating system was designed to ensure that the required base system 
> support was present to allow for the implementation of a POSIX.1 
> subsystem (such as the fork function, which is implemented in the 
> Windows executive, and the support for hard file links in the Windows 
> file system).

p.394:

> The POSIX subsystem takes advantage of copy-on-write to implement the 
> fork function. Typically, when a UNIX application calls the fork 
> function to create another process, the first thing that the new process 
> does is call the exec function to reinitialize the address space with an 
> executable program. Instead of copying the entire address space on fork, 
> the new process shares the pages in the parent process by marking them 
> copy-on-write.

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/