DecomposeCommandLine is documented to use CommandLineToArgv, and the
CommandLineToArgvW system call inherently does not support strings with
internal NUL bytes. This CL changes DecomposeCommandLine to reject those
strings with an error instead of panicking.
Fixesgolang/go#58817
Change-Id: I22a026bf2e69344a21f04849c50ba19b6e7b2007
Reviewed-on: https://go-review.googlesource.com/c/sys/+/487695
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: 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>
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>
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>
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>
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>
ctlHandler is passed to RegisterServiceCtrlHandlerEx as a callback
function. But all ctlHandler parameters have to be uintptr aligned
regardless of their type.
Adjust ctlHandler parameters, so they are aligned accordingly.
Also uncomment part of TestExample that verifies passing of
ChangeRequest.Context.
Fixesgolang/go#25660
Change-Id: Ie96fa5c78b911ad9df6775f5c49e7f6d56464f6b
Reviewed-on: https://go-review.googlesource.com/c/158698
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
New Context field will be used in the following CL to test
ctlHandler parameter alignments.
Also adjust TestExample to pass hard coded Context value of 123456
to test service, and verify that correct value is logged. Final
part of the test is commented out, and will be adjusted in the next
CL.
Updates golang/go#25660
Change-Id: Iad2896ae497ee1edc0d62655eaf08671ec2651c5
Reviewed-on: https://go-review.googlesource.com/c/158697
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This CL is a copy of CL 106275 (see CL 106275 for details).
It introduces CertInfo, CertTrustListInfo and CertRevocationCrlInfo
types. It uses pointers to new types instead of uintptr in CertContext,
CertSimpleChain and CertRevocationInfo.
CertRevocationInfo, CertChainPolicyPara and CertChainPolicyStatus types
have uintptr field that can be pointer to many different things
(according to Windows API). So this CL introduces Pointer type to be
used for those cases.
Fixesgolang/go#25797
Change-Id: I7797ddc6daf3e67b7eab69ab9fbf4d51650f8b6a
Reviewed-on: https://go-review.googlesource.com/118797
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Introduce OpenRemoteKey function that opens some
root registry keys on remote computer.
Also add PERFORMANCE_DATA key, since it is one of
root keys accessible via OpenRemoteKey.
Change-Id: I738fdfee52a34acd4dc09ddb91fcf0e4c707bd83
Reviewed-on: https://go-review.googlesource.com/33814
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
CL 24551 introduced //go:uintptrescapes comment to make
syscall.Proc.Call and syscall.LazyProc.Call parameters escape.
Use new comment in this package too.
Updates golang/go#16035.
Change-Id: I57ec3b4778195ca4a1ce9a8eec331f0f69285926
Reviewed-on: https://go-review.googlesource.com/24870
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
If we want new secure DLL approach to be adopted, we should make
conversion as simple as possible to explain and implement.
I think that replacing
syscall.NewLazyDLL(...) -> windows.NewLazySystemDLL(...)
is easier than
syscall.NewLazyDLL(...) -> &windows.LazyDLL{Name: ..., System: true}
So I propose we introduce convenience function NewLazySystemDLL.
$GOROOT/src/mksyscall_windows.go changes in the following CL.
Change-Id: If3432aff301c347cb355e4e837834696191b2219
Reviewed-on: https://go-review.googlesource.com/21592
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It seems some Windows versions requires you to be
an Administrator to manage services. Just google for
"openscmanager access denied windows 2008" or similar.
Fixesgolang/go#11156.
Change-Id: I4b09d244a61179ece7a1319234e5c3199423cbe9
Reviewed-on: https://go-review.googlesource.com/10933
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
71db3dc120af os: make SameFile handle paths like c:a.txt properly
ff34a3e84dc0 net: fix CNAME resolving on Windows
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/130250043
Also zsyscall_windows_386.go and zsyscall_windows_amd64.go
have same contents, so merge them into single file.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/124430043
All consts in errors_windows.go (except APPLICATION_ERROR) were
"invented" at the start of windows port to have minimal impact on
existing Go packages. No point keeping them around.
Also remove Errno, since we will be using syscall.Errno everywhere anyway.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/128290044
Alex Brainman