X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Tue, 10 Mar 2009 09:57:25 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Replacing setup.exe and cygcheck with dpkg (Was: Re: cygcheck 	typo in both manpage and --help)
Message-ID: <20090310085725.GD31459@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <5c01594c0903081410n548fdb1ewbb43692129942901 AT mail DOT gmail DOT com> <20090308211548 DOT GA8625 AT ednor DOT casa DOT cgf DOT cx> <49B457E7 DOT 3010406 AT dazjorz DOT com> <20090309014539 DOT GB8625 AT ednor DOT casa DOT cgf DOT cx> <20090309064422 DOT GD6875 AT trikaliotis DOT net> <416096c60903090255m1e21f14dw94624232c94d6f61 AT mail DOT gmail DOT com> <20090309102152 DOT GS31459 AT calimero DOT vinschen DOT de> <20090309151515 DOT GA14910 AT ednor DOT casa DOT cgf DOT cx> <49B55B33 DOT 7020904 AT dazjorz DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <49B55B33.7020904@dazjorz.com>
User-Agent: Mutt/1.5.19 (2009-02-20)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Mar  9 19:08, Sjors Gielen wrote:
> I think I checked how Cygwin implements fork() a while ago, can't really  
> remember though. But on a fork(), do processes inherit all information  
> on dll's, et cetera? Or do they reload the dll and re-check the  
> addresses of entry points and all?

Very basically, the executable is started again via CreateProcess, then
Cygwin copies the parent's data segments into the child.  The important
faxct here is that the actual load process of the child is done by the
Windows loader.  If you changed the Cygwin DLL in the meantime, the new
process will load the new Cygwin DLL, not the old one.  From there it
goes downhill because the data layout of the new DLL is different from
the layout in the old DLL loaded with the parent process.

> I *think* this cygfoo1_2_3.dll system does not work with the Cygwin dll  
> itself, because that all still happens completely outside of Cygwin  
> scope

Yes.  This happens because we're using Windows API and thus Windows
loader to load processes.  The Windows API simply hasn't been designed
to fork.  That's why Cygwin has to do all the tricky and not very
performant stuff before and after loading a process.  Actually the
native NT API is capable to fork a process and that's used, for
instance, in Interix.  However, Interix is its entire self-contained
POSIX subsystem, distinct from Windows, while Cygwin processes are
running inside of the Windows subsystem.  Unfortunately important parts
of the API used to attach a new process to the Windows subsystem are not
documented.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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/