At this point points of difference between the three local
mksyscall_windows.go implementations and
golang.org/x/sys/windows/mkwinsyscall v0.0.0-20210104204734-6f8348627aad
are:
- pkg/etw: Deduplicates imported functions due to multiple calling APIs
- pkg/security and vhd: Forced UTF-16 mode, not checking A/W suffix. I
also removed cosmetic differences between these two implementations.
`go generate` reports no changes with these updates.
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
This moves all the current users of
$GOROOT/src/syscall/mksyscall_windows.go to instead use
golang.org/x/sys/windows/mkwinsyscall, as directed by the version of the
former in Go 1.15.
It also syncs the local forks of mksyscall_windows.go with the latest
version of golang.org/x/sys/windows/mkwinsyscall/mkwinsyscall.go, so
that the local patches can be easily seen in a side-by-side comparison.
Significant changes compared to the in-tree forked versions:
* *bool parameters are read back through a temp-var, not directly like
other pointer parameters.
* ?-suffixed function names support testing for function presence before
calling. This replaces a local implementation of this in
pkg/security, which was not actually used anyway. The upstream version
correctly supports functions that don't already have an error return.
* `errnoErr(0)` is now useful, so each call of `errnoErr` doesn't need
to be protected with a check for 0 first.
* The generated functions are now sorted. This of course produced a
*lot* of churn in the generated files.
vhd\vhd.go was changed to generate syscalls into zvhd_windows.go, since
regeneration removes the build tag added by hand in
9d8277341f.
After all that, I also ran
```
go generate . .\pkg\etw\ .\pkg\process\ .\pkg\security\ .\vhd\
```
to update all the existing generated code.
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
Adds the basic structs for VHD function calls and includes one simple wrapper for VHDX creation.
This includes the updated version of mksyscall_windows.go, which previously assumed any api that doesn't end in "W" must not be unicode, and encodes the strings incorrectly. This hard-codes for unicode support and generates the syscalls from there.
Paul "TBBle" Hampson