The definition of HKEY__ as a struct with an unused int field is only the case in the Windows headers when `STRICT` is defined. From https://learn.microsoft.com/en-us/windows/win32/winprog/enabling-strict:
> When STRICT is defined, data type definitions change as follows:
>
> - Specific handle types are defined to be mutually exclusive; for example, you will not be able to pass an HWND where an HDC type argument is required. Without STRICT, all handles are defined as HANDLE, so the compiler does not prevent you from using one type of handle where another type is expected.
Zig's `opaque {}` already gives this benefit to us, so the usage of a struct with an unused field is unnecessary, and it was causing HKEY to have an alignment of 4, which is a problem because there are HKEY constants like HKEY_LOCAL_MACHINE (0x80000002) that are not 4-byte aligned. Without this change, the compiler would not allow something like HKEY_LOCAL_MACHINE to be defined since it enforces pointer alignment.
I found that after switching from my custom Guid parser to the one in std that it increased zigwin32 build times substantially (from 40 seconds to over 10 minutes). More information can be found in the benchmark PR I created here: https://github.com/ziglang/gotta-go-fast/pull/21 . This PR ports my GUID parser to std so all projects can leverage the faster comptime performance.
The size of a GUID is not platform-dependent, it's always a fixed number of bits. So I've updated guid to use fixed bit integer types rather than platform-dependent C integer types.
The semantics of this function are that it moves both files and
directories. Previously we had this `is_dir` boolean field of
`std.os.windows.OpenFile` which required the API user to choose: are we
opening a file or directory? And the other kind would either cause
error.IsDir or error.NotDir. But that is not a limitation of the Windows
file system API; it was self-imposed.
On Windows, rename is implemented internally with `NtCreateFile` so we
need to allow it to open either files or directories. This is now done
by `std.os.windows.OpenFile` accepting enum{file_only,dir_only,any}
instead of a boolean.
This is a breaking change. Before, usage looked like this:
```zig
const held = mutex.acquire();
defer held.release();
```
Now it looks like this:
```zig
mutex.lock();
defer mutex.unlock();
```
The `Held` type was an idea to make mutexes slightly safer by making it
more difficult to forget to release an aquired lock. However, this
ultimately caused more problems than it solved, when any data structures
needed to store a held mutex. Simplify everything by reducing the API
down to the primitives: lock() and unlock().
Closes#8051Closes#8246Closes#10105
We already have a LICENSE file that covers the Zig Standard Library. We
no longer need to remind everyone that the license is MIT in every single
file.
Previously this was introduced to clarify the situation for a fork of
Zig that made Zig's LICENSE file harder to find, and replaced it with
their own license that required annual payments to their company.
However that fork now appears to be dead. So there is no need to
reinforce the copyright notice in every single file.
All other uses of `ws2_32.socklen_t` in windows.zig casts the value to an i32. `recvfrom` should do so as well; it currently errors out with `expected type '?*i32', found '?*u32'`.
