We also get pre-defined constants instead of carrying our own copies.
However, this changes the public API winio.FileBasicInfo from using
syscall.Filetime to using windows.Filetime, as visible in
backuptar/tar.go.
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>
ListenPipe can fail if there is a concurrent DialPipe because there is a
race window where DialPipe can connect to the initial server named pipe
before it is connected to and closed by ListenPipe.
To fix this, use the lower-level NT API for creating the server pipe,
since this API allows for specifying that a server pipe should initially
be in the disconnected state instead of the listening state. This allows
us to avoid the race condition by creating the pipe in the correct state
initially, so there is no longer a need to create a dummy client
connection.
Starting in go1.9, Golang lowers the timer frequency when not required
reducing CPU usage. This workaround prevents Golang from doing so,
and since the initial issue was fixed, I see no perf regressions.
This does not need to be conditional based on Golang verison, as the issue
being worked around was only in go1.6.
Signed-off-by: Darren Stahl <darst@microsoft.com>
Kathryn Baldauf