lama Posted July 6, 2009 Posted July 6, 2009 (edited) This patch was around here since April but I just got my eye on it NOW! 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 July 6, 2009 by lama
lama Posted July 6, 2009 Author Posted July 6, 2009 [request] If this ever works out for someone, please post your replies here...
Kelsenellenelvian Posted July 6, 2009 Posted July 6, 2009 EwwwwwwwwwwwThats a real nasty and error prone solution...
lama Posted July 6, 2009 Author Posted July 6, 2009 (edited) EwwwwwwwwwwwThats 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 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 July 6, 2009 by lama
MagicAndre1981 Posted July 6, 2009 Posted July 6, 2009 this was already discussed here:http://www.msfn.org/board/index.php?showtopic=133516it is possible, but not licensed by MSFT for client operating systems.
dencorso Posted July 6, 2009 Posted July 6, 2009 (edited) 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! Edited July 7, 2009 by dencorso
cluberti Posted July 6, 2009 Posted July 6, 2009 this was already discussed here:http://www.msfn.org/board/index.php?showtopic=133516it 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.
MagicAndre1981 Posted July 7, 2009 Posted July 7, 2009 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.
palhan Posted July 7, 2009 Posted July 7, 2009 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.mspx1. Server ConsolidationA 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.
cluberti Posted July 7, 2009 Posted July 7, 2009 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.
palhan Posted July 7, 2009 Posted July 7, 2009 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.
cluberti Posted July 7, 2009 Posted July 7, 2009 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.
lama Posted July 8, 2009 Author Posted July 8, 2009 (edited) 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! 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 RAM1. RamDisk Plus 2. Romex's RamDisk3. 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 canEDIT: Thanks for keeping your signature cool (it did help me install 9x so thanks again ) Edited July 8, 2009 by lama
dencorso Posted July 9, 2009 Posted July 9, 2009 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 RAMNo, 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!
lama Posted July 9, 2009 Author Posted July 9, 2009 downloaded long time back (while i saw first few lines and replied)
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now