From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Message-id: From: Pietro Gagliardi To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Date: Mon, 30 Jun 2008 08:42:50 -0400 References: Subject: Re: [9fans] 9vx fork problem Topicbox-Message-UUID: cd08e824-ead3-11e9-9d60-3106f5b1d025 - Modify the kernel (it is based on Unix - even Microsoft says so) - Learn how Cygwin does it - Don't use real processes, like in Inferno On Jun 30, 2008, at 8:34 AM, Steve Simon wrote: >> 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 >