Jump to content

Future of Chrome on Windows 7


yoltboy01

Recommended Posts

On 1/17/2023 at 9:40 PM, win32 said:

I found that there are ultimately four reasons why Chromium is broken on NT 6.x:

1. New imports in kernel32 and userenv. They can all be stubbed, not hard to fix. (Vista/7; 8.x has them)

2. Use of job object APIs in ways that are only supported on 8.x (without sandbox) and 10 (with sandbox)

3. Use of new NtQueryInformationProcess class for enumerating process handles; if it can't be used, the content process will be terminated (8.0 and below, sandbox only)

4. Use of new DirectWrite factories, like IDWriteFactory3, which was introduced in Windows 10

#1 is taken care of, I'm getting there with #2 and then I should be able to do #3. #4's solution is actually quite simple; copy over a Windows 10 DWrite.dll to use with Chromium using DLL redirection methods (I used 10.0.17763.1 and I think 10240 and up should work too). Then patch these DLL names in the import table with a hex editor or CFF explorer:

api-ms-win-core-libraryloader-l1-2-0.dll -> kernel32.dll
api-ms-win-core-localization-l1-2-2.dll -> kernel32.dll

This is sufficient to run the latest Chromium browser snapshot on Windows 8:

chromium.png

Right now there are truly missing functions on Windows Vista and 7, in api-ms-win-core-delayload-l1-1-0.dll and api-ms-win-core-delayload-l1-1-1.dll. Some of those return function pointers so they can't be stubbed.

You're a legend, dude. Thank you for your contributions, it's helpful and appreciated as always.

Link to comment
Share on other sites


I now got it running on Vista in --no-sandbox mode after making some adjustments to locale API to allow Windows 10's dwrite.dll to load. However, the performance is very poor. It now takes up to a minute to launch the browser instead of it taking a few seconds.

It should be easier to get dwrite.dll on 7 (no kernel32 functions need to be modified/upgraded on 7), but 7 still won't be able to run these new versions of Chromium because no changes have been made to the job object API there. There is also the possibility that performance will be very poor as well. VxKex will provide that and more, eventually.

Edited by win32
Link to comment
Share on other sites

4 hours ago, win32 said:

I now got it running on Vista in --no-sandbox mode after making some adjustments to locale API to allow Windows 10's dwrite.dll to load. However, the performance is very poor. It now takes up to a minute to launch the browser instead of it taking a few seconds.

It should be easier to get dwrite.dll on 7 (no kernel32 functions need to be modified/upgraded on 7), but 7 still won't be able to run these new versions of Chromium because no changes have been made to the job object API there. There is also the possibility that performance will be very poor as well. VxKex will provide that and more, eventually.

I assume you talk about the 111 version ? Did you try to apply the huge list of flags I gave you ? A few seconds is still slow, on my 14 years old PC (2009) with mechanical HDD Chrome 110 starts in 0.5 sec or smth like that. That is with that flags and the Dixel's launcher. I f you still use the old launcher, it needs to be re-butchered because starting from 92 (or so) chrome had changed the user data dir path.

Link to comment
Share on other sites

5 hours ago, D.Draker said:

I assume you talk about the 111 version ? Did you try to apply the huge list of flags I gave you ? A few seconds is still slow, on my 14 years old PC (2009) with mechanical HDD Chrome 110 starts in 0.5 sec or smth like that. That is with that flags and the Dixel's launcher. I f you still use the old launcher, it needs to be re-butchered because starting from 92 (or so) chrome had changed the user data dir path.

Yes, I did. No difference in performance.

I believe it is because of a call to NtAlpcSendWaitReceivePort that should only be made once, to obtain some cache information; however it never receives it, which means this call is made constantly until it can be received, or it probably gives up after an untold number of calls and gets on with the loading process. So there is an ALPC port in Vista that seems to be unable to answer a certain type of message required by DirectWrite.

Link to comment
Share on other sites

6 hours ago, win32 said:

Yes, I did. No difference in performance.

I believe it is because of a call to NtAlpcSendWaitReceivePort that should only be made once, to obtain some cache information; however it never receives it, which means this call is made constantly until it can be received, or it probably gives up after an untold number of calls and gets on with the loading process. So there is an ALPC port in Vista that seems to be unable to answer a certain type of message required by DirectWrite.

Then we need to turn off the bloody DirectWrite for Chrome on Windows 7 completely. I know they removed that flag a long time ago,

but in some chinese forks - the flag still works, the problem is, no chinese forks on v.111 exist yet.

I myself use a chinese fork I re-butchered for my needs, it's based on Chrome 102 and it has the flag to switch the DirectWrite off completely. What do you think of this idea ? We can compare and see the portion of that code in the fork. Also, don't forget - starting from 105 or so, everything is only soft, no hard rendering for windows 7 anymore. Surely it would be slower due to this also.

EDIT:

@win32see this comment and try to test the browser with krenel from October, locally. I just tried it and the 110 version loads up even faster and the responsiveness is amazing.

https://msfn.org/board/topic/181612-wip-windows-vista-extended-kernel/?do=findComment&comment=1236240

Edited by D.Draker
Link to comment
Share on other sites

@win32Got it working on 8.1. Thanks! Really appreciate it! Only had to redirect core-localization-l1-2-2. By the way, I first tried using a W11 Dwrite (22000 something) and it didn't work. Switched to W10 (10.0.19041.1566) and its been running smoothly.

Edited by recapir
@
Link to comment
Share on other sites

On 1/22/2023 at 9:24 PM, win32 said:

It now takes up to a minute to launch the browser

So today I tried to play with it and got all of the missing replaced and it launches in a matter of several milliseconds and then quits. I can see the main windows with aero and it is blank (white page).

This is with the launcher, of course. Also it wanted me to replace SetProcessInformation (even though it was not shown in Dep. walker). And PrefetchVirtualMemory (was shown in the walker) had to be repaced too.

SetProcessInformation and PrefetchVirtualMemory are Win 8 and up.

The result is the same on Vista and Win 7.

EDIT: No aero on Win 7, of course.

Edited by D.Draker
Link to comment
Share on other sites

For those who were seeking "official" confirmation.

Opera finally admits they lied . After I pressured them ? I dunno.

A reminder : 96 is based on chrome 110, which I ported to Vista.

https://blogs.opera.com/desktop/changelog-for-96/

"DNA-104390 Remove Windows 7, 8 support ..."

https://msfn.org/board/topic/184249-chrome-110-based-opera-i-ported-it-to-vista/

Link to comment
Share on other sites

7 hours ago, D.Draker said:

For those who were seeking "official" confirmation.

Opera finally admits they lied . After I pressured them ? I dunno.

A reminder : 96 is based on chrome 110, which I ported to Vista.

https://blogs.opera.com/desktop/changelog-for-96/

"DNA-104390 Remove Windows 7, 8 support ..."

https://msfn.org/board/topic/184249-chrome-110-based-opera-i-ported-it-to-vista/

All of your predictions seemed to be true. I would say I am dissapointed but I already had a bad gut feeling after you first told us about their lies. 

 

Well, then it is really up to these Forums here again to try fixing what Google and Microsoft try to destroy. How is it that they say "it is too hard to port things back to 7/8.1, since Google already removed their codes"' without even trying? They're just bad liars and never really attended to do so. 

Again, thanks @D.Draker @win32 and everyone, who participate in finding ways how to keep up using modern software on those OS. Great job guys

Link to comment
Share on other sites

25 minutes ago, yoltboy01 said:

How is it that they say "it is too hard to port things back to 7/8.1, since Google already removed their codes"' without even trying? They're just bad liars and never really attended to do so. 

That's why I don't rely on the developers' decisions when it comes to extending support for unsupported OSes. This is exactly the same scenario like that "Microsoft could extend Windows 7's ESU until 2026" article from gHacks, where Microsoft said they could, but they didn't.

Edited by mina7601
Link to comment
Share on other sites

On 1/20/2023 at 1:02 AM, D.Draker said:

and I'm against sharing it in public

On 1/21/2023 at 9:08 PM, alzcore397 said:

THANK YOU for saying this!! This is the option to keep the patching safe! Wish more people understood this and stop posting the guides.

Don't quite understand what do you mean.

Users of old OSes are already having problems with absense of security updates.

Adding closed source hacks makes this problem only worse.

 

Maybe you are talking about making patches open source only when they are completely ready?

Link to comment
Share on other sites

Chromium 112 is out now. Has anyone tried it on Windows 8.1 ?

 

EDIT: Just tried it out and it will no longer open up anymore. It gives me the error "DiscardVirtualMemory" couldn't be located in chrome.dll 

I looked that function up and it was introduced in Windows 8.1, so I quite don't get why that error pops up. Tried the same build out on Windows 11 and it worked

Edited by yoltboy01
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...