Apology, psapi.h bug, and WinXP progress

[Alex313031]

Plz read : Hello, I know you decided to stop working with me after the easter egg incident. However, there were some things that got misconstrued and blown out of proportion. There were definitely some valid things though as well. I have made an explanation/apology post about everything. https://alex313031.blogspot.com/2024/01/the-good-bad-and-ugly.html Please read it. If, after reading it, you still do not wish to collaborate, I totally understand and will respect it.

---

Now onto the bug report.

Reverting PSAPI to ver. 1 and delay linking the psapi.lib for XP/Vista support https://github.com/win32ss/supermium/commit/d75d17331f2f8733bb300b2095747cce6421d951 is breaking the sandbox on Windows 7/8/8.1/10/11 for me, when using either your supermium 119 .patch file, or directly using the repo (after populating the third_party dir with gclient runhooks). Yet, supermium 119 does not have this issue, only when building it from source. Is there perhaps a difference in the source that was used to compile the 119 release vs. what is publicly available (besides the logo and wrapped installer change). BTW I noticed the logo isn't as high res as it could be. You should either use the ones directly from the pre M12 tree, or use this SVG, and scale it to what you need and export as a .png.

@win32ss

[win32ss]

Reverting PSAPI to ver. 1 and delay linking the psapi.lib for XP/Vista support d75d173 is breaking the sandbox on Windows 7/8/8.1/10/11 for me, when using either your supermium 119 .patch file, or directly using the repo (after populating the third_party dir with gclient runhooks). Yet, supermium 119 does not have this issue, only when building it from source. Is there perhaps a difference in the source that was used to compile the 119 release vs. what is publicly available (besides the logo and wrapped installer change). BTW I noticed the logo isn't as high res as it could be. You should either use the ones directly from the pre M12 tree, or use this SVG, and scale it to what you need and export as a .png.

It appears that psapi isn't loaded into the Supermium address space, causing all calls to it to fail. One solution is to call LoadLibrary on psapi, probably in the executable's main function, but instead I started moving psapi references to progwrp because psapi was only finalized in Server 2003 SP1 (XP SP3 is below 2003 SP1/SP2 in that respect), and before that is missing functions used by Supermium. Another option is to revert to psapi v2 and only support 7 and up as the psapi functions will be called from kernel32.

I have to decide what will happen with progwrp. It's possible that two versions of progwrp will be made: progwrp-lite for ensuring Vista+ compatibility and full progwrp for NT 3.51/4.0/5.0 (depending on the functions used in the application). progwrp-lite would be the one that will have its libraries released and be referenced in future Supermium patches, while the full progwrp will be reserved for other purposes, likely commercial.

[Alex313031]

@win32ss As I am not targeting NT before 6.1.7600, I'll just leave the psapi stuff the same as upstream, and remove the progwrp.lib and ntdll.lib references.

I didn't know that progwrp could even downlevel target stuff as old as NT 3.51/4.0, thats cool! And so is the "non lite" version gonna be a product of your new company?

Also, will there be any more updates to vista extended kernel, and will it ever be open source? Also, upon further inspection, it seems the icons you used are from the pre M12 branch, am I correct?

[Vangelis66]

Another option is to revert to psapi v2 and only support 7 and up as the psapi functions will be called from kernel32.

It's possible that two versions of progwrp will be made: progwrp-lite for ensuring Vista+ compatibility

... Kindly asking you not to forego Vista SP2 x86 support, my current OS on my old laptop :wink:, as Vista Extended Kernel for 32-bit never materialised... Thanks a bunch for what you do here :heart: !

[win32ss]

I didn't know that progwrp could even downlevel target stuff as old as NT 3.51/4.0, thats cool! And so is the "non lite" version gonna be a product of your new company?

Yes. The purpose of the DLL will be to port other applications to older versions of Windows.

Also, will there be any more updates to vista extended kernel, and will it ever be open source? Also, upon further inspection, it seems the icons you used are from the pre M12 branch, am I correct?

