Content Type
Profiles
Forums
Events
Everything posted by Dave-H
-
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.
-
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?
-
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.
-
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.
-
I get a warning from the Malwarebytes Browser Guard extension on that site, but it works fine if I override it. Supermium 132.0.6834.224 on XP.
-
Is nothing sacred?!
-
New version now released, Supermium 132.0.6834.224 R4. This release of Supermium includes various changes and improvements, including: (#1412) - Option to disable autoplay introduced in chrome://flags, #disable-autoplay (#1403) - --force-dark-mode option introduced to deal with possible issues with white flashes in dark mode. However, some flashes may still appear due to caching of previous page views (#1445) - chrome://version uses Supermium branding (#1441, #1433, #1398, #1400) - Small changes to default metrics, particularly affecting v109 and CR23 tab styles (#1438) - New tab button fixed in place (and the tab close button should no longer overlap favicons) (#1411) - Download link now appears by default in chrome://downloads, as opposed to referrer link (issue unassigned) - #disable-gpu-driver-bug-workaroundsnow available in chrome://flags Some small mitigations have also been introduced for crashes in portable configurations on Windows 7.