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

[Ascii2]

7 hours ago, Dave-H said:

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

Yes, with the daniel_k's solution, he is not providing a pre-patched binary of a single kernel variant version and a single HAL variant version like that "other" patch you referenced; rather, he provides a patcher that can be used on any compatible variant or HAL and any version of such.  The daniel_k's solution is generally better and provides more compatibility options.

7 hours ago, reboot12 said:

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.

7 hours ago, Dave-H said:

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!

I would disagree.  Older PCs could have relatively large amounts of RAM.  It is also important to note that it is not RAM that needs to be considered, but addressable memory (which is inclusive of RAM and other things like allocations for video card memory).  A old PC system utilizing only 4 GB of RAM would still likely benefit from the PAE fix patch.  Even then, there were computers with much larger amounts or RAM and addressable memory; these were often rather expensive at the time.

It is also best to think of the patch as a PAE (Physical Address Extension) fix patch rather than a RAM patch; the intentions and products are different.

It also seems like there is a presumption that multi-core processors must use a Muti-processor HAL; however, that presumption would not be correct.  Multi-core processor can still use Uniprocessor HAL.  It is a configuration I often use (one may also often take the opportunity to scale a single core well beyond where it would tend to scale in a multi-core conflagration while having the other cores turned off).  Many CPU architectures since about 13 years ago have had this capability and design consideration.

7 hours 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?
One isn't making the extra RAM any more accessible to programs or the system than the other, for instance?

The daniel_k patcher provides a patch tool, while "other" patch you linked to is someone's product of patching and in a limited case.

[Ascii2]

8 hours ago, Dave-H said:

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.

Yes, the batch script is rather defective in that it is unreasonably presumptive as to where resources or files are and can result in not finding the something it should find, finding the wrong thing (which can become a data corruption problem after write operations are performed on originals, such as boot.ini), presuming one wants to use kernel or HAL from sp3.cab, etc.  However, the script does provide some level of instruction of a potential method to patch files and deploy those patched files.

[user57]

well "4 GB is the ram limit for a 32 bit operating system" is finally busted

i wonder why even big company´s are still making that fault:

https://www.asrock.com/mb/Intel/B560M-C/index.us.asp

"**Due to the operating system limitation, the actual memory size may be less than 4GB for the reservation for system usage under Windows® 32-bit OS. For Windows® 64-bit OS with 64-bit CPU, there is no such limitation."

 

to explain the selector/segment or maybe segment selector 

in the past like 8 bit or 16 bit (sometimes both - aka having 8 bit instructions and 16 bit data) 

the combination of segment + offset = "real address"

also 

the instruction pharser that read the next opcode, automaticly use the next segment selector (for continuous flow - without chucks) - why this would not be the case for 32 bits ? (it is a cs:eip combination (cs for code segment))

you could write a code either with a selector+offset or just the offset - for "just the offset "the cpu automaticly then choosed the next one (where it then just executes the next instruction)

if that isnt doing it there would be still the explained instruction codes that concretly use a selector:offset combination

either way if the cpu isnt doing the next segment selector automaticly you still could write a jump at the end of the the 4GB address(or just changing the selector to the next one) 

https://wiki.osdev.org/Segmentation 

for a data allocation this would also be of use you could get a DS(data segment) + offset , and directly you would have a 4 GB chuck

thats why i always (in like the past i wanted to have a virtualalloc2 function that also gives out the selector) - but me writing that info forums (including microsoft ones) where just ignored

 

the others where already explained , like 4 mb pages (instead of 4k), PSE, PAE - PDE´s , PTE´s and why there is a chuckwise solution (and why this chuckwise solution is useable for app´s/executables/modules)

[Ascii2]

23 hours ago, reboot12 said:

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

My impression is that there might be HAL issues or CPU errata/microcode issues on at least the SandyBridge machines.  I have tested the WinXPPAE.exe 3.5.0.0 patch tool on newer HAL files than the initial Service Pack 2 version, and they are also rejected as invalid by the patcher.  Perhaps the SP2 versions do not need the patch; it is possible that whatever is patched for the Service Pack 3 HALs might not be an issue on the SP2 HALs.  Have you tried using the SP2 HAL with the WinXPPAE.exe 3.5.0.0 patch tool patched SP2 kernel?  Regardless, you might wish to try newer SP2 HAL.  The update packages that I have are all intended as the English language (United States) versions, however, I would expect the HALs should still work in another language distribution if the HAL file is specified explicitly in boot.ini.

I have uploaded the HAL updates for English Windows XP with Service Pack 2 to:
https://www.mediafire.com/file/5ibjk0jsnltisxa/SP2_HAL_Updates.zip/file

File Name: SP2_HAL_Updates.zip
Size: 7,597,675 bytes
CRC32: BA5633F7
MD5: 170844F1EDE2CE551C9E5F213A283059
SHA-1: E29ADE7FE24B8C7D10CDCF1EB30D197733B57DFA
SHA-256: B911093A86B272BFDADCEF9F27335DD6E677E0DE60E4D00BBFEFD83C3AC3AB54
SHA-512: E7F08887D5E1DC432C269A40CD5E977F2806FF9D14DDFBBE86B6C58BFB519A3D738F9E98665F3D110619D314A8D6E6385BED5C5520CD97559A7058F62DB55A68

 

Edited yesterday at 04:03 AM by Ascii2

[Dave-H]

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

[reboot12]

7 hours ago, Ascii2 said:

Have you tried using the SP2 HAL with the WinXPPAE.exe 3.5.0.0 patch tool patched SP2 kernel?

WinXPPAE 3.5 can't patch any SP2 hal version:

Patching halmacpi.dll (ACPI Multiprocessor PC HAL)... Invalid file!

[Ascii2]

5 hours ago, reboot12 said:

WinXPPAE 3.5 can't patch any SP2 hal version:

Patching halmacpi.dll (ACPI Multiprocessor PC HAL)... Invalid file!

Yes. I was getting rather tired when I wrote that and the post to you and did not proofread the post well enough.  I had originally started writing around that quoted question, but then tried to patch the SP2 HALs myself to check.

Something I wanted to ask, but forgot, is:
Whether it is important for you to stay on an old Windows XP Service Pack 2 level kernel?
If not, you might try a newer kernel version (and other possibly other updates).

[j7n]

Does this promise anything more than has been possible in Server 2003 without patching?

[user57]

is someone making that test spoken of ? like j7n did with server 2003 x32 bit´s (its a XP based OS)
someone has to disable the pagefile (because theoretical windows can also pass the 4 GB using a pagefile, a pagefile is just data on a harddrive/HDD/SSD)
then someone has to use up more then 4 GB of ram, it would be a good indicator, but perfect would be to look of the pages are really in the upper 4 GB ram

i meant to turn off the pagefile quite often - but then it didnt do that anyways the pagefile was still not offline 

maybe daniel k. should say something about this 

he wrote in a other post that in his opinion both ntoskrnl and hal has to be changed to make xp able to do the 64 GB (dibya said the oposite for example) - who knows who is right 
daniel k.writes that he modified hal and ntoskrnl
(that suggest that that ntoskrnl´s and hal.dll are patched)
also he mention symbol files - that also suggest that a ntoskrnl version and a hal version was used
to do so you cant just select the patched ntoskrnl.exe and hal.dll by a symbol file searcher
you have to figure out what version that ntoskrnl and hal are... then you have to force the disassembler to use the file from the non patched version
the filecompare tool will find the changes if you have the right ntoskrnl and hal therefore

also daniel k. wrote that he used the free space method for doing the patch
this can be risky because some codes only access some free space sometimes, or on certain conditions (this often makes random crashes)
a better solution is to add a section or increase a section - you have to know what you do here but - you quickly can kill the files like that if you dont know what you are doing

are there more then 3 versions to do so ? its gambling around like "dibya´s" "the russian one" and the "daniel k. one"

 

[Ascii2]

15 hours ago, j7n said:

Does this promise anything more than has been possible in Server 2003 without patching?

It does not.