mjd79

It's now a question for users whether ungoogled or Vista support is more of a priority. My computer can take more than 24 hours for one compilation. Unfortunately, in the previous system installation and previous software setup, I made such a mess of things with the trial-and-error method (and doing some things at my own discretion, not how the tutorials dictate) that something went wrong during compilation. This time I found much better tutorials and have experience from the previous tries. Compiling Chromium in theory is very simple, but very many things can go wrong. Now I downloading the entire repository with every possible version from the main branch. You can also fetch with the command -gclient sync --revision src@137.0.7116.0.

I have just managed to start compiling for now a clean Chromium 137.0.7116.0 without any patches, just to be sure that no problems will occur. If successful, my intention is to apply all the patches from https://github.com/e3kskoy7wqk/Chromium-for-windows-7/tree/main/137.0.7116.0 and restore Vista and 7 SP0 compatibility, and 32 and 64 bit versions using https://github.com/Chuyu-Team/YY-Thunks/ - what the author of Chromium for Windows 7 does not intend to continue for some reason, despite the fact that it is the simplest and very well working solution.

It seems that yes, chrome.dll is already 270mb....

Ok, so now it's time for specifics and evidence. I'll start with v135 ungoogled and v137 on Windows Vista SP2 x64 (update level 2017.04 - final). Let's start with what extended kernel files can be redirected locally (v2023-03-09 rev2). Most except ntdll.dll, bcrypt.dll, and kernel32.dll. Included in this version is kernel33.dll, and it is this that should be used by renaming it to kernel32.dll. Then paste that below into notepad, save it as a file with a .reg extension and add it to the registry. This turns on the ability to redirect DLLs locally. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options] "DevOverrideEnable"=dword:00000001 Just create a folder chrome.exe.local in the folder with it and copy these files. Now, using CFF Explorer, change the NtOpenKeyEx import in chrome_elf.dll to NtOpenKey (thanks to D.Draker for the hint) On some graphics cards with very old drivers supporting, for example, only DX9, the GPU sandbox may crash. In this case, create a shortcut to chrome.exe and add --disable-gpu-sandbox. In chrome://flags set "Choose ANGLE graphics" backend to D3D9, from now on the browser should work correctly without this flag. Now I'll move on to 7 SP0, in which it turns out. you need advapi32.dll from Vista's extended kernel or from Supermium 132 (it's called p_advp32.dll there) In the first case (x64 only), use CFF Explorer to replace the import from RPCRT4.dll I_RpcBindingIsServerLocal with I_RpcBindingIsClientLocal. Then open chrome.dll in HxD, for example, and search for advapi32.dll. You will find it in two places, change it to e.g. advapi33.dll and save. In the same way, of course, name the file from Vista ext kernel/Supermium. That's it, the browser should work fine. I also recommend adding this to the registry so that non-ungoogled versions don't disable MV2 extensions on their own, and so that they can be added from the Chrome Web Store. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Chromium] "ExtensionManifestV2Availability"=dword:00000002 Screen confirming disabling client hint working in one of the previous posts, this one would be too long.

NtOpenKey without the "Ex" appended was enough. shell32 you mentioned and most other libraries I redirected locally from the extended kernel of March 9, 2023 (rev2). It is not possible according to what I have determined for now to redirect bcrypt.dll and ntdll.dll, kernel32.dll, which is a wrapper for Chromium 110 and 111 support does not work, probably due to lack of platform updates, however, there is also kernel33.dll in the files, which is the original kernel last modified by win32ss in December, 2022, and it works with ungoogled 135 and Chromium 137 without problems. My Vista update level is end of April 2017, no post-eol updates.

I am using this library for now for personal use and temporarily. I will try to use advapi32 from SP1 Absolutely zero success, even though advapi with SP1 does not lack dependencies in SP0. BTW I forgot to mention, but in v137 the flag to disable clients hints actually worked, including on Vista. Besides, every time I use these libraries, I mention that they come from Supermium. And the fact that I use them to run other, better browsers at the moment, is just my business. As long as I don't create ready-made mods and make its libraries available with them (no, I won't do that, I will prepare simple tutorials at most)

The good news is that I've already run ungoogled 135 and the latest 137 on Vista SP2 x64 (without the 2019 platform update BTW), with some March 9, 2023 extended kernel files redirected locally. On 7 SP0 the problem at least for ungoogled 135 appeared to be with advapi32, I will also check if it can be transferred from SP1 without too much trouble, or if you will have to use the wrapper included in Supermium. I'll show the screenshots later For now I'm also talking only about x64 versions, in Vista Extended Kernel there are unfortunately only wow64 files and not for x86, in addition, mostly flawed. On 7 SP0 it should be possible to run any combination.

@D.Draker, I already know what break ungoogled Chromium 135 and Chromium 137 by Chinese stundent on 7 SP0. It's ADVAPI32.dll, I temporarily used the whole library from Supermium, but in a day I'll check which specific function is responsible for it. On Vista x64 SP2 it should be possible to run these browsers with an extended kernel redirected locally, as long as the “ntext.dll” file created a few years ago by win32ss is enough to replace ntdll.dll.

Unfortunately, as you probably already saw in the relevant topic, it will not support Vista. I checked the version for 7 SP1 on 7 SP0 out of curiosity, the browser takes a suspiciously long time to start and I get a STATUS_BREAKPOINT error on every tab. I, unfortunately, do not have the skills or a sufficiently powerful computer to be able to compile his browser with the design that helped him maintain Vista compatibility, but perhaps there is a suitable person on the forum. On 7 SP0 it is probably possible to solve this problem, I checked much older compilations of the Chinese student, and its run without this problem.

I am not against this project, I would like to see it develop, and get to as good a level as the “Chinese student” fork, but since the man just mentioned solved the problems with memory usage and more, the more the author of Supermium can do it. In my opinion, Supermium should be created completely from scratch, and in two versions. The first for Vista (without the extended kernel) all the way up to 11, and the second for XP, containing all the necessary features in system library wrappers, OCA-style, which runs successfully the same version of Chromium that Supermium supposedly is, only without the sandbox for now.

After thinking about what you wrote, I have a conclusion - how is it that super-duper prominent authors of forks like Supermium or Thorium are not able to determine what causes such high memory usage/errors associated with it on some sites, and it was reached by an MSFN user, who, in addition, does not work with the source code, but already compiled browser?

It is up to D.Draker to whom he makes this method available. I received it in a private message for a reason, probably one that he doesn't want it available to the public.

BTW the memory related functions that D.Draker recommended to me instead of VirtualAlloc make the memory usage of Chrome 130 on Windows 8.1 no different than the latest official v109 for 8.1. However, this is what I won't make public, unlike my previous findings, because this would 100% used by win32ss in Supermium or Blaukovitch in his backports without any credit.

Only on the 8.1, so it won't help much him. Besides, Supermium 132 contains working with sandbox implementation of UpdateProcThreadAttribute, which I used (I didn't use the whole wrapper, but only one function) In general, I suspect that if you remove in Supermium 132 R2 --no-sandbox from the flags added during compilation, it would run on 8.1 without a problem

Blaukovitch versions in my humble opinion.... at least they are not worth trusting. They were once proven to connect to Russian IPs, which the normal versions of these browsers do not have. On top of that, he still hasn't fixed the VirtualAlloc bug in x64 versions (which, unlike the author of Supermium, he knows how to at least openly admit) The author of Chromium for Windows 7 is also creating a fork of Firefox https://github.com/e3kskoy7wqk/Firefox-for-windows-7/releases/tag/137.0 which, unlike r3dfox, is almost the original, with only the old code restored.

The artificial blockade is probably possible to remove. I was able to get around the artificial lock on older versions of Zoom and Google Drive v68 (Win 7) and v79 (8.1) by simply replacing the version number with a newer one in the relevant files. I will try to check it out.

