Comment 1:

unfortunately implementing network facility API for Windows does not complete yet. for
now both InterfaceAddrs and Addrs of Interface will return an IPAddr (just an addr)
instead of an IPNet (an address prefix). also it does not fetch IPv6 stuff inside the
kernel.
as usual, we very welcome a series of CLs on this issue.

Labels changed: added priority-later, removed priority-triage.

Comment 3:

Labels changed: added go1.2.

Status changed to Accepted.

Comment 4:

Labels changed: added feature.

Comment 5:

Not for 1.2.

Labels changed: removed go1.2.

Comment 6:

Labels changed: added go1.3maybe.

Comment 7:

Labels changed: removed feature.

Comment 8:

Labels changed: added release-none, removed go1.3maybe.

Comment 9:

Labels changed: added repo-main.

Comment 10:

Issue #7955 has been merged into this issue.

Comment 11:

Labels changed: added os-windows, removed priority-later.

Comment 12:

go1.3 and beyond don't need to support windows 2000 which doesn't support IPv6 and fancy
network facilities by default, so writing a patch would be pretty straightforward now.
ah, patches welcome.

Comment 13 by everton.marques:

I think one possible fix is to replace net.IPAddr from net/interface_windows.go, line
145, with net.IPNet:
current: 145 ifa := IPAddr{IP: parseIPv4(bytePtrToString(&ipl.IpAddress.String[0]))}
fix: 145 ifa := parseIPNet(ipl.IpAddress.String, ipl.IpMask.String)
(http://golang.org/src/pkg/net/interface_windows.go)
func parseIPNet(addr, mask [16]byte) IPNet {
    ipnet := IPNet{IP: parseIPv4(bytePtrToString(&addr[0]))}
    m := parseIPv4(bytePtrToString(&mask[0]))
    if m == nil {
        ipnet.Mask = IPMask{}
        return ipnet
    }
    p4 := ipnet.IP.To4()
    if len(p4) == IPv4len {
        m4 := m.To4()
        ipnet.Mask = net.IPv4Mask(m4[0], m4[1], m4[2], m4[3])
    } else {
        ipnet.Mask = net.IPMask{
            m[0], m[1], m[2], m[3],
            m[4], m[5], m[6], m[7],
            m[8], m[9], m[10], m[11],
            m[12], m[13], m[14], m[15],
        }
    }
    return ipnet
}
Unfortunately I don't have the skill to actually it. :(

Comment 14:

Thanks, but we don't use here for discussion and/or code review purposes. FWIW, here are
a few hints:
- use GetAdaptersAddresses instead
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365915(v=vs.85).aspx
- then, parse IP_ADAPTER_ADDRESSES instead
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366058(v=vs.85).aspx

It seems that I was working on this. I will send mail to gerrit in later.

https://codereview.appspot.com/4590050/

https://codereview.appspot.com/4590050/#msg11

alex says:

interfaceTable2 is using GetAdaptersAddresses() yet. And windows2000 don't have
GetAdaptersAddresses().
When the API is not found, syscall occur error and panic. net package is calling API dynamically.
i.e. it shouldn't back into syscall.

Go1.4 doesn't support windows2k no longer. So is it ok to re-implement by GetAdaptersAddresses() ?

Sure @mattn. Hopefuly I will have time to review it. Please no changes to syscall package. We have to put all new syscall changes into internal/syscall/windows. Thank you.

Alex

@alexbrainman what structure of internal package do you expect? net/internal ? internal/syscall ?

I suggest we put all new windows syscalls into internal/syscall/windows. This we'll be able to use both old syscall and new windows package names in the same source file. We can always change our mind because it is under internal/...

Alex

I wonder we should avoid new package name with renaming stdcall like newstdcall?

I don't like newstdcall package name. But you can ask others.

rename old syscall to stdsyscall?

I don't like it either. A package's name should describe what it does, not what it contains.

On 19 Jan 2015, at 16:27, alexbrainman notifications@github.com wrote:

I don't like newstdcall package name. But you can ask others.

—
Reply to this email directly or view it on GitHub.

No we cannot touch syscall package. Other people use it.

I don't talking about renaming package name of syscall. I'm talking that we must rename old syscall to use in new syscall like below.

internal/syscall/windows.go

package syscall

import (
  stdsyscall "syscall"
)

I didn't propose to create internal/syscall package. I proposed to create internal/syscall/windows package. We won't need to rename anything then.

That's OK. (import "syscall" as stdsyscall in package internal/syscall)

I didn't propose to create internal/syscall package. I proposed to create internal/syscall/windows package. We won't need to rename anything then.

fair enough. we must put mksyscall_windows.go into there also.

I was hoping we just call mksyscall_windows.go from where it is now.

I think we should stick to "internal/syscall", instead of
"internal/syscall/windows".

Because the existing use of "internal/syscall“ isn't called
"internal/syscall/linux"
or "internal/syscall/unix".

@minux
right!

@alexbrainman

I was hoping we just call mksyscall_windows.go from where it is now.

is this an another issue to file?

I think we should stick to "internal/syscall", instead of
"internal/syscall/windows".

I disagree. Once we start using new package we would have to use both old and new in the same source file most of the time. If we name both syscall, then one package would have to be renamed once imported. Why should we think about new name every time we import internal/syscall? Why not come up with good name now, name the package and use it from now on?

Alex

https://go-review.googlesource.com/#/c/3024/

CL https://golang.org/cl/17412 mentions this issue.