You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's not really something that I want, but given the issues I'm having with #42115, I thought it was worth to bring up the idea.
There are some stats on https://store.steampowered.com/hwsurvey which show that there are actually much less Steam users (I know that's probably not representative of Node.js Windows users, feel free to share better numbers) on 32 bit Windows (0.27%) than on 64 bit Windows 7 (4.08%, and we already stopped supporting Windows 7):
As far as I remember linux 32 bit was dropped because of toolchain issues and the initial plan was to fix it later. That never happend and it seems noone really cares.
FWIW the default on Azure WebApps/Functions is still 32 Bit windows. Don't know why and they support also 64 Bit but the default is 32 bit as far as I know. Maybe because the lower mem requirement of 32 bit windows allows significant savings for a cloud provider.
My gut feel is that we'd get quite a bit more pushback for removing 32-bit windows compared to 32-bit xlinux. I know that there are still customers, at least for java, that still need the 32-bit Windows builds for whatever reason, so I suspect that would be the same for node.js as well.
Although saying that, we could perhaps do with a few more windows devs at the project to help with issues such as the one you reference ... Perhaps dropping the tier it would make us find some volunteers more easily? ;-)
Well, that time it was not even possible to get a compiler for the build machines to compile 32Bit code at all understanding the C++ standard require by v8. Google Chrome is available for 32Bit so in general it should work. But not sure if google uses msvc.
Anyhow, I fully understand the problem and if there are not enough people to solve them it's better to drop 32Bit only instead delaying/blocking the whole project.
I'm +1 from dropping support of 32 Windows in v18. If companies care about this, they should actually allocate some people to fix it. This includes Microsoft (cc @fhinkel@bnb).
Reacted by Stewart X Addison, Richard Lau, Antoine du Hamel, Beth Griggs, Darshan Sen, Jiawen Geng, lin72h, Momen, Jesús Leganés-Combarro and Ulises Gascón
(I know that's probably not representative of Node.js Windows users, feel free to share better numbers)
I actually think this is a good metric to track, specifically because a lot of the apps that "gamers" use end up bundling Node.js somehow (Electron or QT + Node.js).
I'm +1 from dropping support of 32 Windows in v18. If companies care about this, they should actually allocate some people to fix it.
What if Node.js adds a warning to Windows 32bit builds and we see if people notice/care?
Based on the pushback we got around dropping Windows 7 I'm not that keen to go down this route. I'm open to downgrading 32-bit Windows from tier 1 if it's becoming impossible to keep working.
It seems reasonable to have the build of NodeJS that will be in LTS at that point in time to be the last version with 32bit support. My understanding of this page, https://nodejs.org/en/about/previous-releases, indicates v22 would be best aligned, though a strong argument could be made that v20 would suffice given the general low usage of 32bit node.
Reacted by Richard Lau, Tierney Cyren and Gilson Urbano
I develop software that has a decent userbase on weaker machines in poorer countries, and even they've seen 32 bit usage plummet to around 0.4% of users, with Windows 7 usage still at around 2%.
I'm already having to use out of date build tools in our CI for both Rust and Go to get everything working for these users, whether Node drops it or not developers are going to be forced into it because of lowest common denominator sometimes.
What would this mean for the win32 references throughout the code, such as path.win32., would they stay the same, or be renamed to path.windows, etc?
Also, PassMark also has numbers on this: https://www.pcbenchmarks.net/os-marketshare.html.
According to it, 0.2% of users are running 32 bit windows, but I don't know how reliable that really is
I don't think there's much point in deviating from the existing win32 naming convention. (Its purpose was to distinguish from the old 16-bit Windows API, but the 64-bit API and the 32-bit API are largely compatible thanks to x64 CPUs supporting both transparently.)
Reacted by Aviv Keller, Jiawen Geng, Suraj and Colin
Activity
mscdex commentedon Mar 31, 2022
I'm surprised that 32-bit support on Windows wasn't downgraded completely to Experimental at the same time that 32-bit on Linux was downgraded.
Flarna commentedon Mar 31, 2022
As far as I remember linux 32 bit was dropped because of toolchain issues and the initial plan was to fix it later. That never happend and it seems noone really cares.
FWIW the default on Azure WebApps/Functions is still 32 Bit windows. Don't know why and they support also 64 Bit but the default is 32 bit as far as I know. Maybe because the lower mem requirement of 32 bit windows allows significant savings for a cloud provider.
targos commentedon Apr 4, 2022
That's also the kind of issues we have with Windows.
targos commentedon Apr 4, 2022
@nodejs/tsc @nodejs/build @nodejs/platform-windows What do you think?
sxa commentedon Apr 4, 2022
My gut feel is that we'd get quite a bit more pushback for removing 32-bit windows compared to 32-bit xlinux. I know that there are still customers, at least for java, that still need the 32-bit Windows builds for whatever reason, so I suspect that would be the same for node.js as well.
Although saying that, we could perhaps do with a few more windows devs at the project to help with issues such as the one you reference ... Perhaps dropping the tier it would make us find some volunteers more easily? ;-)
Flarna commentedon Apr 4, 2022
Well, that time it was not even possible to get a compiler for the build machines to compile 32Bit code at all understanding the C++ standard require by v8. Google Chrome is available for 32Bit so in general it should work. But not sure if google uses msvc.
Anyhow, I fully understand the problem and if there are not enough people to solve them it's better to drop 32Bit only instead delaying/blocking the whole project.
mcollina commentedon Apr 4, 2022
I'm +1 from dropping support of 32 Windows in v18. If companies care about this, they should actually allocate some people to fix it. This includes Microsoft (cc @fhinkel @bnb).
richardlau commentedon Apr 4, 2022
Maybe someone could crawl through the daily download metrics in https://storage.googleapis.com/access-logs-summaries-nodejs/index.html (linked to from https://nodejs.org/metrics/) to gather some sort of evidence (either way).
bnb commentedon Apr 4, 2022
I actually think this is a good metric to track, specifically because a lot of the apps that "gamers" use end up bundling Node.js somehow (Electron or QT + Node.js).
I agree.
benjamingr commentedon Apr 4, 2022
What if Node.js adds a warning to Windows 32bit builds and we see if people notice/care?
I agree with Matteo and Tierney that if companies care about this they should allocate some people to fix it.
richardlau commentedon Apr 4, 2022
Based on the pushback we got around dropping Windows 7 I'm not that keen to go down this route. I'm open to downgrading 32-bit Windows from tier 1 if it's becoming impossible to keep working.
targos commentedon Apr 4, 2022
The problem now is that we are not able to build it at all (with V8 10.1).
24 remaining items
targos commentedon Mar 13, 2023
@anfibiacreativa Do you have any results to share?
alexsch01 commentedon Apr 13, 2024
I think it's a good time to drop 32 bit Windows
anfibiacreativa commentedon Apr 15, 2024
A while ago a colleague in the Windows experience team reached out about this issue. Please let me bring this issue back to their attention.
bnb commentedon Apr 15, 2024
IMO if there's not a compelling reason soon, we should drop it in the next SemVer major.
mhdawson commentedon Apr 15, 2024
@anfibiacreativa thanks for following up.
AdamBraden commentedon Apr 19, 2024
As noted above Win10 and thus 32bit is supported by Microsoft until October 2025.
It seems reasonable to have the build of NodeJS that will be in LTS at that point in time to be the last version with 32bit support. My understanding of this page, https://nodejs.org/en/about/previous-releases, indicates v22 would be best aligned, though a strong argument could be made that v20 would suffice given the general low usage of 32bit node.
colin969 commentedon May 26, 2024
I develop software that has a decent userbase on weaker machines in poorer countries, and even they've seen 32 bit usage plummet to around 0.4% of users, with Windows 7 usage still at around 2%.
I'm already having to use out of date build tools in our CI for both Rust and Go to get everything working for these users, whether Node drops it or not developers are going to be forced into it because of lowest common denominator sometimes.
avivkeller commentedon May 26, 2024
What would this mean for the
win32references throughout the code, such aspath.win32., would they stay the same, or be renamed topath.windows, etc?Also, PassMark also has numbers on this: https://www.pcbenchmarks.net/os-marketshare.html.
According to it,
0.2%of users are running 32 bit windows, but I don't know how reliable that really istniessen commentedon May 27, 2024
I don't think there's much point in deviating from the existing
win32naming convention. (Its purpose was to distinguish from the old 16-bit Windows API, but the 64-bit API and the 32-bit API are largely compatible thanks to x64 CPUs supporting both transparently.)build: remove support for 32-bit Windows
build: remove support for 32-bit Windows
build: remove support for 32-bit Windows