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

[reboot12]

Which patch for WinXP SP2 ? I tried WinXPPAE_v35.7z but patch only ntkrnl*.exe

Search for differences

1. C:\WINDOWS\system32\ntkrnlpa.exe: 2 015 232 bytes
2. C:\WINDOWS\system32\ntkrnl2.exe: 2 015 232 bytes
Offsets: hexadec.

   138:	D9	23
   139:	22	1E
15BF1B:	07	00
15BF20:	01	02
160F0E:	74	EB
1B07CC:	10	00
1B07CD:	00	02
1B07E2:	1B	00
1B07EA:	FC	F8
1B07EE:	01	02

10 difference(s) found. 

I try use patched files from Dibya128GB -> ntkrnlpa.exe + hal.dll but OS not boot and only black screen.

[user57]

On 1/2/2017 at 4:19 PM, liquidLD said:

yes, on 32 bit XP . It's my understanding that in a 32 bit PAE system,no app can acces more than 3-4 Gb, but the system can utilise in some manner all the memory available.

So,even if one app cannot use,let's say ,more than 3 or 4 Gb, the OS,as a whole can. And it's always good to have lots of memory. Especially when you run many apps at once.

edited for some grammar mistakes (not a native speaker)

there are 3 that can exceed the 4 GB limit

PAE

PSE

PAGING

lets say this patch works, it dont exceed the normal 4 GB limit what rather is like 2 GB per running executable/app - this is because the usermode useally takes 0-7FFFFFFF addresses 

the rest is in kernel mode (80000000-FFFFFFFF)

so somewhat somehow it can use that 4 GB per app, but its split apart (2 gb usermode memory and 2 gb kernel mode memory)

 

to have a little more userspace, there is a smaller solution to pass that 2 GB limit to a 3 GB limit

https://learn.microsoft.com/en-us/windows/win32/memory/4-gigabyte-tuning

then the usermode limit is 0-BFFFFFFF and kernel mode is C0000000-FFFFFFFF

(3 gb usermode, 1 gb kernelmode)

but back to that important answer, normal apps dont use for example segments to exceed that 2 GB/maybe 4 GB limit 

 

but there is actually a different reasoning why the 64 GB are use anyways 

and that reason is that you dont have just 1 app/executable running on XP

those different apps then can point to a different spot in memory (aka passing the 4 GB limit)

so having multiple applications (for example google use a lot of extra/or restarting applications/executables) is also a solution to use the 64 GB ram

 

have the patch ever tryed to be functional ? norm-wise it is certainly possible, someone might actually run a lot of big applications and check what physical memory pages are mapped out

 

to make a paging example there are segments

https://en.wikipedia.org/wiki/X86_memory_segmentation

but XP barly use these segments (nor do 7 8 or 10 - and if they do they are not used to pass the 4 GB limit)