There will probably be one more in the future, to correct the export forwards to proper imports (not easy in 32 bit binaries), because that trips up Unicows and perhaps some other alternatives to GetProcAddress. The tooling to build the import DLLs will be made open source, but some of the functions don't exist in C so a disassembly of them is the closest it can be to "open source".

And yes the icons did come from the pre-M12 branch.

[Alex313031]

@win32ss OK this is werid. I fixed everything, and got a working build last night, but now, as I am working on it today, it keeps coming up with "api-ms-win-core-com-l1-1-0.dll was not found on your computer" errors. Upon using dependency walker from the 19041 SDK, it shows that dbghelp.dll (which is linked into both chrome.exe and chrome.dll) is the culprit.

Did you ever have this issue? And if you didn't, could I at least know this information about your setup that you are using to get successful builds:

1. OS (10 or 11, or Linux version if cross-compiling)
2. MSVS Version (i.e. 7.5)
3. WinSDK version (particularly important since this is where dbghelp.dll comes from) (i.e. 19041, 20348, 22621, etc.)
4. Are you natively compiling or cross-compiling

[win32ss]

@win32ss OK this is werid. I fixed everything, and got a working build last night, but now, as I am working on it today, it keeps coming up with "api-ms-win-core-com-l1-1-0.dll was not found on your computer" errors. Upon using dependency walker from the 19041 SDK, it shows that dbghelp.dll (which is linked into both chrome.exe and chrome.dll) is the culprit.

Did you ever have this issue? And if you didn't, could I at least know this information about your setup that you are using to get successful builds:

1. OS (10 or 11, or Linux version if cross-compiling)

2. MSVS Version (i.e. 7.5)

3. WinSDK version (particularly important since this is where dbghelp.dll comes from) (i.e. 19041, 20348, 22621, etc.)

4. Are you natively compiling or cross-compiling

Windows 10 1809 LTSC Visual Studio 2022 (17.7.1) Windows 11 SDK 22621 Native compile, of course

I think that dll is included in the 1809 api-set-schema (so a type of "virtual DLL") so it's not a problem there. The Supermium distributions (what is contained in the 7z packages built by the autoninja script) don't contain this dbghelp and will use the system's dbghelp instead.

[Alex313031]

@win32ss OK thanks. Also, you made an easy to make mistake in about_flags.cc. See > https://github.com/win32ss/supermium/pull/152

Also, I meant that I am getting the errors on Windows 7, where the file is not to be found, even with net framework and all the visual c++ redists

[win32ss]

@win32ss OK thanks. Also, you made an easy to make mistake in about_flags.cc. See > #152

Also, I meant that I am getting the errors on Windows 7, where the file is not to be found, even with net framework and all the visual c++ redists

Thanks for pointing that out. Those flags don't do anything for now, but once I am done with the rest of ungoogled functionality (next up is switches for disabling the machine ID-based encryption of the data directories and rolling them up into a portable switch that automatically sets the data dir to be in the same directory as chrome.exe) I will use them for blocking telemetry and involuntary connections to Google.

And yes on Windows 7, that DLL was never made for it, and is presumably not a virtual DLL in its apisetschema either. But now I remember that I actually did get the newer dbghelp included in the distribution once, and deleting it from the build output folder seemed to fix it for all further non-clean builds, as the Windows Vista and up versions of dbghelp are sufficient for Chromium at this time.

[Alex313031]

@win32ss So what should I do then? Copy a different dbghlp.dll or remove it or what? I just pulled supermium tip of tree, and the only thing I changed was PSAPI. Still having the issue on <Win10. IDK how the heck I broke it, or how upstream broke it. I had a f***ing working build yesterday!! SOO frustrating as I cannot continue work on thorium-win7 until this is resolved.

On another note, I have another PR coming in soon to properly restore SSE2 support for x86 32 bit.

