[monocasa]

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...

[delta_p_delta_x]

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/8a6806ac91486...

[Dwedit]

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).

[cmovq]

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...

[Dwedit]

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]

Sure, I rarely see people refer to the win32k stubs in win32u as part of the native api, despite the Nt prefixes.