Regards,
Iker Arizmendi
However, using ZwCreateProcess, informing CSRSS and everything else
necessary to create a process using the native API is pretty tedious -
and all undocumented.
I also think there are good reasons for this functionality not to be
exposed to the Win32 API. Therefore, I am not quite convinced that using
fork for Win32 processes is a very promising solution...
--Johannes
--
Johannes Passing - http://int3.de/
As to whether a Win32 fork would be promising, I think
the answer to that is "yes". Of course, not all applications
benefit from the availability of fork, but some do. And for
authors of the latter I think a Win32 fork would be a
very welcome addition.
Iker
MIke
"Iker Arizmendi" <IkerAr...@discussions.microsoft.com> wrote in message
news:78098D4F-6C29-41D1...@microsoft.com...
"Iker Arizmendi" <IkerAr...@discussions.microsoft.com> wrote in message
news:61CECC87-CC3C-4588...@microsoft.com...
http://www.redhat.com/support/wpapers/cygnus/cygnus_cygwin/architecture.html
Regards,
Iker
This document is rather old, 10 years or so. While we're still using
Win32 calls to emulate fork, the method has changed noticably.
Especially, we don't create the child process in the suspended state
anymore, unless specific datastructes need a special handling in the
parent before they get copied to the child. In the current 1.5.25
release the only case for a suspended child are open sockets in the
parent. The upcoming 1.7.0 release will not suspend at all.
One reason not to use ZwCreateProcess was that up to the 1.5.25 release
we're still supporting Windows 9x users. However, two attempts to use
ZwCreateProcess on NT-based systems failed for one reason or another.
It would be really nice if this stuff would be better or at all
documented, especially a couple of datastructures and how to connect a
process to a subsystem. While fork is not a Win32 concept, I don't see
that it would be a bad thing to make fork easier to implement.
Corinna
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat