Support newer Windows

[narinishi]

Supermium still depends on progwrp for newer versions of Windows, such as 8.1. I would like to be able to use your alternate library.

[IDA-RE-things]

I'm working in that direction.
But you can't see differenses in execution or speed.
Except that it will be significantly smaller in size.

[IDA-RE-things]

Its done, and ready for testing.
You can download in releases.

[narinishi]

Works great. Thanks for including x64 version.

[Vangelis66]

@IDA-RE-things :

Many thanks for your efforts 👍 ; I'm quoting you from the v1.2.0.5048 Release Notes:

UPD: (2024.05.16) : now also available "API redirector" for Win7+ systems (x86, x64), -- as separate archive -- which just redirects API's to system dll's as it do original DLL for this OS'es. But has smaller size and has no other init code (as side effect also small speedup). No other differences in behaviour. (#9)

My old laptop comes with Windows Vista SP2 32-bit, was bought in 2008 and has rather under-resourced specs 😞 by today's standards:

CPU: Intel Core 2 Duo T5250 @1.50Ghz (SSSE3)
iGPU: Mobile Intel 365 Express Chipset Family
RAM: 3GB DDR2 (was initially 2GB)

win32ss's progwrp.dll (32-bit) works, but I was wondering whether I could profit from your own, optimised for older OS & H/W, DLL; do you plan on supporting Vista SP2 x86 ? On XP+ and with v1.2.0.5048+, does one still need BOTH DLLs inside your released archive (and rename one as instructed in the readme.txt) ?

Thanks in advance for any insight/guidance 😄 ...

[IDA-RE-things]

Hello,
About Vista x86. - its possible, but will no advantage in speedup. Because original also redirects almost APIs to system dll's
If I will done this, it will be like the variant for Win7+. But will requere more work to setup virtual machine etc to check if it works fine.

On XP+ and with v1.2.0.5048+, does one still need BOTH DLLs inside your released archive (and rename one as instructed in the readme.txt

yes, now its divided to 2 components, The instructions, which file should be ranamed to replace original is inside archive.

[Vangelis66]

Thanks for your reply 😄

but with no advantage in speedup.

... How can you be so certain?
Sadly, Supermium-x86 here launches very slowly, especially from a "cold start"; I just updated to its latest release (R5) and this one takes even longer to launch (had the R2 release before, as I had skipped R4 😜 )

In your original reply, you advised:

Stay with original DLL for this OS.

I don't have any choice, do I? Versions of your DLL prior to v1.2.0.5043 DON'T work 😢 here for Vista SP2 x86, while versions after that include a hard block for the OS... I do hope, when you find the spare time and needed resources (Vista VMs etc.), you come up with something equally useful for under-resourced Vista machines as you have done already for the XP SP3 x86 ones 😄 ...

Best wishes.

[IDA-RE-things]

So are you using HDD? I thought you were using an SSD drive in Vista, so I said there would be no acceleration.
Everything in the XP version is cutted down, and running it on Win Vista+ would lack hardware video acceleration. Its because I cutted it at all.

Ok, I will think about what to do with this.

Yes, I will try to do this for x86 systems, not only XP, but also Vista and Win7,
but it will use XP-compatible API's
and will no lack hardware acceleration.
I think will be available soon.

[IDA-RE-things]

UPD: seems as worked when running x86 over Win7 x64.
so should work with Vista x86 also.
hardware acceleration looks as available, refering to chrome://gpu properties.

Will build it and upload soon.

[Vangelis66]

So are you using HDD?

... Yes 😉 ; the laptop (Toshiba) came in 2008 with a 128GB HDD, but in 2016 it was cloned/migrated to a 500GB one, which I'm using to this day; two partitions, C+D, with the OS living on the C partition (155GB) ...

I thought you were using an SSD drive in Vista

FYI, SSDs are to be avoided on Vista, because the OS lacks native utilities to successfully trim SSDs (payware apps do exist):

https://msfn.org/board/topic/180893-ssd-for-vista/
https://msfn.org/board/topic/182915-windows-vista-ssd-care-tips/
https://msfn.org/board/topic/182189-vista-is-probably-destroying-my-ssd/
https://msfn.org/board/topic/182109-windows-vista-modernisation-guide/

and running it on Win Vista+ would lack hardware video acceleration.

My iGPU (Mobile Intel 365 Express Chipset Family) with its Toshiba custom driver is already blacklisted by latest Supermium/Thorium:

If I force GPU via --ignore-gpu-blocklist, this is how things look:

seems as worked when running x86 over Win7 x64.
so should work with Vista x86 also.

Vista SP2 != Win7 SP1 ; I would advise you not to rush things and, for good measure, test/verify on Vista itself 😉 ; I'm under the impression "upstream" lib (progwrp.dll) treats Vista differently compared to Win7, isn't that so?

In any case, if it can be done, there's no need to rush it - if it can't be done, then I'm fine with that, too 😜 ; thanks for your precious coding time 😄 ...

[IDA-RE-things]

It works same with my alternative, because for API I use XP-compatible mode here. All NT6-specific APIs are emulated (including Vista).
The original redirects all APIs directly to system DLLs, except 1 function for Vista (or may be another few, having stubs).
In any case now all works fine and same. No more complex implementation needed at this time as I see.

PS: Are you alrerady trying latest build 5049 to compare ?

[Vangelis66]

Will build it and upload soon.

PS: Are you alrerady trying latest build 5049 to compare ?

... I just finished testing your latest release, v1.2.0.5049, on latest Supermium R5 x86 and I'm sad to report that I was met with failure 😿 ...

I'm actually using the portable PAF distribution from

https://portableapps.com/apps/internet/supermium-portable

so chrome.exe is invoked indirectly via the launcher SupermiumPortable.exe; upstream progwrp.dll-v1.1.0.5010 works as expected under this scenario, however when your latest 1.2.0.5049 binaries are being used in its place:

only one chrome.exe process appears inside the Task Manager and nothing more (no GUI is loaded, etc.) ; I have to kill both chrome.exe and SupermiumPortable.exe manually in TM to end this; will revert to the original implementation...

Thanks anyway...

[IDA-RE-things]

Hm.... thats bad.
Ok, I will check whats happened.

[IDA-RE-things]

Try todays build 5051. Now should work. I have tested it (for running) on Vista VM.
Check how it works on real hardware.

[Stepman123]

The Windows 7 version now runs on One Core API Server 2003 x86. Supermium 122.0.6261.152 (R5)

[IDA-RE-things]

Stepman123,
Its cool. I think you are about that version, which I created to just redirect API's (named Win7+),
because another version also now runs on Win7, but emulates Win7 API by XP-only API.

[Stepman123]

(named Win7+)

Yes, that's it.

[Vangelis66]

Try todays build 5051. Now should work.
I have tested it (for running) on Vista VM.
Check how it works on real hardware.

... v1.2.0.5051 (x86) "installed" correctly:

Launching SupermiumPortable.exe (which itself invokes .\App\Supermium32\chrome.exe ) here, with default parameters and on a new/fresh profile, now spawns a Supermium empty window with no top GUI, like below:

which stays on screen for 2-4secs and then auto-closes 😭 ... FWIW, with these new DLLs of yours I don't get hanged chrome.exe+SupermiumPortable.exe processes inside Task Manager...

I don't think I should pursue this any more; it'll be a waste of your precious time 😜 ; I'm glad that win32ss's solution just works and I'll have to move on with that:

Thanks for trying though, take good care 😄 !

[IDA-RE-things]

Hi, I tested it for running on VM (VirtualPC 2007), but with test set of switches and without portable runner. Thats what I have:

---

---

Ok, I wil check it with portable runner and without any switches, If it dont works with it.

I have no time for testing if with all possible environments, thats sorry. :) The user, which really need it, should help with it. Same was with Win2003 srv, which not runned from initial build and was requered 2-3 iterations. Its because initially was intened for XP SP3 only.

