[Bug]: Win7 can't open electron app after upgrade to v19.x.x

[CN-Tower]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a bug report that matches the one I want to file, without success.

Electron Version

19.x.x

What operating system are you using?

Windows

Operating System Version

win7

What arch are you using?

x64

Last Known Working Electron version

17.x.x

Expected Behavior

Can open and work.

Actual Behavior

Can not open program in win7 operate system.

Testcase Gist URL

No response

Additional Information

No response

[ckerr]

#35197 from yesterday also reported e19 not working on Windows 7. 🤔

[miniak]

it might be 64-bit specific as I can run Electron 19 just fine on 32-bit Windows 7

[VerteDinde]

@CN-Tower Would it be possible for you to make a standalone testcase with only the code necessary to reproduce the issue? For example, Electron Fiddle is a great tool for making small test cases and makes it easy to publish your test case to a gist that Electron maintainers can use.

Since we have several reports that Electron 19 is working on Windows 7 without issue, having a repro here will ensure everyone's looking at the same issue and remove all unnecessary variables from the equation.

I'm adding the blocked/need-repro label, but after you make a test case, please link to it in a followup comment.

Thanks!

[CN-Tower]

@VerteDinde The hello world demo can also reproduce this case: https://gist.github.com/CN-Tower/605dea9d8a92149f908114bf389178f4

[lorand-horvath]

So are there plans to fix Electron 19 support for Windows 7?
VSCode 1.71 (Insiders) bumped Electron from 18 to 19 and now it won't start on Windows 7 anymore due to this bug.

[lorand-horvath]

If anyone is interested, here's the error log when trying to start VSCode 1.71 Insiders (Electron 19) on Windows 7 x64

[main] [error] SystemError [ERR_SYSTEM_ERROR]: A system error occurred: uv_os_gethostname returned ENOSYS (function not implemented)
    at Et.initServices (C:\Program Files\Microsoft VS Code Insiders\resources\app\out\vs\code\electron-main\main.js:77:68046)
    at Et.startup (C:\Program Files\Microsoft VS Code Insiders\resources\app\out\vs\code\electron-main\main.js:77:63904)
    at process.processTicksAndRejections (node:internal/process/task_queues:96:5)

[rzhao271]

Interesting. Then I think it has to do with libuv/libuv#3260

[rzhao271]

Electron already has a patch for that function, actually: #31804.
What's strange to me is that the Electron patch doesn't seem to include the lines https://github.com/libuv/libuv/pull/3285/files. It copies over the function, but then doesn't use it within the patch?

[lorand-horvath]

@rzhao271 Is there anyone working on a patch for this? Would be nice to have Electron 19 functional on Windows 7 x64.

[lorand-horvath]

@rzhao271 Is there a fix planned for this issue? In a few days VSCode 1.71 (August) will be released and those on Windows 7 won't be able to run it because of this Electron 19 bug.
I would appreciate any useful info...

[walsub]

19.0.6 works on Windows 7 for me. What is the error?

[lorand-horvath]

@walsub Forget about it, they've already made up their minds. VSCode 1.71 (Electron 19) will not run on Windows 7:
https://github.com/microsoft/vscode/milestone/202?closed=1
microsoft/vscode#159546

[walsub]

Ah, VSCode doesn't support Windows 7 anymore. Will Electron 19 or above still support Windows 7? According to README, it still supports but I wonder if there is something happening in Electron as well?

[AnrDaemon]

Will Electron 19 or above still support Windows 7?

No. libuv/libuv#2821

[ghost]

Will Electron 19 or above still support Windows 7?

No. libuv/libuv#2821

@AnrDaemon - that shows libuv dropped support for W7, back in early 2021. But the whole point of this discussion is that Electron added a workaround so they could continue to support W7. So how do you get to a conclusion that Electron will no longer support Windows 7 - unless this has been formally dropped?

The current situation is that Electron 19 has a regression, because the fix #31804 is no longer sufficient.

A close with "won't fix because Electron 19 does not support Windows 7" would be a valid route to close this defect perhaps, but we're not there yet.

[lorand-horvath]

@zedayseekay Thanks for taking the time to write the explanation above... finally someone who knows what he's talking about.

[ghost]

@VerteDinde The hello world demo can also reproduce this case: https://gist.github.com/CN-Tower/605dea9d8a92149f908114bf389178f4

I have just tried a fresh install of a Windows 7 guest.

I have installed Fiddle with defaults and done nothing else. When I launch a test using 19.0.6, both the default Hello World from that experience, and the gist you provided, execute correctly.

I am happy this is a real defect but unfortunately I can't reproduce it using the same method as you, so now I'm curious what the difference is because it might be a troubleshooting clue...

For me the successful Hello World reports Node 16.14.2, Chromium 102.0.5005.167, Electron 19.0.16.

[ I will post a gist for a test using one of the Fiddle modules that does exercise libuv,but that is going to take me a while since I can't even install the toolchain without fighting "Windows 7 not supported" messages ]

[ckerr]

The current situation is that Electron 19 has a regression, because the fix #31804 is no longer sufficient.

Is this still broken in >= 20 as well?

[lorand-horvath]

The current situation is that Electron 19 has a regression, because the fix #31804 is no longer sufficient.

Is this still broken in >= 20 as well?

I don't think anybody knows (or care). I've asked several times above whether anyone is working on fixing the Windows 7 bug in Electron 19 and got absolutely no response. This open-source world is very strange...

[ghost]

Additional notes on how to reproduce in a Windows 7 VM:

• Windows 7 SP1 does not support TLS 1.2 fully out of the box, so you will need to address that before you can download any components; the majority of the npm ecosystem in 2022 mandates TLS 1.2. The easiest way is to use the Powershell script from this blog: (no affiliation, I just found it very useful!) https://www.hass.de/content/setup-microsoft-windows-or-iis-ssl-perfect-forward-secrecy-and-tls-12
  Note the script above changes half a dozen defaults, so if you instead want to instead use individual fixes, be aware it might take you some time to find them all!
• If you install Fiddle into a fresh Windows 7 instance, version 16.14.2 of node.js will be downloaded by default for v19.0.6 of Electron. When I attempt to download and install https://nodejs.org/download/release/v16.14.2/ individually using the .msi method, the installer fails, citing a minimum support level of Windows 8.1. I worked around this by just installing manually into a dev directory.
• For node.js, setting the NODE_SKIP_PLATFORM_CHECK environment variable to 1 skips the check for platform version.

I still haven't found a fiddle which will reliably reproduce this, but at least I have a stable environment now...

[ghost]

The current situation is that Electron 19 has a regression, because the fix #31804 is no longer sufficient.

Is this still broken in >= 20 as well?

I don't think anybody knows (or care). I've asked several times above whether anyone is working on fixing the Windows 7 bug in Electron 19 and got absolutely no response. This open-source world is very strange...

@VerteDinde and @ckerr are both from the Electron team. So the right people are looking at this problem, and they've both responded, so I don't think there are grounds for this complaint.

The blocker at the moment is that @CN-Tower 's example works for me - I don't get any error message. So we either need to spend some time looking why it failed for CN-Tower, if they could please reply here with more detail, or we need to find a minimal example of the failure which we can all use in Fiddle to troubleshoot. I might write one now I've finished all the effort required just to get Windows 7 working reliably in a VM guest in 2022.

The issue can be reproduced in the wild by installing iRacing software - the UI for that worked on Windows 7 in the previous example and has broken in this release because it relies on Electron 19.x. However, installing the whole of iRacing just to reproduce is a) not very convenient b) not possible unless you happen to have a paid subscription anyway. :-)

[lorand-horvath]

@zedayseekay You don't need to go as far as iRacing to try to reproduce in the wild. I believe the latest VSCode 1.71 (Electron 19) would suffice to show the issue microsoft/vscode#157616

[yume-chan]

Visual Studio Code crashes on startup because it accessed require('os').hostname(), which throws the error mentioned above:

[main] [error] SystemError [ERR_SYSTEM_ERROR]: A system error occurred: uv_os_gethostname returned ENOSYS (function not implemented)
    at Et.initServices (C:\Program Files\Microsoft VS Code Insiders\resources\app\out\vs\code\electron-main\main.js:77:68046)
    at Et.startup (C:\Program Files\Microsoft VS Code Insiders\resources\app\out\vs\code\electron-main\main.js:77:63904)
    at process.processTicksAndRejections (node:internal/process/task_queues:96:5)

Adding such call to an empty Electron Fiddle also causes crashes:

[yume-chan]

https://github.com/electron/electron/pull/32833/files#diff-e3f64b826dff0b6c0a661e73b2c04c00bd318ed31fbf943d2045b31f2af1b936L173-L177

#32833 removed part of #31804, uv_os_gethostname no longer calls the patched uv__gethostnamew_nt60 function.

[lorand-horvath]

@miniak THANKS AGAIN #35702 (comment)