January 11, 20233 yr 2 minutes ago, mina7601 said: Very funny. I'm not surprised this happens though. agreed
January 11, 20233 yr 2 hours ago, legacyfan said: He definitely sounds like someone else I just dont know who So I am not the only one noticing.. if only I knew who does he remind me of
January 12, 20233 yr Nobody should name names! Let them step on their own tongues. The rest of us can decide for ourselves. Some people just get "bored" and find ways to "entertain themselves". The rest of us just need to learn to not let that "entertainment" be at 'our expense'.
January 12, 20233 yr Just now, NotHereToPlayGames said: Nobody should name names! Let them step on their own tongues. The rest of us can decide for ourselves. Some people just get "bored" and find ways to "entertain themselves". The rest of us just need to learn to not let that "entertainment" be at 'our expense'. sorry about that everyone lets get this back on topic again
January 12, 20233 yr On 1/9/2023 at 10:47 AM, Cocodile said: I'd even say, 110 crashes quite often, even with nosandbox. The last stable is 109. stable 109.0.5414.75 release came out Tuesday 1/10 forget about v110 & greater Edited January 12, 20233 yr by erpdude8
January 14, 20233 yr On 1/13/2023 at 12:49 AM, erpdude8 said: stable 109.0.5414.75 release came out Tuesday 1/10 forget about v110 & greater That's exactly what I've been saying ! Thnx !
January 17, 20233 yr 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: 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.
January 17, 20233 yr Author 3 hours ago, 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: 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. Dude I can't say it often enough: Your the best!
January 18, 20233 yr On 1/17/2023 at 8:40 PM, win32 said: This is sufficient to run the latest Chromium browser snapshot on Windows 8 Is this sufficient to run the latest Chromium browser on Windows 7 ? Thnx.
January 19, 20233 yr 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: 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. Man please explained it a bit more in details - how to patch these dlls files to get working chrome(ium) 110+ on win8.1?
January 19, 20233 yr 4 hours ago, x0xcdrx0x said: Man please explained it a bit more in details - how to patch these dlls files to get working chrome(ium) 110+ on win8.1? This method is also based on my discovery (from my ported Opera 96 on Chrome 110), and I'm against sharing it in public, I already told @win32 about it. Why ? Simply because you all could easily end up with nothing when the evil developers read this topic. Just wait for new kernel to be ready, you will all get it then ! Be patient . Besides, you ask about win 8.1, which is not being discussed here.
January 20, 20233 yr Keep an eye on the Catsxp browser, they have already ported the Chromium 110 Beta to Windows 7, so there is active effort to try to keep these systems going
January 21, 20233 yr On 1/20/2023 at 1:02 AM, D.Draker said: This method is also based on my discovery (from my ported Opera 96 on Chrome 110), and I'm against sharing it in public, I already told @win32 about it. Why ? Simply because you all could easily end up with nothing when the evil developers read this topic. Just wait for new kernel to be ready, you will all get it then ! Be patient . Besides, you ask about win 8.1, which is not being discussed here. we all wait to see what happens on the ESU February updates POS ready 7 @D.Draker THANK YOU for saying this!! This is the option to keep the patching safe! Wish more people understood this and stop posting the guides. We had the same issue back on 2020 with the old youtube layout code post public and some hidden developers keep seeing that and changing the code so that css stopped working very soon. @win32 thank you for your contribution and we looking forward for the patching files
January 21, 20233 yr On 1/17/2023 at 1: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: 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. thanks @Win32! your contributions to the community are always helpfull and I appreciate what you have done here keep up the good work! Edited January 22, 20233 yr by legacyfan
January 21, 20233 yr On 1/20/2023 at 4:09 PM, djole123 said: Keep an eye on the Catsxp browser, they have already ported the Chromium 110 Beta to Windows 7, so there is active effort to try to keep these systems going Why should we trust a Chinese browser tho?
Create an account or sign in to comment