Virtuali-Umberto, Important Question Regarding Virtual Address Space

[Alferra]

All this while I have read how users overflow the glass of water with the drop of an additional scenery. You have rightfully been insistent about proceeding from a wrong assumption.
I downloaded the Process Explorer over the weekend from here

https://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

A must have for any Flight Simmer. With it, I was able to appreciate how right off the bat loading FSX with a simple addon can use up to 2.6 G of the 4 available with an aircraft like the PMDG. More important, I can appreciate how flying into a scenery area like an airport by FSDREAMTEAM can add maybe 300,000 to the Virtual Address Space in FSX. Most of us fly with weather, texture detail, fancy airplanes (The PMDG alone is about 800,000), sceneries, and all these things add up pretty quickly. I would be willing to bet most of us routinely run FSX with about 3.5 of the 4.0 available VAS, of which less than 10 percent is the scenery of any airport.

Now the question: I stumbled accross this:

http://blogs.citrix.com/2011/10/13/wow64-memory-mapping-of-32bit-apps-running-on-a-64bit-windows/

Umberto, you are a wizard and genius in all of this, how possible do you think it would be that FSX 32 bit can be made to use more than 4.0 G ?

[virtuali]

http://blogs.citrix.com/2011/10/13/wow64-memory-mapping-of-32bit-apps-running-on-a-64bit-windows/

Umberto, you are a wizard and genius in all of this, how possible do you think it would be that FSX 32 bit can be made to use more than 4.0 G ?

The article is a bit misleading or not very clear.

The author tested several *separate* 32 bit processes, and he proved that Windows 64 bit does a good job allowing to use more then 4GB in total. But this is not news. Under Windows 64 bit, EACH separate process can address UP TO 4GB in its own "Virtual Address Space". It's "Virtual", because the real address seen by the OS is somewhere in the 64 bit address space, but the application will only see a private 4GB area.

In fact, an user commented:

This shows that a 64 bit system can 32 bit processes up to the limit of its memory, but it does not indicate the individual 32 bit processes can ACCESS memory beyond the 4GB allocated to it. You have just demonstrated that the 64 bit operating system can map 32 bit processes to any area of physical memory within its address space, which is to be expected. Each of those 32 bit processes is STILL limited to 4G of physical memory, as indicated by your status display.

And the author replied:

thanks for your comment, but I think you got me wrong (maybe I have to rephrase parts of the blog). I just wanted to find out whether an 32bit application can be loaded to memory adresses above 4GB or not

The 4GB limitation (provided the application has the IMAGE_FILE_LARGE_ADDRESS_AWARE flag set, otherwise it's only 2GB) it's something we must live with, and cannot be bypassed with any software trick.

The only thing we can do, as developers, is trying to move AWAY from FSX in-process as much as possible of our code.

That's what we do with our Couatl engine.

Years ago, lots of interactivity in our products was provided by the Add-on Manager, which is an in-process FSX .DLL, so it will have to share VAS space with FSX.

Today, the Add-on Manager has become dumber and dumber, and most of the work is made by Couatl, which is an out-of-process .EXE, so it has ITS OWN 2GB address space, and it doesn't take away precious VAS from FSX, regardless how complex its code became. And it's fairly complex now, considering the whole GSX logic runs inside it.

[Alferra]

Wait a minute Umberto, totally agree with everything you said, but are you saying that all this while my EZ DOK camera addon is adding in the FSX usage ? it is almost 400,000. It is an addon but I thought it was separate usage.

Here is what I do to prevent memory overflows, besides playing with the sliders:

1) Use as few views as I possibly can.

2) Upon FSX startup before loading, in the scenery library I check only the scenery areas and airports that I will be using from origin to destination, unchecking overflight areas and airports. The remote areas are also unchecked, so as to load as few scenery areas as possible.

3) Upon completion of a single flight segment, restart FSX and repeat the process for the next flight. Otherwise the scenery memory will accumulate causing an overflow sooner than later.

4

[virtuali]

are you saying that all this while my EZ DOK camera addon is adding in the FSX usage ? it is almost 400,000. It is an addon but I thought it was separate usage.

If an add-on it's made of a .DLL that is loaded in the DLL.XML file, then it will take away VAS from FSX.

If an add-on it's an .EXE loaded with the EXE.XML or started manually, it will not share VAS with FSX.