How to find out if Supermium is using the new version of DirectWrite and not GDI or an older DirectWrite?

[SleakaJ]

As per the latest update 124.0.6367.245 R2 "DirectWriteCore now bundled with Supermium, as well as Noto Color Emoji" with the requirement of "VC++ 2015 runtime needed to use this version of DirectWrite, or else it will fall back to GDI or older DirectWrite".

I installed VC++ 2015 on my XP system and my emoji are still greyscale in Supermium. Is there a flag or something I need to enable? How do I find out if it's using GDI? GDI fonts in chrome://flags is disabled.

Edit: Ok, got colour emoji working. Had to use 7zip to unzip the installer and copy the NotoEmoji.ttf font manually to the Windows\Fonts folder. The EXE installation doesn't seem to want to overwrite the original greyscale NotoEmoji.ttf file. Once I'd deleted the older greyscale NotoEmoji.tff file from the Fonts folder, colour emoji now appears properly in Supermium. Original question still remains though.

[Vangelis66]

Original question still remains though.

My OS is Windows Vista SP2 32-bit, fully updated until its EoS; I'm using Supermium-v124-r2-x86

With the browser exited, one can use a tool such as DependencyWalker (use the x64 variant if you happen to be on a 64-bit OS 😉 ) and then probe Supermium's main EXE (chrome.exe) with the tool; if in the dependency tree you see proof that the local DWrite.dll file is being correctly loaded, then the conditions/prerequisites to use win32ss's DWrite implementation are being satisfied:

If, OTOH, one or more dependencies for the local DWrite.dll file are missing, DepWalker will tell you so, by marking those with a yellow circle with a (?) inside it; if the local DWrite.dll file is somehow AWOL, then DepWalker will show that chrome.exe will load its stock OS equivalent from within system32 (where available); same will happen at runtime when the local variant can't be properly loaded...

My analysis here tells that on a fully updated Vista/7/8/8.1 OS, no issue should occur and that the MSVC++2015-2019 installation step can be omitted - this is really a WinXP thing, because it a) doesn't come with an OS DWrite implementation (Vista SP2+) b) doesn't come with Win10 UCRT as a MS Update...

[Ravenant1234]

So even if I had VC++ 2015-2019 I still need win 10 UCRT update to properly function on win7?

[Vangelis66]

Read again:

on a fully updated Vista/7/8/8.1 OS, no issue should occur and that the MSVC++2015-2019 installation step can be omitted - this is really a WinXP thing, because it a) doesn't come with an OS DWrite implementation (Vista SP2+) b) doesn't come with Win10 UCRT as a MS Update...

"VC++ 2015-2019" is used as a "vehicle" to install (system-wide) Win10 UCRT on WinXP SP3 systems; if you have previously installed VC++ 2015-2019 on your Win7 SP1 system for whatever other reason (other programs having it as a dependency), then you should leave it installed; the last WinXP-compatible version of the redistributable (v14.28.29213.0) does bundle Win10 UCRT as DLLs, but versions after v14.29.30024.0 (which continue to be Win7 SP1 compatible) do not; they instead bundle the KB (Windows6.1-KB2999226-x86.msu/Windows6.1-KB2999226-x64.msu) that installs Win10 UCRT on Win7 SP1, if it hasn't been installed already via Windows Update and/or manually...
Tl;DR:
On a properly/fully updated Win7 SP1 OS, Win10 UCRT should be already present system-wide (irrespective of the MSVC++ runtimes installed).

[Ravenant1234]

ok thanks!