-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Windows: Rework kernel32 apis #19641
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
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
To facilitate #1840, this commit slims
std.windows.kernel32to 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
ntdllAPIs, 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.windowsfor 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
TODOcomments that specify which functions can be reimplemented usingntdllAPIs in the future.Other changes: