Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node v14.13.0-x64 does not install on Win7 x64 #35430

Closed
tmccurdy opened this issue Sep 30, 2020 · 24 comments
Closed

Node v14.13.0-x64 does not install on Win7 x64 #35430

tmccurdy opened this issue Sep 30, 2020 · 24 comments
Labels
windows Issues and PRs related to the Windows platform.

Comments

@tmccurdy
Copy link

Is it normal that Windows7 (x64) is not supported by the latest Node version? When and what version is Windows7 not being supported?

@MylesBorins
Copy link
Contributor

@tmccurdy are you able to install the 14.12.0 msi?

https://nodejs.org/dist/v14.12.0/node-v14.12.0-x64.msi

@targos
Copy link
Member

targos commented Sep 30, 2020

Support for Windows 7 was removed in #31954 (for Node.js v14.0.0)

@targos targos added the windows Issues and PRs related to the Windows platform. label Sep 30, 2020
@richardlau
Copy link
Member

Support for Windows 7 was removed in #31954 (for Node.js v14.0.0)

Partially reverted in #33176 (in Node.js 14.5.0). The msi installer is still blocked on Windows 7 but the 7z/zip and/or exe downloads are not if an environment variable is set.

@asdf2345
Copy link

asdf2345 commented Nov 19, 2020

Support for Windows 7 was removed in #31954 (for Node.js v14.0.0)

Partially reverted in #33176 (in Node.js 14.5.0). The msi installer is still blocked on Windows 7 but the 7z/zip and/or exe downloads are not if an environment variable is set.

Yet the environment variable does literally nothing after it's set

@Domarius
Copy link

Yet the environment variable does literally nothing after it's set

Close and re-open the command window.

@Astara
Copy link

Astara commented Dec 21, 2020

Does the installer check if the Win7 platform is still supported through Microsoft's extended support that is sold through the end of 2023?
Since cygwin is a POSIX/Linuxish compatible platform, does node.js support run on Cygwin?

@Psychosynthesis
Copy link

Psychosynthesis commented Mar 15, 2022

Add Windows support to the 14 branch of the node!

Because of this limitation, half of the projects cannot be supported if the developer's computer has a seven.

As far as I can tell, this is essentially just a whim of the developers - "let's stop supporting this junk", despite the fact that people continue to use it, and there are no killerfits here, which could be expected in the 14th version due to the termination of support.


I duplicate my post also in this thread: #38761

Sorry if this looks intrusive, but because of this, I am now facing a situation in which I, apparently, have to install a virtual machine to run a new Windows under it, simply because I cannot (and do not want to) update the OS for a thousand reasons, but for work I need Win and NodeJS not lower than 14th, аnd this is real ridiculous situation. Therefore, I want the developers to pay attention to the problem. Thanks.

@Trott Trott added the v14.x label Mar 15, 2022
@K4sum1
Copy link

K4sum1 commented Mar 15, 2022

Afaik the latest node is able to work on 7 by changing a single function and setting the variable.

@tniessen
Copy link
Member

Does the installer check if the Win7 platform is still supported through Microsoft's extended support that is sold through the end of 2023?

@Astara I don't think so. It's all open-source, so feel free to propose changes through PRs or recompile with your own logic. There are alternative installation methods that do not require using the MSI as well.

Add Windows support to the 14 branch of the node!

@Psychosynthesis the latest 14.x releases include this logic:

node/src/node_main.cc

Lines 30 to 50 in 9beb4f8

#define SKIP_CHECK_VAR "NODE_SKIP_PLATFORM_CHECK"
#define SKIP_CHECK_SIZE 1
#define SKIP_CHECK_VALUE "1"
int wmain(int argc, wchar_t* wargv[]) {
// Windows Server 2012 (not R2) is supported until 10/10/2023, so we allow it
// to run in the experimental support tier.
char buf[SKIP_CHECK_SIZE + 1];
if (!IsWindows8Point1OrGreater() &&
!(IsWindowsServer() && IsWindows8OrGreater()) &&
(GetEnvironmentVariableA(SKIP_CHECK_VAR, buf, sizeof(buf)) !=
SKIP_CHECK_SIZE ||
strncmp(buf, SKIP_CHECK_VALUE, SKIP_CHECK_SIZE + 1) != 0)) {
fprintf(stderr, "Node.js is only supported on Windows 8.1, Windows "
"Server 2012 R2, or higher.\n"
"Setting the " SKIP_CHECK_VAR " environment variable "
"to 1 skips this\ncheck, but Node.js might not execute "
"correctly. Any issues encountered on\nunsupported "
"platforms will not be fixed.");
exit(ERROR_EXE_MACHINE_TYPE_MISMATCH);
}

Is this not working for you, even after setting the NODE_SKIP_PLATFORM_CHECK environment variable as documented for Node.js 14? As discussed here and elsewhere, the MSI might not be working, but other installation mechanisms should.

@K4sum1
Copy link

K4sum1 commented Mar 15, 2022

Why even add more code that wastes cycles and makes the program bigger? If it breaks, it breaks. If it works, it works.

@Psychosynthesis
Copy link

Psychosynthesis commented Mar 15, 2022

@tniessen v.14.19.0 was not working even if i set the NODE_SKIP_PLATFORM_CHECK. However, I succeeded to install version v.14.17.6 and it work for me (at least for now).

Previously, I installed the latest available 13.x version, and then simply replaced its files with files from the fourteenth zip archive.
I don't know if it's possible to skip the step with the 13th version - I just checked if my project would work on it.

This, of course, is better than nothing, but it will be sad if the developers of any of the packages once again decide to update their dependencies without much sense (as in this case, they obviously did in typescript-eslint v.5.3).

@MyTDT-Mysoft
Copy link

soo much trouble caused by rushing drop support of something that is totally capable to run node... for no gains other than say that some newer function call that is just a convenient way (or may more linux like) way of doing what was already possible, instead of wrap such functionality on a function that does not need to be changed ever again, that would implement the same functionality even if in a slight less performant way... its lol :)

@tniessen
Copy link
Member

Why even add more code that wastes cycles and makes the program bigger? If it breaks, it breaks. If it works, it works.

@K4sum1 Why do guard rails exist that waste metal and cost money? Because they deter from entering dangerous areas. Node.js makes no security guarantees on Windows 7. You can still climb over guard rails and you can still use Node.js on Windows 7 by simply setting NODE_SKIP_PLATFORM_CHECK as documented. But it also means you are on your own.

v.14.19.0 was not working even if i set the NODE_SKIP_PLATFORM_CHECK

@Psychosynthesis If you can reproduce that behavior, please feel free to report it as a bug and/or send a PR to fix it.

soo much trouble caused by rushing drop support of something that is totally capable to run node... for no gains other than say that some newer function call that is just a convenient way (or may more linux like) way of doing what was already possible, instead of wrap such functionality on a function that does not need to be changed ever again, that would implement the same functionality even if in a slight less performant way... its lol :)

@MyTDT-Mysoft Feel free to contribute to the project.

@K4sum1
Copy link

K4sum1 commented Mar 23, 2022

@K4sum1 Why do guard rails exist that waste metal and cost money? Because they deter from entering dangerous areas. Node.js makes no security guarantees on Windows 7. You can still climb over guard rails and you can still use Node.js on Windows 7 by simply setting NODE_SKIP_PLATFORM_CHECK as documented. But it also means you are on your own.

So your analogy compares possible death to running a program on a OS with millions of users? Good going there.

@tniessen
Copy link
Member

So your analogy compares possible death to running a program on a OS with millions of users?

@K4sum1 That's clearly a straw man argument, and I'm tired of arguing against logical fallacies...

The dangerous part is not "running a program on a OS", as you misrepresent it. The dangerous part is running a program that makes no security guarantees on an unsupported OS that many users do not receive security patches for. It might be that you don't see any danger in doing that, but we do. Maybe your applications don't deal with sensitive data or security-critical processes, but many do.

An analogy is "a comparison of two otherwise unlike things based on resemblance of a particular aspect". In this case, the "two otherwise unlike things" are danger in real life and danger within computer systems, and the "particular aspect" is a mechanism that deters from said danger but that can be bypassed. So you are somewhat correct, it is an analogy, even though you misrepresent its meaning. The analogy does not at all imply that one danger is comparable to the other, but pretending that it does (as you just did) is a useful straw man, assuming one is willing to resort to logical fallacies.

Lastly, "millions of users" does not support your point at all. If millions of people walk along a dangerous area with no guard rail, the risk is certainly higher than if there were only a few people. Similarly, if millions of users run node on an unsupported platform with no security guarantees, the risk is higher than if there were only a few users.

@MyTDT-Mysoft
Copy link

MyTDT-Mysoft commented Mar 24, 2022

ok, so that means you will do whats possible to have it working, but you wont care about security, which is totally fine, but dont shove unrequested security out of one throat, also isnt like it will have security problems because its on win7 unless its a bug with win7, which then its not even your job to protect against... but then again maybe we should put the fault on other projects that depend on node... that shouldnt be using it... since node wants to care about web server security, which is not aligned with the offline usage of such projects like emscripten, where all this "security" is irrelevant

@K4sum1
Copy link

K4sum1 commented Mar 24, 2022

The dangerous part is running a program that makes no security guarantees on an unsupported OS that many users do not receive security patches for. It might be that you don't see any danger in doing that, but we do. Maybe your applications don't deal with sensitive data or security-critical processes, but many do.

Anyone with 7 is either going to stick with 12, or use the environment variable, sensitive data or not. I just use a portable version of 12 on my drive for when I need to use Node.js, and it works fine. You can't stop me from using 12 on 7, unless that code gets removed, and I can use the latest version without modification. Yes I'm too lazy to set an environment variable, and I'm definitely not maining 10 any time soon, fight me.

Also anyone in a security critical situation that has 7 has either ESU updates, or uses 0patch, meaning the weak point in this case would be Node.js 12, not Windows. Also if security is the reason, why did Node.js drop the still officially supported Server 2012 R1?

@hello-smile6
Copy link

The dangerous part is running a program that makes no security guarantees on an unsupported OS that many users do not receive security patches for. It might be that you don't see any danger in doing that, but we do. Maybe your applications don't deal with sensitive data or security-critical processes, but many do.

Anyone with 7 is either going to stick with 12, or use the environment variable, sensitive data or not. I just use a portable version of 12 on my drive for when I need to use Node.js, and it works fine. You can't stop me from using 12 on 7, unless that code gets removed, and I can use the latest version without modification. Yes I'm too lazy to set an environment variable, and I'm definitely not maining 10 any time soon, fight me.

Also anyone in a security critical situation that has 7 has either ESU updates, or uses 0patch, meaning the weak point in this case would be Node.js 12, not Windows. Also if security is the reason, why did Node.js drop the still officially supported Server 2012 R1?

Just wipe your hard drive and install Debian.

@Psychosynthesis
Copy link

@tniessen

The dangerous part is running a program that makes no security guarantees on an unsupported OS that many users do not receive security patches for. It might be that you don't see any danger in doing that, but we do. Maybe your applications don't deal with sensitive data or security-critical processes, but many do.

OMG what a mess...

Firstly, in your "supported system" there are no less known holes than in the ancient seven. Even if not more considering that the new Windows has now become a target for intruders.

Secondly - if a person really cared about security, he would at least not write his applications in JS, think about it.

@stanleyxu2005
Copy link

Good to know there is a trick to run Node 14+ on Windows 7 with NODE_SKIP_PLATFORM_CHECK=1.

For me, I choose to develop with Windows 7 but deploy onto Linux. As long as all required node_modules can be installed properly on both Win7 and my Linux distribution, I will still manually upgrade Node carefully.

Out of my curiosity, is there any real security issue encountered when running Node 14+ on Windows 7?

@tniessen
Copy link
Member

tniessen commented Jun 5, 2022

Secondly - if a person really cared about security, he would at least not write his applications in JS, think about it.

@Psychosynthesis I read this sentence at least a dozen times. I followed your advice and thought about it. And yet, I still can't tell if you are joking, and I still have no idea what to say to this.


@stanleyxu2005 Yes, there is a simple trick to run newer Node.js versions on Windows 7. You can even set the environment variable globally, either system-wide or at least for a user, so you only have to do it once.

Out of my curiosity, is there any real security issue encountered when running Node 14+ on Windows 7?

I am not aware of any that are specific to Windows 7. Then again, we don't test or audit on Windows 7, and I believe most security researchers have moved on to newer operating systems as well. We also have a bug bounty program but unsupported operating systems might be out of scope, so people might have less incentive to report security issues related to Windows 7.


As much as I appreciate hostile comments from people who complain about non-profit software that they don't contribute to, I'd like to get this back on track. Is installation of Node.js 14 or newer still an issue on Windows 7 when the environment variable is set properly? If so, please provide more information or open a PR to address the issue.

@K4sum1
Copy link

K4sum1 commented Jun 5, 2022

Secondly - if a person really cared about security, he would at least not write his applications in JS, think about it.

@Psychosynthesis I read this sentence at least a dozen times. I followed your advice and thought about it. And yet, I still can't tell if you are joking, and I still have no idea what to say to this.

Javascript isn't known for its security. I would start complaining, but I know a lot of shit isn't entirely the fault of Javascript itself, but other shit too.

As much as I appreciate hostile comments from people who complain about non-profit software that they don't contribute to, I'd like to get this back on track. Is installation of Node.js 14 or newer still an issue on Windows 7 when the environment variable is set properly? If so, please provide more information or open a PR to address the issue.

I think once I tried setting it, but it still didn't install. I think the installer should just give a prompt saying 7 isn't fully supported and remove the code that looks for the variable in the installer and the program.

Also if 7 was dropped for security, why was Server 2012 R1, a still supported OS, dropped with it?

@MyTDT-Mysoft
Copy link

also i think when people say that theres an issue even for a not supported OS, but there isnt really a reason do to that, like not paying attention and using an optional new code path that would require a new OS, even if you dont normally test on it, i think for a big project like that, isnt really fair to dismiss people that showed that theres a problem that shouldnt exist, like i dont see a reason for Node to even require win7 instead of XP for example.

and has it was said using what MS support as a reason to support or not something is really a bad thing, and i've seen lately lot of people saying that as a justification, like many not having 32bit support even when it had 32bit support and the windows version they require also have 32bit support, so yeah, i think people should always put requirements to a minimum and optionally building on that even without priority or formal support, but never dismissing something that is simple to adjust, helping the requirements to be kept as minimum as it can be.

@bnoordhuis
Copy link
Member

I doubt this thread is going to result in productive outcomes so I'm taking the liberty of putting it out to pasture. Please file a new issue if there are legitimate installation problems.

@bnoordhuis bnoordhuis closed this as not planned Won't fix, can't repro, duplicate, stale Jun 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
windows Issues and PRs related to the Windows platform.
Projects
None yet
Development

No branches or pull requests