> Thank you for the detailed reports.
> It makes it very easy to fix the bugs!

It really is my pleasure. Hunting bugs is
one of my favorite pastimes. Well, that's
not completely true: hunting bugs is usually
only fun when dealing with code of a certain
quality. Plan 9 makes the cut, as does all
of your code.

> + kexit(nil);

I figured that would do it.

Anthony

> 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

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

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

No, it's not. The words fork and pid in that sentence
are concepts completely internal to 9vx. The host OS,
be it OS X or Linux or Windows, has absolutely no idea
they exist and is not contributing at all toward their
implementation. The only thing the host OS sees is a bunch
of pages from a file being mapped and unmapped from
memory.

In fact, 9vx would probably be easier to bring up on Windows
than trying to do anything special just to implement rfork
for a p9p-style port (not implementing rfork would
be easier still; see below).

> 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 a separate issue. In p9p I prepared for this by getting
rid of all the uses of rfork to create threads, replacing them
with the thread library and threadcreate. The latter should be
easier to implement with Windows primitives, if you stay that
course.

Russ

>> I think this is at the root of why 9vx cannot run on MS-Windows.

> No, it's not.

I can only appologise for emailing before reading the vx30 paper properly,
I now understand (some of) how cunning it really is.

I 9vx for windows is the way to go.

Thanks russ.

-Steve

Pietro Gagliardi wrote:
> - Modify the kernel (it is based on Unix - even Microsoft says so)

Sure it is...in the same way that VMS is based on UNIX (which means not
at all....)