[IDA-RE-things]

UPD: yes, It closes, when running without any switches, So I will work more to investigate whats happened.

[IDA-RE-things]

I found that the difference is: I use --no-sandbox switch in my config. You can also try this switch with that existing build (but I dont know how to add it to that portable runner). I have running it from batch file (.cmd) with switches.
no-sanbox helps now.
I will do more inverstigation later, why it dont want to work with sandbox, but now you can try to use it.
May be something else happens.

[IDA-RE-things]

Have uploaded new build. Yes, for Vista/Win7 it requeres --no-sandbox switch in commandline to run.
Other OS'es not reque this switch.
I think its not a much price for speeding up the launch, especially cold start on HDD

[Vangelis66]

...It's very late at night in my timezone, however:

1. Thanks a lot for your continuous work on this (and especially for Vista SP2 32-bit)

2. (but I dont know how to add it to that portable runner).

Adjacent to the PortableSupermium.exe launcher, you should have a folder named "Other"; inside of it, a subfolder named "Source"; copy the file AppNamePortable.ini and place it adjacent to the launcher file, i.e. PortableSupermium.exe; rename the ".INI" to SupermiumPortable.ini (same filename as the portable launcher);
open the renamed INI with your text editor; add your custom cmdline launch switches in the "AdditionalParameters=" line 😉 :

AdditionalParameters=--no-sandbox
DisableSplashScreen=false
RunLocally=false

# The above options are explained in the included readme.txt
# This INI file is an example only and is not used unless it is placed as described in the included readme.txt

3. --no-sanbox helps now.

I did a quick test with latest v1.2.0.5052 and the --no-sandbox cmdline switch:

On a clean/fresh profile, latest Supermium (R5) did launch and stayed open, but:

1. The window caption buttons are absent - remember, I have aero enabled on Vista, this isn't XP 😉
2. Most webpages FAIL to load, the browser citing a "Page Unresponsive" error:

BTW, I did not try to install any extension from the CWS...

When I tried to launch my default/"dirty" profile, it was a complete mess; the session tabs failed to load, the browser kept generating messages/notifications about tabs crashing and, most importantly, extensions crashing (practically all of them); I felt despaired, to be frank 😞 ...

While I do have faith in you 😄 , all I can tell you is I feel it's still a long way from final success in the (my?) case here...

for Vista/Win7 it requeres --no-sandbox switch in commandline to run.

While that flag was also needed in the initial releases of Supermium for Win7, it's no longer a prerequisite even on XP with the original progwrp.dll - personally, I'd still prefer to have a sandboxed browser than one without it, seeing I'm running an OS no longer patched (same case as with XP/Win7/8/8.1) ...

I will do more inverstigation later, why it dont want to work with sandbox,

... Take your time, but please do (investigate...) 😜

... Hitting bed now, finally...

[IDA-RE-things]

While I do have faith in you 😄 , all I can tell you is I feel it's still a long way from final success in the (my?) case here...

The success was only "speed and size", in my case, and on XP (Even by "excluding some spare parts of that car"). Initially I dont planned another :) . It was only for me.

It seem like more good solution will be to provide another separate version for Vista/Win7, or emulate less API's by XP-compatible calls, which will have almost all API's, redirected to original DLL's. (as original progwrp do same). Because in current variant all calls emulated by XP-compatible API's. It works on my config, But of course not for all configs, as your one.

I also dont have real Aero inside VM to check if it really works with aero (And I not using it anywhere). May be it depends on Video-adapter inside VM.

I'm do investigating it more in such case.

When I tried to launch my default/"dirty" profile, it was a complete mess;

I'm do testing of it only on special test profile, with --user-data-dir switch, to prevent profile corruption etc, while it not works successfully. And only if it works fine, I'm do it with real profile... This fueature is "under development" state as you understand. So dont risk by real profile direct.

