4 ms·

NT's POSIX subsystem never supported fork(). They, um, overlooked that bit...

daeken 16y ago
Actually, that's incorrect. Both the old-school POSIX subsystem and the Interix (Services For Unix) subsystem support a fork system call with copy-on-write semantics. In fact, the NT kernel itself can fork processes trivially, but this isn't exposed in the Win32 subsystem, like most of the fun stuff on NT.
- rbanffy 16y ago
  I always found it weird having a bunch of Windows kernel operations that are not exposed to Windows apps. How would you call those?
  - daeken 16y ago
    Ntdll.dll contains the userspace side of the NT API. Specifically, Zw* and Nt* contain most of the APIs that map directly into the kernel. Then there's the Rtl* stuff which provides a lot of fun functions for manipulating processes, and the Ldr* stuff for loading binaries; Ldr is a lot of fun to hook into, if you want to manipulate binaries with a high degree of transparency. Edit: One thing to note, though, is that it's easy to subvert the Win32 subsystem by using these APIs directly. I.e. if you want to fork a Win32 process, you're going to need to not only fork it the standard NT way, but then tell CSRSS what you're actually doing. It's easy to run into a situation where the Win32 subsystem won't play nicely with you, because it just doesn't have enough information.
  - bediger 16y ago
    How is that weird? A semi-hidden API like this is a huge benefit to Microsoft itself, and a detriment to its competitors, or indeed, anyone who writes software that becomes a DLL in the next version of Windows. If you write to a documented API (Win32, GINA, etc) your code is slower and possibly less capable than it could be. If you write to the undocumented NT-native-API, you have to invest time and effort into understanding it, and risk having it change out from under you at the next rev. Microsoft internally, and/or favored partners, get to use the faster, capable native API. So, Windows developers have something of a dilemma to deal with, don't they? Also, I'm given to understand they're callable as C functions.

Actually, that's incorrect. Both the old-school POSIX subsystem and the Interix (Services For Unix) subsystem support a fork system call with copy-on-write semantics. In fact, the NT kernel itself can fork processes trivially, but this isn't exposed in the Win32 subsystem, like most of the fun stuff on NT.

rbanffy 16y ago
I always found it weird having a bunch of Windows kernel operations that are not exposed to Windows apps. How would you call those?
- daeken 16y ago
  Ntdll.dll contains the userspace side of the NT API. Specifically, Zw* and Nt* contain most of the APIs that map directly into the kernel. Then there's the Rtl* stuff which provides a lot of fun functions for manipulating processes, and the Ldr* stuff for loading binaries; Ldr is a lot of fun to hook into, if you want to manipulate binaries with a high degree of transparency. Edit: One thing to note, though, is that it's easy to subvert the Win32 subsystem by using these APIs directly. I.e. if you want to fork a Win32 process, you're going to need to not only fork it the standard NT way, but then tell CSRSS what you're actually doing. It's easy to run into a situation where the Win32 subsystem won't play nicely with you, because it just doesn't have enough information.
- bediger 16y ago
  How is that weird? A semi-hidden API like this is a huge benefit to Microsoft itself, and a detriment to its competitors, or indeed, anyone who writes software that becomes a DLL in the next version of Windows. If you write to a documented API (Win32, GINA, etc) your code is slower and possibly less capable than it could be. If you write to the undocumented NT-native-API, you have to invest time and effort into understanding it, and risk having it change out from under you at the next rev. Microsoft internally, and/or favored partners, get to use the faster, capable native API. So, Windows developers have something of a dilemma to deal with, don't they? Also, I'm given to understand they're callable as C functions.