[2/3] kernel32/heap: Fix some hacks in GlobalMemoryStatus(). (try 2)
amartinson at codeweavers.com
Fri Jun 3 14:10:30 CDT 2011
On 06/03/2011 01:33 PM, Dmitry Timoshkov wrote:
> Adam Martinson<amartinson at codeweavers.com> wrote:
>> The issue is that Dragon NaturallySpeaking 7 setup doesn't have the
>> IMAGE_FILE_LARGE_ADDRESS_AWARE flag set, but it uses InstallShield 6 as
>> a child process, which does have it set. IS6 calls GlobalMemoryStatus()
>> and passes the data back to DNS7 setup, and if you have more than 2GB
>> RAM DNS7 setup thinks you have negative memory. Windows figures this
>> out and rounds to 2GB, Wine does not.
> I'd suggest to write some tests and try to understand what does Windows
> and at which step.
I don't know of any way to do this with the current testing framework,
and I think the apps that require it (DNS7 is the only one I know of)
give us a clear enough picture. If there are other apps that need
specific things out of this kind of behavior then I'll try to figure out
some way to incorporate it in the tests.
>> The unset
>> IMAGE_FILE_LARGE_ADDRESS_AWARE flag is not inherited by the child
>> process (I did check), so this leads me to believe Windows must be doing
>> some sort of check like this when deciding to round. If there is a flaw
>> in my logic or there is a better way to do this I am all ears.
> Processes can't share their address spaces (using a shared memory mapping
> doesn't count) with other processes, if they would do, you certainly would
> be willing to use a different OS.
Ah, I thought you were talking about
I was trying to figure out how to exclude system processes if it was
called by an app process, etc, which seems like a reasonable thing to
do. Attached is a version which should appropriately limit the scope.
More information about the wine-devel