What fork() does in Unix is not akin to either a Win32 thread or process. It's something which win32 simply doesn't have - that's why it's so tricky.

When you call fork(), one process becomes two. The old process gets the PID of the new process, then continues to do whatever it was doing.

The new process contains a copy of the old process's virtual memory, including the stack and mapped areas. The CPU context is also copied, therefore, the child process returns from the fork() system call just as the parent did - except that it's a new process. fork() returns 0 to the child process (which is how it can tell it's the child process).

The memory is all *copied* (Well, actually probably implemented using copy-on-write) except for shared maps, which are obviously still shared, as they would be between unrelated processes.

The processes can work independently, and don't affect each others' memory.

All file descriptors are copied, and are available to both processes, but they are real independent file descriptors, i.e. both processes can independently close them, seek them etc. This includes all types of socket, IPC etc.

It's normal for a child process to close lots of files immediately after fork() - because you can't stop them from being inherited (unlike exec), so the child needs to close unnecessary ones.