search

win32ss / supermium

Chromium fork for Windows XP/2003 and up
https://win32subsystem.live/supermium/
BSD 3-Clause "New" or "Revised" License
2.38k stars 79 forks source link

unofficial electron builds? #36

Closed idontyboi closed 9 months ago

idontyboi commented 1 year ago

Hello, a fellow Win7 main user here who won't be able to update to 10 due to always something going wrong.

With very, very, very many Electron-based applications, Chromium's Windows 7 support has went further than just the browser: it also powers many applications including Discord, Guilded, Slack, VSCode, game launchers and a lot more. When those applications update to Electron 23+, they will stop working on Win7.

If an unofficial Electron build is made, it could be possible to get all those no-longer-working applications working again by simply replacing the executable with the Supermium-Electron.

win32ss commented 1 year ago

I was informed of such recently. I am going to start building Electron once I receive some more storage.

andika207 commented 1 year ago

unofficial electron ? I like this utility https://github.com/hainguyents13/mechvibes but can't use it on WinXP because it relies on an unsupported electron version and the developer tried to port it to XP with no luck. https://github.com/hainguyents13/mechvibes/issues/4

idontyboi commented 1 year ago

VSCode exploration has electron 25 binaries which finally broke it. I can get electron 23 to work, but not newer. [2596:0726/174213.523:ERROR:network_service_instance_impl.cc(625)] Network service crashed, restarting service. repeatedly without window on Electron 24, 25 and 26. Waiting for Supermium to be able to run VSCode soon.

How did I experiment later Electron versions?

How I got this far is homemade XomPie DLLs. Even the first beta of Electron 24 launches without windows with the same message. The command line I have to run is electron.exe --no-sandbox --in-process-gpu to avoid GPU process crashing, however it still does not display a window. I can spoof Windows 8 of Electron 22/23 without it crashing, but 8.1 has exactly the same errors. It's almost certainly a Windows 8.1 shared memory API that's to be blame, and it can't be ported to Windows 7. I looked at the Chromium source code, and the shared memory API access is controlled by a variable. Maybe if I figure out exactly where the variable is and edit to always be false, then I can get newer Electrons to run.

idontyboi commented 1 year ago

Still haven't got Electron26 working, as it still gets stuck on "no window creation, network service crash endlessly". Single-process crashes entirely so I can't figure out what's wrong with the network service (even under Electron 22). Have also tested: WebView2 version 110 (can't figure out to disable the sandbox)

Even if Electron 24 or above were to work, it would run slower on my old GPU due to Google removing DXVA HW acceleration. See Bug 1378004: Stop using D3D9 on Windows 10 or above. D3D11 even on my final driver version causes minor graphical glitches on some pages that I actively use.

Even had to implement APIs not even implemented in Wine to get this far... Such as RoGetAgileReference, albeit only partially. You really can't make this stuff up. ```c #ifndef COBJMACROS #define COBJMACROS #endif #include #include #include /* A RoGetAgileReference polyfill under Windows 7 */ typedef struct { void(**lpVtbl)(); ULONG cRef; IUnknown *agileObject; } IAgileReferenceW7; STDMETHODIMP IAgileReferenceW7_QueryInterface(IAgileReferenceW7 *lpMyObj, REFIID riid, LPVOID *lppvObj) { if (!lpMyObj) return HRESULT_FROM_WIN32(E_INVALIDARG); if (memcmp(riid, &IID_IAgileReference, sizeof(IID)) == 0) { InterlockedIncrement(&(lpMyObj->cRef)); *lppvObj = lpMyObj; return 0; } return HRESULT_FROM_WIN32(E_NOINTERFACE); } STDMETHODIMP_(ULONG) IAgileReferenceW7_AddRef(IAgileReferenceW7 *lpMyObj) { return InterlockedIncrement(&(lpMyObj->cRef)); } STDMETHODIMP_(ULONG) IAgileReferenceW7_Release(IAgileReferenceW7 *lpMyObj) { ULONG NewRef = InterlockedDecrement(&(lpMyObj->cRef)); if (NewRef == 0) { IUnknown_Release(lpMyObj->agileObject); CoTaskMemFree(lpMyObj); } return NewRef; } STDMETHODIMP IAgileReferenceW7_Resolve(IAgileReferenceW7 *lpMyObj, REFIID Ref, void **ppvObjectReference) { return IUnknown_QueryInterface(lpMyObj->agileObject, Ref, ppvObjectReference); } void (*IAgileReferenceW7_Vtable[])() = { [0] = IAgileReferenceW7_QueryInterface, [1] = IAgileReferenceW7_AddRef, [2] = IAgileReferenceW7_Release, [3] = IAgileReferenceW7_Resolve }; // The function itself. HRESULT WINAPI RoGetAgileReference(int options, // Ignored REFIID riid, // Ignored also IUnknown *pUnk, IAgileReference **ppAgileReference ) { if (pUnk == 0) return E_INVALIDARG; if (ppAgileReference == 0) return E_INVALIDARG; // Allocate a memory pointer. IAgileReferenceW7 *Reference = CoTaskMemAlloc(sizeof(IAgileReferenceW7)); if (Reference == 0) { return E_OUTOFMEMORY; } Reference->cRef = 1; Reference->lpVtbl = IAgileReferenceW7_Vtable; Reference->agileObject = pUnk; IUnknown_AddRef(pUnk); *ppAgileReference = Reference; return 0; } ```
ghost commented 1 year ago

@win32ss Hello, is this change causing hardware acceleration issues on older NVIDIA graphics cards? My latest GPU driver is 342.01.

Disable DXVAVideoDecodeAccelerator by default.

We've shipped D3D11VideoDecoder for many years now, all remaining cases where it's disabled are due to old drivers. With the removal of Windows 7 and 8.1 support, it's time to try and stop shipping the DXVA decoder and fully migrate to the VDAv2 D3D11VideoDecoder.

Note: DXVAVideoDecodeAccelerator will still be reachable through the PPAPI pathways (see GpuVideoDecodeAcceleratorHost) until that path is switched over to the MojoVideoDecoder path (b/230007619)

[modify] https://crrev.com/11bcb7013a3858f5573472e0d8df76f845fa2884/content/test/gpu/gpu_tests/common_browser_args.py [modify] https://crrev.com/11bcb7013a3858f5573472e0d8df76f845fa2884/media/base/media_switches.cc [modify] https://crrev.com/11bcb7013a3858f5573472e0d8df76f845fa2884/content/test/gpu/gpu_tests/pixel_test_pages.py [modify] https://crrev.com/11bcb7013a3858f5573472e0d8df76f845fa2884/media/base/media_switches.h [modify] https://crrev.com/11bcb7013a3858f5573472e0d8df76f845fa2884/media/mojo/services/gpu_mojo_media_client_win.cc

Smu1zel commented 1 year ago

If that's true, I honestly think it's stupid they even considered this and just go "eh they can use software decoding" and just destroyed the performance for Sandy Bridge and old TeraScale 1 cards (they even stated the usage is a whole 4% of what 80!?). Guess they really have stopped caring for old hardware. But hey, "update your drivers" for your abandoned graphics card...

Ok rant over, I'd really appreciate this being restored to Supermium if this is actually causing performance issues. Like I even have daily used hardware that I do believe uses DXVA as a driver bug workaround on Windows 10! @Alex273UA could you check chrome://GPU if it's working (upstream broke it for a minute idk if it's fixed)?

(I repeated my message, my bad)

ghost commented 1 year ago

@Smu1zel I checked chrome://GPU, it doesn't work.

Smu1zel commented 1 year ago

@Smu1zel I checked chrome://GPU, it doesn't work.

Well that's unfortunate, we'll have to wait until they fix it upstream and make a build off of it.

idontyboi commented 1 year ago

Chrome 109.0.5414.149 (which ALREADY has a ton of context menus broken in GitHub, due to it attempting to use Chrome ~114 Popover API which isn't even avaliable in Firefox 116. I'm sticking with Chrome 109 due to the GPU acceleration issues in Supermium, even under the initial 115 version where it is already disabled)

This will obivously also affect Electron and any Chromium-based browser and application.. My GPU is a GMA X4500-based Intel G41 Express Chipset, which has D3D11 blacklisted due to exactly the graphical glitches.

Canvas: Hardware accelerated
Canvas out-of-process rasterization: Enabled
Direct Rendering Display Compositor: Disabled
Compositing: Hardware accelerated
Multiple Raster Threads: Disabled
OpenGL: Enabled
Rasterization: Hardware accelerated on all pages
Raw Draw: Disabled
Video Decode: Hardware accelerated
Video Encode: Unavailable
Vulkan: Disabled
WebGL: Hardware accelerated
WebGL2: Unavailable
WebGPU: Hardware accelerated

I can't check the status in Supermium, because either chrome://gpu doesn't work (a white screen), or just crash the whole browser. But I get massive lags when playing 720p H.264 video which does not happen under Chrome 109.

win32ss commented 1 year ago

It makes perfect sense that the commit listed above has broken the video acceleration for many users.

I should be receiving my new storage devices in the coming days, allowing me to build Electron (where Supermium will be applied to it in patch form).

Smu1zel commented 1 year ago

Chrome 109.0.5414.149 (which ALREADY has a ton of context menus broken in GitHub, due to it attempting to use Chrome ~114 Popover API which isn't even avaliable in Firefox 116. I'm sticking with Chrome 109 due to the GPU acceleration issues in Supermium, even under the initial 115 version where it is already disabled)

This will obivously also affect Electron and any Chromium-based browser and application.. My GPU is a GMA X4500-based Intel G41 Express Chipset, which has D3D11 blacklisted due to exactly the graphical glitches.

Canvas: Hardware accelerated
Canvas out-of-process rasterization: Enabled
Direct Rendering Display Compositor: Disabled
Compositing: Hardware accelerated
Multiple Raster Threads: Disabled
OpenGL: Enabled
Rasterization: Hardware accelerated on all pages
Raw Draw: Disabled
Video Decode: Hardware accelerated
Video Encode: Unavailable
Vulkan: Disabled
WebGL: Hardware accelerated
WebGL2: Unavailable
WebGPU: Hardware accelerated

I can't check the status in Supermium, because either chrome://gpu doesn't work (a white screen), or just crash the whole browser. But I get massive lags when playing 720p H.264 video which does not happen under Chrome 109.

GitHub isn't very compatible with older browsers anymore. Just try using it on Pale Moon and SeaMonkey, everything will be broken.

To add some input, I did try setting ANGLE to D3D9 on Windows 11. What occured was the Video Decode tab in Task Manager not budging at all and the decoder becomes "VDAVideoDecoder" and I have no idea if that's hardware or software. The result was consistent across Supermium 115, 117, and Chromium 118 with a HD 630.

idontyboi commented 1 year ago

Still no progress on getting Electron 24+ working. So, I instead tried to make other components and applications working:

Thus, Electron will likely require a few more patches on top of Supermium to work.

The hardware acceleration situation (Should I create a new issue for this?)

The hardware acceleration situation in Chromium looks like this:

GPUs Blacklisted

The specific GPU drivers and GPUs affected that may not have driver updates, atleast initially checking, are:

All NVidia Drivers <451.48

All of these NVidia drivers are blacklisted. These include:

Intel HD Graphics 4000

That GPU as a whole is blacklisted. So, no driver updates will help you on this one.

Suggestions

  1. Can the commits up above be reverted to restore D3D9 video acceleration?
  2. The only thing preventing DXVA-D3D11 acceleration under Windows 7 is the API MFCreateDXGIDeviceManager under MFPlat.dll. The DLL mshtmlmedia.dll, present in IE11 under Windows 7, provides at least these functions MFCreateMFByteStreamOnStreamEx, MFLockDXGIDeviceManager, MFUnlockDXGIDeviceManager and MFCreateDXGIDeviceManager. Could the DXVA-D3D11 be enabled if it were delay-loaded from that source instead?
Smu1zel commented 1 year ago

Still no progress on getting Electron 24+ working. So, I instead tried to make other components and applications working:

  • Node 20.5.0 works if you rename GetSystemTimePreciseAsFileTime to GetSystemTimeAsFileTime. It's only used in a internal libuv API that is not used by node whatsoever. os.hostname does not work (worse, it errors out!) due to it expecting a Win8+ API [GetHostNameW]. I just used my API wrappers to make it work. The last fully working version is 16.6.2, and the last version that launches without modifications is 20.2.0.
  • libuv is causing all the Node Win7 problems. The last fully working version is 1.41, and the last version that launches without modifications is 1.44. Latest works under the wrapper DLLs.
  • V8 11.8 should work under vanilla Windows 7 (V8.dev even lists it as supported!). Not sure if the OOM issues are fixed in that version.
  • ANGLE, at least Chromium 115, works just fine
  • SwiftShader, at least Chromium 113, works.
  • Mojo_Core.DLL, well.. I replaced it with Chrome 113 and Chromium 115 without any side effects under my Chrome installation. Does it actually use it?

Thus, Electron will likely require a few more patches on top of Supermium to work.

The hardware acceleration situation (Should I create a new issue for this?)

The hardware acceleration situation in Chromium looks like this:

  • 11bcb70 disabled the DXVA video accelerator by default. The PPAPI is still utilizing it, so it isn't removed. In order to forcibly enable the DXVA HW accel under Supermium 115 but not 117, use command line --disable_d3d11_video_decoder=1 --enable-features=DXVAVideoDecoding
  • 51f418c removed the DXVA video accelerator. Not possible to enable the leftovers.
  • Further DXVA-related code removals happened in 41dea47 and 3ce3584.
  • There's Bug 1448064 as well.. This should probrably be checked as well. Does DXVA invoke the legacy VDA code? Relevant commits: (80775bb, fca79e4, 6fb414a, 064f82b, 5c06665, 800aa1c)

GPUs Blacklisted

The specific GPU drivers and GPUs affected that may not have driver updates, atleast initially checking, are:

All NVidia Drivers <451.48

All of these NVidia drivers are blacklisted. These include:

  • Windows 7 Quadro drivers do not reach that high. So, ALL Quadro GPUs that are capable of running under Windows 7.
  • Tesla and even some Fermi (GT 8000/9000, GTX 100, 200, 300, 400 and 500 series) cards in general can not get drivers that go up that high.

Intel HD Graphics 4000

That GPU as a whole is blacklisted. So, no driver updates will help you on this one.

Suggestions

  1. Can the commits up above be reverted to restore D3D9 video acceleration?
  2. The only thing preventing DXVA-D3D11 acceleration under Windows 7 is the API MFCreateDXGIDeviceManager under MFPlat.dll. The DLL mshtmlmedia.dll, present in IE11 under Windows 7, provides at least these functions MFCreateMFByteStreamOnStreamEx, MFLockDXGIDeviceManager, MFUnlockDXGIDeviceManager and MFCreateDXGIDeviceManager. Could the DXVA-D3D11 be enabled if it were delay-loaded from that source instead?

My 8400 GS wasn't blacklisted last time I tried it (back in June). Video encoding was disabled by a bug workaround, but everything else was allowed.

As for the HD 4000, doesn't surprise me, as Google blacklists old Intel GPUs for some reason after a while.

On Windows 11 with ANGLE set to D3D9 with a HD 630, it used VDAVideoDecoder, so maybe another path is being used for these old systems to still accelerate? Or it's just detecting my system is new enough to use D3D11 decoding and uses it regardless. Not sure how the Video Decoding bar in Task Manager works.

Either way, I'm guessing the fallback path for whatever reason doesn't work on 7, causing issues anyway. Since they trashed it after they were done with 7 support it was probably there for that reason.

EDIT: Oh I see, this is what you're talking about. Doesn't sound good now that DXVA has been removed.

Smu1zel commented 11 months ago

Still no progress on getting Electron 24+ working. So, I instead tried to make other components and applications working:

  • Node 20.5.0 works if you rename GetSystemTimePreciseAsFileTime to GetSystemTimeAsFileTime. It's only used in a internal libuv API that is not used by node whatsoever. os.hostname does not work (worse, it errors out!) due to it expecting a Win8+ API [GetHostNameW]. I just used my API wrappers to make it work. The last fully working version is 16.6.2, and the last version that launches without modifications is 20.2.0.
  • libuv is causing all the Node Win7 problems. The last fully working version is 1.41, and the last version that launches without modifications is 1.44. Latest works under the wrapper DLLs.
  • V8 11.8 should work under vanilla Windows 7 (V8.dev even lists it as supported!). Not sure if the OOM issues are fixed in that version.
  • ANGLE, at least Chromium 115, works just fine
  • SwiftShader, at least Chromium 113, works.
  • Mojo_Core.DLL, well.. I replaced it with Chrome 113 and Chromium 115 without any side effects under my Chrome installation. Does it actually use it?

Thus, Electron will likely require a few more patches on top of Supermium to work.

The hardware acceleration situation (Should I create a new issue for this?)

The hardware acceleration situation in Chromium looks like this:

  • 11bcb70 disabled the DXVA video accelerator by default. The PPAPI is still utilizing it, so it isn't removed. In order to forcibly enable the DXVA HW accel under Supermium 115 but not 117, use command line --disable_d3d11_video_decoder=1 --enable-features=DXVAVideoDecoding
  • 51f418c removed the DXVA video accelerator. Not possible to enable the leftovers.
  • Further DXVA-related code removals happened in 41dea47 and 3ce3584.
  • There's Bug 1448064 as well.. This should probrably be checked as well. Does DXVA invoke the legacy VDA code? Relevant commits: (80775bb, fca79e4, 6fb414a, 064f82b, 5c06665, 800aa1c)

GPUs Blacklisted

The specific GPU drivers and GPUs affected that may not have driver updates, atleast initially checking, are:

All NVidia Drivers <451.48

All of these NVidia drivers are blacklisted. These include:

  • Windows 7 Quadro drivers do not reach that high. So, ALL Quadro GPUs that are capable of running under Windows 7.
  • Tesla and even some Fermi (GT 8000/9000, GTX 100, 200, 300, 400 and 500 series) cards in general can not get drivers that go up that high.

Intel HD Graphics 4000

That GPU as a whole is blacklisted. So, no driver updates will help you on this one.

Suggestions

  1. Can the commits up above be reverted to restore D3D9 video acceleration?
  2. The only thing preventing DXVA-D3D11 acceleration under Windows 7 is the API MFCreateDXGIDeviceManager under MFPlat.dll. The DLL mshtmlmedia.dll, present in IE11 under Windows 7, provides at least these functions MFCreateMFByteStreamOnStreamEx, MFLockDXGIDeviceManager, MFUnlockDXGIDeviceManager and MFCreateDXGIDeviceManager. Could the DXVA-D3D11 be enabled if it were delay-loaded from that source instead?

My 8400 GS wasn't blacklisted last time I tried it (back in June). Video encoding was disabled by a bug workaround, but everything else was allowed.

As for the HD 4000, doesn't surprise me, as Google blacklists old Intel GPUs for some reason after a while.

On Windows 11 with ANGLE set to D3D9 with a HD 630, it used VDAVideoDecoder, so maybe another path is being used for these old systems to still accelerate? Or it's just detecting my system is new enough to use D3D11 decoding and uses it regardless. Not sure how the Video Decoding bar in Task Manager works.

Either way, I'm guessing the fallback path for whatever reason doesn't work on 7, causing issues anyway. Since they trashed it after they were done with 7 support it was probably there for that reason.

EDIT: Oh I see, this is what you're talking about. Doesn't sound good now that DXVA has been removed.

I dug the thing out again and checked back. On Edge 119 on Windows 11, Video Decoding is "accelerated" but both the decoding and encoding fields at the bottom of chrome://GPU are blank. Even after overriding the driver bug workaround that disabled the d3d11 decoder, the fields remain blank. Meanwhile, Chrome 109 has the Decoding field populated, and this card probably doesn't support any kind of encoding, so that part seems normal. I also checked Chrome 119 and Supermium 118 and got the same blank fields. So yes, the removal of DXVA is probably the reason for the loss of performance.

This is also backed up by this card using the 340.xx drivers, which is probably what affected users have.