Added HV Socket known IDs, Dial, bug fixes

[helsaawy]

Added:

• Well-know Hyper-V VMIDs for parents, children, and loopback.
• VSock interop service GUID.
• Dial() and DialContext() to dial a specific Hyper-V socket at a known address (along with a corresponding HvsockDialer struct.

Bug fixes:

• Dial (and Listen) now properly initialize and set properties of their sockets after ConnectEx (and AcceptEx).
• The socketError used by bind was incorrect, it should be int32(-1), not uintptr(^0)

Created a sockets package, currently only with syscalls to Bind, ConnectEx and GetSockName, bypassing syscall/windows restrictions on the types that cane be used

Signed-off-by: Hamza El-Saawy [email protected]

[kevpar]

This seems like a change that should be split across multiple PRs. For instance can we add sockets package, and then use it in another PR?

I'd also like to understand better what the motivation is for these changes. What can a user of go-winio not do without these changes?

[helsaawy]

This seems like a change that should be split across multiple PRs. For instance can we add sockets package, and then use it in another PR?

I'd also like to understand better what the motivation is for these changes. What can a user of go-winio not do without these changes?

Without the sockets package, a user wouldn't be able to call GetPeerName, Bind, or ConnectEx on an arbitrary socket type (the syscall packages only allow them on types implemented internal to them). We had our own bind internally here, but it wasnt exported and required handling raw pointers.

Those three (GetPeerName, Bind, andConnectEx) are fairly useless on their own, but they allow use to easily define our own Dial for HV sockets.

I could add sockets alone, but I think it would look fairly unnecessary, as without Hvsock defining its own socket type, it would appear fairly redundant with golang's socket functions.

That said, I can split this into sockets and HV sockets updates (or HV sockets feature additions and bug fixes).