[MarkSweep]

> I wonder how much of this problem was caused by lack of adequate documentation describing how an installer should behave, and how much was developers not reading that documentation and being content when it works on their machine.

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.

https://codeberg.org/ziglang/zig/issues/31131

[kaashif]

This comment is pretty wild:

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

[throwA29B]

>ignore them for some reason

The reasons are clearly stated in the issue you have linked.

[MarkSweep]

I understand the stated reasons and disagree with their conclusions. It seems like a lot of extra work on the part of the Zig developers to have to reverse engineer undocumented interfaces. There is potentially extra work for the Windows developers if they want to change their private implementation details that Zig programs are now relying on. And in the case where the lower level APIs are missing features implemented higher level APIs, Zig has to either reimplment the functionality themselves or not have the same level of support for Windows features that normal Win32 apps have. A concrete example is looks like Zig programs can't open serial devices:

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.

[guenthert]

"As Zig has evolved, it has become a target to avoid calling Win32 APIs from kernel32.dll etc., instead using lower-level ones in ntdll.dll."

If we needed an example of why we should avoid using passive voice, this is it.

[loevborg]

This sentence doesn't include examples of the passive voice.

[guenthert]

Ha, you're absolutely right. The "has become a target" got me there. So glad, Zig wasn't targeted there.

[MForster]

The sentence that you quoted is more generic. The Zig issue is only one example of "some reason".

[gzread]

Wow! What a mind-bogglingly stupid idea. I will cancel my plans to learn Zig.

[ziml77]

My excitement for Zig dropped the longer they stayed at 0.x (and they really have meant 0.x with the breaking changes they were making). This decision from them completely killed it for me.

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.

[baranul]

Part of this was the allowed or special treatment given to Zig at certain sites. It then allowed the false impression to be created of it being production ready and/or far more stable than it actually is. Often intentionally overlooking or glossing over that it's still in beta, making breaking changes, and has thousands of issues (over 3,000 on GitHub).

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.

[nektro]

ntdll.dll APIs are guaranteed to be stable though

[MarkSweep]

The best statement of whether or not calling functions in ntdll is here: https://learn.microsoft.com/en-us/windows-hardware/drivers/k...

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

[iknowstuff]

Kinda wild