This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bug: C-prog from Win dies in fork; gdb.exe also won't run


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]