But I also checked that it opens pages, of cource, before uploading it. It was ok. May be Aero calls to this mess.. may be some another.

[IDA-RE-things]

Im now investigating whats happened with sandbox under Win7 with my implementation.
And after that , when its done, will check Aero.

Take your time, but please do (investigate...)

Its right.

[IDA-RE-things]

I have a good news. Done large work by hands. And now it works with Aero and with sandbox enabled on Win7 & Vista.
I have tested it on real Win7 with Aero enabled, and Vista VM.
But on Vista VM just for running and simple browsing, because under VM it slow here sometime (same with original DLL), only 1 processor in VM and graphics w/o acceleration.
Also have checked that it works with above portable runner - all ok.
So I think should work fine. But requeres more testing of course.

Note that my implementation uses most APIs emulated here by XP APIs, or stubs (as for XP native version), in contrast to original lib, which just redirects its to system libs for NT6.

And check it on test profile, before running with a real profile to prevent above accident :)

[IDA-RE-things]

Hello, @Vangelis66.

I have found that on my 1st test machine with Win7, the Aero interface was not functioning properly,
becasue I changed at past, theme API dll with 3rd party utility, to support XP-compatible themes.
And now I have tested it with real Aero interface on second Win7 machine, and have detected that yes, was a little bug in redirecting of few "aero theme api" -related functions,
Now I have fixed it and uploaded fixed variant. 5056. Ony 1 file changed, related to Vista+ API redirection.

Now it looks like this:

You can try how it works.

[Vangelis66]

Hi @IDA-RE-things 😄 , hope you're well...
Sadly, some health issues 😞 had prevented me from continuing my tests with your updated releases these past days; however, over this weekend I did resume my testing 😜 ...

I have now upgraded to the most current Supermium 32-bit release, 122.0.6261.152-R6; this one uses the upstream/official lib progwrp.dll-v1.1.0.5012.

My default "dirty" Supermium profile with lots of customisations 😉 in the form of cmdline switches and internal chrome://flags, plus a number of installed extensions, works as it should 👍 ...

Now I have fixed it and uploaded fixed variant. 5056. Ony 1 file changed, related to Vista+ API redirection.

... and in your Release Notes:

NOTE 3: Vista users should stay with build 5056, while no other changes made for Vista.

Thus, indeed, I only tested with v1.2.0.5056 of your lib (i.e. just the two DLLs, renamed as instructed in the readme.txt file inside the distribution) ...

Well, I have mixed results to report:

1. Launching a fresh/new Supermium profile with your provided libs works as expected under my setup of Vista SP2 32-bit - all errors that I reported previously with regards to a clean profile have been FIXED! Many thanks! 👍 ; below a screengrab in Dark Mode:

2. I then made a backup of my dirty profile (as a precaution) and then launched Supermium with your 1.2.0.5056 libs; I was met with failures 😭 ...

a. As the browser was loading, most extensions crashed:

b. As the browser was loading, internal (chrome://*) and normal tabs, pinned or not, CRASHED:

c. Trying to reload a crashed tab was to no avail (Error Code: STATUS_BREAKPOINT):

... After my initial frustration, it became clear to me that these failures on my dirty profile were due to either

1. one (or more) of my custom cmdline arguments Supermium is being launched with,
2. one (or more) of internal flags I have toggled during my customisation of the browser, or
3. one (or more) of the already installed Chrome extensions (or, possibly, one of their settings) ...

Needless to say, troubleshooting and actual discovery of the culprit(s) took many nerve-wrecking trial-and-error attempts 😠 , which itself took many hours 😞 ...

To cut a (very) long story short, the actual culprit was internal flag

chrome://flags/#enable-future-v8-vm-features (toggled to Enabled)
or its cmdline equivalent
--enable-features=V8VmFuture

I had enabled that flag to "squeeze more" out of Supermium's V8 JS engine (bring it on par with Chrome 125 ?), but this experimental custom flag is the one that is incompatible with build5056 of your libs 😿 ; to use your libs, I have to leave that flag at "default" (or disable it) - that culprit flag works as expected with the official lib, though...

If you have some spare time, could you please investigate why #enable-future-v8-vm-features breaks Sm when using your 5056 DLLs under Vista SP2?

Many thanks already, you have done a great job for people on older H/W; and yes, Sm does indeed load somewhat quicker here with your libs compared to the official implementation (progwrp.dll) 👍 ...

Kindest regards 😃

PS: While I'm running the browser in "portable" mode, I did notice that your libs write to the registry:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Chrome-xpapi-adapter]
"NumOfActiveWakeLocks"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Progwrp]
"NumberActiveWakeLocks"=dword:00000000

