• Announcements

    • xper

      MSFN Sponsorship and AdBlockers!   07/10/2016

      Dear members, MSFN is made available via subscriptions, donations and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, become a site sponsor and ads will be disabled automatically and by subscribing you get other sponsor benefits.
lama

[32Bit or x86] Use more memory above 3.25GB

24 posts in this topic

This patch was around here since April but I just got my eye on it NOW! :thumbup

http://zh-deepxw.blogspot.com/2009/04/readyfor4gb.html (Direct Download Link)

If I'm understanding this right, the requirements are PAE hardware + Vista/Win7 (XP not supported)

For XPx86 systems, there is this workaround so softwares get memory above 3.25GB:

Some special RamDisks use PAE to address range beyond the limit (SuperSpeed's RamDisk Plus and Romex's RamDisk does that for NT OSes (XP and Vista) R. Loew's RamDisk64 does that for lagacy OSes (Win98,98SE,ME).

Once you install the ramdisk, you can set your PageFile path to that drive (set up Min and Max input according to the size of your RamDisk size). If you further need the pagefile on HDD, you can do it otherwise, its good to never see that kind of file in HDD. After next restart, you can test out any of your memory hogging program and get surprised

you can also optimize your system by transferring "TEMP" folder, "Temporary Internet Files" or "Cache" folder of Opera/Mozilla to RamDisk and enjoy the super speed installations and web surfing!

This serves the main goal: give softwares more memory :)

Edited by lama
0

Share this post


Link to post
Share on other sites

[request] If this ever works out for someone, please post your replies here...

0

Share this post


Link to post
Share on other sites

Ewwwwwwwwwww

Thats a real nasty and error prone solution...

0

Share this post


Link to post
Share on other sites
Ewwwwwwwwwww

Thats a real nasty and error prone solution...

Agree (with XP) but what about Win7 and Vista??? Its a patch and gets the job done :)

For 64Bit users, its best you remain there and new users should be encouraged for X64 anyways :D

EDIT: I was checking out the CAT DOG fight in this forum.thread and thought since this place has some lagacy and new patch projects, it may give them some idea to automatically make WinSetup address more memory (VLite or 7Lite when it comes) can be cool if it becomes less ugly though

Edited by lama
0

Share this post


Link to post
Share on other sites
For XPx86 systems, there is this workaround so softwares get memory above 3.25GB:

