-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows: Rework kernel32 apis #19641
Windows: Rework kernel32 apis #19641
Conversation
b987c2e
to
edcbf9d
Compare
I've added fleshed out the comments on the remaining APIs. I've categorised them into three groups:
|
3e99b86
to
ab020f0
Compare
60252bb
to
7615944
Compare
57f8ff0
to
6fb865e
Compare
3999adb
to
98b3e14
Compare
aa26b64
to
44b364c
Compare
44b364c
to
4ac10cd
Compare
To facilitate ziglang#1840, this commit slims `std.windows.kernel32` to only have the functions needed by the standard library. Since this will break projects that relied on these, I offer two solutions: - Make an argument as to why certain functions should be added back in. Note that they may just be wrappers around `ntdll` APIs, which would go against ziglang#1840. If necessary I'll add them back in *and* make wrappers in `std.windows` for it. - Maintain your own list of APIs. This is the option taken by bun[1], where they wrap functions with tracing. - Use `zigwin32`. I've also added TODO comments that specify which functions can be reimplemented using `ntdll` APIs in the future. Other changes: - Group functions into groups (I/O, process management etc.). - Synchronize definitions against Microsoft documentation to use the proper parameter types/names. - Break all functions with parameters over multiple lines.
4ac10cd
to
3095e83
Compare
@andrewrk This pr has been open for a couple months now, since then a couple Windows API changes have been made. I've kept this branch up-to-date but I'd like it to be merged before I do any more changes (specifically, adding a Do you have any objections to these changes? |
Sorry for the delay, I hadn't seen it until now. Looks good! Thanks for your patience on the merge. |
In ziglang#19641, this binding changed from `[*]u16` to `LPWSTR` which made it a sentinel-terminated pointer. This introduced a compiler error in the `std.os.windows.GetModuleFileNameW` wrapper since it takes a `[*]u16` pointer. This commit changes the binding back to what it was before instead of introducing a breaking change to `std.os.windows.GetModuleFileNameW` Related: ziglang#20858
In #19641, this binding changed from `[*]u16` to `LPWSTR` which made it a sentinel-terminated pointer. This introduced a compiler error in the `std.os.windows.GetModuleFileNameW` wrapper since it takes a `[*]u16` pointer. This commit changes the binding back to what it was before instead of introducing a breaking change to `std.os.windows.GetModuleFileNameW` Related: #20858
In ziglang#19641, this binding changed from `[*]u16` to `LPWSTR` which made it a sentinel-terminated pointer. This introduced a compiler error in the `std.os.windows.GetModuleFileNameW` wrapper since it takes a `[*]u16` pointer. This commit changes the binding back to what it was before instead of introducing a breaking change to `std.os.windows.GetModuleFileNameW` Related: ziglang#20858
In ziglang#19641, this binding changed from `[*]u16` to `LPWSTR` which made it a sentinel-terminated pointer. This introduced a compiler error in the `std.os.windows.GetModuleFileNameW` wrapper since it takes a `[*]u16` pointer. This commit changes the binding back to what it was before instead of introducing a breaking change to `std.os.windows.GetModuleFileNameW` Related: ziglang#20858
To facilitate #1840, this commit slims
std.windows.kernel32
to only have the functions needed by the standard library. Since this will break projects that relied on these, I offer these solutions:Make an argument as to why certain functions should be added back in. Note that they may just be wrappers around
ntdll
APIs, which would go against Prefer depending on NtDll rather than kernel32 or other higher level DLLs #1840.If necessary I'll add them back in and make wrappers in
std.windows
for it.Maintain your own list of APIs. This is the option taken by bun, where they wrap functions with tracing.
Use
zigwin32
.I've also added
TODO
comments that specify which functions can be reimplemented usingntdll
APIs in the future.Other changes: