Jump to content

Simple XP 32BIT 64Gb RAM (true Pae) Guide


Recommended Posts

Posted

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!
:dubbio:


Posted (edited)
On 6/29/2025 at 5:22 PM, Dave-H said:

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!
:dubbio:

It is my understanding (I do not renumber why so; it may be hearsay) that the latest patcher, v3.5, includes a process RAM allocation limit; whereas, older versions (so sure how much older) did not.  I am unsure of the reasoning why (but do have best guess) and I do not remember if such is consistent with the Windows XP (any flavor) with Service Pack 1 behavior.  EDIT:  Also, perhaps about 20 years ago, I knew rather better how PAE funcntions.  It is my impression that while PAE does allow to more RAM usage (and against a virtual addressing resource penalty), there are still limits and individual processes might not be able to utilize more than a particular amount.  I think for 64-bit Windows those limits are much (much) higher.  The daniel_k HAL/NTKernel patcher seems to try to restore a more true PAE behavior.

It would have been nice if the daniel_k HAL/NTKernel v3.5 patcher would have come with instructions and a changelog.

Edited by Ascii2
Posted (edited)
10 hours ago, reboot12 said:

@Dietmar @Mov AX, 0xDEAD

I use the WinXPPAE 3.5 patch for a week and I noticed a problem with disk operations - the same is for the 64G version:
Video when ram patch is used - lags: https://files.catbox.moe/ericzb.zip
Video when no ram patch: https://www.sendspace.com/file/17e170

Testing config:

  • Asus P8H61-M LE R2.0
  • RAM 2x4GB DDR3-1600 Dual-Channel
  • CPU Intel Core i3-2120
  • WinXP SP2 Pro
  • HDD: SATA in AHCI mode

 

I notice a few things:
It is my understanding that Windows XP with Service Pack 2 is used here (which presumably also using Service Pack 2 HAL and kernel).
The patch author appears to have tested against Windows XP Professional with Service Pack 3 but not Windows XP Professional with Service Pack 2.
reboot12 has not indicated which kernel and HAL file versions (both version number and variant/flavor of HAL or kernel) he has patched and tested.  It would be also good to specific the relevant boot.ini configuration used.
The problems experienced might not be due to defective patch but rather other bugs or defects in the patched files or elsewhere (such as other system files or other software).
The videos do not demonstrate a problem with disk operations but rather performance of select operations.

Edited by Ascii2
Posted (edited)
1 hour ago, Ascii2 said:

reboot12 has not indicated which kernel and HAL file versions

Yea, I use SP2:

  • ntkrnl2.exe SP2 5.1.2600.2180 (patched by WinXPPAE 3.5 on SP2 OS) + hal2.dll SP3 5.1.2600.5512 (patched by WinXPPAE 3.5 on SP3 OS because the patcher cannot patches the hal.dll SP2 version)
  • ntkrnl3.exe SP3 5.1.2600.5512 + hal3.dll SP3 5.1.2600.5512 - both patched by WinXPPAE 3.5 on SP3 OS
  • ntkl64g.exe SP3 5.1.2600.6368 + hal64g.dll SP3 5.1.2600.5512 - files from @Dave-H 64 GB of RAM patch.zip

I test (for a short time) my XP SP2 on other machines and probably no lag issue but this is fresh installed OS - no any drivers, apps.

  • maybe lag issue is only on my SandyBridge machine
  • recently I changed 2x4GB RAM - maybe they cause the problem?
  • my OS has all drivers and many applications installed - maybe some application or driver works badly with a RAM patcher?

I have to test the patch for a long time on other computers + all drivers installed.

boot.ini

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="RAM v3.5" /noexecute=optin /fastdetect /kernel=ntkrnl2.exe /hal=hal2.dll
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="WinXP" /noexecute=optin /fastdetect

This is my table when DEP/PAE works on WinXP SP2 depending on the setting of the noexecute option in boot.ini
noexecute-boot-ini.png

So, I do not have to use boot.ini switch /PAE because noexecute=optin is enough.

