Adam Martinson amartinson@codeweavers.com wrote:
+/* Check the current process and all ancestors that share its address space.
- Some apps run sub-processes that have the IMAGE_FILE_LARGE_ADDRESS_AWARE flag set, but
- the parent process doesn't (eg, Dragon NaturallySpeaking 7 setup runs Install Shield 6).
- If any don't have IMAGE_FILE_LARGE_ADDRESS_AWARE, return FALSE. */
My previous question still applies.
On 06/02/2011 03:11 PM, Dmitry Timoshkov wrote:
Adam Martinsonamartinson@codeweavers.com wrote:
+/* Check the current process and all ancestors that share its address space.
- Some apps run sub-processes that have the IMAGE_FILE_LARGE_ADDRESS_AWARE flag set, but
- the parent process doesn't (eg, Dragon NaturallySpeaking 7 setup runs Install Shield 6).
- If any don't have IMAGE_FILE_LARGE_ADDRESS_AWARE, return FALSE. */
My previous question still applies.
Your previous quesion:
How do the processes running in separate address spaces have anything
to do with that?
I thought I addressed that with this version of the patch, but if I'm not checking address space correctly, please tell me the correct way. PEB::InheritedAddressSpace doesn't work, I'm not sure what else I should be looking for.
Adam Martinson amartinson@codeweavers.com wrote:
Your previous quesion:
How do the processes running in separate address spaces have anything
to do with that?
I thought I addressed that with this version of the patch, but if I'm not checking address space correctly, please tell me the correct way. PEB::InheritedAddressSpace doesn't work, I'm not sure what else I should be looking for.
Fortunately win32 is not DOS.
On 06/03/2011 03:41 AM, Dmitry Timoshkov wrote:
Adam Martinsonamartinson@codeweavers.com wrote:
Your previous quesion:
How do the processes running in separate address spaces have anything
to do with that?
I thought I addressed that with this version of the patch, but if I'm not checking address space correctly, please tell me the correct way. PEB::InheritedAddressSpace doesn't work, I'm not sure what else I should be looking for.
Fortunately win32 is not DOS.
Unfortunately that doesn't answer my question =P
On 06/03/2011 09:14 AM, Adam Martinson wrote:
On 06/03/2011 03:41 AM, Dmitry Timoshkov wrote:
Adam Martinsonamartinson@codeweavers.com wrote:
Your previous quesion:
How do the processes running in separate address spaces have
anything to do with that?
I thought I addressed that with this version of the patch, but if I'm not checking address space correctly, please tell me the correct way. PEB::InheritedAddressSpace doesn't work, I'm not sure what else I should be looking for.
Fortunately win32 is not DOS.
Unfortunately that doesn't answer my question =P
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. 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.
Adam Martinson amartinson@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.
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.
On 06/03/2011 01:33 PM, Dmitry Timoshkov wrote:
Adam Martinsonamartinson@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 http://msdn.microsoft.com/en-us/library/aa366912%28v=vs.85%29.aspx, so 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.
Adam Martinson amartinson@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.
Start with writing a simple Windows app that replicates what DNS/IS6 are doing.
Ah, I thought you were talking about http://msdn.microsoft.com/en-us/library/aa366912%28v=vs.85%29.aspx, so 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.
You don't understand, it doesn't matter what DLLs are loaded in other processes, that shouldn't have any influence on address space limitations in current process.
On 06/03/2011 02:36 PM, Dmitry Timoshkov wrote:
Adam Martinsonamartinson@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.
Start with writing a simple Windows app that replicates what DNS/IS6 are doing.
Alright, I'll see what I can come up with over the weekend.
Ah, I thought you were talking about http://msdn.microsoft.com/en-us/library/aa366912%28v=vs.85%29.aspx, so 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.
You don't understand, it doesn't matter what DLLs are loaded in other processes, that shouldn't have any influence on address space limitations in current process.
No, I mean the process tree was something like wine-preloader -> DNS7 setup -> IS6. No point in checking system processes here, tho I think all of Wine's binaries set IMAGE_FILE_LARGE_ADDRESS_AWARE. What you're saying is correct, but we're talking about different things.
Adam Martinson amartinson@codeweavers.com writes:
On 06/03/2011 01:33 PM, Dmitry Timoshkov wrote:
Adam Martinsonamartinson@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.
There's absolutely no reason for that flag to be inherited across processes. You can't just try things at random until they happen to fix your app, particularly not when the result is such a horrible mess. That should be a hint that there's something wrong with your hypothesis.
On 06/03/2011 03:06 PM, Alexandre Julliard wrote:
Adam Martinsonamartinson@codeweavers.com writes:
On 06/03/2011 01:33 PM, Dmitry Timoshkov wrote:
Adam Martinsonamartinson@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.
There's absolutely no reason for that flag to be inherited across processes. You can't just try things at random until they happen to fix your app, particularly not when the result is such a horrible mess. That should be a hint that there's something wrong with your hypothesis.
Alright, I'll do some more research before going further.
On 06/03/2011 03:29 PM, Adam Martinson wrote:
On 06/03/2011 03:06 PM, Alexandre Julliard wrote:
Adam Martinsonamartinson@codeweavers.com writes:
On 06/03/2011 01:33 PM, Dmitry Timoshkov wrote:
Adam Martinsonamartinson@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.
There's absolutely no reason for that flag to be inherited across processes. You can't just try things at random until they happen to fix your app, particularly not when the result is such a horrible mess. That should be a hint that there's something wrong with your hypothesis.
Alright, I'll do some more research before going further.
I'm sure this isn't a surprise, but looks like my premise was wrong: http://nuance.custhelp.com/app/answers/detail/a_id/3784/~/installation-returns-a-negative-amount-of-memory. Since Windows doesn't figure it out I guess we don't need to either xD We can probably use the same workaround as for Photoshop 4 in 3/3.
-
Adam Martinson -
Alexandre Julliard -
Dmitry Timoshkov