Dave-H

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.

Sotwe.com is working fine here in the UK on Supermium 132.0.6834.224 on XP.

Members are reminded of forum rule 1a. 1a. This is not a warez site! Links/Requests to warez and/or illegal material (e.g., cracks, serials, etc.) will not be tolerated. Discussion of circumventing WGA/activation/timebombs/license restrictions, use of keygens, or any other illegal activity, including, but not limited to, requests for help where pirated software is being used or being discussed, will also not be tolerated. Offenders may be banned on first violation. It is expressly forbidden to post links to, or to discuss, any form of warez.

In case anyone is interested, here attached are the two pairs of files used on the system by daniel_k's patch (hal2.dll and ntkrnl32.exe) and the '64G' patch (hal64g.dll and ntkl64.exe). I'm afraid I don't know how to analyse them to see just how similar they are. Looking with CFF Explorer, the dlls certainly do look very similar (they are exactly the same size), although of course not identical. If anyone with the necessary skills can compare them properly, I would be very interested to know the results! RAM Patches Files.zip

So it would be a waste of time installing daniel_k's patch on a uniprocessor machine anyway? I wonder why he bothered to include the option! So, do you think the two patches I've tried are actually doing exactly the same thing, so there's no advantage of one over the other? One isn't making the extra RAM any more accessible to programs or the system than the other, for instance?

OK, I decided to have a try with daniel_k's patch to see if it produced any different results to the one I was already using, which was linked to here. It took me a while to get it installed. As I have a multi-boot machine, my file paths are not standard, which caused the batch file to fail. For instance, the batch file contains many instances of the path "%SystemDrive%\Windows\". As my Windows XP installation is in D:\WIN-NT this did not of course work! The author should really have used "%WinDir%" I would have thought, unless I'm missing something. Do be aware of this if you try to use this patch on a system which doesn't use the standard paths. Anyway, once I'd edited the batch file so all the paths were correct for my system, it still didn't work. It said it couldn't open SP3.cab, so couldn't extract the files it needed to patch. Why I do not know, It warns that it needs to be run as Administrator, but apart from the fact that I am of course an Administrator user on the machine, there is no option to run the batch file as an administrator as far as I can see when the installation is on FAT32 drives. Maybe that wasn't the issue, but I could execute the commands fine manually in Command Prompt, the batch file just didn't seem able to do that itself. Very strange. Anyway, I did the whole thing that way, manually executing the lines in the batch file one by one, and it all seems to have worked. Everything looks exactly the same as with the previous patch, the browser is still falling over on Facebook. It's certainly a much more complicated install routine than the patch I was using first. How the other patch does it by just using two extra files added in System32 and a simple modification to boot.ini is a mystery to me. In the daniel_k patch, you have to specify what sort of machine it is (ACPI Multiprocessor in my case) to get the right HAL files. How the other patch does it without having that specified is impressive! I'll let you know how I get on now with this patch. Cheers, Dave.

Linking to pre-activated versions of software is forbidden under forum rules. Links and name references removed.

I must say that I couldn't see anything obviously wrong on reboot12's video either, no crashes or error messages. Is Explorer being sluggish the only issue? I've been using Explorer a lot since I applied the patch, and I've not noticed any difference in performance, apart from the USB issue I mentioned earlier, which now seems to be fixed. Incidentally, I've now determined what specifically is causing the out of memory problem on my browser. It's being caused by my Facebook Purity extension, which is why it was only happening on Facebook! If I disable the extension, the problem goes away. Of course, that isn't the answer. It works fine on the 64-bit version of the browser on Windows 10. The issue still is that although the extension might be causing high memory use in the browser, now that it supposedly has 16GB of RAM to play with, it shouldn't still be running out of RAM!

@LoneCrusader OK, I substituted the USBPORT.SYS file (I used the one in Dibya's patch) and everything seems to be fine with the USB connection now, working normally. Thanks for the tip!

Thanks. I will try to find the version of USBPORT.SYS I need, and report back! Is there any reason to think that daniel_k's patch is any more likely to solve the browser problem than the one I'm using?

Of course, I have now found an issue! When I connected my mobile phone to the system by USB, and tried to transfer some files to it, it didn't work. It went through the motions, but wouldn't actually copy any files. Eventually I had to kill the transfer. I tried again with the normal memory configuration, and it worked fine. So it looks as if the USB problems much mentioned here are happening with the patch I'm using.

Thanks. That is, of course, the $64,000 question. Is that patch actually providing 16GB of RAM on my system, or is it just appearing to, with some or all of the extra RAM not actually accessible? All of my system analysers (and I have lots of them!) say that I now have 16GB of RAM, but how can I test that this is actually properly usable?

I've been having problems with my installation of Supermium on 32-bit XP, where tabs crash with an 'out of memory' error. This happens particularly on Facebook. You can see the RAM being eaten on the Task Manager as I scroll the Facebook newsfeed, until eventually it falls over. I read up here about ways to get 32 bit XP to see more RAM, and eventually I found this patch. It seemed very simple to implement (and undo!) compared with some of the other possible solutions being discussed here, so I thought I would give it a try. I wasn't very confident, expecting a BSOD at worst, and other issues even if that didn't happen. To my amazement, at least on my system, it seems to have worked perfectly! The system now reports 16GB of RAM available, which is great. Unfortunately, it hasn't fixed the browser crashing problem. If I scroll Facebook now, Task Manager still shows the RAM being eaten, but when there's still apparently loads still left, the browser tab still crashes with the same 'out of memory' error. I suspect that this isn't a problem peculiar to Supermium, it would probably happen with any recent Chromium-based browser. So, anyone any idea why this is still happening? It is simply because it's a 32-bit browser, so perhaps can't access more than a limited amount of RAM, regardless of how much is available? If so, is this an insurmountable problem? Any suggestions gratefully received! Cheers, Dave.