Prompted by BrowserUk in his post on Perlmonks on Win32, fork and XS globals, I looked into the PAGE_WRITECOPY for CreateFileMapping, and it seems that, in fact, this function, together with a bit of work could be made to implement a (data-)fork call on Windows, with real sharing of identical pages.

There is this sample program on the MSDN, which outlines how to use a mapped view of a file for shared memory IPC, and by using the PAGE_WRITECOPY flag instead of FILE_MAP_ALL_ACCESS, we should get COW semantics for the shared area.

The part for implementing fork() would seem to just be:

1. (and that is the hard part) Determine the range of data to be shared with the child
2. CreateFileMapping in the parent process to share the area from 0.
3. MapViewOfFile
4. Launch the child process
5. In the child process, call OpenFileMapping() to connect to the data area from the parent process.
6. Fix up any cached values that need changing after a fork(), for example $$

Lots of people use WWW::Mechanize::Firefox. This makes me happy.

Some of these people would like to do away with needing Firefox to be running on the machine doing the automation. To look in that direction, and to gain some familiarity with nodejs, I started porting the proxy object backend MozRepl::RemoteObject to nodejs. I've uploaded the work in progress to Github as NodeJs::RemoteObject. There is a lot of copied and pasted code between the two ::RemoteObject modules, and likely, this will beget a third, shared incarnation of (Javascript) proxy object implementations.

The main thing that's still needed is to actually write a web "browser" implementing just enough to run most web applications, for nodejs. I think there already is something called "jsdom", which claims to be just enough of a browser to make this work.