Win32 has no fork(): how does CreateProcess differ from the Unix fork/exec model, and what does that change for code ported between the two?

## Two different creation models On Unix, creating a process that runs a different program takes two primitives. `fork()` produces a near-identical copy of the calling process — same code, same heap and stack contents, same open file descriptors, same current directory — differing mainly in the returned PID. The copy is cheap because the kernel shares pages copy-on-write rather than physically duplicating them. The child then typically calls one of the `exec` family, which discards that address space and replaces it with a new executable image while keeping descriptors, PID and parent relationship. Win32 exposes no equivalent of the first half. The single call is `CreateProcessW` (and its variants `CreateProcessAsUserW`, `CreateProcessWithLogonW`), which takes an application name and/or a command line, security attributes for the process and its first thread, an inherit flag, creation flags, an environment block, a working directory, a `STARTUPINFOW`, and an out `PROCESS_INFORMATION`. The kernel creates a new process object with an empty address space, maps the executable image into it, sets up the process and thread environment blocks, and creates one thread that begins in the loader. The loader resolves imports and runs `DllMain` with `DLL_PROCESS_ATTACH` for every DLL before your entry point sees control. ## Nothing is inherited unless you ask This is the point ports break on. A `fork()` child starts life owning everything the parent had. A `CreateProcessW` child starts with nothing of the parent's memory. Three things can cross the boundary, and each is explicit: - **Handles.** A handle is inherited only if it was created with `SECURITY_ATTRIBUTES.bInheritHandle` set, or later marked with `SetHandleInformation(h, HANDLE_FLAG_INHERIT, HANDLE_FLAG_INHERIT)`, *and* `CreateProcessW` is called with `bInheritHandles = TRUE`. Since Windows Vista you can be precise instead of blanket, passing an explicit list through `PROC_THREAD_ATTRIBUTE_HANDLE_LIST` on a `STARTUPINFOEX` via `UpdateProcThreadAttribute`. Blanket inheritance is a real bug source: an unrelated inheritable handle leaking into a long-lived child keeps a file locked or a pipe unclosed, so the reader never sees end-of-file. - **Standard streams**, passed through `STARTUPINFOW.hStdInput/hStdOutput/hStdError` with `STARTF_USESTDHANDLES` — the Windows way to build the equivalent of a shell pipeline. - **Environment and working directory**, passed as parameters (NULL means "copy the parent's"). ```c SECURITY_ATTRIBUTES sa = { sizeof sa, NULL, TRUE }; /* bInheritHandle = TRUE */ HANDLE r, w; CreatePipe(&r, &w, &sa, 0); SetHandleInformation(r, HANDLE_FLAG_INHERIT, 0); /* keep the read end private */ ``` ## No exec-in-place, no zombies A Win32 process cannot replace its own image; the closest you get is spawning a replacement and exiting. That removes a whole family of Unix idioms — re-exec to reload configuration, exec after dropping privileges, the shell's fork-then-exec. Termination reporting is also different. There is no SIGCHLD and no zombie state that a parent must reap to free a PID. Instead `PROCESS_INFORMATION` hands you `hProcess` and `hThread`; the process handle becomes signalled when the process exits, so `WaitForSingleObject(hProcess, INFINITE)` is the wait, and `GetExitCodeProcess` reads the status. The process *object* survives as long as any handle to it is open — that is what lets you read the exit code after the fact — so forgetting `CloseHandle` on both handles leaks kernel objects, the Windows analogue of leaking zombies. One sharp edge: `GetExitCodeProcess` returns `STILL_ACTIVE` (259) for a running process, so a program that genuinely exits with 259 is indistinguishable from one still running; wait on the handle first. ## Cost, and why Windows code prefers threads Because every creation is a full image load plus loader work plus DLL initialisation, and because there is no copy-on-write shortcut, process creation on Windows is considerably more expensive than `fork()`. That shaped the platform's idioms: Windows software reaches for threads, the thread pool and asynchronous I/O where Unix software might reach for another process. A design that spawns a process per request is defensible on Linux and usually a mistake on Windows. ## Ported-code checklist Watch for: a parent that assumed the child sees its heap; reliance on descriptor numbers 0/1/2 as integers rather than handles; `daemon()`-style double-fork (use a service instead); pre-fork worker pools; and copy-on-write snapshotting of large in-memory state. Also two `CreateProcessW` API traps — `lpCommandLine` must point to writable memory because the function may modify it in place, and when `lpApplicationName` is NULL an unquoted path containing spaces is parsed ambiguously, the classic `C:\Program Files\...` hijack. The NT kernel itself is not incapable of address-space cloning — the old POSIX/Interix subsystem used a native routine to implement `fork` — but Win32 does not expose it and it is undocumented for application use.