Dave-H

My OrangeMonkey extension is certainly working for other scripts, so either the script itself is faulty or it isn't compatible with 360Chrome. @NotHereToPlayGames is certainly still a member here, although not as active as they used to be.

Not working here either. If I try with Supermium, it does work, With that, there is code in the box next to the run and reset buttons when the page first loads, which is not there in 360Chrome. I thought uBlock might have been causing the problem, but disabling it made no difference. Don't know why this is I'm afraid.

The script loads OK for me, but how can I test it? What is it actually supposed to do?

I can't see anything obviously wrong with that, but I'm no expert on scripting, I'm afraid. @NotHereToPlayGames is the man to ask.

I use OrangeMonkey to run my scripts, and that appears to work fine, but so should Tampermonkey of course! I'm not sure how to check whether they are actually working!

Has anyone here actually got Dibya's patch to work? I've found a couple of supposed sources for it, but they all seem to contain just original system files, with no apparent modifications made to them. The instructions that came with one of them seem very strange indeed - "1. Place contents of the "For System32 folder into C:\WINDOWS\system32; Replace .exe and .dll files in System32 2. Enter "C:\WINDOWS\system32\drivers", copy contents of "For Drivers" folder (all .sys files) to the dictionary 3. Enabling PAE Click the start menu, then run (alternatively pressing win + r). Type "C:\boot.ini" then add "\PAE" at the very end of the last line of text. SAVE the file! 4. Reboot and enjoy up to 128gb of ram on your Windows XP installation" The "For System32" folder contains all the HAL and NTKRNL dll and exe files used for various types of system. They all seem to be unmodified originals. Quite how putting all of them in your System32 folder (when only one pair is needed) will do anything other than produce an error message is puzzling!

I think we have to take Shane's word for it that the patch has been applied to Supermium 132. As I said earlier, it's an ESR version, which surely should be capable of having the patch applied to it, as it should be fully supported until the next ESR version is released. I'm not sure how we can test whether the patch has been applied successfully or not.

I can't remember the full details, but the wuaueng.dll I'm using is dated 2nd June 2012, and it is a modified version (for SHA-2) so that could well be the issue.

Thanks, very interesting. My authorization.xml file has an expiry date in it of 2014-11-17, so it appears to have expired over ten years ago! The article does say that the expiry of that file is not relevant on the XP version of Microsoft Update when using Legacy Update. "Legacy Update hosts a proxy service to connect to this server, which we use on Windows 2000, XP, and Vista. Due to the way Microsoft Update is designed, configuring a custom server in the registry also inherently allows it to receive Microsoft Update updates. It also means the expiry doesn’t apply, because the authorization file is no longer relevant. This is the workaround we most likely would have used." I don't know if that also applies with the workarounds I and others here are using, but the fact that the file actually expired many years ago would seem to indicate that. So, why isn't it working any more?

So has Win32ss engineered the patch for Supermium, even though it's only at Chromium 132? It is based on the ESR version, which should surely be able to have the patch applied?

Microsoft Update seems to be no longer working for me. It had been fine, although I hadn't tried it for a long time. Now getting error 0x80248015 as soon as the scan starts.

I do hope that remark was a generalisation referring to the software, and not aimed at anyone on this forum personally.

Thank you so much, but I'm afraid that is pretty much all completely over my head! Do you know why the /3GB switch cannot be used with the RAM patch applied?

Having now reviewed things, I've come to the conclusion that increasing the apparently available RAM won't do anything at all to help with my crashing browser. Correct me if I'm wrong, but from what I've researched, the problem is fundamental, and it's because it's a 32-bit browser on a 32-bit system. My understanding now is that 32-bit processes are limited to accessing 2GB of RAM, and that remains the case regardless of how much RAM is on the system. All the RAM patch will help with is running more processes simultaneously, it won't help at all with giving more memory to individual processes. The Facebook browser tab is constantly running out of memory because of the FB Purity add-on, which is eating huge amounts of it. It appears that there's nothing I can do about that. Although it caused other problems, unfortunately, the only thing which helped was using the /3GB switch in boot.ini, which I gather allows a process to access 3GB of memory instead of 2GB. I've tried using the /3GB switch with the extended RAM patch, but the system then just BSODs on startup, so I assume that configuration isn't an option. Am I right here, and there's actually nothing I can do about the browser problem? Thanks, Dave.

New release 132.0.6834.226 R5. This release was expedited to cover critical vulnerability CVE-2025-6554 (#1486). Some other changes were made: (#1480) - "Web Scrobbler" extension should now work on Windows XP, as well as other extensions that create notifications (#1473) - Favicons should no longer slide out of tab bounds when dozens of tabs are open in a given window (#1483) - Support for custom tab and new tab button shapes that are derived from an scs file are disabled by default after some users experienced performance declines after their introduction. This functionality is now gated behind the --enable-advanced-customization switch. Unless someone tells me that CVE-2025-6554 (#1486) is really important, I think I'll pass on this one.