build: drop the libnode.dll module preference from the hook

GetModuleHandle("libnode.dll") cannot fire for the hosts the suite runs
against, none of which load a shared libnode.dll, and node-gyp's own
hook resolves every delay-loaded name to the process image the same way.
The libnode.dll name match stays, so an addon whose import table names
it is still redirected rather than left to the loader.

Signed-off-by: hexbinoct <abubakarm@gmail.com>

Author: hexbinoct

src/win_delay_load_hook.cc

@@ -2,7 +2,7 @@
  * When this file is linked to a DLL, it sets up a delay-load hook that
  * intervenes when the DLL is trying to load 'node.exe' or 'libnode.dll'
  * dynamically. Instead of trying to locate the file it'll just return a
- * handle to the process image (or to libnode.dll if the host loaded one).
+ * handle to the process image.
  *
  * This allows the test addons to load into any Node-API host executable,
  * regardless of its file name. Same approach as node-gyp's
@@ -21,18 +21,14 @@
 #include <string.h>
 
 static FARPROC WINAPI load_exe_hook(unsigned int event, DelayLoadInfo* info) {
-  HMODULE m;
   if (event != dliNotePreLoadLibrary)
     return NULL;
 
   if (_stricmp(info->szDll, "node.exe") != 0 &&
       _stricmp(info->szDll, "libnode.dll") != 0)
     return NULL;
 
-  // Prefer libnode.dll to support a Node.js built as a shared library.
-  m = GetModuleHandle(TEXT("libnode.dll"));
-  if (m == NULL) m = GetModuleHandle(NULL);
-  return (FARPROC) m;
+  return (FARPROC) GetModuleHandle(NULL);
 }
 
 decltype(__pfnDliNotifyHook2) __pfnDliNotifyHook2 = load_exe_hook;