> Apparently, after a fork, a child retains it's parent's > pid in _tos->pid.
I think this is at the root of why 9vx cannot run on MS-Windows. I have been very slowly crawling towards an updated port of 9pm (p9p for windows as it was) learing the Windows API and the plan9 kernel as I go. The one total show stopper is a lack of a real fork() in windows. This meant I chose to implement rfork(RFPROC) as somthing like vfork() - CreateThread() followed by CreateProcess() whilst the parent is blocked. This works in simple cases but breaks on rc(1). This is fixable by modifying the rc source (rc runs under windows in its inferno form anyway) but that is not the point. I implemented rfork(RFPROC|RFMEM) as CreateThread() with stack copy and relocation. This works well but means every windows-thread/plan9-psudo-proc has a different stack and thus _tos and _tos->pid won't work. This is OK, I just recompile every app using a modified malloc.c in libc but once again, if you break the purity of unmodified plan9 binaries then then you win almost noting over recompiling them on the target platform anyway - kencc syntax extensions not withstanding. I would love to get 9vx running on windows and if anyone has any ideas how to solve these problems then let me know. -Steve
