win32

You would get the equivalent of a nightly build or one of these automatically-built snapshots: https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html

Are these issues only in 5015 and not in 5012? In 5015 I made changes to the SRW locks, enabling them in shared mode.

Yes, the page above is the official Supermium website. And the account was flagged for "spamming". as I found out when trying to export the repository directly from GitHub to GitLab. The repositories were not deleted, but they are hidden from public view along with my account itself. At the time of this incident, I had built Chromium 124-based Supermium and it worked on XP (x86 and x64). But I still had a few deficiencies to correct before even a pre-release, specifically graphical glitches with GPU enabled, some upstream UI bugs, plus other outstanding bugs reported recently. Other features such as a UA/UACH spoofer and UI customization were being worked on as well. I reiterate that there is no malware in Supermium, progwrp, its installer and its uninstaller.

The win32ss account on GitHub was flagged for an unspecified reason. I am going through the appeal process to restore it, but I will make sure the repository surfaces somewhere else such as GitLab even if GitHub does accept the appeal.

Yes, the timebomb's logic is a little off in that it only checks that the year is 2024 or greater, and that the month is August or greater.

It turns out that it is supposed to be a commercial product: https://github.com/win32ss/supermium/issues/29#issuecomment-1821936051

I also haven't been able to find any connections opened to Chinese IP addresses, much unlike 360 Chrome. The "expires in one year" is a restriction in the application itself. If you try running the browser in August 2024 or later, it will silently crash. However, there is a logic error in the timebomb so it will run for the first seven months of the following years. However I think a patch for it would be technically a crack as it is proprietary software with restrictions on launching.

Supermium moves to the stable branch (version 119/120) at the end of this month when the next release will be made. This should reduce the number of upstream-inherited bugs. GDI rendering should be perfected for this release as well and there will be an option to disable prompts for "unsafe downloads" (and avoid having a sample of the downloaded file possibly being sent to Google). The GDI option in particular will have improved rendering of remote fonts over Vista-level DirectWrite.

I have been able to compile C++ 17 sample code with LLVM 16.0.5 and 17.0.1 in the VS2010 IDE. After installing LLVM and selecting the LLVM v100 toolchain from the project properties, I had to do the following things to make it work: -first, the VC++ 2010 and Windows 7 SDK headers were freaking out at the C++17 syntax. So I took the headers from VC++ 2022 as well as the Windows 11 SDK's UCRT headers and placed them in "Additional Include Directories". -Then, I went to the LLVM section of project properties and added the following compiler options: ``-Wc++17-extensions `` and ``-fms-compatibility-version=19``. This enables support for C++17 and allows the use of the built-in types that the new headers expect. -Linking is complicated. The LLD linker cannot be used due to various issues so we must use the VC++ 2010 linker. This works to an extent, but there will usually be missing functions that the linker is unable to resolve. I built libs containing various functions such as __std_terminate,and a delete operator, which should be placed in "Linker -> Input -> Additional Dependencies" (https://github.com/win32ss/win32ss.github.io/raw/main/images/msvcrt10_cpp17_x64.lib and https://github.com/win32ss/win32ss.github.io/raw/main/images/msvcrt10_cpp17_x86.lib). -Furthermore, if you are using msvcrt*, the VC++ 2010-supplied msvcrt.lib has baked-in directives that block it from being used where _MSC_VER is not equal to 1600. Clang will make it 1900 when -fms-compatibility-version is set to 19. This means that the directives must be patched; by opening up msvrt.lib in a hex editor, searching for all instances of /FAILIFMISMATCH:"_MSC_VER=1600" and changing 1600 to 1900 (zeroing-out the whole string may also work). *newer ucrt libs were attempted, but there were issues with the linker not recognizing CFG. This would require rebuilding the runtime to remove CFG references.

Hello everyone. I just finished re-adding GDI to Supermium. At first it would only work in --single-process mode, but I got it working in standard mode by ensuring that FontCache objects have the Skia GDI font manager when GDI is enabled. Then I want to fix TLS, readd D3D9 DXVA support, and link Supermium against a DLL with implementations of many newer functions. I have fixed my PMs if you are interested.

Yes, the DirectWrite in there is good enough to make some fonts load in Supermium, but I don't believe the media foundation or Direct2D parts are compatible.

KB4499184 is a preview (read: beta) of the May 2019 update. I assume that comdlg32 is the source of the problem since that's where the dialogs are located. I'll see if I can reproduce this.

I am, but I haven't been able to respond because there was no home Internet access for a few days here.

One of the recent commits to Firefox hard-coded the user agent to Windows NT 10.0.

I looked at the git mirror of the official Gecko repository and they haven't made any commits to remove Windows 7/8.x compatibility yet.

So XP x64 doesn't have the global variables that store the major/minor versions after all (WRK does). In that event, you should look for MmCreatePeb or a similarly named function; this will provide the values that are fed to user mode version functions. You can also modify ntdll's RtlGetVersion or "intercept" kernel32's GetVersionExW.

Look in ntos' RtlGetVersion. It's either hardcoded in there (Vista+) or it references the global variables that store the major and minor versions (XP x64, I'm almost certain).

Did you update to the latest release of Supermium?

I just installed 2020-01 and will be able to test ASAP. I'm really surprised that it would fare worse with a higher update level, considering it's working good on Windows Vista (sandbox included!) and 8.

I had originally tested with a Windows 7 install with a low update level, but I have received complaints about it not working with ESU updates. Do you have those? For that reason I will also start testing (and debugging) with ESU updates.

It should work on regular Windows 7 with SP1 (it always worked in my VM with nothing but SP1, but some users complained about it not loading because of missing delay-load module; my second release should solve that). Vista needs the extended kernel however.

Here is the future of Chromium on Windows 7: https://github.com/win32ss/supermium I have been closely tracking the many changes made to Chromium since November 2022, made with the intent of dropping support for Windows 7 and 8.x. As of version 111, it became very difficult to keep the newest versions running on Vista with the extended kernel; shared memory allocation changes made it impossible to do so as subtle changes to the API (which were done in kernel mode) prevented stable operation of the browsers. So I decided to build my own Chromium. I discovered that a further change was made to the shared memory allocation which broke it even further; the successor to mojo, IPCZ, was forced on by default. It only works properly with Windows 8.1+'s shared memory API. I disabled IPCZ for pre-8.1 and this made the sandbox work again on Vista and 7. Perhaps I will see exactly why IPCZ is broken (from the Windows API level) and try to fix it for the next release. The only win32 API link I can find is CreateFileMappingW, which I need to test with an IPCZ-enabled build on both 8 and 8.1 to see what makes it fail.

After some time has passed and multiple launch attempts have been made, it does launch, but this is not acceptable either. I'm trying to find out why it crashes at first.

I checked again, and it seems that it's due to an issue that is specific to my GPU where it takes several minutes to initialize the OpenGL user mode driver. I asked for confirmation of this issue from other users, but no one else got it. But I do believe it may be related to the extended kernel, so I will fix it.

On Windows Vista, CUDA must be disabled in the GPU driver's control panel to run Vegas Pro 15. If not, it gets hung up on a version check. I will look into it.