Because POSIX.1 compliance was a mandatory goal for Windows, the operating system was designed to ensure that the required base system support was present to allow for the implementation of a POSIX.1 subsystem (such as the fork function, which is implemented in the Windows executive, and the support for hard file links in the Windows file system).
Was this fork function copy-on-write? If so, is it still present in recent versions of Windows? If so, can it also called Win32 applications (though an undocumented API)?
From memory of Windows Internals, fork was a copy-on-write implementation. Based on the way the rest of the Windows memory manager works it would be unusual and surprising for it to be anything else.
I also seem to recall that the way fork was implemented was for all memory allocations to be put inside section objects so that the sections could be duplicated across processes with the copy on write setting.
Unfortunately that means you probably can't use it in a non-posix subsystem process, because you would need to have carefully setup your address space to contain only sections. Standard Win32 processes don't do this.
Also, if you're going to support fork(), everyone needs to support it - from the kernel up. For an example of a system which might be surprised to get fork()-ed, consider the windowing system. What would it even do in that case? (I assume X11 has an answer to this, but I don't know what it is). Since fork()-ing on Windows would be a highly unusual thing to do, I would expect your process to get completely borked if you were to do it to a standard Win32 process.