Node: Dispute of "block running on EOL Windows versions #31954" - Alternative Suggestion

[xCykrix]

Is your feature request related to a problem? Please describe.
Dispute of PR https://github.com/nodejs/node/pull/31954

Describe the solution you'd like
Changing of "Windows 8.1+ Required" to a warning regarding the usage of EOL operating systems that may inexplicably lead to the software failing to function for any reason.
Continuing support of Windows 7 at its EOL, even in a minimal state, up until the point that it becomes a burden to the active scope of the project.
It is currently in a known working state at the last version before 14.0.0, and I believe it will continue to work for the near future given that no significant changes will be made to Windows 7... ever...

Describe alternatives you've considered
I cannot see any possible alternatives besides removing the commit in a local fork and compiling the binaries myself.
This could also be circumvented by using a Linux virtual machine, but that is a significant hassle and is the last resort for me.

My full schpeel
While I struggle to understand the reasoning behind this, I deeply disagree with https://github.com/nodejs/node/pull/31954 restricting the ability to use Windows 7.

I feel this should be removed and/or at least optional in some form. This could be achieved with a warning at runtime instead of failing to enter runtime) to the risk of using an EOL operating system that may result in the software inexplicably not working. Even going as far as offering minimal support for EOL operating systems if you do not wish to support this operating system any further past compiling it with its known working state.

Windows 10 left a bitter taste in the mouth of many with poor quality control and update mechanics. Given that Windows 7 is quite stable at its End of Life, I believe it should be supported up until a point that it cannot be supported any longer due to limitations in the scope of the project that prevents it.

[xCykrix]

Reference Issue: https://github.com/nodejs/node/issues/33000

[bnoordhuis]

Node.js has been doing that for some time. There are only so much resources to go around and we choose to spend them elsewhere. If you insist on using an unsupported, end-of-lifed operating system, your options are:

1. Use the last version of Node.js that supported Windows 7, or
2. Remove the check and build from source.

I'm closing this as a wontfix.

[addaleax]

Fwiw, I also disagree with the practice of exiting the process if the OS is unsupported. I get that people shouldn’t be using Windows 7 anymore, but if they want to and we tell them it’s unsupported, that’s not really our problem but theirs, right?

@xCykrix If you open a PR that removes the exit(ERROR_EXE_MACHINE_TYPE_MISMATCH); line from src/node_main.cc, I’d approve it. I guess there’s a good chance that other people would disagree, but fwiw, PRs tend to lead to results faster than discussions in issues.

[bnoordhuis]

The current practice came about after ample discussion. The reason I closed this so quickly is that trying to backtrack on it just wastes everyone's time, including the OP's. Please close this again.

[addaleax]

@bnoordhuis Do you have a reference to that discussion?

[bnoordhuis]

@addaleax #3804

[addaleax]

@bnoordhuis I see zero discussion on this particular topic in that thread. The most popular suggestion in it actually seems to be a warning.

I’ll be re-opening this and keeping it open.

[sam-github]

@addaleax I don't understand what is unique to this particular issue was not discussed previously. What I saw was:

• https://github.com/nodejs/node/issues/3804#issuecomment-175849269
• ctc meeting referenced: https://github.com/rvagg/io.js/blob/3967cb591232e50d2eec3cff3327eaffa9c0081d/doc/ctc-meetings/2016-01-27.md#drop-windows-xp-and-vista-support-in-60-3804

"stop on startup" is specifically mentioned several times, final mention in CTC meeting notes above:

I can make the change to stop on startup

[bnoordhuis]

What's unclear about https://github.com/nodejs/node/issues/3804#issuecomment-175849269? The PR is #5167 in case you missed it.

[addaleax]

@bnoordhuis The comment does not mention stop-on-startup behaviour, only dropping support? And the PR doesn’t contain any discussion about it, either.

The CTC meeting notes do contain a reference, but nowhere do I see a reason why we chose to go that particular path of not allowing Node.js to run at all under unsupported Windows versions.

[bnoordhuis]

The vote was to stop it from running because we don't want users to waste time when it doesn't work, we don't want to receive bug reports or pull requests that need to be triaged/reviewed, etc.

To be clear: I don't want to revisit that discussion, I'm posting this only to clarify. I really would like for you to close this issue again. It's either that or bringing it before the TSC again.

[jasnell]