Some special RamDisks use PAE to address range beyond the limit (SuperSpeed's RamDisk Plus and Romex's RamDisk does that for NT OSes (XP and Vista) R. Loew's RamDisk64 does that for lagacy OSes (Win98,98SE,ME)

For the NT-family OSes that can also be achieved using the free Gavotte's Rramdisk, that you did not mention.

And, believe me, it does rock! :yes:

Edited by dencorso
0

Share this post


Link to post
Share on other sites
this was already discussed here:

http://www.msfn.org/board/index.php?showtopic=133516

it is possible, but not licensed by MSFT for client operating systems.

While Geoff Chappell's page (that you linked to) is technically accurate on what he discusses, he still fails to mention that you cannot (at least on Windows via the Win32 API) run an executable code block with an address above the 32bit boundary, because the 32bit CPU's registers won't be able to store an address that maps that high. PAE still limits you to a 4GB window, no matter where you slice it, although you can place it higher (above the 4GB boundary, for instance), to load a 32bit app's 2 or 3GB of VA (and the 2 or 1GB kernel VA) into that range when it's loaded. It's overhead for the OS (although probably not much, especially with today's processing speed and multi-core setups), and one that Microsoft only plans to support (or, to be more accurate, planned, as Server 2008 R2 is x64 only, and Win7 will very likely be the last x86 client) on server-class OSes. The RAMDisk drivers that get discussed, while good and useful, still suffer some drawbacks being PSE-36, namely things like all I/O doing double-buffering, or not being able to "slide" the 4GB mapped window like you can with PAE and AWE.

Also, with PAE, you've got some issues with overhead in the memory manager itself when you do interprocess communication, TLB reloads on context switching - and a bit more for this on multi-CPU systems, as the TLB buffers have to be synched to make sure they're all accurate in their virtual to physical TLB mappings (although Windows APIs do allow batching of this by an application to try and reduce the perf hit this will cause), you're storing more information in the session view space in kernel for PTE space, even though the kernel is still the same size with or without PTE, so there can be kernel pool and session space cramping on large memory systems in 32bit, and there are more that are documented on technet and MSDN if you want to read up.

Or, you could use an x64 OS and not have any of the overhead or restrictions of the Windows platform with regards to PAE and run everything natively (or in WOW64 isolation for a 32bit app, of course - with the side benefit that any 32bit app compiled LARGEADDRESSAWARE actually can use 4GB of VA instead of 3GB because there's no kernel space in the 32bit VA in WOW64). This is obviously easier for developers to handle, and there are other benefits above and beyond that x64 gives but that's outside the scope of this discussion.

Ultimately, does it matter? I dunno, I don't think most folks use more than 4GB anyway, and those of us that do are using x64 for reasons other than native support for more than 4GB memory. I still see it as the bridge Intel initially designed PAE (and PSE) for to allow for use of >4GB of RAM on x86 systems before they had their 64bit platform (Itanium) ready.

0

Share this post


Link to post
Share on other sites

I know, I only wanted to point out that it is possible to use more RAM, but it doesn't solve the issues with the x86 architecture.

But I still don't understand why you banned Geoff Chappell here on the board.

@lama

NeoWin is a spamming board with stupid children without technical background.

0

Share this post


Link to post
Share on other sites
he still fails to mention that you cannot (at least on Windows via the Win32 API) run an executable code block with an address above the 32bit boundary, because the 32bit CPU's registers won't be able to store an address that maps that high.

Since software reference only virtual memory that will never be an issue. A VA can point anywhere in physical memory - also above 4G even if the registers are only 32bit wide.

http://www.microsoft.com/whdc/system/platf...PAE/pae_os.mspx

1. Server Consolidation

A PAE-enabled operating system should be capable of utilizing all physical memory provided by the system to load multiple applications; for example, App#1, App#2, App #N, each consisting of 4 GB (maximum) of virtual address. In a non-PAE enabled system, the result can be a great deal of paging, since maximum physical memory in the system is limited to 4 GB.

With the additional physical memory supported under PAE mode, an operating system can keep more of these applications in memory without paging. This is valuable in supporting server consolidation configurations, where support of multiple applications in a single server is typically required. Note that no application changes are required to support this capability.

0

Share this post


Link to post
Share on other sites
Since software reference only virtual memory that will never be an issue. A VA can point anywhere in physical memory - also above 4G even if the registers are only 32bit wide.
Correct, Windows does the translation. However, there's still a perf hit for the translation and the TLB shoot down. The app just isn't aware of it.
0

Share this post


Link to post
Share on other sites

There is also a bit more translation overhead in 64bit mode.

"run an executable code block with an address above the 32bit boundary" is also not entirely true. That only applies when you are using AWE.

0

Share this post


Link to post
Share on other sites
There is also a bit more translation overhead in 64bit mode.
True, but everything in x64 is a fastcall, and there are double the CPU registers. It tends to negate the perf hit for TLB translation in the end, especially for native Windows binaries. And again, there's the added benefit of 4GB of VA available in WOW64 for 32bit apps compiled aware, as well, although I don't know many desktop apps other than graphics programs that do this.
0

Share this post


Link to post
Share on other sites
For XPx86 systems, there is this workaround so softwares get memory above 3.25GB:

Some special RamDisks use PAE to address range beyond the limit (SuperSpeed's RamDisk Plus and Romex's RamDisk does that for NT OSes (XP and Vista) R. Loew's RamDisk64 does that for lagacy OSes (Win98,98SE,ME)

For the NT-family OSes that can also be achieved using the free Gavotte's Rramdisk, that you did not mention.

And, believe me, it does rock! :yes:

hmmm? the link you gave me shows some problem of FAT on Gavotte's RamDisk BUT, Thanks! for the information ofcourse :) Now I have 3 RamDisks that addresses space above 3.25GB RAM

1. RamDisk Plus

2. Romex's RamDisk

3. Gavotte's RamDisk :)

I still prefer RamDiskPlus cauz its a full feature ramDisk (saves RamImage on exit etc) but, I will explore more ramdisks as i can

EDIT: Thanks for keeping your signature cool (it did help me install 9x so thanks again :) )

Edited by lama
0

Share this post


Link to post
Share on other sites
hmmm? the link you gave me shows some problem of FAT on Gavotte's RamDisk BUT, Thanks! for the information ofcourse :) Now I have 3 RamDisks that addresses space above 3.25GB RAM
No, I did not. I gave you a link to the right thread, not to a specific post. My ideia was that you'd read the whole thread (it's not very long), to know more about Gavotte's Rramdisk. If you look for it there is a post there, by myself, with the latest version of Rramdisk attached. Cheers!
0

Share this post


Link to post
Share on other sites

downloaded long time back (while i saw first few lines and replied) :D

0

Share this post


Link to post
Share on other sites

Ewwwwwwwwwww

Thats a real nasty and error prone solution...

Agree (with XP) but what about Win7 and Vista??? Its a patch and gets the job done smile.gif

I know it's an old thread but I somewhat disagree with Kelsenellenelvian's opinion. The solution is exactly the same in case of both XP and Vista/7. You just remove the artificial limitation imposed by M$ about how much RAM the system is able to use with PAE enabled. I don't see anything nasty in it :w00t:

You can know that it's 100% artificial just by looking at Windows 2000 kernel files which are exactly the same in case of all different editions. The only difference is in the registry - when it's set to Professional you can use only 4GB of RAM, when it's set to Advanced Server you can use 8GB, and when it's set to Datacenter Server then you can use 32GB. There's no difference in the system files themselves. In case of Windows 2000 the situation is similar when it comes to how many CPUs / cores the system will use as the number differs according to the Windows 2000 edition you're using. blackwingcat has removed those limitations in his patches, and that's why you can use more RAM and utilise more CPUs / cores with his kernel installed.

I'm experimenting with XP at the moment and you can remove the max amount of RAM limitation by editing the kernel files. There's a problem though that the system default USB driver doesn't work after doing that. However, there's a way to work around it. 3rd party USB drivers do work which means that you can still use USB 3.0 so (as long as your PC has USB 3.0 ports) you can just use it for all USB devices and leave USB1.1/2.0 ports unused.

For 64Bit users, its best you remain there and new users should be encouraged for X64 anyways biggrin.gif

X64 may be "the future", trendy, jazzy, etc. but the real problem is that a lot of older hardware simply don't work in 64-bit systems due to lack of proper drivers. I'm definitely not going to throw away a perfectly working printer and scanner simply because they're not supported by the new OS -_-

0

Share this post


Link to post
Share on other sites

@MagicAndre1981: Great find! :yes:

For the record, for XP, there's a further problem because MS's crippled the hal, starting from SP2. So, for a patch to be useful, someone'd have to backport to the SP3 hal what has been removed from SP1. The main reference for this is daNIL (Galimov): read his replies to this blog entry, starting in 2009.

Until this is solved, PAE aware ramdisks are the most reliable solution, IMO.

0

Share this post


Link to post
Share on other sites

I've read the blog. You can use more RAM just by patching the kernel file. I don't know whether the older HAL fixes the USB driver problem because in my case it just doesn't work. Trying to use HAL from SP1a causes infinite reboot loop.

Ramdisks have different use :rolleyes: I like to split the RAM so that I can have 5GB for the OS and 3GB for a ramdisk. That's what I did in Windows 2000 and I'm trying to do now in XP. And yes, there are situations where running several programs at once or just one multi-threaded application can use all of the available 5GB RAM.

Edited by tomasz86
0

Share this post


Link to post
Share on other sites

I know you know what you do. But so does daNIL. He was the one who 1st decided to provide the > 4 GiB address patch for XP.
He gave up because of the problems with HAL.DLL. So that's definitive for me, and the issue with USB may be just the tip of the proverbial iceberg.
So, with all due respect, forgive me for asking but, are you *sure* you used the right HAL from SP1? Remember there are actually at least 5 varieties of hal for XP, and the one selected gets renamed (actually copied to) HAL.DLL. Now, while the file name changes to hal.dll, the original filename in the properties tab remains untouched, so that, by looking at it you may find the original name of hal.dll. The definitive reference on the main builds of hall.dll is this, of course, but it does not cover the security updates and hotfixes. What you describe makes me think you picked the wrong hall.dll to start with. Of course, I may be wrong. But there's no harm in double checking, so please do it.

0

Share this post


Link to post
Share on other sites

It seems to me that by the so called HAL problems he means exactly the USB driver issue, i.e. that with HAL from SP1 the USB driver worked:

you need to extract halmacpi.dll from XP SP1 distributive to system32 folder, and modify/add the boot.ini menu to include it like this

multi(0)disk(0)rdisk(0)partition(1)\WINNT=Windows XP Professional patched halsp1″ /pae /fastdetect /kernel=ntkrnlp2.exe /hal=halmacpi.dll

Not sure which hal.dll youre using, but it works ok on my pc, usb drives and DMA are working.

It seems that it was someone from China to mention the patch for the first time. At least here is the oldest entry from Google about it:

http://www.unpack.cn/thread-27735-1-1.html

As for the HAL itself, here is a good M$ article about it:

How to Troubleshoot Windows 2000 Hardware Abstraction Layer Issues

386 source file: i386\driver.cab\halmacpi.dll

Computer type: ACPI Multiprocessor PC

i386 source file: i386\driver.cab\halaacpi.dll

Computer type: ACPI Uniprocessor PC

i386 source file: i386\driver.cab\halacpi.dll

Computer type: Advanced Configuration and Power Interface (ACPI) PC

i386 source file: *i386\driver.cab\halsp.dll

Computer type: Compaq SystemPro Multiprocessor or 100% Compatible

i386 source file: *i386\driver.cab\halapic.dll

Computer type: MPS Uniprocessor PC

i386 source file: *i386\driver.cab\halmps.dll

Computer type: MPS Multiprocessor PC

i386 source file: *i386\driver.cab\hal.dll

Computer type: Standard PC

i386 source file: *i386\driver.cab\halborg.dll

Computer type: SGI mp

Copy to this folder: winnt\System32

Rename to this file name: hal.dll

I'm sure I tried to use the correct one which is halmacpi.dll (ACPI Multiprocessor PC) in my case. Of course I'm going to do more trials in the future.

At the moment I don't see any other issues except for the USB driver problem. I used PAE in Windows 2000 for a few years so I know more or less what to expect. Still more time is needed to check for everything.

Edited by tomasz86
0

Share this post


Link to post
Share on other sites

This may be relevant:

@TELVM: Many thanks to you for pointing into the right direction with the link! Much appreciated!!!

I tested it on XP SP3 with the hal.dll from XP SP1 and it worked. Be careful I have not done a lot of tests, but connecting a USB stick worked.
Be advised that the link patches another location very near my patching location. But in my opinion the patch from the link only enables up to 16 GB RAM instead of mine which should enable 64 GB RAM.

For XP SP3 we patch the following offset in ntkrpamp.exe which enables all available RAM up to 64 GB:
- WinDbg "bp nt!MiPagesInLoaderBlock+0x5d" from
e0d73851 751b jne nt!MiPagesInLoaderBlock+0x7a (e0d7386e)
to
e0d73851 90 nop
e0d73852 90 nop
- IDA from
INIT:005D0851 jnz short loc_5D086E
to
INIT:005D0851 nop
INIT:005D0852 nop
- hex editor offset 0x1B2A51 from
75 1B
to
90 90

After ntkrpamp.exe is changed we have to do the following to replace the original kernel file:
- correct the checksum of ntkrpamp.exe with LordPE
- add /PAE switch to boot.ini
Do not omit this step otherwise we can not address the full RAM! This is necessary, because
we will use hal.dll from XP SP1.
- replace the original kernel file by the patched one:
- rename the file "C:\Windows\Driver Cache\i386\driver.cab" to "driver.cab_"
- rename the file "C:\Windows\Driver Cache\i386\sp3.cab" to "sp3.cab_"
- rename the file "C:\Windows\system32\ntkrnlpa.exe" to "ntkrnlpa.exe_"
- cancel the "Windows File Protection" message box and choose "Yes"
- copy the patched file ntkrpamp.exe to "C:\Windows\system32\ntkrnlpa.exe"
- cancel the "Windows File Protection" message box and choose "Yes"
- rename the file "C:\Windows\system32\hal.dll" to "hal.dll_"
- copy hal.dll from XP SP1 (internal file name halmacpi.dll) to "C:\Windows\system32\hal.dll"
- do not forget to add the boot.ini switch /PAE, otherwise we can not address the full RAM,
because we use hal.dll from XP SP1
- reboot

Again many thanks to TELVM for clearing things up!


Reference: Windows XP Ram Limit posts #17 and 22 to the end.

Obs: 0x1B2A51 for 5.1.2600.5512 becomes 0x1B3A51 for 5.1.2600.6387...

0

Share this post


Link to post
Share on other sites

Thanks, dencorso :) It's very useful finding. I haven't done any more tests yet so can't tell more about the details so far, but:

But in my opinion the patch from the link only enables up to 16 GB RAM instead of mine which should enable 64 GB RAM.

This is because in the other patch ntkrnlpa.exe is hex edited like this:

1. Look for C:\WINDOWS\SYSTEM32\NTKRNLPA.EXE

Original : BB 00 00 10 00 33 FF 6A 07 8B F0
Modify To : BB 00 00 40 00 33 FF 6A 07 8B F0

(1000 is the Hex of 4096)
(4000 is the Hex of 16384)

If you set it to 4000 then it's no surprise that the maximum amount of RAM gets set to 16GB. You could probably experiment with other values. I've got only 8GB of RAM here so can't test anything more than this myself.

Edited by tomasz86
0

Share this post


Link to post
Share on other sites

Interesting thread, I made the jump to W7Ux32 on my birthday(legacy h/w,no 64 bit drivers) and if Resource Monitor is to be believed,

the upper gig of my new 4GiB build is being used by BIOS and hardware I'm happy with that and have enough faith in the construction

of the ADATA 60GiB SSD not to worry about it.

Am I living in a fools paradise?

:w00t:

0

Share this post


Link to post
Share on other sites

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.