tty, win: get SetWinEventHook pointer at startup

[bzoz]

SetWinEventHook is not available on some Windows versions.

Fixes: nodejs/node#16603

[bzoz]

CI: https://ci.nodejs.org/view/libuv/job/libuv-test-commit/545/

[gireeshpunathil]

I have raised a concern here. In short, due to the fact that these (some APIs are not available on some Windows versions.) are un-documented, we could address this almost always retrospectively only (and some real hard debugging), after someone's code has been broken.

[StefanScherer]

Here is a list of APIs available in NanoServer https://msdn.microsoft.com/en-us/library/mt588480%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

I found the link in the blog post about the NanoServerApiScan tool https://blogs.technet.microsoft.com/nanoserver/2016/04/27/nanoserverapiscan-exe-updated-for-tp5/

Hope that helps. I don't know of a more up-to-date list.

[gireeshpunathil]

@StefanScherer - thanks! that is really a structured documentation. And I don't see SetWinEventHook in the list. So to support libuv / node on NanoServer, we need to pick APIs that are commonly available, looks reasonable to me.

[bnoordhuis]

Micro-nit: no blank line.

[digitalinfinity]

Curious- why is this needed? https://msdn.microsoft.com/en-us/library/windows/desktop/dd318453(v=vs.85).aspx states that HWINEVENTHOOK is available by simply including windows.h, which we do at the top of this file (and more generally, I would expect that most of the structs/types that we define in this file are available through windows.h so I'd like to understand why our definitions would not be redundant)

[bzoz]

In the header file it is inside #if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP). To be safe I redefined it here.

It looks like it is not needed though.

[digitalinfinity]

More a question than a comment but do we ever call FreeLibrary on these DLLs? I guess we just expect them to be loaded for the duration of the process? I imagine there are some scenarios where we'd want some of these DLLs to be unloaded earlier if possible but certainly not in this case

[digitalinfinity]

Overall LGTM- I would also suggest that we consider running the Nano Server API Scan tool as part of the Windows CI since as @gireeshpunathil mentioned, it's easy to introduce a hard API dependency that's unsupported on Nano Server

[MylesBorins]

Hey all.

node.js v6.12.0 with libuv 1.15.0 is currently set to be released on Tuesday the 7th. Is this ready to land? If so do you see any problems with floating a patch on LTS or would we be better off skipping the 1.15.0 upgrade for now?

edit: too quick on the submit button there

[bzoz]

Landed in e7f4e9e

@MylesBorins floating patch should be perfectly ok

[StefanScherer]

I don't have a libuv build environment, but I can share a Dockerfile to build and test it in a Windows container and to test the PR within a nanoserver container afterwards:

FROM stefanscherer/node-windows:8.6.0-build-tools

# Install Git
ENV chocolateyUseWindowsCompression false
RUN iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1')); \
    choco install -y git -params "/GitAndUnixToolsOnPath"

# Add missing PATH to build-tools
RUN $env:PATH += ';{0}\.windows-build-tools\python27' -f $env:USERPROFILE ; \
    [Environment]::SetEnvironmentVariable('PATH', $env:PATH, [EnvironmentVariableTarget]::Machine)

# Clone specific libuv version
ARG branch=v1.15.0
ARG org=libuv
RUN git clone -b $env:branch https://github.com/$env:org/libuv

# Compile test binaries
WORKDIR libuv
RUN .\vcbuild.bat x64

# Run test in a fresh nanoserver container
FROM microsoft/nanoserver
COPY --from=0 /libuv/ /libuv/
WORKDIR libuv
RUN Debug\run-tests.exe

It's a multi-stage build. First stage has all development tools to clone the GitHub repo and build the test binaries.

The second stage then runs the same test in a "fresh" nanoserver image.

With v1.15.0 the test crashes in NanoServer:

$ docker build -t libuv --build-arg branch=v1.15.0 --build-arg org=libuv .
...
Step 10/13 : FROM microsoft/nanoserver
 ---> 302c09e12784
Step 11/13 : COPY --from=0 /libuv/ /libuv/
 ---> d5f084be252b
Step 12/13 : WORKDIR libuv
 ---> e985a36d560a
Step 13/13 : RUN Debug\run-tests.exe
 ---> Running in 3798ea5d87e1
The command 'cmd /S /C Debug\run-tests.exe' returned a non-zero code: 3221225785

Building the older v1.14.1 or this PR branch works in nanoserver:

$ docker build -t libuv --build-arg branch=bartek-fix-win-nanoserver --build-arg org=janeasystems .
...
Step 10/13 : FROM microsoft/nanoserver
 ---> 302c09e12784
Step 11/13 : COPY --from=0 /libuv/ /libuv/
 ---> e1d3f7980b05
Step 12/13 : WORKDIR libuv
 ---> ee9715ad4145
Step 13/13 : RUN Debug\run-tests.exe
 ---> Running in 8c4145a96a00
1..304
ok 1 - platform_output
...

It only shows an error in test 120 and 253:

not ok 120 - loop_alive
# exit code -1073741819
# Output from process `loop_alive`: (no output)
...
not ok 253 - threadpool_queue_work_simple
# exit code -1073741819
# Output from process `threadpool_queue_work_simple`: (no output)

[MylesBorins]

Cherry pick to node in nodejs/node#16724