Is this absolutely necessary?

[IDA-RE-things]

Hello, glad to see.

I did notice that your libs write to the registry

the registry approach was selected to support inter-process "Screen Saver running prevention" feature, by Power-saving routines. whish are absent on XP and Vista.
When user playing videos on pages.

And about the errors with your "dirty profile"... Yes, seems that some functions called where was stub breakpoints, set by me.
Because of using several "nonstandard" flags, Its normal and expected, and I will fix this, If I will reproduce.
Its pay for reducing of non-execuded code size, which was not executed in "normal" situations :).
I will investigate why it crashes with #enable-future-v8-vm-features.
But if it was cause by something else, then it will help do it more quickly, if you attach here crashdumps, if you can, found in \reports\ directory of profile.

[IDA-RE-things]

UPD: have fixed that issue with stub on 1 function (EventRegister), when --enable-features=V8VmFuture (#enable-future-v8-vm-features) used.
it was reproduced also on XP with that flag. Now I know in what case this function used and have restored it back to stub, returning error, instead of breakpoint-stub.
I think all another should work after this.
Will create new build later.

[Vangelis66]

I will investigate why it crashes with #enable-future-v8-vm-features.

UPD: have fixed that issue with stub on 1 function (EventRegister),
when --enable-features=V8VmFuture (#enable-future-v8-vm-features) used.

Thanks once again! 👍

But if it was cause by something else, then it will help do it more quickly,
if you attach here crashdumps, if you can, found in \reports\ directory of profile.

I had just generated my own crash dumps, as requested, when your very last comment went public 😉 ...
Since I am running the PAF installation of Sm, the actual location of the dumps is inside:
.Data\profile\data\crashpad\reports\
I used a fresh Supermium 122 R6 profile with just the internal flag #enable-future-v8-vm-features set to "Enabled" and then relaunched; result:

NB: To get back to a working instance of Sm with the IDA-RE-things DLLs still in place, relaunch the browser with the --no-experiments cmdline switch, then access chrome://flags and toggle #enable-future-v8-vm-features to default; remove the cmdline switch (passed to the PAF launcher) and restart the browser!

the registry approach was selected to support inter-process "Screen Saver running prevention" feature,
by Power-saving routines. whish are absent on XP and Vista, when user playing videos on pages.

Thanks for this explanation - I guess I could've first read #13 😜 ...

[IDA-RE-things]

Hello, I have created and upload build 5061, after fixing another small issue, not touched this topic.
Your "dirty profile" should work fine. If not, will continue to investigate.

[Vangelis66]

I have created and uploaded build 5061, after fixing another small issue, not touched (in) this topic.

Great! Many thanks! ❤️

Your "dirty profile" should work fine.

... If I got this right 😜 , for Vista32 I don't need file D3DCompiler_XP.dll contained inside the b5061 distribution; with that taken into account, and following needed file-renaming, I think this time ALL went fine 👍 :

Congrats! 🥇

Thanks for this explanation - I guess I could've first read #13 😜 ...

That issue was also mentioned in upstream #574 (recovered via Google Cache, as Supermium's GitHub repo has been taken down, hopefully not for long):