The problem is that for SSE2 and below, clang makes it non cumulative, vs SSE3 and up it does make it cumulative. What I mean is that for example, setting -msse4 really tells it to do -mfxsr -mx87 -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2. However, setting -msse2 does not do this. Also, setting /arch:SSE2 doesn't work for all targets. The proper way is to do that, but also to add -mfxsr -mmmx -msse -msse2 to either the win BUILD.gn, or the main compiler BUILD.gn in the common_flags for Windows. This is needed since many third party libraries expect MMX and FXSR instructions.

I discovered all this after lots of aches and pains trying to make a SSE2 build of M109 for win7 (which I eventually succeeded in and tested on a Pentium 4 Northwood CPU which lacks SSE3)

UPDATE: https://github.com/win32ss/supermium/pull/153 (this also removes a file I'm assuming you accidently created, and adds the "supermium" target. Using the chrome target works just fine as well :) )

[win32ss]

@win32ss So what should I do then? Copy a different dbghlp.dll or remove it or what? I just pulled supermium tip of tree, and the only thing I changed was PSAPI. Still having the issue on <Win10. IDK how the heck I broke it, or how upstream broke it. I had a f***ing working build yesterday!! SOO frustrating as I cannot continue work on thorium-win7 until this is resolved.

It is safe to remove as Windows 7 has its own version of dbghelp in system32, which has all necessary functions.

UPDATE: #153 (this also removes a file I'm assuming you accidently created, and adds the "supermium" target. Using the chrome target works just fine as well :) )

Thanks. A lot of junk files got made when I first built Supermium, and I didn't manage to remove all of them.

[Alex313031]

@win32ss Also, using /arch:SSE2 the way I did it usually works. I had issues with it in M118. But it works for M109 and M119. If you have issues, you can remove it. It should only affect things that use MSVC rather than clang, which on windows is only NaCl (which we disable anyway)

And so, I should remove dbghelp.dll from the out/blahblah directory before or after compilation?

Also, on a random note, I made a modified version of the 6.1.48 Virtualbox Guest Additions ISO that will work on Windows NT 4.0 SP5 or SP6, if you want it I could upload it to Github.

[win32ss]

And so, I should remove dbghelp.dll from the out/blahblah directory before or after compilation?

Before, to prevent it from being included with the 7z archives that the build scripts will make (if you use those).

Also, on a random note, I made a modified version of the 6.1.48 Virtualbox Guest Additions ISO that will work on Windows NT 4.0 SP5 or SP6, if you want it I could upload it to Github.

Didn't know Oracle broke NT4. I don't use VirtualBox very much, but I think others may use those hardening-afflicted versions.

[Alex313031]

@win32ss OK thanks, and yeah, I make mini_installers. OK fixed it where it is running again, but now another problem, the sandbox is broken. It wont run without --no-sandbox on windows 7, although it runs fine on 10 without the flag. Any idea why? Should I still link in ntdll.lib and psapi.lib even with PSAPI=2?

Also, can you please tell me the exact winsdk version you are using. (I.E. for example 10.1.22621.2428. ) You can find this info in programs and features (appwiz.cpl)

UPDATE: Here is the log when running it without --no-sandbox on Windows 7. When using --no-sandbox no errors are written to the debug log.

[0108/094011.808:ERROR:registration_protocol_win.cc(135)] TransactNamedPipe: The pipe has been ended. (0x6D)
[0108/094020.856:ERROR:main_dll_loader_win.cc(112)] Failed to load Chrome DLL from Z:\thorium\chrome.dll: The specified module could not be found. (0x7E)
[0108/094037.985:ERROR:registration_protocol_win.cc(135)] TransactNamedPipe: The pipe has been ended. (0x6D)
[0108/094104.054:ERROR:main_dll_loader_win.cc(112)] Failed to load Chrome DLL from Z:\thorium\chrome.dll: The specified module could not be found. (0x7E)
[0108/094118.632:ERROR:registration_protocol_win.cc(135)] TransactNamedPipe: The pipe has been ended. (0x6D)
[0108/094120.569:ERROR:crashpad_client_win.cc(142)] crash server failed to launch, self-terminating

