Any plans for Node v18 and v20 ?

[tmcdos]

Hello.
First I would like to express my great thanks for your work!
Second, to express my regret I am not a C++ developer and thus unable to contribute despite my desire.
And last, I would like to kindly ask do you plan to work on backporting v18 and/or v20 ? What kind of help do you need?

[vladimir-andreevich]

Hi,

I am pleased to hear that my work is beneficial.

There are additional things to consider regarding Node.js v18:

1. Node.js v18 now uses Python 3.11 which does not support Windows 7. This creates an additional potential dependency which must be properly handled. I plan to backport Python 3.11 on Windows 7, test the correctness of the modified Python 3.11 interpreter on my projects, and then use the modified version of the interpreter to build Node.js v18. Since I am looking at the long-term perspective, I publish and use the builds with all fixes; fortunately, the final build with fixes of Python 3.11 has been released a few days ago.

2. The installation list of Visual Studio individual components has been updated. This means that the installation instructions need to be revisited, and the building instructions which are already published might become irrelevant.

3. The release time of the required Node.js v18 and Python 3.11 versions coincided with the examination period of the third academic quartile of my master's programme. Since I give the study considerably higher priority, the release might be postponed by a few days.

I cannot say anything regarding Node.js v20 since I need to inspect which changes related to the interaction with Windows are introduced in v20.

Everything which is needed from you is patience.

[tmcdos]

Hi, thank you for the quick and detailed response!
I totally understand and agree that your education is top priority (I would do the same on your place).
Can Node.js v18 be built for example on a VM with Win10 (where Python 3.11 will supposedly work) but targeting Win7 final executable?

There have been discussions for changing the GYP build system with something better but I doubt there is a consensus:
nodejs/TSC#901
https://github.com/frutiger/ncg

By the way, have you faced problems compiling libuv for Win7? I believe there is at least one incompatibility with the GetHostnameW WinAPI function.

[vladimir-andreevich]

I do not see any reason for building Node.js on a virtual machine as long as it builds on the host OS and does not conflict with other development tools. Node.js does not necessarily need to be targeted for a specific Windows version, including Windows 7; removing the formal OS version check is enough.

In versions 14 and 16 of Node.js, libuv is the only problem which prevents the runtime from running on Windows 7. Essentially, the whole idea of backporting is in the custom implementation of the missing function and injecting it into various parts of this library, sometimes with the modification of libuv behaviour. Other solutions which I also considered are 1) simply reverting the change which makes libuv dependent on the GetHostNameW function and 2) retrieving the computer name inside libuv without using the Windows Sockets 2 application programming interface.

[tmcdos]

One of the reasons for building Node on a VM would be because I am a web developer and besides Node.js and NPM I have no desire of installing VisualStudio, Windows SDK, Python on my development machine - I would build Node once, throw away the VM and then simply use the EXE on my regular Win7 PC. I am not using Node.js native add-ons - so I don't need GYP and/or Python on my dev PC.

I have seen a patch for the GetHostnameW function but I suspect there might be other incompatibilities. There are many forks of libuv but I don't know which of these forks is compatible both with desired Node.js core and with Win7.
libuv_win7_GetHostnameW.patch

[vladimir-andreevich]

I understand your argument regarding the use of a virtual machine.

I am not familiar with the forks of libuv. Of course, there is a chance that there might exist other incompatibilities; at least I have not faced them yet. However, please take into consideration that I do not use Node.js frequently, thus some incompatibilities may be still unrevealed. If you experience any problems, please report them, and I have a look at what might go wrong.

[tmcdos]

Thank you, @vladimir-andreevich
Wish you success on the exams and looking forward for your instructions for compiling Node v18 and hopefully v20, too :)
Big thanks for the hard work!

[vladimir-andreevich]

Thank you! The work is not that hard but rather time-consuming since I solve problems much harder than this at the university.

[tmcdos]

I truly understand your feelings - I experience the same when I fight with bugs in some NPM packages and spend numerous hours to debug the issues. I have created and collected patches for almost 2 dozens of packages, some of them for multiple versions.

[vladimir-andreevich]

Node.js 18 is ready! Test it by running complex projects using it on your Windows 7 machine. Let me know whether everything works fine.

[tmcdos]

