go/src/internal/syscall/windows/syscall_windows.go

168 lines
4.8 KiB
Go
Raw Normal View History

// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
package windows
import "syscall"
os: make readConsole handle its input and output correctly This CL introduces first test for readConsole. And new test discovered couple of problems with readConsole. Console characters consist of multiple bytes each, but byte blocks returned by syscall.ReadFile have no character boundaries. Some multi-byte characters might start at the end of one block, and end at the start of next block. readConsole feeds these blocks to syscall.MultiByteToWideChar to convert them into utf16, but if some multi-byte characters have no ending or starting bytes, the syscall.MultiByteToWideChar might get confused. Current version of syscall.MultiByteToWideChar call will make syscall.MultiByteToWideChar ignore all these not complete multi-byte characters. The CL solves this issue by changing processing from "randomly sized block of bytes at a time" to "one multi-byte character at a time". New readConsole code calls syscall.ReadFile to get 1 byte first. Then it feeds this byte to syscall.MultiByteToWideChar. The new syscall.MultiByteToWideChar call uses MB_ERR_INVALID_CHARS flag to make syscall.MultiByteToWideChar return error if input is not complete character. If syscall.MultiByteToWideChar returns correspondent error, we read another byte and pass 2 byte buffer into syscall.MultiByteToWideChar, and so on until success. Old readConsole code would also sometimes return no data if user buffer was smaller then uint16 size, which would confuse callers that supply 1 byte buffer. This CL fixes that problem too. Fixes #17097 Change-Id: I88136cdf6a7bf3aed5fbb9ad2c759b6c0304ce30 Reviewed-on: https://go-review.googlesource.com/29493 Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2016-09-21 11:19:36 +10:00
const (
ERROR_SHARING_VIOLATION syscall.Errno = 32
os: make readConsole handle its input and output correctly This CL introduces first test for readConsole. And new test discovered couple of problems with readConsole. Console characters consist of multiple bytes each, but byte blocks returned by syscall.ReadFile have no character boundaries. Some multi-byte characters might start at the end of one block, and end at the start of next block. readConsole feeds these blocks to syscall.MultiByteToWideChar to convert them into utf16, but if some multi-byte characters have no ending or starting bytes, the syscall.MultiByteToWideChar might get confused. Current version of syscall.MultiByteToWideChar call will make syscall.MultiByteToWideChar ignore all these not complete multi-byte characters. The CL solves this issue by changing processing from "randomly sized block of bytes at a time" to "one multi-byte character at a time". New readConsole code calls syscall.ReadFile to get 1 byte first. Then it feeds this byte to syscall.MultiByteToWideChar. The new syscall.MultiByteToWideChar call uses MB_ERR_INVALID_CHARS flag to make syscall.MultiByteToWideChar return error if input is not complete character. If syscall.MultiByteToWideChar returns correspondent error, we read another byte and pass 2 byte buffer into syscall.MultiByteToWideChar, and so on until success. Old readConsole code would also sometimes return no data if user buffer was smaller then uint16 size, which would confuse callers that supply 1 byte buffer. This CL fixes that problem too. Fixes #17097 Change-Id: I88136cdf6a7bf3aed5fbb9ad2c759b6c0304ce30 Reviewed-on: https://go-review.googlesource.com/29493 Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2016-09-21 11:19:36 +10:00
ERROR_NO_UNICODE_TRANSLATION syscall.Errno = 1113
)
const GAA_FLAG_INCLUDE_PREFIX = 0x00000010
net, internal/syscall/windows: fix interface and address identification on windows The current implementation including Go 1.5 through 1.5.2 misuses Windows API and mishandles the returned values from GetAdapterAddresses on Windows. This change fixes various issues related to network facility information by readjusting interface and interface address parsers. Updates #5395. Updates #10530. Updates #12301. Updates #12551. Updates #13542. Fixes #12691. Fixes #12811. Fixes #13476. Fixes #13544. Also fixes fragile screen scraping test cases in net_windows_test.go. Additional information for reviewers: It seems like almost all the issues above have the same root cause and it is misunderstanding of Windows API. If my interpretation of the information on MSDN is correctly, current implementation contains the following bugs: - SIO_GET_INTERFACE_LIST should not be used for IPv6. The behavior of SIO_GET_INTERFACE_LIST is different on kernels and probably it doesn't work correctly for IPv6 on old kernels such as Windows XP w/ SP2. Unfortunately MSDN doesn't describe the detail of SIO_GET_INTERFACE_LIST, but information on the net suggests so. - Fetching IP_ADAPTER_ADDRESSES structures with fixed size area may not work when using IPv6. IPv6 generates ton of interface addresses for various addressing scopes. We need to adjust the area appropriately. - PhysicalAddress field of IP_ADAPTER_ADDRESSES structure may have extra space. We cannot ignore PhysicalAddressLength field of IP_ADAPTER_ADDRESS structure. - Flags field of IP_ADAPTER_ADDRESSES structure doesn't represent any of administratively and operatinal statuses. It just represents settings for windows network adapter. - MTU field of IP_ADAPTER_ADDRESSES structure may have a uint32(-1) on 64-bit platform. We need to convert the value to interger appropriately. - IfType field of IP_ADAPTER_ADDRESSES structure is not a bit field. Bitwire operation for the field is completely wrong. - OperStatus field of IP_ADAPTER_ADDRESSES structure is not a bit field. Bitwire operation for the field is completely wrong. - IPv6IfIndex field of IP_ADAPTER_ADDRESSES structure is just a substitute for IfIndex field. We cannot prefer IPv6IfIndex to IfIndex. - Windows XP, 2003 server and below don't set OnLinkPrefixLength field of IP_ADAPTER_UNICAST_ADDRESS structure. We cannot rely on the field on old kernels. We can use FirstPrefix field of IP_ADAPTER_ADDRESSES structure and IP_ADAPTER_PREFIX structure instead. - Length field of IP_ADAPTER_{UNICAST,ANYCAST,MULTICAST}_ADDRESS sturecures doesn't represent an address prefix length. It just represents a socket address length. Change-Id: Icabdaf7bd1d41360a981d2dad0b830b02b584528 Reviewed-on: https://go-review.googlesource.com/17412 Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
2015-12-04 19:06:01 +09:00
const (
IF_TYPE_OTHER = 1
IF_TYPE_ETHERNET_CSMACD = 6
IF_TYPE_ISO88025_TOKENRING = 9
IF_TYPE_PPP = 23
IF_TYPE_SOFTWARE_LOOPBACK = 24
IF_TYPE_ATM = 37
IF_TYPE_IEEE80211 = 71
IF_TYPE_TUNNEL = 131
IF_TYPE_IEEE1394 = 144
)
type SocketAddress struct {
Sockaddr *syscall.RawSockaddrAny
SockaddrLength int32
}
type IpAdapterUnicastAddress struct {
Length uint32
Flags uint32
Next *IpAdapterUnicastAddress
Address SocketAddress
PrefixOrigin int32
SuffixOrigin int32
DadState int32
ValidLifetime uint32
PreferredLifetime uint32
LeaseLifetime uint32
OnLinkPrefixLength uint8
}
type IpAdapterAnycastAddress struct {
Length uint32
Flags uint32
Next *IpAdapterAnycastAddress
Address SocketAddress
}
type IpAdapterMulticastAddress struct {
Length uint32
Flags uint32
Next *IpAdapterMulticastAddress
Address SocketAddress
}
type IpAdapterDnsServerAdapter struct {
Length uint32
Reserved uint32
Next *IpAdapterDnsServerAdapter
Address SocketAddress
}
type IpAdapterPrefix struct {
Length uint32
Flags uint32
Next *IpAdapterPrefix
Address SocketAddress
PrefixLength uint32
}
type IpAdapterAddresses struct {
Length uint32
IfIndex uint32
Next *IpAdapterAddresses
AdapterName *byte
FirstUnicastAddress *IpAdapterUnicastAddress
FirstAnycastAddress *IpAdapterAnycastAddress
FirstMulticastAddress *IpAdapterMulticastAddress
FirstDnsServerAddress *IpAdapterDnsServerAdapter
DnsSuffix *uint16
Description *uint16
FriendlyName *uint16
PhysicalAddress [syscall.MAX_ADAPTER_ADDRESS_LENGTH]byte
PhysicalAddressLength uint32
Flags uint32
Mtu uint32
IfType uint32
OperStatus uint32
Ipv6IfIndex uint32
ZoneIndices [16]uint32
FirstPrefix *IpAdapterPrefix
/* more fields might be present here. */
}
const (
IfOperStatusUp = 1
IfOperStatusDown = 2
IfOperStatusTesting = 3
IfOperStatusUnknown = 4
IfOperStatusDormant = 5
IfOperStatusNotPresent = 6
IfOperStatusLowerLayerDown = 7
)
net, internal/syscall/windows: fix interface and address identification on windows The current implementation including Go 1.5 through 1.5.2 misuses Windows API and mishandles the returned values from GetAdapterAddresses on Windows. This change fixes various issues related to network facility information by readjusting interface and interface address parsers. Updates #5395. Updates #10530. Updates #12301. Updates #12551. Updates #13542. Fixes #12691. Fixes #12811. Fixes #13476. Fixes #13544. Also fixes fragile screen scraping test cases in net_windows_test.go. Additional information for reviewers: It seems like almost all the issues above have the same root cause and it is misunderstanding of Windows API. If my interpretation of the information on MSDN is correctly, current implementation contains the following bugs: - SIO_GET_INTERFACE_LIST should not be used for IPv6. The behavior of SIO_GET_INTERFACE_LIST is different on kernels and probably it doesn't work correctly for IPv6 on old kernels such as Windows XP w/ SP2. Unfortunately MSDN doesn't describe the detail of SIO_GET_INTERFACE_LIST, but information on the net suggests so. - Fetching IP_ADAPTER_ADDRESSES structures with fixed size area may not work when using IPv6. IPv6 generates ton of interface addresses for various addressing scopes. We need to adjust the area appropriately. - PhysicalAddress field of IP_ADAPTER_ADDRESSES structure may have extra space. We cannot ignore PhysicalAddressLength field of IP_ADAPTER_ADDRESS structure. - Flags field of IP_ADAPTER_ADDRESSES structure doesn't represent any of administratively and operatinal statuses. It just represents settings for windows network adapter. - MTU field of IP_ADAPTER_ADDRESSES structure may have a uint32(-1) on 64-bit platform. We need to convert the value to interger appropriately. - IfType field of IP_ADAPTER_ADDRESSES structure is not a bit field. Bitwire operation for the field is completely wrong. - OperStatus field of IP_ADAPTER_ADDRESSES structure is not a bit field. Bitwire operation for the field is completely wrong. - IPv6IfIndex field of IP_ADAPTER_ADDRESSES structure is just a substitute for IfIndex field. We cannot prefer IPv6IfIndex to IfIndex. - Windows XP, 2003 server and below don't set OnLinkPrefixLength field of IP_ADAPTER_UNICAST_ADDRESS structure. We cannot rely on the field on old kernels. We can use FirstPrefix field of IP_ADAPTER_ADDRESSES structure and IP_ADAPTER_PREFIX structure instead. - Length field of IP_ADAPTER_{UNICAST,ANYCAST,MULTICAST}_ADDRESS sturecures doesn't represent an address prefix length. It just represents a socket address length. Change-Id: Icabdaf7bd1d41360a981d2dad0b830b02b584528 Reviewed-on: https://go-review.googlesource.com/17412 Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
2015-12-04 19:06:01 +09:00
//sys GetAdaptersAddresses(family uint32, flags uint32, reserved uintptr, adapterAddresses *IpAdapterAddresses, sizePointer *uint32) (errcode error) = iphlpapi.GetAdaptersAddresses
//sys GetComputerNameEx(nameformat uint32, buf *uint16, n *uint32) (err error) = GetComputerNameExW
//sys MoveFileEx(from *uint16, to *uint16, flags uint32) (err error) = MoveFileExW
//sys GetModuleFileName(module syscall.Handle, fn *uint16, len uint32) (n uint32, err error) = kernel32.GetModuleFileNameW
const (
ComputerNameNetBIOS = 0
ComputerNameDnsHostname = 1
ComputerNameDnsDomain = 2
ComputerNameDnsFullyQualified = 3
ComputerNamePhysicalNetBIOS = 4
ComputerNamePhysicalDnsHostname = 5
ComputerNamePhysicalDnsDomain = 6
ComputerNamePhysicalDnsFullyQualified = 7
ComputerNameMax = 8
MOVEFILE_REPLACE_EXISTING = 0x1
MOVEFILE_COPY_ALLOWED = 0x2
MOVEFILE_DELAY_UNTIL_REBOOT = 0x4
MOVEFILE_WRITE_THROUGH = 0x8
MOVEFILE_CREATE_HARDLINK = 0x10
MOVEFILE_FAIL_IF_NOT_TRACKABLE = 0x20
)
func Rename(oldpath, newpath string) error {
from, err := syscall.UTF16PtrFromString(oldpath)
if err != nil {
return err
}
to, err := syscall.UTF16PtrFromString(newpath)
if err != nil {
return err
}
return MoveFileEx(from, to, MOVEFILE_REPLACE_EXISTING)
}
os: make readConsole handle its input and output correctly This CL introduces first test for readConsole. And new test discovered couple of problems with readConsole. Console characters consist of multiple bytes each, but byte blocks returned by syscall.ReadFile have no character boundaries. Some multi-byte characters might start at the end of one block, and end at the start of next block. readConsole feeds these blocks to syscall.MultiByteToWideChar to convert them into utf16, but if some multi-byte characters have no ending or starting bytes, the syscall.MultiByteToWideChar might get confused. Current version of syscall.MultiByteToWideChar call will make syscall.MultiByteToWideChar ignore all these not complete multi-byte characters. The CL solves this issue by changing processing from "randomly sized block of bytes at a time" to "one multi-byte character at a time". New readConsole code calls syscall.ReadFile to get 1 byte first. Then it feeds this byte to syscall.MultiByteToWideChar. The new syscall.MultiByteToWideChar call uses MB_ERR_INVALID_CHARS flag to make syscall.MultiByteToWideChar return error if input is not complete character. If syscall.MultiByteToWideChar returns correspondent error, we read another byte and pass 2 byte buffer into syscall.MultiByteToWideChar, and so on until success. Old readConsole code would also sometimes return no data if user buffer was smaller then uint16 size, which would confuse callers that supply 1 byte buffer. This CL fixes that problem too. Fixes #17097 Change-Id: I88136cdf6a7bf3aed5fbb9ad2c759b6c0304ce30 Reviewed-on: https://go-review.googlesource.com/29493 Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2016-09-21 11:19:36 +10:00
const MB_ERR_INVALID_CHARS = 8
//sys GetACP() (acp uint32) = kernel32.GetACP
//sys GetConsoleCP() (ccp uint32) = kernel32.GetConsoleCP
//sys MultiByteToWideChar(codePage uint32, dwFlags uint32, str *byte, nstr int32, wchar *uint16, nwchar int32) (nwrite int32, err error) = kernel32.MultiByteToWideChar
//sys GetCurrentThread() (pseudoHandle syscall.Handle, err error) = kernel32.GetCurrentThread
const STYPE_DISKTREE = 0x00
type SHARE_INFO_2 struct {
Netname *uint16
Type uint32
Remark *uint16
Permissions uint32
MaxUses uint32
CurrentUses uint32
Path *uint16
Passwd *uint16
}
//sys NetShareAdd(serverName *uint16, level uint32, buf *byte, parmErr *uint16) (neterr error) = netapi32.NetShareAdd
//sys NetShareDel(serverName *uint16, netName *uint16, reserved uint32) (neterr error) = netapi32.NetShareDel