for example in a older normwise app there is this segment (often called a selector) that is using the CS:EIP combination to execude the code flow, while the data access DS selector can access a different part in memory - but that wasnt happening - both DS and CS where made to point to the same memory in like win98-win10 OS`s

the ES segment for example could be a choice to pass the 4 GB limit over the segment solution

a even simplier idea would just to use the next counter for CS 

 

but if you then disassembly the applications you can see that the executables/apps are not using that - that goes for 99 %+ of apps/executables - also they cant if the OS/kernel mode dont have a controlment for this

the most applications/executables dont have the selector being used

but you can write an access with like a code using "cs:offset" instead of just "offset"

 

besides the software, also a role plays if the hardware can do it, some still have 32 wires, then the CPU might be able to do so, but the motherboard dont have enough wires

[j7n]

If you have a lot of RAM memory (to make use of PAE) that in itself consumes space in the kernel memory where a translation table is kept. Drivers allocate kernel memory for their own needs. For this reason /3GB might lead to instability with only 1 GB left over. /USERVA allows to tune the boundary to give a little more user memory, such as 2.5 GB.

[user57]

maybe it would be possible over this what microsoft calls AWE

https://learn.microsoft.com/en-us/windows/win32/memory/address-windowing-extensions

however it seems to give control over physical pages but it is connected to a virtual address

but it is not using a selector 

 

going with only 1 executable, that means you might can map more then 4 GB of data piece wise

but always when you want to access that RAM/data you have to remap it to a virtual offset

 

and just thinking around if that AWE is used by internal functions of windows - thats maybe how windows xp passes the 4 GB limit - in a post before i wrote its possible to map the other ram (higher then 4 gb) in a 32 bit system (or with a different name "pages") 

thus xp could map ram above 4 GB in multiple applications (that sounds very similiar to what i wanted to point out)

 

having the "multiple app/executable" solution is not that bad so you actually use up the 8 GB 16 GB or whatever you have installed in your computer

chrome is the best example right now i have 24 open executables of chrome (with 3 times google started up)

[reboot12]

OK, finally works 

I was running all the time with CSMWrap and it turned out that with this it doesn't work on Haswell:
https://forums.mydigitallife.net/threads/winxppae-v3-5-winxp-sp2-issue.89363/#post-1881947

Also, the ntkl64g.exe file has a bad checksum and doesn't work when trying to run using winload.exe - error 221:

setcsum ntkl64g.exe

 SetCSUM v1.01, (c)2000 Jeremy Collake
 http://www.collakesoftware.com
 mailto:collake@charter.net
 ----------------------------------------------------------------------
 .\ntkl64g.exe =
    Header Checksum:  001FACDE
    Correct Checksum: 001FF99B
    Checksums do not match!
     Set correct checksum in file? [Y/N/Q] Y
     Recompute
     Header Checksum: 001FF99B
     Correct Checksum: 001FF99B
     Checksum set!

 Done!

[Dave-H]

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.

[user57]

i forgot the about RAMDISC
that AWE was already used in the past with RAMDISC´s (and used more then 4 GB of ram in xp in the past like this)
but it has the problem i described before, it can fill more then 4 GB of ram (or the upper parts past of 4 GB physical ram addresses)
but then you have to "remap" that pages into a virtual offset - that goes fast but its a small step to do (you have to make it in pieces then)

for an app/executable that might be different, because multiple apps/executables mean more virtual offsets for each app/executable
therefore the app´s/executables then would be able to use 4 GB of ram in every executable 
(every app can be seen as a extra virtual offset) - in this case windows then just maps the higher physical ram (for example physical ram addresses from 5-8
 GB) - that is possible 
thats because useally you only see the "virtual offset" - it is not a physical address 
so then you would have 4 GB each app/executable

to mention a other problem, chrome or an application are not always "flawed" either, they actually have bugs 
for example i have a win7 machine where a memory crash always apear after some time
bigger app´s dont useally have a own controlment for its memory, they use a engine - in this case probaly a memory managment engine
that win7 chrome is bugged with a "untouched download" from chrome for me 
so it not neccesary has to be always a error of the backport for example to windowsXP 

well about that patch - i havnt worked on it so its hard for me to say if it is really doing its job
what i can see but is that this patch dont show its connection for the PTE´s and PDE´s - that would be a neccesary thing it must can handle (the patch is incredible small)
let´s say it cant, then it might print out "i have 16 GB of ram", but the progress might not be done
maybe the patch just works - that would be possible 

the patch should be tested, or maybe someone comments if he already has tested that patch, maybe someone has knowledge

what dave wrote sounds a bit like that it actually dont work
chrome make multiple apps/executables - and if its doing that it has at least 2 GB of ram for each app
2 GB should be enough for one TAB by like a far
if that out of memory error apears when a lot off app/executables apears it would be an indicator that the patch dont work
because it cant handle the PTE´s PDE´s or maybe other parts of that progress (that handle the controlment of physical pages above 4 GB)
then it would try to use the first piece of the 4 GB ram and that error would apear

so hard to say, but i would try multiple apps/executables that actually use up more then 4 GB ram

[Dave-H]

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?

[Dave-H]

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.

[user57]

one way i could think of would be to check the PTE´s and PDE´s if the physical ones actually point to the higher physical ram
for this you need to write a tool that reads out the PTE´s and PDE´s for each running app/executable

that with the physical ram is simple to understand, app´s/executables have "offsets", these offsets then have a "virtual offset"
that offset then can be "mapped" to everywhere in the ram like in lets say 64 gb of RAM into the 60 GB part of the ram
to see if the upper parts higher then 4 GB are used you probaly have to start enough of app´s/executables that use up the 4 GB ram 
if so some of these app´s/executables should have PTE´s and PDE´s pointing to higher physical ram then 4 GB

another way would be to look the source code
the ntoskrnl is likely to control that
and the WRK is like open source (once published by microsoft for students to study)
it would requie to look these codes if they are doing it - it´s some work to dig into this but 
we dont know exactly what this version of ntoskrnl in that WRK can do - but in the past there was the LARGE PAGE discussion and the so called "LONG MODE"
in "LONG MODE" pages are not 4k they are 4 MB (that was one possible way to pass the 4 GB limit because the bits representing the physical connection are then 1024 times more)

to explain all the things in paging i would have to write a bit to much now, its like an entire book, as mentioned there are 3 PSE,PAE,PAGING
lets just say for PAE
PAE (in 32 bit) consits of 64 bit PTE´s and PDE´s, not all of the bits are where the page is, for a better explaination i suggest to look that here:
https://wiki.osdev.org/Paging
not having 64 bits is not a problem because the pages are to be multiplyed by the page size as mention like from 4k to 4 MB 
also its a combination of PDE´s and PTE´s

depending on the mode what was set also the norm of the PTE´s and PDE´s are changing
so on the osdev wiki website you look for the 64 bit entrys, above is a 32 bit entry explaination, 64 bit entrys are not to confuse with the 64 bit mode (that a x64 OS has)
it just describe the size of the PTE´s and PDE´s, they have been 64 bit of size in a 32 bit OS since PAE was around (PAE came with the NX flag, then having that 64 bit entry for the first time)

here you read out where the physical pages point to, therefore you then have the information if ram over 4 GB was used

[LoneCrusader]

9 hours ago, Dave-H said:

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

The thing that hath been, it is that which shall be.

Been here before Dave, we covered this back in 2017.  Simple fix with a Server 2003 version of USBPORT.SYS.

daniel_k's solution appears to be the best of the various different packages that address the PAE limit.

[Dave-H]

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?

[Dave-H]

@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!

[reboot12]

22 hours ago, Dave-H said:

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!

@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

 

Edited Sunday at 05:24 PM by reboot12

[user57]

that video from reboot12 just shows a very slow interacting opening windows for the "WinXPPAE 3.5 patch"
for the other video it shows fast interacting for opening windows not using "WinXPPAE 3.5 patch"
it actually dont show a "out of memory problem"
is that patch doing something else ? the patch changes you can see with a file comparer

i cant dig into a new project, because im already doing one
but i would look what this patch actually is doing

i remember a elder discussion but, it was either the first release of xp or the second
where the "LARGE PAGE" discussion apeared and the "LONG MODE" 
in the past it has only 4K pages in the norm
so that XP discussion claimed to use the large page where the discussion was about instead of 4K paged, was changed to 4 MB pages
they called it "the long mode"

so here might be a possible catch, that 4 MB pages where in that discussion said to be buggish and slow in interaction ...
while AMD claimed to be able to use these 4 MB pages without any speed loss 
do someone might remember that discussion ?
i only remember that this version then quickly got removed, later /PAE apeared (and claimed to use 4k pages in PAE, and having faster speed)

what i wrote about the long mode and large page should be considered as discussion (it might not be correct, or need fixes
, i just try to point out a elder discussion - for example if i google "long mode" now it just says "thats the x64 bit mode" - but thats not 
what was discussed that day from the past)