Other functions, like GetVersion(), will lie about the OS version
depending on various win32 and manifest compatibility shims in place.
Calling RtlGetVersion is the proper way to retrieve the true OS version.
Change-Id: I2bd6d097dd763df51617cd825dc0ad300abf6212
Reviewed-on: https://go-review.googlesource.com/c/sys/+/182718
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matt Layher <mdlayher@gmail.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
This adds the recommended API for determining well-known folder paths,
such as where to place application configuration data. The MSDN
documentation mentions an optimization for the "current user" by passing
NULL as the token, so we provide both variants.
Updates golang/go#32248
Change-Id: I4a2d5d833543e6a0ba8f318944dd6493a0ec31d3
Reviewed-on: https://go-review.googlesource.com/c/sys/+/181637
Reviewed-by: Jason Donenfeld <Jason@zx2c4.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
On freebsd 12, the system call for getdirentries writes 64 bits to
*basep, even on 32-bit systems. Accomodate that by providing a uint64
to the system call and copy the base to/from that uint64.
The uint64 seems to be a virtual file offset, so failing if the high
bits are not zero should be fine for reasonable-sized directories.
Update golang/go#32498
Change-Id: I4451894aff4e353c9f009c06ad2fdd5578dfd9f8
Reviewed-on: https://go-review.googlesource.com/c/sys/+/181500
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
The SCM can be locked by NT. While traditionally any process could lock
the SCM using "LockServiceDatabase", Microsoft removed this
functionality because it created so many bugs, and that function now
does nothing. However, the system itself, via the "NT Service Control
Manager", is still allowed to lock the SCM.
For example, at boot time on Windows 8.1, the SCM is locked after a
service is started until that service reports itself in a running state.
This poses a bit of a problem: it's useful to install device drivers
from inside services as part of their initialization, and mark the
service as having started only after the device has installed. But
device installation might potentially load new drivers, and drivers
themselves exist as a special type of service. This means that if a
driver is installed before marking the service as started, the entire
SCM will deadlock, and the OS will be partially unresponsive for a
minute or two.
Fortunately Microsoft supplies an API for exactly this purpose. The
solution is to mark the service as started before installing device
drivers, only under the circumstance that the SCM is locked. So, this
commit adds the proper API for determining this. It can be used like
this:
if m, err := mgr.Connect(); err == nil {
if lockStatus, err := m.LockStatus(); err == nil && lockStatus.IsLocked {
log.Printf("SCM locked for %v by %s, marking service as started", lockStatus.Age, lockStatus.Owner)
changes <- svc.Status{State: svc.Running}
}
m.Disconnect()
}
deviceDriver.Install()
This creates messages like the following, indicating that this API
works:
SCM locked for 1s by .\NT Service Control Manager, marking service as started
Change-Id: Ic2f5b387e23efc3a287b2ab96ff84b357b712e36
Reviewed-on: https://go-review.googlesource.com/c/sys/+/180977
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This corrects the Windows int type to be the more correct int32 Go
analog, as well as not using GetLastError() for the error value of the
GUID string parsing function.
Change-Id: I9716f991ef649f7d299295e3f4e75d3986ec3a74
Reviewed-on: https://go-review.googlesource.com/c/sys/+/181397
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Many service attributes are settable using the ordinary CreateService
function, but ones added later in Windows need to be set using the
ChangeServiceConfig2 function. One of these is the Description field,
which is nicely plumbed behind the scenes, so that users of the API can
set it, and the mgr package will just figure out what to do with it.
Another one that works exactly the same way is SidType. Support for its
constants was added in 30999d6 ("windows: add missing service
constants"), but it wasn't actually built into the mgr package's
configuration struct, creating inconstancies in interface.
This commit rectifies that by adding proper support to mgr's config
struct.
Change-Id: I4f148f2d2477a03a65e8a571a8401392f6fe9f28
Reviewed-on: https://go-review.googlesource.com/c/sys/+/180978
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matt Layher <mdlayher@gmail.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Virtually every project that works with x/sys/window's GUIDs winds up
rolling their own version of this in one way or another. So let's add
the correct win32 wrappers for it, so that these are always generated,
parsed, and converted in the uniform correct way.
Change-Id: I35f4b4ab5fc681d3e16fc5bbaf2cb20031eb3f12
Reviewed-on: https://go-review.googlesource.com/c/sys/+/180938
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Rather than having to write grotesque things like:
groups, _ := processToken.GetTokenGroups()
for _, g := range (*[(1 << 28) - 1]windows.SIDAndAttributes)(unsafe.Pointer(&groups.Groups[0]))[:groups.GroupCount] {
// ...
}
Users can now write clean things like this:
groups, _ := processToken.GetTokenGroups()
for _, g := range groups.AllGroups() {
// ...
}
Change-Id: Ief06de6899c497175628ff51b9d6ae55a90d14f1
Reviewed-on: https://go-review.googlesource.com/c/sys/+/178857
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
mkerrors.go is called by 'go generate' command to generate
zerrors_windows.go
mkerrors.go executes mkerrors.bash. But mkerrors.bash requires
winerror.h to be present on the system to succeed. And winerror.h is
never present on the system. So executing mkerrors.go always fails.
zerrors_windows.go is never changes. It was changed recently once.
The change before that was in 2014.
This change removes mkerrors.go, so other commands that are part of
'go generate' execution can proceed. If someone needs to update
zerrors_windows.go, they can call mkerrors.bash directly.
Fixesgolang/go#32349
Change-Id: I9b3e581e183377201e8f74c2d991d97564f36778
Reviewed-on: https://go-review.googlesource.com/c/sys/+/179582
Reviewed-by: Takuto Ikuta <tikuta@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Jason Donenfeld <Jason@zx2c4.com>
While the linux/riscv64 port is not yet upstream, most of the syscalls package
already has linux/riscv64 support and this will make testing and development
easier.
Updates golang/go#27532
Change-Id: I6e505be55fdbb2942fb6e4f34c040e7b82809630
Reviewed-on: https://go-review.googlesource.com/c/sys/+/177799
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
mkerrors.bash requires a Windows host, as it hard-codes paths like
/mnt/c/Program Files (x86)/Windows Kits.
But this does not allow to generate in non-WSL env.
Currently mkerrors.bash runs earlier than mksyscall_windows.go
when we run `go generate` and it fails on non-WSL env.
So zsyscall_windows.go is not generated in that case.
To fix that, I reoreder of code generation in this CL so that we can
generate zsyscall_windows.go in non-WSL env.
Also update error message in mkerrors.bash.
Change-Id: I04eccdbfe1e1ff56f8c405250f0724000d66d579
Reviewed-on: https://go-review.googlesource.com/c/sys/+/178781
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Modify mkall.sh to support generation of zsyscall_plan9_{386,amd64,arm}.go
files. This does not generate any git diff as they were manually generated
with the same commands.
Fixesgolang/go#29586
Change-Id: I5316fdb46f306974584eee653b439408294ea1cf
Reviewed-on: https://go-review.googlesource.com/c/sys/+/179041
Reviewed-by: David du Colombier <0intro@gmail.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
The kernel raw syscall takes an additional parameter specifying
the size of the Sigset_t parameter, returns a file descriptor and sets errno.
Add a uintptr maxSize parameter, adjust the return to be (newfd int, err error).
Add the _NSIG #define and a wrapper to call with maxSize set to _C__NSIG/8 as done
in glibc/musl.
Change-Id: I277db0aab5c12364533c26ea800b7f394ec83ae4
Reviewed-on: https://go-review.googlesource.com/c/sys/+/178858
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
I realize that at this time, x/sys/windows is most certainly not aiming
to be some sort of UI library or anything remotely close to that.
However, MessageBox is sort of the one universal Windows API that's used
even for console programs. It's *the* classic debugging helper. It's
even pretty customary for console programs to display their usage
message in a message box rather than stdout. I realize this might be
somewhat disturbing to consider if you're in the blissful Unix utopia,
but on Windows, this is just sort of how things roll. Easy access to
MessageBox() is important.
Change-Id: I16183b69e8a27a5ddaf73d1d4e106bb7b201a6f0
Reviewed-on: https://go-review.googlesource.com/c/sys/+/178899
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is the way to do things like execute a process elevated with UAC
and interact with that whole system. It turns out to be quite important
for writing Windows software.
Change-Id: I5e05dc9b89ea308d42ac86ba563fd01922fc940c
Reviewed-on: https://go-review.googlesource.com/c/sys/+/178898
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
These allow actual inspection of SIDs. For example, it might be
desirable to iterate through the group SIDs in order to find one set by
SERVICE_CONFIG_SERVICE_SID_INFO:
for _, g := range groups {
if g.Attributes != windows.SE_GROUP_ENABLED|windows.SE_GROUP_ENABLED_BY_DEFAULT|windows.SE_GROUP_OWNER {
continue
}
if !g.Sid.IsValid() {
continue
}
if g.Sid.IdentifierAuthority() != windows.SECURITY_NT_AUTHORITY {
continue
}
if g.Sid.SubAuthorityCount() < 6 || g.Sid.SubAuthority(0) != 80 {
continue
}
sid = g.Sid
break
}
Another usage of the APIs added would be to find if a user is in the
administrator group with either an elevated or unelevated token:
isAdmin := false
for _, g := range groups {
if g.Attributes&(windows.SE_GROUP_ENABLED|windows.SE_GROUP_USE_FOR_DENY_ONLY) == 0 {
continue
}
if !g.Sid.IsWellKnown(windows.WinBuiltinAdministratorsSid) {
continue
}
isAdmin = true
break
}
Change-Id: I8f8dc8d37b71ec58fd51e21ea1f1b3aada6d66b0
Reviewed-on: https://go-review.googlesource.com/c/sys/+/177841
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This is what everybody winds up doing with this object, so we make it
somewhat nicer than copying and pasting this everywhere or using type
aliases.
Change-Id: I3e12395cadfe212a7d01ce86478de9486383729a
Reviewed-on: https://go-review.googlesource.com/c/sys/+/178577
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The GetCurrent*Token variety of functions are actually implemented as
inline functions in the header files of the SDK. Attempting to call out
to these as library functions is an error. This commit also adds a test
to ensure that these work as expected.
Change-Id: I105f1ca1a8936114fe61bc22188200c31f240a23
Reviewed-on: https://go-review.googlesource.com/c/sys/+/177840
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This adds a number of useful comments for ChangeServiceConfig2. It looks
like the MingW headers have these in two different places, awkwardly,
and whoever imported these constants missed the second half of them,
whereas the real Microsoft header files have them all together in one
place.
Change-Id: I723c4bcd86e5a1b905cb738c5c2b49805a354af4
Reviewed-on: https://go-review.googlesource.com/c/sys/+/177842
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Byte slices aren't necessarily aligned, which means casting them to
integer types and dereferencing may result in an unaligned load. This
is mostly fine on Intel but isn't necessarily fine on other platforms.
Any good compiler will generate optimal code for the platform using the
pattern of this commit.
Change-Id: I6dd8debad1cb850b8562ee96ae0f366d1f822a6f
Reviewed-on: https://go-review.googlesource.com/c/sys/+/176857
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
On AIX, Stat_t's fields dealing with time are of type StTimespec while
all other GOOS are using Timespec.
StTimespec and Timespec are the same on ppc but not in ppc64. Therefore,
values returned by ppc64 syscalls need to be adjusted in order to
allow the use of Timespec instead of StTimespec.
Fixesgolang/go#32073
Change-Id: I0c212bf1741a27c49e995bf928d4941b6d583e54
Reviewed-on: https://go-review.googlesource.com/c/sys/+/177838
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Birthtime/Birthtimespec was renamed to Btim to match the others.
Also unexport the [ACMB]tim_ext fields on freebsd 386.
Update mkpost.go to do the renames.
Ran the following on the existing ztypes_*.go files:
#!/bin/sh
set -e
for f in ztypes_*.go; do
cat $f | go run mkpost.go | gofmt > $f.tmp
mv $f.tmp $f
done;
cat ztypes_freebsd_386.go | env GOOS=freebsd GOARCH=386 go run mkpost.go | gofmt > ztypes_freebsd_386.go.tmp
mv ztypes_freebsd_386.go{.tmp,}
Fixesgolang/go#31735
Change-Id: I15765d690ee8d2be6bbb37f465322bc019722e08
Reviewed-on: https://go-review.googlesource.com/c/sys/+/175157
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
