IDA-RE-things / Chrome-xp-api-adapter

lighweight and fine-tuned unofficial alternative of progwrp.dll for Supermium/Thorium browsers, running on XP
11 stars 0 forks source link

Supermium 124.0.6367.245 R2 became incompatible to progwrp 1.2.0.5067 #20

Open JoachimHenze opened 2 months ago

JoachimHenze commented 2 months ago

The fresh release of "Supermium 124.0.6367.245 R2" https://github.com/win32ss/supermium/releases/tag/v124-r2 released on 2024-08-19 is no longer compatible to @ida-re-things progwrp 1.2.0.5067.

The browser still launches like that, but as soon as I do browse any website, it will show the content for a fraction of a second and then the tab will die with STATUS_ACCESS_VIOLATION, e.g. when browsing: https://github.com/IDA-RE-things/Chrome-xp-api-adapter or www.google.de

This bug does not happen when using the stock shipped progwrp.dll 1.1.0.5018 from win32ss.

But the ida-re-things-version 1.2.0.5067 does still offer slightly superior TLS for me.

IDA-RE-things commented 2 months ago

Ok, I will check whats happened. I tryed latest 124-r2, but switched back to previous 124, which works for me while :)

124-r2 works for me with my lib for above test url's, but fails on other url : https://chromewebstore.google.com/

IDA-RE-things commented 2 months ago

UPD: I checked my crashdump, I see it uses now Microsoft DWrite.dll, patched to use custom emulation libs by ShaneFourier, and fails in function chrome.dll!blink::WebFontTypefaceFactory::CreateTypeface().

So its no so simple to fix this problem (downt know from where it) and dont have time to deep investigation. I'm busy with other projects. So sorry, I continue to use previous 124 release, which works.

Moreover, 124-r2 also fails on some pictures (so old bugs stay here).

May be I will investigate it, when some (dont know which feature will be added/fixed in Chromium/Supermium so I will really need to upgrade to it).

JoachimHenze commented 2 months ago

My motivation to give 124r2 a shot was that https://github.com/IDA-RE-things/Chrome-xp-api-adapter/issues/15 is finally fixed with with that (confirmed!).

Ultimately I did also decide to stick with 124r1 for now to be able to keep using your 1.2.0.5067, because your fine TLS and synchronization API implementation is more important to me than the small fixes in 124r2. You do still outperform @win32ss with that.

But I do assume, that sooner or later the motivation for updating will get stronger.

IDA-RE-things commented 2 months ago

UPD: I have found a way how to join my adapter dll's with a v124-r2 fix. To do it, install "v124-r2", Then remove dll's by Shane Fourier (near chrome.exe ): (or move them to backup directory)

d3dcompiler_47.dll
DWrite.dll
pwp_shl.dll
pwrp_k32.dll
p_advp32.dll
p_ole.dll
progwrp.dll

Instead of its, place here my libs from my distributive:

chrome-xpapi-adapter.dll
D3DCompiler_XP.dll
progwrp.dll 

This variant works on my machine fine and uses fix for #15 . (I'm now write this post from such config) DWrite.dll for fonts in such case is not used.

JoachimHenze commented 2 months ago

Yes, I do confirm that this works for me as well. I do keep the fix for #15 like that, and I do keep also the sharp GDI font rendering like that. Perfect. Thank you for that small hack. Very much appreciated!

Vangelis66 commented 2 months ago

DWrite.dll for fonts in such case is not used.

... For me, under Windows Vista SP2 32-bit (on old H/W), this was the main motivation to upgrade to 124-r2; win32ss went into the trouble of backporting Win10-level DirectWrite down to Vista SP2 (which has an immature/crippled DW implementation) and XP SP3 (has no DW at all), see below:

https://www.patreon.com/posts/microsoft-made-7-108443697

https://github.com/win32ss/supermium/discussions/696#discussioncomment-10098269

Vista's own DW is deficient in many ways today (e.g. doesn't decode several web fonts, such as FontAwesome) and a forced fallback to Vista's GDI font rendering leaves much to be desired (my view, anyway :wink: ) ; plus, with GDI or Vista's DW I'm unable to print from the Sm/Th browsers :sob: (unless I disable the browser's sandbox) ...

Until a new set of DLLs is being developed to work with DWrite.dll, I'm gonna have to return to the "official" progwrp.dll lib going forward with Sm-124-r2 and the imminent Sm-126 releases; many thanks for what you've accomplished already towards NT 6.0 support on old/poor hardware - it has been greatly appreciated :heart: ...

Kind regards :smile: .

IDA-RE-things commented 2 months ago

UPD: I spent a 2 days and now my code also supports loading of above patched DWrite.dll (I have not uploaded the adapter while, its in testing on my machine).

But when browser starts (even with original progwrp), it encounters Heap Corruption from calls inside DWrite.dll (which is visible under debugger).

I have created bug-report for this : https://github.com/win32ss/supermium/issues/820

Vangelis66 commented 1 month ago

Greetings :smile:

Upstream #820 has been closed (fixed in Sm-126-pre); upstream #855 has also been closed (fixed in Sm-126-r1); will you be finally moving to a public release of your alternate libs? I'll also appreciate it dearly if the "Vista" (x86 on old H/W) compatible edition of your libs is also updated :wink: ...

Best of wishes :smile: !

IDA-RE-things commented 1 month ago

yes, I know that DWrite.dll was fixed. But I can't work with my real profile with any of browser versions (v122, v124, v126) due to OutOfMemory problem: https://github.com/win32ss/supermium/issues/846 My internal version currently fully compatible with v126 (while testing on XP), but I have not uploaded it while OutOfMemory problem exist inside the Browser. Compatibility with Vista/Win7 not tested while (I think should be also compatible).

Vangelis66 commented 1 month ago

... Thanks for providing this update of how things stand currently :+1: :heart: ; I can only hope and pray most/all coding hurdles are somehow surpassed, eventually :wink: ; grateful for your ongoing efforts :1st_place_medal: ...

IDA-RE-things commented 1 month ago

Its done now, optimized, and uploaded finally. You should check how fine it works on Vista. I checked it only on XP/Win7.

xixhub commented 1 month ago

XP SP3 Supermium 124.0.6367.245 R2

I am using your latest version _chrome-xpapi-adapterx86.b5073-wD3D9accel. Everything works fine, but there is a question: Why is the file FontSet-v3.dat created here C:\Documents and Settings\User\Local Settings\Application Data\DWriteCore\ ? Is it some kind of cache of all fonts in the system? This file is not created on standard dll's by win32ss

IDA-RE-things commented 1 month ago

the main DWrite.dll are nearly same. Except it uses my support libs. FontSet-v3.dat is created by DWrite.dll. Yes, this is some type of cache of fonts, installed in system. And its also created by default dll's, distributed with browser. On my machine it has same behavour. If on you machine it dont creates FontSet-v3.dat, then it has problem with loading of DLL.