Being honest, I never trusted Supermium, Thorium, Blaukovitch crack, etc. I preferred to use unsupported Chrome 109 rather than think about it. v109 will be 30 versions older than the latest in a few months, I noticed a few years ago that this is the upper limit for Chromium, where browsers start to have the first serious problems with javascript. Also some of the extensions in the latest versions don't work for me anymore, fortunately I have my archive of MV2 extensions, updated from time to time. That's why I'm looking for an alternative, and I think for the time being it will be my own modded Google Chrome version of at least 130, in which I will know 100% myself what I've changed (basically I've figured out what I've changed in the hex in chrome.dll via decompiled IDA code)

That's why under 8.1 and 8.0 I create my own alternative based on his browsers. It's already very difficult on 7, but with how many VxKex forks have been created, and it's not clear which one to trust, I'll look into that too. Aome versions of VxKex run Chromium up to 136 without modification BTW. If I can at least port Chrome 130 to Windows 7, it will also work on Vista with the extended kernel. But Vista without ext kernel will left with versions of “Chinese student” which isn't bad at all, on vanilla Vista SP2 its 136 x86 version seems to be very fast and stable.

All along I thought that VirtualAlloc itself should be replaced. I'll check it out right away. Thanks

Despite the backported DWrite and the platform update (which is required by ext kernel), I have not been able to run anything beyond Chromium 111.0.5550 probably.

I tried, in place of VirtualAlloc in the kernel32 import table I can't fit this function (too long name), and redirecting it in the original kernel I use for Chromium on 8.1 causes an error in ntdll, which is very strange... BTW Memory usage alone does not seem to be an issue in 8.1, with the same number of tabs with the same pages the v130 uses a similar amount of memory to Chrome 109 on Win7. The bigger problem is with virtual memory, after some time, such as an hour of using the browser suddenly starts to occupy all the virtual memory.

I have no idea, Chrome 125 failed to run even with the 9th March 2023 extended kernel, so does your version run with or without it? Unfortunately, it is not possible to redirect ntdll locally, so if the extended kernel is required, it is impossible to avoid installing it.

I found a “solution” based on Blaukovitch's crack. It turns out that all it takes is to change a few bytes in chrome.dll (unfortunately, completely different in each Chromium-based browser and in other versions) and the original Chrome 130 works, including the sandbox fixed by my method described above. @D.Draker, could you check this with v127 on Vista? For Chrome (not Chromium, etc) 127.0.6533.73 x64, just replace offset 621D030 in chrome.dll with: B8 10 00 00 00 C3 90 48 8B 05 02 E6 8B 06 48 31. Also need to binary change the import in chrome.dll to API-MS-WIN-CORE-REALTIME-L1-1-0.dll and remove the "precise" addition from the QueryUnbiasedInterruptTimePrecise function. It's still not a complete success as I don't fully understand what I'm changing, hence I'm not able to port it to anything other than an identical version of Chrome.

I finally got to what's messing up the Chromium 110-126 sandbox on Windows 8.1, and it's the UpdateProcThreadAttribute feature. When I redirected it in the original kernel32.dll to the pwrp_k32.dll included in Supermium 132 R2, the sandbox started working. Just find a 100% sure solution to the RAM and virtual memory usage problems, and you will be able to use any Chromium-based browser (except Edge) up to version 126. I still don't know what is causing the problem with Chromium 127 and newer preventing the browser from running. And fixing the sandbox in version 126 is just a milestone. It is 17 versions higher than 109, but it is also 9 versions older than the latest official Google Chrome.... If anyone knows how to debug, I would greatly appreciate your help. All I know is that the problem is definitely in chrome.dll. 126 also worked on 8.0, but the sandbox after the repair still does not work, the browser starts up, but with the error SBOX_FATAL_CLOSEHANDLES, and does not display any page, of course.

The topic is about Win 8.1, but since there is no separate one for 8.0 I am posting the information here, it also works after very similar modifications (even GetSystemTimes is not missing, although this 8.0 is RTM without any updates, and 8.1 I use updated to the end of 2017)