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>
I noticed that we call syscall in servicemain without aligning stack.
That is against Windows rules, so align the stack as required.
I tried running this code with specifically non-aligned stack (I aligned
stack, and then subtracted 1 from SP) on my Windows 10 to test this
change. But it makes no difference on my Windows 10 PC - I built and run
golang.org/x/sys/windows/svc/example, and it runs successfully
regardless of stack alignment. But alignment might make difference on
other computers.
Maybe fixesgolang/go#40160
Change-Id: I351f7f730fba4aa6dc409a79de4ad737b4a0a7d4
Reviewed-on: https://go-review.googlesource.com/c/sys/+/246317
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This CL fixes unsafe casts to slices that are missing length or capacity.
Running tests with -d=checkptr enabled may panic on casting unsafe.Pointer to a static array of large predefined length, that is most likely much bigger than the size of the actual array in memory. Checkptr check is not satisfied if slicing operator misses length and capacity arguments `(*[(1 << 30) - 1]uint16)(unsafe.Pointer(p))[:]`, or when there is no slicing at all `(*[(1 << 30) - 1]uint16)(unsafe.Pointer(p))`.
To find all potential cases I used `grep -nr ")(unsafe.Pointer(" ./windows`, then filtered out safe casts when object size is always static and known at compile time.
To reproduce the issue run tests with checkptr enabled `go test -a -gcflags=all=-d=checkptr ./windows/...`.
Updates golang/go#34972Fixesgolang/go#38355
Change-Id: I9dd2084b4f9fb7618cdb140fb2f38b56b6d6cc04
GitHub-Last-Rev: 73288ad18a
GitHub-Pull-Request: golang/sys#65
Reviewed-on: https://go-review.googlesource.com/c/sys/+/225418
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This commit adds the following MUI functions:
- GetUserPreferredUILanguages
- GetSystemPreferredUILanguages
- GetThreadPreferredUILanguages
- GetProcessPreferredUILanguages
Change-Id: I44f1c07245ab814935778c6b910b224d24cc753c
Reviewed-on: https://go-review.googlesource.com/c/sys/+/207860
Reviewed-by: Simon Rozman <simon@rozman.si>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
CL 199519 broke the build with Go 1.11. Even though this is not an
officially supported release anymore, people still seem to rely on it
and the fix is easy enough and won't break anyone using newer, supported
Go versions.
Change-Id: I632d6840bc1f49c01c372727c9a55d2daf98f4a8
Reviewed-on: https://go-review.googlesource.com/c/sys/+/206357
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This test's existence was predicated upon assumptions about the full
range of known data types and known data into those types. However,
we've learned from Microsoft that there are several undocumented secret
registry types that are in use by various parts of Windows, and we've
learned from inspection that many Microsoft uses of registry types don't
strictly adhere to the recommended value size. It's therefore foolhardy
to make any assumptions about what goes in and out of the registry, and
so this test is meaningless and error-prone.
Updates golang/go#35084
Change-Id: Ie545229afd8dc5bde90fffa0f735f7102cd4a6eb
Reviewed-on: https://go-review.googlesource.com/c/sys/+/203605
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
According to MSDN, "If the data has the REG_SZ, REG_MULTI_SZ or
REG_EXPAND_SZ type, this size includes any terminating null character or
characters unless the data was stored without them. [...] If the data
has the REG_SZ, REG_MULTI_SZ or REG_EXPAND_SZ type, the string may not
have been stored with the proper terminating null characters. Therefore,
even if the function returns ERROR_SUCCESS, the application should
ensure that the string is properly terminated before using it;
otherwise, it may overwrite a buffer."
It's therefore dangerous to pass it off unbounded as we do, and in fact
this led to crashes on real systems.
Change-Id: I2ab324e85f75dc3e4d6d62fec3b96937fec77510
Reviewed-on: https://go-review.googlesource.com/c/sys/+/202957
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Chmod toggles the FILE_ATTRIBUTES_READONLY flag depending on the
permission bits. That's a bit odd but I guess some compromises were made
at some point and this is what was chosen to map to a Unix concept that
Windows doesn't really have in the same way. That's fine. However, the
logic used in Chmod was forgotten from Open, which then manifested
itself in various places, most recently, go modules' read-only behavior.
This corresonds with the syscall CL 202439.
Updates golang/go#35033
Change-Id: Id8e74c5205057a74a35eda213516780b79a2aed2
Reviewed-on: https://go-review.googlesource.com/c/sys/+/202440
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
ShellExecute is an ancient API with an unusual return signature. It
pretends to return an HINSTANCE for backwards compatibility with Windows
3, but it's actualy a fake HINSTANCE. What's really happening here,
according to MSDN, is that it returns either an Windows error less
than or equal to 32, or it succeeds. So we adjust the return value
accordingly.
Prior to this commit, it was impossible to tell whether this command had
succeeded. For example, when using the "runas" verb, ShellExecute did
not correctly indicate whether or not permission was granted.
Change-Id: Ie60554d6465798bacb9a225c4ead7e8dd62bce14
Reviewed-on: https://go-review.googlesource.com/c/sys/+/199521
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Nenad Kozul <knenad@gmail.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This allows us to modify this file and fix it more fluidly. Users can
invoke it from go generate via:
go run golang.org/x/sys/windows/mkwinsyscall
This was taken from Go repo commit 6b85fa80.
Updates golang/go#34388
Change-Id: I8dc39eed96b2499ccbde53554b3e16e6c1f6aa98
Reviewed-on: https://go-review.googlesource.com/c/sys/+/198637
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
From MSDN on CreateServiceW:
The returned handle is only valid for the process that called
CreateService. It can be closed by calling the CloseServiceHandle
function.
This isn't an actual kernel object to be closed with CloseHandle.
Change-Id: Iee225a666576d57a6c4864abef20206d54cbbce2
Reviewed-on: https://go-review.googlesource.com/c/sys/+/198298
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Changes in syscall_windows.go were copied from
internal/syscall/syscall_windows.go.
zsyscall_windows.go was regenerated by running
'go generate -tags=generate golang.org/x/sys/windows'
using a toolchain built from tip (after CL 196122).
These functions are called by cmd/go/internal/lockedfile via
internal/syscall/windows. I'd like to copy lockedfile into another
project (CL 197299), but these functions need to be exposed here in
order to do so. We may need these in x/mod eventually, too.
Change-Id: I2033106d2ba65009e764591bfe5702f4d41dffdd
Reviewed-on: https://go-review.googlesource.com/c/sys/+/198060
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
There's no point in adding a function call to retrieve a constant, or
worse, a syscall to retrieve a constant. These are fixed and baked so
deep into NT they'll never change. So let's benefit from the obvious
optimization and make these constants. Go easily inlines the function
calls as well. We also take the opportunity to sunset
OpenCurrentProcessToken and restore its original behavior, since users
should be invoking this deliberately with the correct access mask.
Change-Id: I92f7de56c0fcf5b69b59f5a79d2828c7ddf3c8f6
Reviewed-on: https://go-review.googlesource.com/c/sys/+/196800
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This function shouldn't return an error. Like other String() functions
everywhere in Golang, this should instead return empty or a token value
during an error, so that it can be passed to %v and similar. Also, allow
for SID strings of maximum size.
Change-Id: Ib6d8407f8ad0bdabcb22c31b8f387594f2ea7672
Reviewed-on: https://go-review.googlesource.com/c/sys/+/196799
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
GetCurrentProcess and GetCurrentThread return -1 and -2 respectively. We
could arguably hard code those values, but MSDN cautions not to; I'm
sure this advice is old now, given that the psuedo handles for tokens
(not processes/threads) are now implemented with inline functions in the
headers for Windows 8, but anyway, we'll follow Microsoft's advice.
However, regardless of that, these functions never ever return an error.
MSDN doesn't indicate that they do, reverse engineering the functions
doesn't indicate that they do, and checking against 0 is just plain
wrong, considering 0!=INVALID_HANDLE_VALUE; however
INVALID_HANDLE_VALUE==-1, so that's not correct either. In fact,
checking any value and returning any error does not make sense.
Incidently having to check code for the pseudo handle is more verbose
too.
In order to make this function do the correct thing and meet the spec,
remove the error value from the return.
Change-Id: If03c9dab001be3bf5a04999aef20dbfcf8a4f405
Reviewed-on: https://go-review.googlesource.com/c/sys/+/196798
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
The SECURITY_ATTRIBUTES struct always takes a SECURITY_DESCRIPTOR
pointer. Now that we've defined SECURITY_DESCRIPTOR, make
SECURITY_ATTRIBUTES properly specify the type. This eliminates the need
for terrible uintptr(unsafe.Pointer(...)) casts everywhere.
Change-Id: Ibbc85524cfe33589d43f963e10aa19d7f47686f2
Reviewed-on: https://go-review.googlesource.com/c/sys/+/196797
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This adds the basic foundation for dealing with security descriptors and
access control lists. The basic creators and getters are included in
this patch. These are some of the most fundamental security objects on NT,
and any work with the security API is fairly limited without it. These
are "core" NT structures.
Change-Id: I9a6399cb6ee41a825de30d5364ab69102d5f6d57
Reviewed-on: https://go-review.googlesource.com/c/sys/+/195498
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Windows type PBOOL is a pointer to a 4 byte value, where 0 means false
and not-0 means true. That means we should use uint32 here, not bool,
since Go bools can be 1 byte. This commit was re-generated using
mksyscall_windows.go from CL 196122.
Updates: golang/go#34364
Change-Id: I8e83b9a09c0b58d14ac9a7dee316553940ac6ee3
Reviewed-on: https://go-review.googlesource.com/c/sys/+/196123
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