Edited by reboot12
Posted

if /PAE is on windows dont load NTOSKRNL.exe windows then load NTKRNLPA.exe

it often sounds like that the things are like very simple, like it can be done within 5 mins
but rather often these projects are big. you cant just do like many of them
i would be happy if that would be the case, but rather teamwork is required, one person doing all of these isnt possible 
rather if someone would try he would just have to much to do (and in the end probably no problem was solved) - thats why i didnt want to join a other project then xp for example - we have still a lot to do with xp 
this one is also not a small one if you dig into the paging system - there are books that describe that mechanism´s and norms (assembly books for example) + getting these into the ntoskrnl
before boot the bios also prints out "i have 8 gb ram" 
the message in the first post also just shows windows saying it have that, but there is no confirmation that it actually is doing that

to look for what the patch actually changed there are file compare app´s
this is a free one :
https://www.file-upload.net/download-15511527/fc.exe.html

a small patch theoretical could do it just like that, that´s in range of possibilities 

with the file compare tool you can look the disassembled code, so you can see with what the patch(es) interferes 

so thank you to all that help with us, a testing maybe loading multiple apps/executables would be a good idea
these running app´s actually should use up more then 4 GB in total, maybe some chrome instances 
that would tell us more about the functionality of this patch a bit more

just 1 app/executable cant pass the 32 bit limit without a selector/segment selector, except maybe there would be the switch option (like the ramdisc is doing)
however what the patch maybe could do is that different apps can be mapped to higher ram then 4 GB
that only require the right pages that represent the higher area over 4 GB into different executables/app´s
to say is that like 99,99 % of app´s/executables dont use selectors, and i never have seen them (also in win7-10) for the purpose to pass more then 4 GB ram

the switch solution (like a ramdisc do) works a bit different
you can store like 16 gb of ram, thats not the problem - but each time you want to access a certain ram you have to remap that data to an certain virtual offset
(thats what a ramdisc is doing, that is very fast but its a piece wise solution) - that solution dont use a selector but - i dont think windows can do that yet
but again over multiple executables there we dont have that problem - 4 GB for each running application sounds not bad


 

Posted
On 10/25/2022 at 6:25 AM, j7n said:

Sorry four the double post. I added 16 gigs of RAM to my other computer for a 20 in total. It works well without an E-MU/Creative Sound Card. Maybe components that come on motherboards are better tested because they may get installed in a "server" environment. I have nVidia, Realtek NIC, Realtek sound, Intel Ahci. Even a crash of CPU-Z doesn't happen anymore. None of task managers, etc. crash, Daemon Tools works, Yamaha SYXG works.

This ram is really difficult to fill up intentionally. All programs restore up, including games, no complaints from the OS at 19 GB used. No swap file.

fzpA7Vq.jpg

 

something like this

Posted (edited)
22 hours ago, reboot12 said:

Yea, I use SP2:

  • ntkrnl2.exe SP2 5.1.2600.2180 (patched by WinXPPAE 3.5 on SP2 OS) + hal2.dll SP3 5.1.2600.5512 (patched by WinXPPAE 3.5 on SP3 OS because the patcher cannot patches the hal.dll SP2 version)
  • ntkrnl3.exe SP3 5.1.2600.5512 + hal3.dll SP3 5.1.2600.5512 - both patched by WinXPPAE 3.5 on SP3 OS
  • ntkl64g.exe SP3 5.1.2600.6368 + hal64g.dll SP3 5.1.2600.5512 - files from @Dave-H 64 GB of RAM patch.zip

I test (for a short time) my XP SP2 on other machines and probably no lag issue but this is fresh installed OS - no any drivers, apps.

  • maybe lag issue is only on my SandyBridge machine
  • recently I changed 2x4GB RAM - maybe they cause the problem?
  • my OS has all drivers and many applications installed - maybe some application or driver works badly with a RAM patcher?

I have to test the patch for a long time on other computers + all drivers installed.

boot.ini

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="RAM v3.5" /noexecute=optin /fastdetect /kernel=ntkrnl2.exe /hal=hal2.dll
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="WinXP" /noexecute=optin /fastdetect

This is my table when DEP/PAE works on WinXP SP2 depending on the setting of the noexecute option in boot.ini
noexecute-boot-ini.png

So, I do not have to use boot.ini switch /PAE because noexecute=optin is enough.

What is rather apparent is that you are using the initial kernel and HAL releases, where compatible with the daniel_k HAL/NTKernel v3.5 patcher.  Especially for Windows XP with Service Pack 2, it is important to use newer HALs than were initially released for newer hardware during that time period (which would now be considered older hardware).  The systems could have rather annoying bugs otherwise.  Your computer, given the hardware, is such a case.  A newer kernel would be better, unless there is an important reason that you must stay with the older version.  HAL updates were only distrusted as (downloadable) hotfixes; whereas, kernel updates were both in regular updates and hotfixes.

With regards to not having to use the /PAE switch because "noexecute=optin is enough".  That is not correct.  The reason why you might find that the /PAE switch need not be specified for PAE in your case is because you are explicitly specifying and overriding the kernel and HAL to use ("/kernel=" and "/hal=") rather than relying on the otherwise default (potentially "/PAE"-influanced) selection.  (See https://web.archive.org/web/20061224201614/http://www.microsoft.com/technet/sysinternals/information/bootini.mspx for a reference on the various arguments you may use in boot.ini.)

You also still have not specified the variants/flavors of the kernels and HALs used.  Make sure that you have correctly matched the HAL and kernel.

Edited by Ascii2
Posted (edited)
33 minutes ago, reboot12 said:

I am not doubting that you have been able to the a PAE kernel to load.

The /PAE switch appears to modify the bootloader configuration behavior towards selection to PAE, but does not override explicitly specification the kernel and HAL.  Yes, there are various criteria that is evaluated to determine what the bootloader would load, but the criteria should not usually override explicit and compatible specification.  With regards to your sources for the DEP default handling behavior, it is my impression that the evaluation mechanism is against hardware provided DEP (which is often an option on BIOS that is reasonably configurable).   Where hardware DEP is detectable by the bootloader (perhaps because BIOS has the feature disabled), I do not believe the bootloader selection behavior would necessarily tend towards selection of a PAE kernel.  I have never tested that, however.

With regards to Windows XP with Service Pack 2 HAL updates, I have compiled a list of fixes that I think should be useful to you:

For Windows XP Professioal with Service Pack 2

Install in ascending order:

HAL updates (all in ascending order):
KB889673 - A hardware DEP-enabled computer may stop responding when you resume from standby or from hibernation in Windows XP Service Pack 2
KB896256 - Computers that are running Windows XP Service Pack 2 and that are equipped with multiple processors that support processor power management features may experience decreased performance
KB938826 - A Windows XP-based multiprocessor computer does not restart automatically after a memory dump operation
KB951126 - A multiprocessor computer that is running Windows XP stops responding on a black screen after you resume the computer from hibernation
KB954434 - A multiprocessor computer that is running a Windows XP, Windows Server 2003, or Windows Vista stops responding on a black screen after you resume the computer from hibernation
KB958244 - The system may stop responding when you restart a Windows XP-based multicore computer

Only need, to fully update:
KB889673 - A hardware DEP-enabled computer may stop responding when you resume from standby or from hibernation in Windows XP Service Pack 2
KB938826 - A Windows XP-based multiprocessor computer does not restart automatically after a memory dump operation
KB954434 - A multiprocessor computer that is running a Windows XP, Windows Server 2003, or Windows Vista stops responding on a black screen after you resume the computer from hibernation
KB958244 - The system may stop responding when you restart a Windows XP-based multicore computer


Other Fixes of interest despite not being HAL:
KB952117 - When you try to put a Windows XP-based computer into hibernation or into standby, the computer stops responding

 

Edited by Ascii2
Posted (edited)

@Ascii2

I make big tests:

  • using Macrium Reflect clone OS to other HDD - still problem
  • replace RAM modules - still problem
  • use only 2GB RAM 1+1 - still problem
  • using Macrium Reflect make disk image, then restore on other PC - Haswell 8GB RAM (4+4 Dual Channel), OS boot, find new devices, I install drivers. I test and it looks like there is no problem and WinXPPAE 3.5 works well :-)
    I use exactly same patched files and settings: ntkrnl2.exe SP2 5.1.2600.2180 + hal2.dll SP3 5.1.2600.5512, noexecute=optin
    I have to use the system for some time to make sure 100% that there is no problem.

It seems that the problem is only on SandyBridge machines.

Edited by reboot12
Posted

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.
:)

Posted (edited)
21 minutes ago, Dave-H said:

How the other patch does it without having that specified is impressive!

This is not impressive - simply this is patched ntkrpamp.exe for multi CPU/multi core use:
kernel.png

Modern computers have multi-core processors and the use of RAM patch on old PC does not make sense because old computers with a single-core processor do not support a large amount of RAM and a patch is not needed.

Therefore, the 64G patch does not contain other kernal and hal files.

Edited by reboot12
Posted

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?
:dubbio:

Posted (edited)

 

53 minutes ago, Dave-H said:

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?

I don't know, but if you compare patched kernel files 5.1.2600.6368 in a hex editor and are changed exactly the same bytes in the same offsets, it means that they work the same. You must first patch using a patcher v3.5 kernel file 5.1.2600.6368

ntkrnlpa.exe 5.1.2600.6368 > https://catalog.update.microsoft.com/Search.aspx?q=2813170

WinXPPAE.bat script default patch all RAM:

WinXPPAE.exe /M:ALL /NOBACKUP

so, put ntkrnlpa.exe (GDR version) and WinXPPAE.exe in same folder then patch as above:

winxppae /M:ALL
Windows XP PAE Patcher 3.0 by daniel_k | HAL patches by <Mov AX, 0xDEAD>
PAE will be enabled using all available RAM.
Patching ntkrnlpa.exe (Uniprocessor PAE Kernel)... OK!
File ntkrpamp.exe (Multiprocessor PAE Kernel) was not found.
File hal.dll (Standard PC/Standard PC w/ C-Step i486 HAL) was not found.
File halaacpi.dll (ACPI Uniprocessor PC HAL) was not found.
File halacpi.dll (ACPI PC HAL) was not found.
File halapic.dll (MPS Uniprocessor PC HAL) was not found.
File halmacpi.dll (ACPI Multiprocessor PC HAL) was not found.
File halmps.dll (MPS Multiprocessor PC HAL) was not found.

No, this is not simple to compare - too big differences :-( Probably ntkl64g.exe is compiled from source code.

org vs v35 differ only in 11 bytes:

Search for differences
1. org_ntkrnlpa.exe: 2 070 016 bytes
2. 35_ntkrnlpa.exe: 2 070 016 bytes
Offsets: hexadec.

   138:    C2    04
   139:    FF    03
   13A:    1F    20
16B632:    07    00
16B637:    01    02
1703C2:    74    EB
1BE554:    10    00
1BE555:    00    02
1BE56A:    1B    00
1BE572:    FC    F8
1BE576:    01    02

11 difference(s) found.
	
Edited by reboot12
Posted

i dont know but the name "ntkrln64g" sounds like it is a wrapper, maybe a kernel extender ? if not there like many versions of ntoskrnl´s you have to find the right version in that case
the searched patches show 7 changes
138-13a is probaly the checksum, that checksum is a "elder driver signature" - if that one isnt currect the system driver (in this case the important ntoskrnl) is not loaded

as you may reconized that patch did not touch that ntkrpamp.exe, you should check what ntoskrl was loaded (there are only 3,  ntkrnlpa, ntoskrnl and ntkrpamp

to check if it use up more then 4 gb ram you should repeat the test from page 7, there is also a page-file that actually can pass that limit you might turn that one off while doing that test

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...