Gary, YOUR CAVEAT is incorrect based on my experience...Forgive me but what is the difference between the 4_gb patch making fs9.exe largeaddress aware or using cff explorer. The author explicitly states he wrote the tool for those not comfortable with CFF explorer... If you dissect it, all it does is add the flag.I used it for years with my 32 bit systems before upgrading to XP64. Your reasoning is because you do not know if you can back out the changes however it makes a backup before it does anything so there is no need to ever back out your changes.If he were running XP 64 he would not have the issue with his video card "stealing" memory from his system. Inherently XP 64 addresses that although it obviously doesn't inherently address a 32 bit apps limitations....BTW, the link I provided is to the same tool and it isNOT for 64 bit systems with 4 gigs of memory only. Nowhere is anything mentioned about 4 gigs of physical memory...This very little tool patches x86 executables in order to let them have 4GB (instead of only 2) of virtual memory It has the same effect on a 32 bit or 64 bit OS period.

In order to achieve this, a flag has to be set in the file's internal format. This is, of course, very easy for insiders who do it every day with the CFF Explorer. This tool was written because not everybody is an insider, and most probably a lot of people don't even know that this can be achieved. Even I wouldn't have written this tool if someone didn't explicitly ask me to.

What the author states about (x86) and (x64) is equally applicable to 32 bit, it is just setting a flag.PS XP does allocate Video memory, only after MS figured out their initial blunder with D3D HW manufacturers capped the amount of mappable video memory to 256mb. Modern apps now dynamically map in Vista and Win7 Quote :

The Growth of VRAMThe Growth of VRAMAnother factor in the PC memory equation has been growing as well: video memory size. In the early days of Direct3D, the typical video card had 16 or 32 MB of Video RAM (VRAM). High-end video cards now have 512 MB, 640 MB, 768 MB, or more VRAM. When video cards had 16 or 32 MB of Video RAM, this memory was mapped directly into every process that used Direct3D for efficient access by the application and video

driver.As video cards grew larger, this became unsustainable. A 768 MB hole in the 2-GB virtual address space of each process would leave very little space for applications. Similarly, taking 768 MB out of the 4 GB physical address space would be too constraining. This problem is exacerbated in dual GPU configurations (SLI®/Crossfire™).Therefore, video card manufacturers typically implement a 256 MB physical memory window for the video graphics memory, and modern drivers do not create direct process mappings for the entire VRAM size. Process address space is still consumed for working with the AGP aperture (64 MB, 128 MB, or more typically on modern game systems 256 MB in size). While PCIe uses a dynamic aperture, it too is mapped into each process that uses Direct3D. Beyond the direct impact of growing VRAM sizes, more process memory is needed to maintain the backing-store for handling “lost-device” situations so for textures, geometry, and other static data, filling up such large video cards and still fitting under the 2 GB limit is extremely challenging.The Windows Vista Display Driver Model (WDDM) was designed to address the lost device limitations inherent to the Windows XP Display Model (XPDM), allowing more efficient sharing of the GPU by multiple applications. WDDM does not require the entire 256 MB aperture be mapped in to the process space.Instead, it dynamically grows the amount as the VRAM allocated by the application increases. For Direct3D 10 applications, this eliminates the need to maintain two copies of resources like textures in memory, one for the VRAM and one in the backing-store for lost-device cases. The system deals with migrating the one copy between memory and the video card, as needed.Unfortunately, to maintain application compatibility with Direct3D 9 running on Windows XP, two copies of managed resources were still maintained for Direct3D 9 applications running on Windows Vista. This also required process space for maintaining resources like render frame buffers. Previously, render frame buffers were simply lost and recreated. Therefore, they did not require any process space under WDM.Since the elimination of the 256 MB aperture returned 256 MB of virtual address space to applications on WDDM that was already budgeted for under WDM, this change did not cause any problems until video cards with more than 256 MB of VRAM became available. Small games still had plenty of that 2 GB address space available, but many modern AAA PC titles were running out of space on WDDM.7 The WDDM VA hotfix (KB940105 for Windows Vista, included in Service Pack 1) 8 gives a bit of breathing room by only mapping video resources into the process that need direct CPU access. Games that use Direct3D 10 also have decreased memory pressure without the extra copies required for “device lost” handling.However, high-end games in development are routinely hitting the 2 GB wall even on Windows XP. In fact, this incident proves that many modern AAA PC titles are already within 256 MB of the 2 GB barrier. Otherwise, they would not have hit this problem until video cards were over 512 MB.

