Get Windows XP x86 to recognize more than 4Gb with PAE?

[dencorso]

How to convert your Win 2k3... to a Workstation!

[player_1]

How to convert your Win 2k3... to a Workstation!

may i take it for granted that most softwares working on XP SP3 will work on 2k3 server?

 

I've been reading related topics and it seems no definite/confident solution has been derived

(i know it's hard, reversing kernel & require throughout OS knowledge)

so i'm thinking of 2k3, lifting ram limit without compatibility issues

Edited June 3, 2014 by player_1

[submix8c]

The answer to this

 

may i take it for granted that most softwares working on XP SP3 will work on 2k3 server?

 

I've been reading related topics and it seems no definite/confident solution has been derived

(i know it's hard, reversing kernel & require throughout OS knowledge)

so i'm thinking of 2k3, lifting ram limit without compatibility issues

 

...is although "some" will restrict even though it will work -after- a little nudge, e.g. change an MSI or extract and use stand-alone, or a "hack". I used a couple of "hacked" modules from one of these POSReady2009 modded updates and test-installed MediaPlayer11 for XP and it WORKS after modding the INF's!

http://www.msfn.org/board/topic/171814-posready-2009-updates-ported-to-windows-xp-sp3-enu/

This was on a test-install of Server2k3. I also copied the XP MovieMaker folder and the shortcut (set it to XP Compat Mode) and it also works.

 

Be informed that I'm not prepared to show what I did in this thread (since it's off-topic). Just giving FYI and some info.

 

HTH

[dencorso]

@player_1: I'd say the 2k3 way is one's best bet at lifting the RAM limit without losing system stability. Of course, since it was meant to be a server, conversion to desktop will require more than just a little tweaking, but should result in a lean, zero-bloat desktop, which I think is quite good. And there's a good guide to start from (which link I provided in a previous post). By creating a library of system images, and imaging the system regularly, and before each major tweaking session, of course, one can easily fall back from most mistakes, without having to restart from scratch. Moreover, this way one can do things in two or more different ways, while starting from exactly the same point, and compare results, when in doubt.

But, be aware, it definitely won't be anything like "instal and forget"... I believe you're well aware of that, but it must be said, anyway, for the benefit of any other user who happens to wander into this thread in the future.

[jaclaz]

found another issue:

patched kernel (with any hal) makes EAC can't read Virtual Drive created with Daemon Tools.

Well, is the issue:

1. EAC+Daemon Tools
2. *any program* dealing with CD/DVD's+Daemon Tools
3. EAC+*any* Virtual CD/DVD driver known to mankind (among the many MS virtual CD, IMDISK, WinCDemu, Total Mounter)
4. *any program* dealing with CD/DVD's++*any* Virtual CD/DVD driver known to mankind (among the many MS virtual CD, IMDISK, WinCDemu, Total Mounter)

If #1 or #2 it seems to me not such a big deal (just use something else that works instead of Daemon Tools ).

 

If #3 or #4 then it may be an issue or a serious issue.

 

jaclaz

[noric]

Great thread! I have been trying your suggestions and they do work (at least on my VM).
 
Now I've just taken a look at the Chinese XP64G 2.1 patch (downloadable here). The executable patches ntkrnlpa and hal.dll on the fly: it doesn't substitute your files with prepatched files, but patches YOUR files (very convenient if you have a localized edition of XP).
Now, the interesting part is that I've done a hex compare between pre-patch and patched files, and I've found out that more strings got patched than we have done here on msfn.org.
I have attached screenshots for both ntkrnlpa and hal.dll. You can see what the Chinese patch does.

 
What do you think about this?

[dencorso]

Great find!    And welcome to MSFN!

 

Now, just for the record, knowing 下载 means "download" does help some, at the site you gave a link to...
 

[noric]

Lol, you're right!

To sum up what we see in the screenshots:

1) the Chinese patches a few bites at the very beginning of the files (both ntkrnlpa and hal)

2) he writes 74xx where we write 9090.

 

Now, how to know what this means?

[jaclaz]

2) he writes 74xx where we write 9090.

Essentially:

• 74EB means the OPPOSITE of 75EB one is "jump if" and the other one is "jump if not" (or viceversa, cannot remember)
• 9090 means "do nothing"

 

jaclaz

[dencorso]

It sure means somebody has been working on refining the patch since we last discussed it.

You see, 75 means "jump when not zero", 74 means "jump when not zero", EB is an unconditional jump and 90 means "do nothing"... 

So, clearly the new patch inverts the sense of two jumps, instead of simply avoiding them...

But unfortunately most assembly is not so straightforward, so a good local disassembly would be needed, to get to the meaning of the new patches. And, even so, it'd demand quite some time. Now, the patches we knew did work, sort of, but had issues which remained unsolved.

Does this new Chinese mod work right? Does it solve the known issues? If so, we may even try to understand them better. But further testing is in order, before doing anything really time-consuming, don't you agree?

[noric]

Thanks guys for your insight.

You're right, dencorso, some testing ought to be done before studying the new patching method.

I also saw that the Chinese patch only changes usbport and usbhub drivers (using win2k3 versions), nothing more. Does this mean that usbvideo now works? I'm quite skeptycal, but who knows... Testing this patch is the only thing to do before speculating.

 

Oh, I forgot to thank you dencorso for the instructions you provided here. I was able to patch my localized files with that. I also used this (thanks to Acheron), otherwise the boot got stuck with the loading bar loading over and over.

[dencorso]

You're welcome!

 

When appropriately unique hexstrings can be found, patching by hexstring search and instruction replace is very reliable, and quite robust to localization... and to updated versions of files. Glad you found it useful.

 

BTW, the older XP64G.EXE I had on archive is v. 1.0.0.1, from 2011, while the one inside the file you gave a link to is v. 1.0.0.2, from 2013...

so, obviously the unnamed developer worked two full years before releasing the new version, and this may conceivably reflect a lot of work done (although it might also mean, among other possibilities, the project was shelved then, lay dormant for some time and was restarted recently, of course) ...

[xrayer]

Hi,

I'm also interested in patching WinXP PAE. Not because of a deficit of memory (my MB with initel P31 cannot install >4GB anyway) but more just because curiosity. I was, till now, in belive that only Vista/7-32b can be easily unlocked and XP is missing the necessary PAE code. 1st I found a thread on overclock.net and then links here and to China sites. The patch was there probably since 2011!

 

So I did some testings on 2 machines:

home: C2D E8600, 4GB RAM, Nvidia 7900GT 256MB, RTL8111 NIC, SB Audigy, FlyDVB Duo PCI, WinXP SP3 CZ, most up to date

work: core i7 750, 8GB RAM, Nvidia GF210 512MB, RTL8111 NIC, RT HD Audio, WinXP SP3 CZ, most up to date

 

Tested patches: scdeny XP64G 2.1, Dencorso manual search & replace parch of kernel & hal, patched english and chinese kernel & hal from overclock.net

I was a bit suspicios about running chinese XP64G patch so I made MD5 sum of all windows files but none was modified by patch itself. It just create copy of kernel and hal files, patch them and add new boot entry so it's noninvasive and clean. I also used latest usb*.sys drivers from Win2k3 server as suggested.

 

Results: in all cases I got working PAE in meaning of visible full 4 resp. 8GB on both machines. At home machine I got a crash (imediate reboot) one time when I launched BlazeDVB-T software for digital tuner. It was with XP64G patch. But I cannot more reproduce this bug. I use the patch 1 week and no further problems. On machine at work I tried to fill up all 8GB and even more to beinig swapping but it withstand the load. I also measured 2D gfx performance with Tom2D benchmark but dind't find significant diffs. Even curiusly with PAE I got slightly higher GDI score than in standard mode. Here are some screens http://rayer.g6.cz/1tmp/xppae/ I read that the patch may cause BSODs when using unpatched usb drivers but I didn't encounter this problem. I tried copy data to usb flash before I overwrite usb*.sys drivers. Also realtek NIC driver was blamed as source of BSOD but I didn't get any (I used older version from 2009, now upgraded to 2014 - the driver is claimed to be common with Win2k3 so I would expect it's PAE proof). But I don't run any server with heavy load and many connections. Just common browsing and file downloads - no problem.

I also read about possibility of use hal.dll from XP SP1. I grab the correct one, unpatched, but it cause immediate reboot when I tried to load it with patched kernel.

 

Does anybody proved some different behavior between Dencorso and scdeny XP64G patch? It patches different bytes. Here's my diff:

Comparing files: NTKRNLPA.EXE <-> ntkl64g.exeFFC ERROR at offset 312 (138h): 17h <-> 16hFFC ERROR at offset 313 (139h): 34h <-> 33h (4 <-> 3)FFC ERROR at offset 1437466 (15EF1Ah): 75h <-> 74h (u <-> t)FFC ERROR at offset 1784401 (1B3A51h): 75h <-> 74h (u <-> t)FFC found 4 ERRORSComparing files: HAL.DLL <-> hal64g.dllFFC ERROR at offset 320 (140h): E7h <-> A7h (š <-> ž)FFC ERROR at offset 321 (141h): F2h <-> CBh (? <-> -)FFC ERROR at offset 96275 (17813h): 74h <-> EBh (t <-> U)FFC ERROR at offset 122111 (1DCFFh): 10h <-> 30hFFC ERROR at offset 122113 (1DD01h): 00h <-> FFhFFC ERROR at offset 122114 (1DD02h): 00h <-> FFhFFC ERROR at offset 122115 (1DD03h): 00h <-> FFhFFC ERROR at offset 122116 (1DD04h): 01h <-> FFhFFC ERROR at offset 122124 (1DD0Ch): 40h <-> 00hFFC ERROR at offset 122125 (1DD0Dh): 00h <-> 40hFFC ERROR at offset 122131 (1DD13h): 01h <-> 03hFFC found 11 ERRORS

 

I'm not sure what this patch on hal.dll really do - if it forces all (even PAE capable) drivers to use DMA doublebuffer to keep safe?

I continue with testing having it as a default boot setup and report if some BSOD occur.

[xrayer]

BTW I compared results of both XP64G 2.0 and 2.1 and it does the same patching job, only 2.1 adds usb*.sys drivers (it contains sp3.cab ~11MB so this is the reason why it inflated so big). Ver 2.1 can be also run standalone (the small exe) without usb*.sys drivers and then you can decide to patch the drivers yourself.

[noric]

Hi xrayer,

check the screens I posted yesterday, if you haven't already seen them. I pretty much found the same info as you. I'm on a localized version (italian).

Considering what you found here:

 

Comparing files: NTKRNLPA.EXE <-> ntkl64g.exe
FFC ERROR at offset 312 (138h): 17h <-> 16h
FFC ERROR at offset 313 (139h): 34h <-> 33h (4 <-> 3)

and what I found in the same position, we can assume the patch lowers those values by 1. Those values also depend on the localization.

 

About this:

 

Comparing files: HAL.DLL <-> hal64g.dll
FFC ERROR at offset 320 (140h): E7h <-> A7h (š <-> ž)
FFC ERROR at offset 321 (141h): F2h <-> CBh (? <-> -)

it seems to me that the patch does F2E7 - 2740 = CBA7

Confirmed if you look at my screenshot: for my localization it's 812C - 2740 = 59EC

This can't be random...