Of particular note is "Failed to load Chrome DLL". Is that why?

UPDATE: I think I fixed it. I didn't need to change any psapi stuff, but I did need to link ntdll.lib, even though im not using the progwrp.dll or targeting anything lower than win7 sp1.

[Alex313031]

@win32ss I solved it, so ignore the post above, except for the WinSDK, I would still like to know your exact setup, so i can replicate it on my end for building, and so that if I have any bug reports at least we know our toolchains are the same.

I might even install Win 10 1803 so that I can play around with legacy edge and so I can use Aero8 to enable "aero" on windows frames.

[win32ss]

@win32ss I solved it, so ignore the post above, except for the WinSDK, I would still like to know your exact setup, so i can replicate it on my end for building, and so that if I have any bug reports at least we know our toolchains are the same.

I'm using Windows SDK 10.0.22621.1778. Is there anything else you would like to know?

[Alex313031]

@win32ss

Actually, I would like to know why not linking in ntdll.lib would cause this, because it seems you only added that when you added progwrp.dll for NT 5.x.x. (It might also be a good idea to add progwrp.dll to the repo, or guard that linker setting behind a flag like use_win32ss_progrwp = true/false)

Lastly, where can I even get a LTSB 1803 ISO? Isn't it like volume license only and I would have to pirate it?

Other than that, nope, thanks for your incredible work and for working with me again! Hope Supermium can run on XP eventually, because that would be a double dream come true.

After your response, we can close this issue.

[win32ss]

@win32ss

Actually, I would like to know why not linking in ntdll.lib would cause this, because it seems you only added that when you added progwrp.dll for NT 5.x.x. (It might also be a good idea to add progwrp.dll to the repo, or guard that linker setting behind a flag like use_win32ss_progrwp = true/false)

Lastly, where can I even get a LTSB 1803 ISO? Isn't it like volume license only and I would have to pirate it?

Other than that, nope, thanks for your incredible work and for working with me again! Hope Supermium can run on XP eventually, because that would be a double dream come true.

After your response, we can close this issue.

Upstream Chromium started using ntdll.lib with M112 and started calling ntdll functions directly. The error seems to indicate that a whole DLL could not be located, which would be verified with dependency walker. But in that case, I would've expected the linker to fail to find references to the ntdll functions in any library, since they are not duplicated in other libraries.

There is no 1803 LTSB, just 1809. It is VL, but other SKUs could be used and the build process would be the same, but the OS would be more annoying of course.

I will add a flag to ensure Supermium can build without progwrp soon.

And this is Supermium on XP now. I am trying to improve performance on single-threaded systems with 512-768 MB of RAM, although these bloated sites are the main issue.

[Alex313031]

@win32ss Oh my god sir. You did it. You did the impossible. There has never been an open source Chromium fork for XP that was newer than M54 (Advanced Chrome). Even all the closed source ones never got to Chromium newer than M96 without the highly buggy One Core API.

This is truly a masterpiece. Like, this made my day. Definitely gonna use Supermium on XP when it comes out. Gonna bust out my big gun, a machine with nearly the highest (officially) supported hardware for XP. An AMD FX-8370 + GTX 970 + 16GB DDR3 + PAE Patch + SSD (yeah TRIM, and 4K block allocation, blah blah, but I dont care about the SSD). On that machine, even with no GPU acceleration at all, I expect browsing to be snappy. Will probably use Thorium on Win7 though.

I will definitely give you credit when Thorium-Win7 M119 comes out, and I will link to this repo in my Chromium-XP repo, to redirect users (unless they want M49 for nostalgia).

And so where can I get an 1809 ISO? Nvm I found one.

