Implementation generated directly with mkwinsyscall has a wrong
assumption about the expected value for PIDs buffer size.
This change adds some small manual code that converts the input
slice length to the number of bytes of the array backing the slice.
A test is also added. It fails with the previous implementation.
Fixesgolang/go#60223
Change-Id: I5e2414acb29c6c949e5e6acd328043f8a8883887
Reviewed-on: https://go-review.googlesource.com/c/sys/+/495995
Commit-Queue: Quim Muntal <quimmuntal@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
This CL updates the windows.UTF16FromString and windows.UTF16ToString
implementation so they forward to their syscall counterparts.
The standard library uses these particular syscall functions across
the board as it can't depend on x/sys. This means that even if the
syscall API is frozen, the implementation still receives improvements
and bug fixes, such as CL 425054.
Porting CL 425054 to x/sys is possible, but for this particular case
I think it's better to just call the syscall package. This way both
repos will benefit from future improvements (which I plan to do soon).
Change-Id: I305c4409142d79a57008d7e6d0717fb8986fe906
Reviewed-on: https://go-review.googlesource.com/c/sys/+/462875
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
On windows, use unsafe.Slice instead of unsafeheader as already the case
for unix and plan9.
The pointers are already *byte/*uint16, so the type conversion can be
omitted as well.
Change-Id: Ida7264cc0c1948bf563ed91d51e637edcdafb77a
Reviewed-on: https://go-review.googlesource.com/c/sys/+/430515
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
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>
