5 ms·

I mean, you could say anything is subject to change. The "documented" <-> "stable" mapping isn't a bijection. CreateFileTransacted was documented for kernel32 b

I mean, you could say anything is subject to change. The "documented" <-> "stable" mapping isn't a bijection. CreateFileTransacted was documented for kernel32 but that didn't stop it from being claimed as deprecated. And CallNtPowerInformation was documented and yet some of it simply doesn't work anymore. Also, Microsoft didn't necessarily document everything, but they did provide .lib files (and often headers) even for "undocumented" APIs in these libraries. Breaking these APIs would break programs they previously provided SDKs for. The reality is, so many third-party applications depend directly on ntdll APIs (even Chrome) and some of them literally cannot work with kernel32 stuff (boot-time partition managers, for one), so as far as I'm concerned, it's about as much set in stone as any library could be.

asveikau 7y ago
Yeah. Direct dependence on ntdll occurs in the wild and it would break stuff to change it. It can also break MS's own code and potentially create massive engineering hurdles for them that are completely unnecessary. But they have always warned people in documentation that they don't consider it a stable interface to the same extent as Win32. In my experience a lot of the NT APIs are nicer, better thought out, more direct.
- KyleJ61782 7y ago
  Using the NTDLL calls breaks stuff because NTDLL doesn't understand anything about the overlaid subsystems. NT was originally designed to support multiple subsystems in addition to Win32, like the Interix (POSIX compliant) subsystem and the OS/2 subsystem I believe. I think (I could be wrong on this) that this was possible by switching the system call table depending upon which process was currently active (doable by switching the system call vector).
  - Avery3R 7y ago
    IIRC the syscall table doesn't get swapped out. Each subsystem translates its calls to NT API calls. For example, user32.dll and kernel32.dll are a part of the win32 subsystem and eventually end up calling NT APIs in ntdll.dll. It's possible for a process to have no subsystem, these are called native NT process and the only dll loaded by default into their address space is ntdll, csrss.exe is an example of this.
  - mehrdadn 7y ago
    The layer underneath that they build subsystems on is always the system call interface (ntdll), not the syscall numbers themselves.
jart 7y ago
It's a political thing. Microsoft isn't going to break themselves. It's more a question of, if you go against all the warnings and use NTDLL in the non-recommended way (i.e. having it be a hard dependency w/o fallback) Microsoft can and will fuck you if they don't like what you're doing. Just as recently as a few months ago, I saw a startup in Sunnyvale called Crossmeta basically throw in the towel, because they built their whole product around this one NTDLL fork() hack, which had been around for nearly decades. Then MS rolled out a security update, and poof, it's gone.
- mehrdadn 7y ago
  Wow, cool story. The part I find surprising is -- there was a fork() hack on NTDLL that actually worked until recently? I know tons of people had tried to get it to work (including the Cygwin folks and also including me) and faced failure after failure!
  - KyleJ61782 7y ago
    Technically the Windows native layer supports fork()-like abilities, but the problem is that the Win32 subsystem and dependent layers (GUI, etc.) don't have fork() copy-on-write capability. So even if you were able to fork a process, you'd still have to deal with duplicating all of the stuff built on top. In fact, the old POSIX compatible subsystem layer utilized this functionality to actually provide a compliant fork(). Of course this all ignores the fact that Win32 processes are heavier duty than Linux processes (though I don't know if that's due to Win32 subsystem overhead or not). Look at any benchmark and you see an order of magnitude difference in process creation times. You're much better off creating threads instead.
    - Kipters 7y ago
      WSL1 also uses that functionality
      - mehrdadn 7y ago
        Huh? WSL1 doesn't use NTDLL, it implements its own stuff.

asveikau 7y ago

Yeah. Direct dependence on ntdll occurs in the wild and it would break stuff to change it. It can also break MS's own code and potentially create massive engineering hurdles for them that are completely unnecessary. But they have always warned people in documentation that they don't consider it a stable interface to the same extent as Win32. In my experience a lot of the NT APIs are nicer, better thought out, more direct.

KyleJ61782 7y ago
Using the NTDLL calls breaks stuff because NTDLL doesn't understand anything about the overlaid subsystems. NT was originally designed to support multiple subsystems in addition to Win32, like the Interix (POSIX compliant) subsystem and the OS/2 subsystem I believe. I think (I could be wrong on this) that this was possible by switching the system call table depending upon which process was currently active (doable by switching the system call vector).
- Avery3R 7y ago
  IIRC the syscall table doesn't get swapped out. Each subsystem translates its calls to NT API calls. For example, user32.dll and kernel32.dll are a part of the win32 subsystem and eventually end up calling NT APIs in ntdll.dll. It's possible for a process to have no subsystem, these are called native NT process and the only dll loaded by default into their address space is ntdll, csrss.exe is an example of this.
- mehrdadn 7y ago
  The layer underneath that they build subsystems on is always the system call interface (ntdll), not the syscall numbers themselves.

jart 7y ago

It's a political thing. Microsoft isn't going to break themselves. It's more a question of, if you go against all the warnings and use NTDLL in the non-recommended way (i.e. having it be a hard dependency w/o fallback) Microsoft can and will fuck you if they don't like what you're doing. Just as recently as a few months ago, I saw a startup in Sunnyvale called Crossmeta basically throw in the towel, because they built their whole product around this one NTDLL fork() hack, which had been around for nearly decades. Then MS rolled out a security update, and poof, it's gone.

mehrdadn 7y ago
Wow, cool story. The part I find surprising is -- there was a fork() hack on NTDLL that actually worked until recently? I know tons of people had tried to get it to work (including the Cygwin folks and also including me) and faced failure after failure!
- KyleJ61782 7y ago
  Technically the Windows native layer supports fork()-like abilities, but the problem is that the Win32 subsystem and dependent layers (GUI, etc.) don't have fork() copy-on-write capability. So even if you were able to fork a process, you'd still have to deal with duplicating all of the stuff built on top. In fact, the old POSIX compatible subsystem layer utilized this functionality to actually provide a compliant fork(). Of course this all ignores the fact that Win32 processes are heavier duty than Linux processes (though I don't know if that's due to Win32 subsystem overhead or not). Look at any benchmark and you see an order of magnitude difference in process creation times. You're much better off creating threads instead.
  - Kipters 7y ago
    WSL1 also uses that functionality
    - mehrdadn 7y ago
      Huh? WSL1 doesn't use NTDLL, it implements its own stuff.