Did not work :(((

[vladimir-andreevich]

I experimented with it for a while but did not manage to reproduce this problem, both in the 32-bit version and the 64-bit version. The specific command to display the version of Node.js that is currently installed works fine for me. I have an idea how to fix it... I need a bit more hours for compilation.

[tmcdos]

I believe that Node v18 (either your compiled instance or the pure original) somehow needs a more recent version of ADVAPI32.dll - and since I am with clean Service Pack 1 with just a few updates on top, I downloaded more recent versions of the following DLLs and put them in the binary folder of the installed Node v18:

advapi32.dll - 6.1.7601.23142 (mine is 6.1.7601.18247)
api-ms-win-core-rtlsupport-l1-1-0.dll - 6.1.7601.23142 (mine is 6.1.7601.18015)
kernel32.dll - 6.1.7601.23142 (mine is 6.1.7601.18015)
msvcrt.dll - 7.0.6001.18000 (mine is 7.0.7600.16385)
ntdll.dll - 6.1.7601.23142 (mine is 6.1.7601.18247)
rpcrt4.dll - 6.1.7601.23142 (mine is 6.1.7601.17514)

However, it does not seem to pick these locally present DLLs and instead tries to load the system ones - and thus fails with the missing exported functions.

[tmcdos]

The problem seems to come from the snapshot feature - but even if I try to build with vcbuild release x64 msi nosnapshot the project still tries to build v8_snapshot and when running mksnapshot.exe it breaks with the missing entry point in ADVAPI32.dll

[tmcdos]

I also tried with noetw option but still no luck. Do you by any chance know how to make the project to use the Win7.1 SDK instead of Win 10 ?

[vladimir-andreevich]

There is no need to use Windows 7 SDK to build the project because the problem is not related to the development tools. I am already working on the solution.

[vladimir-andreevich]

I found the solution, and it is not related to Node.js at all. This was a problem inside Windows 7. The error was caused by the internal occasional event decoding issue in the Trace Data Helper. This problem was fixed in the update KB3080149. Install this update, and everything should work fine.

[tmcdos]

I think that it is something different. Node v18 provides a feature called user-land snapshots

The GYP file specifies that this feature (which comes from V8) will be build by running the mksnapshot.exe (which is also part of the build on a previous step) However, mksnapshot.exe depends on the function EventSetInformation from ADVAPI32.DLL

Since the string EventSetInformation is not present anywhere in the Nove v18 src folder (any file inside) - this means it is somehow required by the Visual C run-time library which is closely related to the SDK (Win10 in our case).
KB3080149 is a spyware update which, besides updating several core DLLs (kernel32, ntdll, advapi32, and a dozen others) to prepare Win7 to be able to upgrade to Win10 (if the user decides) - also installs telemetry and essentially converts your/my Win7 into the same surveillance machine as Win10/11.

For example, the file package_225_for_kb3080149~31bf3856ad364e35~amd64~~6.1.1.1.mum looks like this

<?xml version="1.0" encoding="utf-8"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0" description="Fix for KB3080149" displayName="default" company="Microsoft Corporation" copyright="Microsoft Corporation" supportInformation="http://support.microsoft.com/?kbid=3080149" creationTimeStamp="2015-07-23T12:36:40Z" lastUpdateTimeStamp="2015-07-23T12:36:40Z">
  <assemblyIdentity name="Package_225_for_KB3080149" version="6.1.1.1" language="neutral" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" />
  <package identifier="KB3080149" releaseType="Update" restart="possible">
    <parent buildCompare="EQ" serviceCompare="GE" integrate="separate" disposition="detect">
      <assemblyIdentity name="Microsoft-Windows-Foundation-Package" language="neutral" version="6.1.7601.17514" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" buildType="release" />
    </parent>
    <installerAssembly name="Microsoft-Windows-ServicingStack" version="6.0.0.0" language="neutral" processorArchitecture="amd64" versionScope="nonSxS" publicKeyToken="31bf3856ad364e35" />
    <update name="3080149-548_neutral_LDR">
      <applicable disposition="staged">
        <updateComponent elevate="revision">
          <assemblyIdentity name="Microsoft-Windows-Unified-Telemetry-Client" version="6.1.7601.23142" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" versionScope="nonSxS" />
        </updateComponent>
      </applicable>
      <component>
        <assemblyIdentity name="efa3d2d4428850575377f84ae17e1713" version="6.1.7601.23142" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" versionScope="nonSxS" />
      </component>
    </update>
    <update name="3080149-549_neutral_GDR">
      <applicable disposition="staged">
        <updateComponent elevate="install">
          <assemblyIdentity name="Microsoft-Windows-Unified-Telemetry-Client" version="6.1.7601.18939" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" versionScope="nonSxS" />
        </updateComponent>
      </applicable>
      <component>
        <assemblyIdentity name="48e58db7d4e45a3c24f0651b4d89e153" version="6.1.7601.18939" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" versionScope="nonSxS" />
      </component>
    </update>
  </package>
</assembly>

Notice the text Microsoft-Windows-Unified-Telemetry-Client - the spyware. It is present in other MUM files, too.

I don't have enough knowledge how to edit the MSU or the CAB file of KB3080149 to exclude the telemetry and only install the useful DLL updates.

I have extracted the CAB file from the MSU file but I have no clue how to edit the MUM files or whatever is needed in order to remove the telemetry and then install the result with pkgMgr. As far as I know, the CAT files are signed with the MicroSoft certificate to allow Win7 to accept them - but I don't know if they need to be edited in order to remove the telemetry part of KB3080149.

I was hoping that Node v18 can be somehow build (perhaps by somehow changing the GYP file) without the snapshots feature - but I have no success at this moment (as shown in the screenshots above). Any ideas how to achieve that, or if it's possible at all?

[vladimir-andreevich]

Building Node.js for Windows 7 without core features which create errors without KB updates is not the goal of this repository — the aim is to provide the runtime environment without modifying its core functionality or with minimal changes to it in case there is no other workaround found. The changes here are related to the platform-specific code. If you do worry about privacy, and you do not want to install the update KB3080149, what I can do — I can compile Node.js specifically for you where I disable the run-time user-land snapshots such that Node.js does not depend anymore on the problematic part of Windows Trace Data Helper.

[tmcdos]

Yes, I definitely do not want any kind of spyware or telemetry or surveillance on my computer. I am concerned not just about my privacy but also about spending CPU, RAM and network bandwidth for something that benefits a big corporation instead of me.
I would have suggested that I first try to build Nove v18 without the userland snapshots feature if you tell me how, and if this does not work - only then I would dare to waste your time for building a custom Node v18 for me.

However, this morning I found this extended kernel for Win7 and tried it. And it works!
I was able to run your node.exe that was previously refusing to start. I am also going to check latest Chrome versions when I have more time to spare.

[vladimir-andreevich]

It is great that it works! I recommend you stick to this approach.
Waste my time? 😏 This does not waste my time at all, it is rather a waste of the time of the development computer. The story is about coding 20% of the time and 80% of the time waiting while this disaster compiles, then discovering something is not good, changing one line of code and waiting again for this disaster to compile. 😉
At least now I know your environment — I need to find Windows 7 with only Service Pack 1 and no additional updates, while my Windows 7 ISO has all KB updates pre-installed.

Extended kernel for Windows 7... This is something I should consider doing in the future.

[tmcdos]

I have an ISO which is called Win7 x64 SP2 and is dated April 12, 2011. I can share it with you. OR you can search on RuTracker. By the way I have only a couple of updates - the ones that allow 2TB support, USB 3 support, NVMe TRIM support, newer SChannel ciphers, SHA256 code signing, TLS 1.1 and 1.2 for WinHTTP.
The exact names are:

• kb2775511
• kb2864202
• KB2921916
• KB2990941
• KB2992611
• KB3033929
• kb3087873
• kb3140245

I will definitely stick with VxKex but if it really does not spend too much of your time (and you already know the answer) - would you like to educate me what and where exactly should I modify in order to compile this disaster without the snapshots feature ?
I am not even sure if it will manage to finish the compilation because I installed VS2019 instead of 2022 in VirtualBox.
But I can try :)

I use Node.js only for frontend development - so I don't really care for the snapshots feature. But I also understand that other users of your project might actually need it.

[tmcdos]

@vladimir-andreevich Recently, I am experiencing some weird errors with my Vue.JS projects. The error can be EOF, EPIPE or something like this, but is mainly related to unhandled error event in Node's stream subsystem. It happens when the browser tries to fetch a webpage during development.
Any ideas?

[vladimir-andreevich]

Let me have a look...

[tmcdos]

It is not a too large codebase but also not small - so it might be difficult to create a reproduction example. But if you really need it - I can try.