4 ms·

Is there an official stance on whether ntdll is stable? Obviously they're not going to change things arbitrarily since applications depend on it, but I'm wonder

by cmovq 8mo ago

Is there an official stance on whether ntdll is stable? Obviously they're not going to change things arbitrarily since applications depend on it, but I'm wondering if there is a guarantee like the linux syscall interface or how you can run a win32 application compiled in 2004 on Win11.

monocasa 8mo ago
It's partially stable. Basically any thing documented on msdn in the API docs is considered stable. Such as: https://learn.microsoft.com/en-us/windows/win32/api/winternl/nf-winternl-ntcreatefile https://learn.microsoft.com/en-us/windows/win32/api/winternl...
- delta_p_delta_x 8mo ago
  Indeed. Anything documented has a function wrapper. `NtCreateFile` is a function wrapper for the syscall number, so any user-mode code that has `NtCreateFile` instead of directly loading the syscall number 0x55 will be stable. The latter might not. In fact, it is not; the number has increased by 3 since Windows XP[1]. One could probably produce some sort of function pointer loader library with these tables, but at that point... Why not just use the documented APIs? [1]: https://github.com/j00ru/windows-syscalls/blob/8a6806ac9148633e8afbbdb42e6002930b002741/x64/csv/nt.csv#L100 https://github.com/j00ru/windows-syscalls/blob/8a6806ac91486...
  - Dwedit 8mo ago
    Only Malware uses the system call numbers directly. Using the system call numbers directly is foolish if they're going to change and break your app. Just import and call a function that will perform the actual SYSENTER (or WOW64 context change).
    - monocasa 8mo ago
      Unfortunately, that's not the case. Wine for instance has to keep up to date to maintain compatibility with some applications. https://gitlab.winehq.org/wine/wine/-/releases/wine-11.0 https://gitlab.winehq.org/wine/wine/-/releases/wine-11.0 > NT system calls use the same syscall numbering as recent Windows, to support applications that hardcode syscall numbers.
- cmovq 8mo ago
  Interesting, some functions explicitly mention: > [NtQuerySystemTime may be altered or unavailable in future versions of Windows. Applications should use the GetSystemTimeAsFileTime function.] [0] So it does seem like a bad idea for a standard library. [0]: https://learn.microsoft.com/en-us/windows/win32/api/winternl/nf-winternl-ntquerysystemtime https://learn.microsoft.com/en-us/windows/win32/api/winternl...
- Dwedit 8mo ago
  NTDLL should be stable since it's well documented, and many functions redirect to Ntoskrnl.exe, and things like kernel level drivers call those functions. Those functions won't change without the drivers breaking. Then there's "Win32u.dll". These correspond to API calls from User32.dll, Gdi32.dll, etc. This DLL didn't even exist during the Windows 2000-XP era. This stuff is not well documented, and I don't know if this is stable.
  - monocasa 8mo ago
    Sure, I rarely see people refer to the win32k stubs in win32u as part of the native api, despite the Nt prefixes.

by cmovq 8mo ago

monocasa 8mo ago

It's partially stable. Basically any thing documented on msdn in the API docs is considered stable. Such as: https://learn.microsoft.com/en-us/windows/win32/api/winternl/nf-winternl-ntcreatefile https://learn.microsoft.com/en-us/windows/win32/api/winternl...

delta_p_delta_x 8mo ago
Indeed. Anything documented has a function wrapper. `NtCreateFile` is a function wrapper for the syscall number, so any user-mode code that has `NtCreateFile` instead of directly loading the syscall number 0x55 will be stable. The latter might not. In fact, it is not; the number has increased by 3 since Windows XP[1]. One could probably produce some sort of function pointer loader library with these tables, but at that point... Why not just use the documented APIs? [1]: https://github.com/j00ru/windows-syscalls/blob/8a6806ac9148633e8afbbdb42e6002930b002741/x64/csv/nt.csv#L100 https://github.com/j00ru/windows-syscalls/blob/8a6806ac91486...
- Dwedit 8mo ago
  Only Malware uses the system call numbers directly. Using the system call numbers directly is foolish if they're going to change and break your app. Just import and call a function that will perform the actual SYSENTER (or WOW64 context change).
  - monocasa 8mo ago
    Unfortunately, that's not the case. Wine for instance has to keep up to date to maintain compatibility with some applications. https://gitlab.winehq.org/wine/wine/-/releases/wine-11.0 https://gitlab.winehq.org/wine/wine/-/releases/wine-11.0 > NT system calls use the same syscall numbering as recent Windows, to support applications that hardcode syscall numbers.
cmovq 8mo ago
Interesting, some functions explicitly mention: > [NtQuerySystemTime may be altered or unavailable in future versions of Windows. Applications should use the GetSystemTimeAsFileTime function.] [0] So it does seem like a bad idea for a standard library. [0]: https://learn.microsoft.com/en-us/windows/win32/api/winternl/nf-winternl-ntquerysystemtime https://learn.microsoft.com/en-us/windows/win32/api/winternl...
Dwedit 8mo ago
NTDLL should be stable since it's well documented, and many functions redirect to Ntoskrnl.exe, and things like kernel level drivers call those functions. Those functions won't change without the drivers breaking. Then there's "Win32u.dll". These correspond to API calls from User32.dll, Gdi32.dll, etc. This DLL didn't even exist during the Windows 2000-XP era. This stuff is not well documented, and I don't know if this is stable.
- monocasa 8mo ago
  Sure, I rarely see people refer to the win32k stubs in win32u as part of the native api, despite the Nt prefixes.