Mon Apr 25 19:34:00 GMT 2011
I know that folks have looked before into NtCreateProcess as a way of
doing a real fork() in cygwin, but it's very unclear from the various
list archives why it's still a bad idea today, other than its being
The best explanation I could find was from Corinna, in 2008 :
> 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.
Given that cygwin no longer supports anything older than XP (SP3?), and
that win7 seems determined to make the current fork() implementation not
work reliably, might it be worth revisiting? I realize the answer
depends strongly on the nature of those failures Corinna refers to
(could somebody provide more details?).
I've looked into all kinds of ways of trying to work around the address
space layout problems over the last week, and at this point the idea of
reverse-engineering a single function call that might make the whole
issue go away is pretty attractive. The current approach to fork() seems
to depend on guessing how Windows handles collisions in dll base
addresses in order to work around unwanted behaviors, which is pretty
dicey work. Besides, if we're willing to even talk about hacking how
locale.nls gets mapped...
If there's no interest in revisiting NtCreateProcess, I have some really
crazy ideas to offer, but they would still leave us copying whole
address spaces and trying to outsmart Windows along the way.
More information about the Cygwin-developers