This is the mail archive of the cygwin-developers 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]

NtCreateProcess redux


Hi all,

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 undocumented.

The best explanation I could find was from Corinna, in 2008 [1]:
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.

[1] http://www.eggheadcafe.com/software/aspnet/32040421/ntcreateprocess-and-fork.aspx


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