X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Wed, 12 Mar 2008 14:05:39 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Bug: C-prog from Win dies in fork; gdb.exe also won't run
Message-ID: <20080312130539.GO18407@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <47D4A7E4 DOT 5070509 AT tlinx DOT org> <47D4B7D2 DOT 1F78DADB AT dessent DOT net> <47D4E892 DOT 1090305 AT tlinx DOT org> <47D50BB6 DOT EFB28302 AT dessent DOT net> <47D6056B DOT 6000805 AT tlinx DOT org> <47D610C2 DOT EECE7EE9 AT dessent DOT net> <00b601c8843a$d94fe2c0$2708a8c0 AT CAM DOT ARTIMI DOT COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00b601c8843a$d94fe2c0$2708a8c0@CAM.ARTIMI.COM>
User-Agent: Mutt/1.5.16 (2007-06-09)
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 12 12:16, Dave Korn wrote:
> Brian Dessent wrote on 11 March 2008 04:56:
> 
> > - When the testcase's binary is located anywhere but %windir% or
> > %windir%\system32, then everything is fine.
> > - Otherwise you get:
> 
>   Ah.  So the error only arises when the binary is located in windows system
> dir.  Right alongside all those thousands of DLLs.  All those DLLs which are
> now all of a sudden higher up in the DLL search path than they were when the
> binary was located somewhere else.
> 
>   Just a WAG, but that could be significant.
> 
> > >         I hear what you are saying...yet did you know that MS
> > > improved fork and exec performance by 30% in their SFU Unix-compat
> > > layer? :-).  I wonder what 'pains' they go through -- they might have it
> > > easier and just use straight NT calls rather than Win32.  Dunno...
> > 
> > They don't go to any pains.  The sad part is that the NT kernel does
> > support fork semantics.  But it only exposes them to the Posix
> > subsystem, which is what SFU runs in.  It doesn't expose them to the
> > Win32 subsystem.  
> 
>   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?

There is a way to do some kind of fork in the Win32 subsystem as
documented in Gary Nebbett's book, but it never quite worked when trying
to implement this for Cygwin.  It's rather complicated and bound to be
broken with every new OS.

Having said that, not all of the Win32 API is available for all
subsystems. 

At one point I implemented a *real* setuid, which didn't use
ImpersonateLoggedOnUser (which is easily revertable by calling RevertToSelf),
but instead it used NtSetInformationProcess(ProcessAccessToken).

This worked fine on XP, but failed on Vista with a STATUS_NOT_SUPPORTED
status code.  I asked Microsoft(*) and the reply was that this
functionality is blocked for Win32 processes and only available to the
POSIX subsystem beginning with Vista.  Oh well...


Corinna


(*) http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1034817&SiteID=1

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