Also, are you gonna open source the logo change (if you intended to, I can make a PR with the M12 logos) and wrapped installer. I particularly like the wrapped installer since it asks the user before continuing. (mini_installer is great and all. Simple and robust. But it doesn't give the user any feedback/progress or confirmation, it just silently installs in the background, which many users dislike)

[ghost]

Even all the closed source ones never got to Chromium newer than M96 without the highly buggy One Core API.

Actually false. This one is M115 and works WITHOUT One-Core API.

Oh and, can you especially optimize it, especially for my Core 2 Duo E8400, because I run it on my old desktop, you know... 😏 on an OS that consumes same amount of resource with Windows 7 but able to run less applications 🤭

[Alex313031]

@unattendedplayer Im aware of this. But once again, it is not open source. There is only a readme and update file. No source if provided.

Also, I swear, what is with the popularity of the E8400. I swear every manufacturer or system builder always shipped this as their "highest end" CPU. But what about the E8500 or E8600 (the true king of the core 2 duo lineup). I swear you never see those in the wild except for custom built systems from back in the day. I have an Optiplex 780 that came with an E7500. I upgraded it to a E8600. E8400 is still good tho, for XP and 7.

[win32ss]

Also, are you gonna open source the logo change (if you intended to, I can make a PR with the M12 logos) and wrapped installer. I particularly like the wrapped installer since it asks the user before continuing. (mini_installer is great and all. Simple and robust. But it doesn't give the user any feedback/progress or confirmation, it just silently installs in the background, which many users dislike)

I was thinking about removing all branding changes from the Supermium codebase (moreso the localized strings) to avoid massive git conflicts, including the logos, so they would be applied using a script to be run at build time instead. Although the logos only change once every few years, so they wouldn't need to be excluded like that.

The installer is built on a simple 7zip SFX script. This script in turn calls a small installer stub I made which then copies progwrp to system32 (as it is required for the uninstaller which is stored in the installer cache subdirectory of system32) and then launches mini_installer. I could release the script as that's responsible for the message box regarding installation.

[Alex313031]

@win32ss OK good plan. And yes please. Can you commit or send me whatever is needed to make the message box (without progwrp.dll, as I dont need that since Im only targeting Win7 SP1)

[JoachimHenze]

And this is Supermium on XP now.

I am so greedy to get my hands on such an open-source XP-compatible build. Looking forward for the next Supermium release. Endless thanks for your work on that!

[win32ss]

@win32ss OK good plan. And yes please. Can you commit or send me whatever is needed to make the message box (without progwrp.dll, as I dont need that since Im only targeting Win7 SP1)

config.txt

Just replace setup.exe with mini_installer.exe and follow the instructions for building a 7zip SFX installer: https://superuser.com/questions/283698/create-7-zip-sfx-executable

[ghost]

@unattendedplayer Im aware of this. But once again, it is not open source. There is only a readme and update file. No source if provided.

Still proves my point that there is a closed source browser >90 which is working on XP without OCAPI etc.

Also, I swear, what is with the popularity of the E8400. I swear every manufacturer or system builder always shipped this as their "highest end" CPU. But what about the E8500 or E8600 (the true king of the core 2 duo lineup). I swear you never see those in the wild except for custom built systems from back in the day. I have an Optiplex 780 that came with an E7500. I upgraded it to a E8600. E8400 is still good tho, for XP and 7.

I think it had a good performance/price value. It's one of the best CPUs you could get on something like Asus P5GC/MX (Early LGA775 with max. Dual Core support). It's still doing good on web browsing if paired with a GPU that handles the H/W acceleration.

[Alex313031]

@win32ss OK so I made successful builds of Supermium, Chromium, and Thorium M119 for Windows 7.

There is one small issue though. When doing a fresh install, it doesn't pin the shortcut to quick launch (i.e. the taskbar). Upstream always does this. Did you remove this, or is this a bug. If you did remove this, can you show me the file or commit so that I can change it back.

[win32ss]

@win32ss OK so I made successful builds of Supermium, Chromium, and Thorium M119 for Windows 7.

There is one small issue though. When doing a fresh install, it doesn't pin the shortcut to quick launch (i.e. the taskbar). Upstream always does this. Did you remove this, or is this a bug. If you did remove this, can you show me the file or commit so that I can change it back.

I don't remember removing this code. It was likely removed by upstream as quick launch is deprecated. I never noticed this behaviour so I never did anything about it.

Or you're talking about the Superbar. I see that Supermium does it on Windows 10, but not 7. Then it would be worth looking at.

[Alex313031]

@

@win32ss OK so I made successful builds of Supermium, Chromium, and Thorium M119 for Windows 7. There is one small issue though. When doing a fresh install, it doesn't pin the shortcut to quick launch (i.e. the taskbar). Upstream always does this. Did you remove this, or is this a bug. If you did remove this, can you show me the file or commit so that I can change it back.

I don't remember removing this code. It was likely removed by upstream as quick launch is deprecated. I never noticed this behaviour so I never did anything about it.

Or you're talking about the Superbar. I see that Supermium does it on Windows 10, but not 7. Then it would be worth looking at.

@win32ss WDYM superbar? All I know is that Chromium has always pinned a shortcut to the right of the start button on a fresh install (i.e. or if the user data dir is unpopulated)

[win32ss]

@

@win32ss OK so I made successful builds of Supermium, Chromium, and Thorium M119 for Windows 7. There is one small issue though. When doing a fresh install, it doesn't pin the shortcut to quick launch (i.e. the taskbar). Upstream always does this. Did you remove this, or is this a bug. If you did remove this, can you show me the file or commit so that I can change it back.

I don't remember removing this code. It was likely removed by upstream as quick launch is deprecated. I never noticed this behaviour so I never did anything about it. Or you're talking about the Superbar. I see that Supermium does it on Windows 10, but not 7. Then it would be worth looking at.

@win32ss WDYM superbar? All I know is that Chromium has always pinned a shortcut to the right of the start button on a fresh install (i.e. or if the user data dir is unpopulated)

The updates to the taskbar made in Windows 7. In any event, it seems the methods used to pin to taskbar changed with Windows 10 and the old method was likely removed from the Chromium code (https://stackoverflow.com/questions/57159451/how-to-pin-an-application-to-the-taskbar).

[Alex313031]

@win32ss Can we add it back to the superbar?

Also, SSE3 and SSE2 x86 builds are both failing for me. I noticed SSE2 builds were failing for you.

Did you also get the "blahblah is not a valid Win32 program" error?

[win32ss]

@win32ss Can we add it back to the superbar?

Also, SSE3 and SSE2 x86 builds are both failing for me. I noticed SSE2 builds were failing for you.

Did you also get the "blahblah is not a valid Win32 program" error?

Yes, I can put it back on the superbar.

I forgot to mention that the "/arch:SSE2" statement was problematic (I also removed -msse2, but in a vain attempt to test SSE compatibility). When removed it is working.

I don't get an error like that, although that would mean that PlatformSubsystemVersion is greater than 6.1. Chromium sets it to 5.1 by default.

[Alex313031]

@win32ss Noice. When you commit the superbar fix, can you lemme know, and I will cherry pick it.

Yeah, I removed /arch:SSE2. Seems to only work with vanilla Chromium.

And I have my subsystem set to 6.0 across the board. Should I perhaps set it to 5.1 for x86?

UPDATE: OMFG Im dumb. I accidently left 10.0 as the subsystem version in the //other/SSE3 and //other/SSE2 dirs in my repo (which are copied over the chromium tree when either --sse3 or --sse2 is specified with my setup.sh script)

[Alex313031]

@win32ss Are your SSE2 builds working ok now. I have tested it in regular Thorium as well as Thorium-Win7 with -mmmx -mfxsr -msse2 and it works fine. Tested on a real Northwood Pentium 4 too.

[win32ss]

They're working good on my Pentium M. As good as a Pentium M can be now...

[Alex313031]

@win32ss Noice. Closing issue now.