There is a third option: the developers knew the rules and chose to ignore them for some reason. A modern example of this is the Zig language’s decision to reverse engineer and use undocumented APIs in Windows in preference of using documented APIs.
There is a third option: the developers knew the rules and chose to ignore them for some reason. A modern example of this is the Zig language’s decision to reverse engineer and use undocumented APIs in Windows in preference of using documented APIs.
> In addition to what @The-King-of-Toasters said, the worst case scenario is really mild: A new version of windows comes out, breaking ntdll compatibility. Zig project adds a fix to the std lib. Application developer recompiles their zig project from source, and ships an update to their users.
Uh so what if the application developer isn't around any more?
The fact that they consider the worst case to be one where the application is still actively supported and the developer is willing to put up with this nonsense is pretty surprising. Not sure how anyone could believe that.
The reasons are clearly stated in the issue you have linked.
If we needed an example of why we should avoid using passive voice, this is it.
https://codeberg.org/ziglang/zig/src/commit/6193470ceea89a98...
All this to save a little memory CPU and memory usage? The juice does not seem worth the squeeze.
I understood not using the C Runtime and instead creating direct wrappers over the Win32 API, but going a level lower to APIs that are not guaranteed to be stable is nutty.
> documentation for the WDK and Windows SDK recommends that application developers avoid calling undocumented Nt entry points
So it's safe to call documented ntdll functions. But calling undocumented functions is more risky.
They were allowed to have it both ways, pre-1.0 and yet somehow (near, like, just about) production-ready. Almost there, for years. Strangely given a free pass to get away with this, for what looked to be undisclosed financial and other fuzzy reasons.