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 fixes the name of a struct to match Microsoft's documentation.
It also reverts a change I made in the last patchset of CL 285714. The
idea there was that a Go bool would suffice for a win32 BOOL, because of
little endian. But in fact, a value of 0xff000000 would be treated as
false by Go but true by C, which is a problem. So this changes to using
a vanilla int32 type, which matches the C "int" used in the Microsoft
headers.
Change-Id: Id7cd306e916b3754e8dfe32bf11ec30cad3a13b4
Reviewed-on: https://go-review.googlesource.com/c/sys/+/285717
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>
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>
One thing the newer notification API does not do is automatically
provide the service exit code in its notifier response. It requires
querying manually. Unfortunately, we weren't propagating this
information up from the lower level struct, so this commit copys that
information over.
Change-Id: I70c683007ce34ffab6196329acefc8443f921ebe
Reviewed-on: https://go-review.googlesource.com/c/sys/+/274577
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
The "?" code assumed that the error value was always called "err", when
in reality it might be called something different (like "ret") or even
entirely absent. This commit makes the templating robust to that. At the
same time, we move a lot of the complexity out of the actual templates
and into helper functions, so that this remains easy to read.
Change-Id: I939d56413a24f0e3e1bbf13da5adf13e9401747a
Reviewed-on: https://go-review.googlesource.com/c/sys/+/275472
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>
Currently, doing s.UpdateConfig(s.Config()) will destroy the service,
because s.Config() fails to populate the SidType member, but
UpdateConfig will set the SidType, so that expression effectively zeros
out the SidType. Fix this by having Config() fetch the SidType in the
same way that it fetches the other additional fields there, such as
DelayedStartUp.
Change-Id: Idb917ef1e942020499b411b7777b995c29f0e7d2
Reviewed-on: https://go-review.googlesource.com/c/sys/+/270897
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 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>
Some functions that x/sys/windows will eventually have won't be
available on older versions of Windows, and in general we can expect
Microsoft to continue to add functions to newer builds of Windows
10. Therefore, we introduces a new notation for marking functions that
might not exist, letting the caller handle the situation without a
panic.
Change-Id: Ia66bf4aab601357198872c5cd29b6ca7c3bc6969
Reviewed-on: https://go-review.googlesource.com/c/sys/+/269938
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Because we're expecting for future functions to be unavailable, we
should add an Unwrap() function to the DLLError struct, so that people
can test for this situation easily via:
if errors.Is(err, windows.ERROR_PROC_NOT_FOUND) { ... }
DLLError already was wrapping the underlying Errno error, but never got
the Go 1.13 helper method.
Update golang/go#42584
Change-Id: Ib916ddd55a2de29f988edaaf82f2ae0ce1b18e3b
Reviewed-on: https://go-review.googlesource.com/c/sys/+/269937
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>
While most of our constant gathering can be automated, some win32 error
constants come from unusual corners of the WDK, such as setupapi.h. We
add those constants to a new file, so that they can be referenced as
constants by Go programs.
Change-Id: I9bce7fddf7aaa00204e6048b53f14e6ba18d5f13
Reviewed-on: https://go-review.googlesource.com/c/sys/+/268358
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: Simon Rozman <simon@rozman.si>
Reviewed-by: Alex Brainman <alex.brainman@gmail.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>
TestMyService uses the same service name as service in
golang.org/x/sys/windows/svc.TestExample.
https://build.golang.org sometimes schedules TestMyService and
TestExample to run at the same time. If that happens, tests fail,
because they were not designed to run in parallel.
This CL renames service in TestMyService, so it does not clash with
TestExample.
Fixesgolang/go#42211
Change-Id: I928c2ebbae77de3540f5ce16948fb96eeeed836d
Reviewed-on: https://go-review.googlesource.com/c/sys/+/267604
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TestExample normally stops and deletes test service at the end of the
test. But, if TestExample does not complete for some reason, test
service might remain running and installed.
There is some code that deletes "left over" test service before starting
the test. But that code fails, if service is running. Deletion only
works, if service is not running. This CL adds code to stop the "left
over" service so it can be deleted.
Update golang/go#42211
Change-Id: I826dd587063265c5b96076668c3704c0a7eaa3d8
Reviewed-on: https://go-review.googlesource.com/c/sys/+/267603
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
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>
The Windows compilers appear to align JOBOBJECT_BASIC_LIMIT_INFORMATION
to an 8-byte boundary, which on 32-bit systems means adding 32 bits of
padding. Unfortunately we can't always add a padding field, because
no padding is required on a 64-bit system. So use different versions
of the struct for different targets.
Fixesgolang/go#41001
Change-Id: I38d14edfd3f3a80da22825455f20e1f7de136638
Reviewed-on: https://go-review.googlesource.com/c/sys/+/251197
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Marc-Antoine Ruel <maruel@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
