4 ms·

notably the actual subsystem wasn't really necessary, if i recall it was some poorly implemented stubs for unix style system services. (think a backend for fun

by a-dub 4y ago

notably the actual subsystem wasn't really necessary, if i recall it was some poorly implemented stubs for unix style system services. (think a backend for functions like getpwnam) the important part was the posix api functions that made porting unix daemons that had been written in c/c++ to nt pretty easy. there were some quirks around shared memory/mmap, getpwnam, the sockets api and threading support, but beyond that doing a port was pretty easy. the work there was plugging into the service control and event logging apis. and doing an installshield, that was no fun.

skissane 4y ago
The subsystem absolutely was necessary to properly support fork(). The NT kernel has always supported fork, but Win32 can’t cope with it, forking confuses CSRSS.EXE. POSIX/Interix/SFU/SUA used PSXSS.EXE instead which wasn’t upset by forked processes.
- a-dub 4y ago
  that's right, i remember now fork being an issue. wasn't that much of a deal if i recall as most programs only really used it to spawn new processes by calling exec immediately after. (so, just swap it for CreateProcess) if a program did use fork as part of its concurrency model (like say, preforking apache) then making use of actually functional nt threading support and gratuitous ifdefs was usually the answer.
  - skissane 4y ago
    exec() was another problem - NT doesn’t support reusing a process for a new executable; exec() on Windows actually spawns a child process and then exits the parent - which means exec() changes your PID. Both Cygwin and POSIX/Interix/SFU/SUA use the same workaround - maintain a separate Unix PID for each process. exec() changes the NT PID but leaves the Unix PID unchanged. So exec() creates a new process, but to Unix apps it looks like the same process. You are right that for many apps, rather than rely on emulated fork/exec, it was better to switch to native Windows facilities. Still, there was some value in being able to recompile Unix software with minimal changes (as Cygwin demonstrates). Even WSL now confirms that, albeit in a rather different way. Also, it was necessary to pass the POSIX test suite, which Microsoft briefly was concerned about (until they successfully lobbied the US government to drop POSIX certification as a procurement requirement).

by a-dub 4y ago

skissane 4y ago

The subsystem absolutely was necessary to properly support fork(). The NT kernel has always supported fork, but Win32 can’t cope with it, forking confuses CSRSS.EXE. POSIX/Interix/SFU/SUA used PSXSS.EXE instead which wasn’t upset by forked processes.

a-dub 4y ago
that's right, i remember now fork being an issue. wasn't that much of a deal if i recall as most programs only really used it to spawn new processes by calling exec immediately after. (so, just swap it for CreateProcess) if a program did use fork as part of its concurrency model (like say, preforking apache) then making use of actually functional nt threading support and gratuitous ifdefs was usually the answer.
- skissane 4y ago
  exec() was another problem - NT doesn’t support reusing a process for a new executable; exec() on Windows actually spawns a child process and then exits the parent - which means exec() changes your PID. Both Cygwin and POSIX/Interix/SFU/SUA use the same workaround - maintain a separate Unix PID for each process. exec() changes the NT PID but leaves the Unix PID unchanged. So exec() creates a new process, but to Unix apps it looks like the same process. You are right that for many apps, rather than rely on emulated fork/exec, it was better to switch to native Windows facilities. Still, there was some value in being able to recompile Unix software with minimal changes (as Cygwin demonstrates). Even WSL now confirms that, albeit in a rather different way. Also, it was necessary to pass the POSIX test suite, which Microsoft briefly was concerned about (until they successfully lobbied the US government to drop POSIX certification as a procurement requirement).