Edited February 24, 201214 yr by psolk

Hello "psolk":To achieve a better understanding of this topic, I quote the the authors documentation on his web page for "4GB Patch":"4GB PatchCurrent Version: 1.0.0.1 I originally wrote this tool for a friend of mine who needed it. This very little tool patches x86 executables in order to let them have 4GB (instead of only 2) of virtual memory on x64 platforms. This tool comes very handy for applications which need a great amount of virtual memory like games, 3D renderization, multimedia etc. To gain these 2GB, you just have to use this tool to patch the executable (*.exe file) of the software you want to have these additional GBs of virtual memory. It can be used by clicking on it and choosing the file or through command line (e.g.: "4gb_patch file.exe"). It automatically creates a backup copy of the original executable.Why things are this way on x64 is easy to explain. On x86 applications have 2GB of virtual memory out of 4GB (the other 2GB are reserved for the system). On x64 these two other GB can now be accessed by 32bit applications. In order to achieve this, a flag has to be set in the file's internal format. This is, of course, very easy for insiders who do it every day with the CFF Explorer. This tool was written because not everybody is an insider, and most probably a lot of people don't even know that this can be achieved. Even I wouldn't have written this tool if someone didn't explicitly ask me to."NOTE: I did not see a specific statement on his web page by the author on the applicability of this patch for Windows 32-bit systems, and it is my understanding from MS-Windows documentation that 32-bit apps such as FS9.exe cannot access memory addresses beyond a max of 3GB (without PAE etc.).And of course, since real world USERVA for 32-bit Windows is usually stated to be a max of 2650 MB in Boot.ini, I considered it more appropriate to recommend users to not invite potential trouble by instead using specific parameters matching the limitations of 32-bit apps for use of max 3GB RAM with 2650 USERVA... via setting of the "/3GB Switch" in Boot.ini in 32-bit Windows XP.However, I am also very interested to know what your personal experiences have been after applying the above "4GB Patch" to a 32-bit Win XP Pro installation of FS2004, and I certainly do appreciate and respect your good intentions in sharing insights here... with a goal of keeping a complex procedure as simple as possible to help folks. :smile:I have personally not had time to research all possible changes made in my Windows XP 32-bit FS9 installation and functionality by testing use of the "4GB Patch" more than "1" time. :(FYI: My first attempted restart of FS9 crashed the first time after I applied the "4GB Patch" (probably that test used the very first release of that utility years ago).Since that failed first test of applying the "4GB Patch", I had simply restored my last used FS9.exe... and instead applied the manual "Large_Address_Aware" flag... using "CFF Explorer" in conjunction with the "/3GB Switch" in Boot.ini.Would you please be so kind as to explain further, what specifically you have found to be changed by use of the above "4GB Patch" to a 32-bit installation of Windows XP Pro ? :(BTW: If indeed the results of the manual CFF Explorer edits in my linked tutorial above, and use of the "4GB Patch" are identical, then I would of course recommend in the future, that the latter 'automated' "4GB Patch" be used on FS9.exe instead of the laborious and potentially confusing / risky manual CFF Explorer edit procedure.Thanks for sharing your experiences to improve the FS knowledge base here while helping fellow flight simmers ! :(PS: I see our posts and multiple edits have "crossed" on the AVSIM servers... such that we are somewhat 'out of synch'.Please be assured my goal here is only to help convey helpful info, and of course to have that info both correct and easy to follow for all... including those less familiar with the many intricacies of Windows configuration.Regrettably, I have some pressing commitments that require me to be away for a few days, and for which I must depart ASAP.I welcome any correction and clarification which conveys a better solution for FS users, and I apologize if my posts thus far may have presented a solution which was less than helpful, as my good intentions here are quite sincere.I do hope my offerings will not be construed as an intent to hijack the thread, or to cast aspersions on psolk's helpful contributions prior to my joining the thread.I'd hope we might achieve a clearer consensus in the future of this thread, which would be beneficial to all, and as I must now depart, I understand the dreaded "AVSIM editing time-out" will likely be imposed; so I anticipate I may be unable to "edit" and add anything further 'in context'... until I return in a few days.Best wishes to the OP and to psolk in resolving the issues under discusssion here... and happy flying in the mean time! B)GaryGB

Edited February 24, 201214 yr by GaryGB

Hi Gary,Thank you very much for your highly appropriate and politically correct and amicable response :) I apologize if I came across confrontational in ANY way, I was writing that as I was finding out a customer lost budget for a big sale...Apologies again for the abrasiveness of my post, you are correct, we are all here to share our experiences and help each other out. Mea Culpa...Going from memory I don't remember any adverse affects on my old 32 bit box. All the .exe appeared to do was add the same flag we were all adding manually through CFF.... Unfortunately we are talking 4 years ago now as I think I upgraded to XP64 about 2008 due to all the VAS issues in XP. :( I DO still have an XP boot option on my test box. I would be more than happy to re-install FS9 and do some testing to ensure we are all providing accurate information...I think part of the issue is just the author's original description. If it is indeed a largeaddressaware flag setter then call it that. The flag says use 4 gb the /3gb boot.ini both extends and limits it to 3... If you think about it, we set the same exact flag for XP32 and XP64, the difference is indeed in the Boot.ini and the /3gb userva= option in XP... That is what limits things back down in XP opposed to leaving it wide open in XP64...Thank you again Gary,All the best,-PaulP.S tried to edit my original post to lose some of the attitude :(

Edited February 24, 201214 yr by psolk

Hi Paul:No problem... have a good weekend. :smile:Gotta run now, so perhaps we might connect again next week... Regards,GaryGB

According to Microsoft the /3GB patch (4GT) is is supported on the following pre-Vista systems:

• Windows Server 2003
• Windows XP Professional

http://msdn.microsoft.com/en-us/library/windows/desktop/bb613473(v=vs.85).aspx

Daniel (aka "IAF747"):I don't see a clear statement as to whether you're using a 32-bit or 64-bit version of Windows XP, but I supect it is a 32-bit version. :(CAVEAT: DO NOT use the "4-GB Patch" with a Windows XP 32-bit version installationThe "4-GB Patch" is for Windows 64-bit versions ONLY with 4 or more GB RAM !).BTW: For Windows 64-bit systems ONLY with 4 or more GB RAM, that utility is here:http://www.ntcore.com/4gb_patch.phpInstead, for Windows XP 32-bit, use the "/3GB Switch" in Boot.ini along with manually setting the FS9.exe file "Large_Address_Aware" flag... as shown in tutorial I wrote ...here: :(http://forum.simflig...the-3gb-switch/FYI: Both tweaks described immediately above work on a 2-GB RAM (...or more) 32-bit Windows FS install to reduce OOMs. :(Restore a backup of the last "FS9.exe" used prior to applying the automatic "4-GB Patch" (whether it was a RTM FS2004 version 9.0 , FS2004 version 9.1 patched "FS9.exe", or either "NO-CD" patched "FS9.exe"); that will then be the one to which you will apply the "Large_Address_Aware" flag... using "CFF Explorer" as shown in the linked tutorial above.WHY: I am not certain if one can find / manually remove all changes 'automatically' made by the "4GB Patch" utility.PS: AFAIK, AGP and PCI-Express video cards graphics data do NOT get 'cached' (read: "virtualized" in its entirety) from VRAM up into system RAM in Wiindows XP (although AGP "tries" to reserve contiguous address space blocks via ones AGP Aperture size BIOS setting).But, graphics data does get "virtualized" from VRAM up into system RAM in Windows Vista and Win-7 (both 32-bit and 64-bit versions).This video caching behavior consumes RAM otherwise needed by FS (thereby leaving less address space available in physical RAM, increasing potential reliance on the Windows virtual memory swap / paging file activity when FS scenery detail and aircraft / add-on complexity is set very high, or flight duration is very long ! ). :wink:Hope this helps ! :smile:GaryGB

Thanks Gary!Am heading in that direction, thanks!Maybe 'psolk' can add his first name to his signature? He seems to use your name so I think 'psolk' unless your parents cursed you with a swedish name or something, please tell us your name!It is great to have so much help on here!Cheers

According to Microsoft the /3GB patch (4GT) is is supported on the following pre-Vista systems:

• Windows Server 2003
• Windows XP Professional

http://msdn.microsof...3(v=vs.85).aspx

I don't have XP Professional on my desktop. It is 32 bit XP Home.To further confuse things it doesn't specify XP Professional here: http://support.microsoft.com/kb/833721And then to help me clean my boot mess up (Yes since I got rid of a Windows 7 trial the wrong way-the delete button!) I downloaded EasyBCD : http://windows7forums.com/windows-7-support/2950-windows-7-boot-ini-file.html

Edited February 24, 201214 yr by IAF747

Success!!!The boot.ini file is confirmed in msconfig.But I don't know how to confirm the largeaddressawareBut I did follow it to Gary's discipline of exactness. I saved it in CFF browser.Heathrow (UK2000) just looks beautiful at night!!!!Thanks for your help! 'Psolk', Gary, Tom and 'mgh'....I think FS9 will still be going in 2020 in my home!!I didn't get the white screens in outside views anymore.

Edited February 24, 201214 yr by IAF747

Thank you again Gary,All the best,-Paul

Hi Paul:No problem... have a good weekend.

Glad you got it sorted. I prefer not to have my name in my sig though thanks :(

Glad you got it sorted. I prefer not to have my name in my sig though thanks :(

OK. We will call you 'Agent' Psolk. Have you seen the latest version of Tinker Taylor Soldier Spy? I didn't really get excited about that too much. I want to see the Alec Guiness version......

Hi All:Upon my return, I began gathering more info on the topics discussed in this thread in between attending to other commitments. :Idea:I can confirm that the "4 GB Patch" does set the attribute flag in an original, unedited FS9.exe to "App can handle > 2GB address space" just as one can do with the manual CFF Explorer procedural edit, although a a hexadecimal comparison of the resulting FS9.exe files with the "Beyond Compare" utility shows some differences (as a non-programmer, I do not yet understand the significance ... or in-significance.. of those differences !)However, initial run time functional testing of a original un-altered FS9.exe which is then edited with the 4 GB patch, thus far shows no unusual behavior when also used in conjunction with the "/3GB Switch" in the Boot.ini file of Windows XP Pro 32-bit. :Thinking:Pending further personal testing and correlative testing results by others here, I may update my tutorial linked above to substitute use of the automated "4 GB Patch" in place of the manual procedure using CFF Explorer.Hopefully we might establish a concensus here on configuration options to decrease OOMs in FS9 after additional correlation between FS9 users on several 32-bit Windows installations with use of the "IMAGE_FILE_LARGE_ADDRESS_AWARE" flag in the image header of FS9.EXE (aka "4-Gigabyte Tuning") within a Windows 32-bit User-mode virtual address space configured with the "/3 GB Switch". :Nerd:Thanks again to Paul for any additional detailed input he might share here, and my apologies as well for any justifiable umbrage evoked by the initial bad form of my opening statement first posted to this thread in a moment of haste, having (once again) overcommitted my available time on that day.Regards, and happy flying ! :smile:GaryGB

Edited March 5, 201214 yr by GaryGB