Having had a couple of years to stew on it, rather than removing the stop-on-startup and warning by default, I'd certainly be open to a command-line option that would skip the check on startup with a warning emitted to the terminal. Doing so would at least make it easier to test what does or does not work without having to do a recompile and, if by some miracle things continue to work, fantastic.

$ node --skip-supported-platform-check
Warning: Node.js is not officially supported on this operating system version. Things may break.
> 

... Seems reasonable enough.

[ghost]

Not that my opinion has any influence, but anyway I'll share my thoughts. I see several reasons for not fully dropping Win7 support:

1. Windows is not a free operating system. If someone bought Win7 machines five years ago, upgrading to Win10 costs money. Despite the presence of available patched/cracked free versions on TPB, they are not applicable in commercial infrastructures. Asking users to upgrade their proprietary system in order to keep using Node.js is not in line with free software politics.
2. Dropping support for something that still works is at least inappropriate and forces users to spend more resources and time on manually patching and recompiling each release. Even if the support is excluded from official releases, I would suggest keeping the support in some other release channel (like https://unofficial-builds.nodejs.org/).
3. Being affraid of receiving issues regarding broken Win7 features is not really a problem in my opinion. State explicitly in the documentation that Win7 is no longer supported and move all future Win7 issues to the help repo, with an explanation that the Node.js team will not work on the fix.
4. Node.js is a runtime designed for developers, not all end users. Node.js should assume that their users know what they are doing (hopefully) and provide enough set of features that does not require recompiling in order to support something that is not even broken.
5. While giving all the respect to the Node.js TSC decisions, I would prefer that Node.js in the future conducts a survey for all crucial decisions regarding fundamental user experience features.

[gireeshpunathil]

many vendors allow free upgrade. looks like that is not the case here?

pros (of allowing untested / life-ended platforms):

• in many cases, it does not harm anything; the code will run as is. so great relief for users; business continuity

cons:

• many customers upgrade slowly. ability to run on older versions cause further slowness
• maintenance becomes hard. tools, skills, etc. become stale
• not many bug reports carry OS information despite we ask for it. Many times, several cycles are spent before we dig into that direction. It is not a best practice to start the investigation by suspecting the OS.
• security and compliance issues for those who care for it.

I do not see one outweighing another; so may be other parameters could be brought in to the considerations.

[Jisagi]

The idea @jasnell made, isn't that bad. It wouldn't be either hard nor very intrusive to add the proposed flag only to the binary (node_main.cc). It wouldn't be added to the installer then, so only those who really want it, can get the binaries and use those. This would still stop those who shouldn't be using it, but enables those who know what they are doing/really need it on win7.

I can therefore only second his suggestion.

EDIT: For now, I just compiled my own windows executable without the newly added check. It works, but it's far from the best solution and I doubt many people want to do the same.

[gireeshpunathil]

@fastcoder15 -

Windows is not a free operating system. If someone bought Win7 machines five years ago, upgrading to Win10 costs money. ...

agree, to the extent of windows is not free and upgrading is not free, so the current state causes users to spend more. This is the very strong reason that makes this issue relevant IMO.

Dropping support for something that still works is at least inappropriate and forces users to spend more resources and time on manually patching and recompiling each release. Even if the support is excluded from official releases, I would suggest keeping the support in some other release channel (like https://unofficial-builds.nodejs.org/).

couple of concerns here:

• it incurs efforts to the project too, to validate that certain such OS flavors still work. Please remember there are a number of platform combinations.
• it is not that easy to make such assertions IMO. something that still works cannot be qualified as such. Plurality of workloads might prove the case differently.
• keeping in channels like https://unofficial-builds.nodejs.org : agree on the logistics and channel, if we decide to publish on unsupported platforms.

Being affraid of receiving issues regarding broken Win7 features is not really a problem in my opinion. State explicitly in the documentation that Win7 is no longer supported and move all future Win7 issues to the help repo, with an explanation that the Node.js team will not work on the fix.

• I don't think it is a question of being afraid of receiving issues; it is the question of standard release practices versus providing improved user experience.
• help repo is not differentiated from core repo based on support stands. Instead, it is based on the nature of the issue - perceived as a bug (core) versus may not be a bug, but still need investigation assistance or clarification or advise (help)

While giving all the respect to the Node.js TSC decisions, I would prefer that Node.js in the future conducts a survey for all crucial decisions regarding fundamental user experience features.

• we have been doing this, couple of examples that come on top of my head are:
  
  
  
  • https://github.com/nodejs/TSC/issues/790
  
  
  • https://github.com/nodejs/diagnostics/issues/280
    
    (for pro-actively seeking feedback)
  
  
  • [email protected] (for users to reach out to the project)
  
  
  • it is not very easy to collect feedback for every PRs though.
  
  

bottom-line: w.r.t do this or don't do this, I am still in the middle, and can reach to an opinion based on more user feedback or more insights.

[xCykrix]

I am very happy to see this actually got some discussion. I was quite discouraged to see it closed so quickly with only one member's feedback being present.

@addaleax @jasnell @gireeshpunathil What is your stance after all the further discussion? Removing the check or adding the flag (--skip-supported-platform-check) to bypass that check? I feel like something along the lines of a runtime deprecation notice or similar as the default would be better. It would limit any unknown issues with applications or software that may upgrade NodeJS automatically on "unsupported platforms" unknowing of the current state or flag.

@Jisagi @fastcoder15 Thank you both for your insight into this! I appreciate people taking a second look at this and leaving suggestions. I'll be hopefully opening an official PR for it shortly depending on responses. I'd want to know what is favored (deprecation notice or bypass flag). I'm favoring the deprecation notice at runtime as that would break fewer applications currently active that may not be actively monitored.

[gireeshpunathil]

@xCykrix - for me, removing the check or adding the flag is an implementation detail with differing level of abstraction and control; and a consensus on doing or not doing it should happen first, and for me, as notes earlier, I am unable to make an opinion with the current info.

[xCykrix]

@gireeshpunathil What would be the best way to gather a "consensus"? Is there a favored location for discussing this or should I do a PR implementing one of these with the alternative also being present in discussion for future before approval and etc.? My apologies, as I wasn't even considering to open it myself at the time of writing as I still have a lack of understanding for the development cycle. I've been reading all of the documentation and currently installing the Windows build tools required to even test.

[gireeshpunathil]

there are few ways:

• raise a PR with one of the change proposal as above, that allows review and collaboration
• leave this issue for allowing more opinions to come in, and hoping to see a consensus
• optionally involve TSC if not converging naturally.

Technically this code change proposal implies a policy change proposal too, and hence I am personally inclined to second and third options.

[bnoordhuis]

optionally involve TSC

There's no "optionally" unless the rules changed radically since I stepped down.

The policy was set by the CTC, what is nowadays the TSC. Revisiting it means it needs to be ratified again.

[jasnell]

@gireeshpunathil is correct about the process. Until there is a PR that cannot be resolved through regular discussion, there's nothing for the tsc to really decide here. Even tagging this issue with tsc agenda is a bit pointless because it's not clear at all, absent a PR, what the tsc would be asked to decide on as even if this issue is closed, a PR could still be opened that changes the behavior.

[addaleax]

@xCykrix To give a concrete answer to your question: I would keep the warning and remove the exit() call that stops Node.js from working altogether, and possibly extend the warning to state that Node.js will not accept bug reports or patches for unsupported Windows versions.

[xCykrix]

@addaleax alright! As soon as I get windows to behave I will create a PR for that so we can get it set up properly for TSC :slightly_smiling_face:

[mmarchini]

Windows is not a free operating system. If someone bought Win7 machines five years ago, upgrading to Win10 costs money.

AFAIK Upgrade from Win7 to Win10 is still free ~and supported by Microsoft~ (https://www.theverge.com/2020/1/14/21065140/how-to-upgrade-microsoft-windows-7-10-free-os). So while there might be other reasons for folks to stay on Win7, cost is not a valid one.

---

Do we prevent Node.js from running on other EOL platforms, or just Windows?

[ghost]

AFAIK Upgrade from Win7 to Win10 is still free and supported by Microsoft. So while there might be other reasons for folks to stay on Win7, cost is not a valid one.

Have you tested it yourself? The article you referenced is not reliable. We tested these and similar articles earlier using a virtual machine and the Windows 10 cannot be installed without entering a valid Windows 10 serial key.

Please read the official FAQ page. It clearly says that the Windows 10 free upgrade ended on July 29, 2016. Especially read this:

Do I still qualify for the free upgrade offer if I've already downloaded Windows 10 to a USB drive, but haven't yet upgraded my device?

All upgrades must have completed and reached the "Welcome" screen by 11:59 PM UTC-10 (Hawaii) on July 29, 2016; this is one worldwide point in time.

[mmarchini]

Have you tested it yourself? The article you referenced is not reliable. We tested these and similar articles earlier using a virtual machine and the Windows 10 cannot be installed without entering a valid Windows 10 serial key.

Yes (not on a virutal machine though, but I have a feeling that it wouldn't work properly on VMs). Maybe it's not officially supported by Microsoft, but they didn't disable that feature either.

[addaleax]

Do we prevent Node.js from running on other EOL platforms, or just Windows

No, it’s just Windows.

[xCykrix]

@addaleax so I have the src/node_main.cc finished. But with the extra message, all of the tests actually fail. I'm not quite sure of a way around it, as my C++ knowledge is horrifically lacking.

Should I go ahead and open it with that knowledge heavily present first? It is far above my scope of knowledge with this language haha.

[addaleax]

@xCykrix It’s expected that tests will fail when there is output on stderr, so that should be okay. :+1:

[mmarchini]

No, it’s just Windows.

I wonder if we should make it consistent across platforms (either remove the check from Windows or add it to other platforms). Does anyone know why we went with a different (more "proactive") approach for Windows?

[bnoordhuis]

No, it’s just Windows.

We actually do on macos because we specify the minimum at build time. The binaries simply won't load on older versions of macos. So that's windows + macos.

The reason we don't on linux is because It's Complicated: the heterogeneous nature of linux makes reliable distro detection difficult.

In practice the binaries won't load because of missing symbols, or won't run because of missing system calls. That effectively enforces our baseline so you could say it's really windows + macos + linux.

[gireeshpunathil]

As per the docs, there is no difference between issue and PRs w.r.t tsc agenda. What matters is whether we are in an impasse or not:

https://github.com/nodejs/node/blob/efefdd668dece956c4f75039c77fb0c40dfdd3c8/GOVERNANCE.md#tsc-meetings

Any community member can create a GitHub issue asking that the TSC review something. If consensus-seeking fails for an issue, a Collaborator may apply the tsc-agenda label. That will add it to the TSC meeting agenda.

https://github.com/nodejs/node/blob/f67601cd772b9dbcc94cbf9939b0e229b815e939/doc/guides/onboarding-extras.md#General

tsc-agenda - Open issues and pull requests with this label will be added to the Technical Steering Committee meeting agenda

either ways, there is a PR opened already, so this (tsc agenda or not) is resolved

[xCykrix]

@muv1 While I can see your frustration, as that was my reason for creating this, that is no reason to lash out at the development team. It has been the technical practice to disable using Node.js for EOL operating systems, but it is inconsistent and does not have a way to disable that check at this time (which this is aiming to fix!).

While I am still leaning more towards warnings that are posted at runtime, the contributors have brought good points that may land this with @joaocgreis's suggestion regarding environment variables given that a flag would not be easily passed to child processes of Node.js. Windows 7 has been around for almost the entire Node.js project so Windows deprecation does not yet have well-defined precedences yet and thus only went how Windows XP and Vista have been deprecated in their supported time.

You can find the general overview of what the technical steering committee thought of this while talking on this subject Node.js YouTube April 29th, 2000 TSC Archive Meeting. Just give it a little time to be discussed, it will be brought up again in the next TSC meeting that it was referenced in right above your message, and isn't something that can be changed overnight.

I wouldn't jump ship just yet. Give it a little time to be discussed and check back on the 7th in either this issue or the other one referenced by joaocgreis to see what is happening. :slightly_smiling_face:

References:
My PR: #33108
Joao's PR: #33176

[mhdawson]

Looks like https://github.com/nodejs/node/pull/33176 should address this. Removing agenda tag.

[xCykrix]

To prevent any future confusion, I'm going to go ahead and close this and my attached pull request as I am in support of #33176 myself, and it seems consensus has been met for it.

[GeekCornerGH]

If you open a PR that removes the exit(ERROR_EXE_MACHINE_TYPE_MISMATCH); line from src/node_main.cc, I’d approve it. I guess there’s a good chance that other people would disagree, but fwiw, PRs tend to lead to results faster than discussions in issues.

Can I do this? @addaleax? Does it still matter?