reduce windows API bindings in the standard library to the minimum required for the standard library's own abstractions to work

[andrewrk]

Accepted Decision

---

Windows has a huge API surface. This opens the question of, what is the purpose of std lib windows API bindings?

Is it...

• 🗳️ minimal surface area for the std lib's own abstractions to work, with the idea of eventually being supplemented by a third party package for users who want more comprehensive API coverage?
• 🗳️ a complete, up-to-date, maintained set of all Windows API functions, for some approved set of DLLs?
• 🗳️ some subset across DLLs that "feels right" for a standard library to have, with opinions on which functions should or should not be called (e.g. 'A' functions, see switch to using 'W' versions of windows functions instead of 'A' #534)?

In this proposal I am advocating for (1). I also think that (2) would be reasonable. I agree with @LemonBoy here that (3) is not reasonable.

[Sobeston]

By bindings are we talking just the function signatures, or wrappings with zig errors and such?
The latter obviously being a lot more work.

[mlarouche]

My vote for 2

[LemonBoy]

My vote is for (2) too, if the conversion process can be completely automated it's even better.

[Sobeston]

By bindings are we talking just the function signatures, or wrappings with zig errors and such?
The latter obviously being a lot more work.

If we are talking the former, most of the work could be automated, with the caveat being that deciding which pointers are nullable will likely have to be done by a human.

[Rocknest]

(3) it should contain preferred API's which excludes non thread safe functions and deprecated apis and possibly apis are not present in lowest supported windows version (win 8.1?)

[Sobeston]

and possibly apis are not present in lowest supported windows version (win 8.1?)

I'm not aware of microsoft ever removing api functions (at least in the last 20 years) - they're very against this.

Personally I'm against 3 primarily because it will spawn endless avoidable discussion on what does and doesn't constitute as an excludable function.

There is also that if you're using winapi instead of the rest of the standard library you're likely doing things very wrong in the first place (...let's assume we're at 1.0 and the standard library is all good and covers all common use cases).

Another thing to add to this question: how to we deal with multiple versions of windows, which have differing sets of functions? (related: #1907)

[JesseRMeyer]

2

[Rocknest]

@Sobeston they do not remove apis, but they add them.

[ikskuh]

I vote for (1) as it would fit the Zig spirit of "not doing too much".
std should only use a minimum set of APIs and if a user needs the full WinAPI including windows, fibers, ... he/she should import a WinAPI package.

This reduces the maintenance surface of std and the core of the language is kept small