win: fix undeclared NDIS_IF_MAX_STRING_SIZE

[ugexe]

NDIS_IF_MAX_STRING_SIZE does not appear to be available on many windows system.

[ugexe]

I can confirm libuv 1.16.0 fails to build on an appveyor configuration used for MoarVM and on a separate windows system.

3rdparty\libuv\src\win\getaddrinfo.c(388) : error C2065: 'NDIS_IF_MAX_STRING_SIZE' : undeclared identifier
3rdparty\libuv\src\win\getaddrinfo.c(388) : error C2057: expected constant expression
3rdparty\libuv\src\win\getaddrinfo.c(388) : error C2466: cannot allocate an array of constant size 0
3rdparty\libuv\src\win\getaddrinfo.c(388) : error C2133: 'wname' : unknown size
3rdparty\libuv\src\win\getaddrinfo.c(400) : warning C4034: sizeof returns 0

NMAKE : fatal error U1077: '"c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\Bin\amd64\cl.EXE"' : return code '0x2'

NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX86\x86\cl.EXE"' : return code '0x2'

[cjihrig]

Interesting. According to this, iphlpapi.h should give us everything in netioapi.h. And, according to the ConvertInterfaceLuidToNameW() docs, netioapi.h should give us everything we need since Windows Vista.

It looks like Wireshark does this, but that code is over four years old.

cc: @bzoz and @refack

[bzoz]

ConvertInterfaceLuidToNameW() docs says: "The NDIS_IF_MAX_STRING_SIZE is defined to be the IF_MAX_STRING_SIZE constant, which is defined in the Ifdef.h header file.", so I guess this should be done like it is done in Wireshark.

BTW, @ugexe on what platform the compilation fails for you? I'm +1 on adding the define, but I see you are using nmake and I'm curious. Does libuv build with vcbuild on your setup?

[ugexe]

Platform is Windows 10 (Version 1703; OS Build 15063.674) and VS2017. It does build with vcbuild vs2017, but not without working around an issue in how it detects which VS version to use. Specifically I remove these two lines which are preventing the VS2017 code path from taking place in my environment (regardless if vs2017 argument is supplied). Otherwise it thinks it needs to target v100 (VS2010) which I have never installed (and if I open the project in VS and upgrade to v14x it does not change the outcome of vcbuild vs2017).

---

Without commenting out the noted two lines:

C:\Users\nloga\repos\libuv\>vcbuild vs2017
['-Dtarget_arch=ia32', '-Duv_library=static_library', '.\\uv.gyp', '-I', '.\\common.gypi', '--depth=.', '-Dhost_arch=x64']
Project files generated.
Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.Cpp.Platform.targets(5
5,5): error MSB8020: The build tools for Visual Studio 2010 (Platform Toolset = 'v100') cannot be found. To build using
 the v100 build tools, please install Visual Studio 2010 build tools.  Alternatively, you may upgrade to the current Vi
sual Studio tools by selecting the Project menu or right-click the solution, and then selecting "Retarget solution". [C
:\Users\nloga\.rakudobrew\moar-blead-master\nqp\MoarVM\3rdparty\libuv\foo\libuv\libuv.vcxproj]

C:\Users\nloga\repos\libuv\>echo %WindowsSDKDir%
C:\Program Files (x86)\Windows Kits\10\

C:\Users\nloga\repos\libuv\>echo %VCINSTALLDIR%
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\

[ugexe]

Another data point on the vcbuild issue:

I was looking at the win2012r2-vs2017 build output and wondered if SET "GYP_MSVS_VERSION=2013" should instead be SET "GYP_MSVS_VERSION=2017". This led me to SET "GYP_MSVS_VERSION=2017" on my local system, after which vcbuild worked without removing the two lines noted in my previous comment. Setting it to any other value (such as the 2013 used on jenkins) did not work.

[cjihrig]

@bzoz what do you want to do here? I'd like to get this resolved soon rather than later, as our most recent release is broken on a few platforms.

[bzoz]

@cjihrig I would use the Wiresharks form of

#ifndef NDIS_IF_MAX_STRING_SIZE
#define NDIS_IF_MAX_STRING_SIZE IF_MAX_STRING_SIZE
#endif

if it works on that setup. I'm +1 on this, I was just curious about why this happens.

[ugexe]

I can confirm the wireshark method also resolves the original problem.

[cjihrig]

LGTM if the CI comes back green: https://ci.nodejs.org/view/libuv/job/libuv-test-commit/566/

[cjihrig]

Landed in 84fa7fc. Thanks!