Simon and I have worked on these on and off for a number of projects
over the last 3 years and by now it's quite stable and mature. Rather
than carrying this around privately, these have now been updated to be
in the style of x/sys/windows, in this case matching how the
security_windows.go file does things. Specifically, because these APIs
are kind of hard to work with, and quite lengthy, we split them off into
a setupapi_windows.go file, just like security_windows.go. We already
had the setupapierrors_windows.go file, so that's been folded into the
new one that contains the additional definitions nad functions.
These APIs are among the most obtuse to work with in all of Win32, so
considerable attention has been spent trying to make these wrappers both
quite "raw" so that they match the win32, but also accessible from Go.
The fact that they're so old in Windows history makes for a few tricky
things, like struct padding that doesn't quite match Go's rules, but
we've been able to accommodate basically everything after quite a bit of
work.
Change-Id: I0c2dd85e4bb40eee10186ffc92558a858bdf8c6a
Reviewed-on: https://go-review.googlesource.com/c/sys/+/366654
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Patrik Nyblom <pnyb@google.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Simon Rozman <simon@rozman.si>
Reviewed-by: Patrik Nyblom <pnyb@google.com>
In anticipation of the next commit which adds win32 pipe APIs, add some
of the foundational NT APIs for that, which will be required for making
a robust Go pipe library. Also add a simple test case.
Change-Id: I898bd6c5265a8939a7f05a24c4d9b22941dc56b7
Reviewed-on: https://go-review.googlesource.com/c/sys/+/298171
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It turns out that the proc thread update function doesn't actually
allocate new memory for its arguments and instead just copies the
pointer values into the preallocated memory. Since we were allocating
that memory as []byte, the garbage collector didn't scan it for pointers
to Go allocations and freed them. We _could_ fix this by requiring that
all users of this use runtime.KeepAlive for everything they pass to the
update function, but that seems harder than necessary. Instead, we can
just do the allocation as []unsafe.Pointer, which means the GC can
operate as intended and not free these from beneath our feet. In order
to ensure this remains true, we also add a test for this.
Updates golang/go#44662.
Change-Id: Iaa8b694a6682cc1876879632c7ba068e47b8666d
Reviewed-on: https://go-review.googlesource.com/c/sys/+/297331
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The prior function updated the TEB's LastStatus member, which is not
what we want to be doing here. It's also not consistent with Microsoft's
own Go code for their pipe library, which properly uses the "NoTeb"
variant like this commit.
For good measure, we add a simple test case to make sure these paths are
being exercised.
Change-Id: I4080898f704bdc93a6048001b06ffce516fb412d
Reviewed-on: https://go-review.googlesource.com/c/sys/+/298169
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The native NT API returns error values from a different namespace as the
usual Win32 one. This means it needs to be typed differently. This
commit adds broad support for using NTSTATUS values in a new type called
NTStatus.
First we add the type as a basic uint32. Then we add all of the
predefined constants from ntstatus.h, by augmenting mkerrors.bash to do
automatic extraction. There's a convenece way to convert an NT error to
a Win32 error, so we add the NTStatus.Errno() function. Since NTStatus
is an error type, we define an Error() function that returns a string by
asking ntdll.dll for its contents, in the exact same way that
syscall.Errno.Error() does, by calling FormatMessage. Since functions
need to actually use this, we add the rule that if a `//sys` declaration
returns an error value called "ntstatus", then the type underlying the
error interface is an NTStatus instead of an Errno. Finally we fix one
function that was returning an error interface of an Errno rather than
an NTStatus.
Change-Id: I06296b9563bbec526759d12a19f13ac6ad46dcc3
Reviewed-on: https://go-review.googlesource.com/c/sys/+/297330
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The third argument to GetQueuedCompletionStatus is a pointer to a
uintptr, not a uint32. Users of this functions have therefore been
corrupting their memory every time they used it. Either that memory
corruption was silent (dangerous), or their programs didn't work so they
chose a different API to use.
Updates golang/go#44538.
Change-Id: Ie1f66de11001cf9c8195afaa61f003a86f821a95
Reviewed-on: https://go-review.googlesource.com/c/sys/+/295174
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This function returns 0 and sets last error on failure. While this isn't
said explicitly on MSDN, there's no PID 0, and trivial reverse
engineering shows that this is the case. For example:
.text:00000001800035ED loc_1800035ED: ; CODE XREF: GetWindowThreadProcessId+23↑j
.text:00000001800035ED ; GetWindowThreadProcessId+3D↑j ...
.text:00000001800035ED mov ecx, 578h ; LastError
.text:00000001800035F2 call cs:__imp_RtlSetLastWin32Error
.text:00000001800035F9 nop dword ptr [rax+rax+00h]
.text:00000001800035FE
.text:00000001800035FE loc_1800035FE: ; CODE XREF: GetWindowThreadProcessId+65↑j
.text:00000001800035FE xor eax, eax
.text:0000000180003600 jmp short loc_1800035AA
This function was also just added by a user who is likely its only
consumer, so this error is not too late to fix.
Change-Id: I5dd24e78c006686bb8f1288ad0fe63cd67df56a6
Reviewed-on: https://go-review.googlesource.com/c/sys/+/285272
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This matches usual win32api conventions. While we're at it, we
group together user32.dll functions together.
This CL was based on CL 282634 with all but MessageBox, GetShellWindow
and GetWindowThreadProcessId changes removed to prevent compatibility
break.
Change-Id: I7e17c581723c41580a49c5612cabc7a5c13c0f15
Reviewed-on: https://go-review.googlesource.com/c/sys/+/282972
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Trust: Alex Brainman <alex.brainman@gmail.com>
The original IsWow64Process returns false on arm, always, and so
IsWow64Process2 was added to account for this scenario. This isn't
available on older versions of Windows, so we mark it as such using the
new '?' notation. Finally, we add a test to make sure this all works and
does the expected thing on different versions of Windows.
Change-Id: Ic0412578cfb3f4cf6c9dc92a0028abc579bf6c85
Reviewed-on: https://go-review.googlesource.com/c/sys/+/269077
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
CL 258038 improperly added a weird custom type to mkwinsyscall, rather
than doing the norm with wrapper functions. So, we revert the change to
mkwinsyscall and add the proper wrapper function to do the type
conversion.
Change-Id: I98134e4ce6bf4b52e1384fe84bddeedb00e18c0b
Reviewed-on: https://go-review.googlesource.com/c/sys/+/268777
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
We already provide ByteSliceFromString and BytePtrFromString, and on
Windows we provide UTF16FromString, UTF16PtrFromString, UTF16ToString,
and UTF16PtrToString. So this commit fills in the remaining two
Byte-oriented functions: ByteSliceToString and BytePtrToString. Since
the existing two are available on windows, unix, and plan9, we add the
remaining two to the same places. This helps eliminate unsafe pointer
options in addition to triggering checkptr in Go 1.15, by eliminating
the use of prior idioms for these types of casts.
Change-Id: I85ae49f2756e142c2462fe8b2428216b6992e089
Reviewed-on: https://go-review.googlesource.com/c/sys/+/263757
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
CL 244958 includes isWindowsService function that determines if a
process is running as a service. The code of the function is based on
public .Net implementation.
IsAnInteractiveSession function implements similar functionality, but
is based on an old Stackoverflow post., which is not as authoritative
as code written by Microsoft for their official product.
This change copies CL 244958 isWindowsService function into svc package
and makes it public. The intention is that future users will prefer
IsWindowsService to IsAnInteractiveSession.
Also this change adds "Deprecated" comment to IsAnInteractiveSession to
point future users to IsWindowsService.
Call to IsAnInteractiveSession is also replaced with IsWindowsService
in golang.org/x/sys/windows/svc/example package.
Change-Id: I4a33b7f590ee8161d1134d8e83668e9da4e6b434
Reviewed-on: https://go-review.googlesource.com/c/sys/+/259397
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Trust: Alex Brainman <alex.brainman@gmail.com>
