[Bug 10844] erroneous out of memory message from application

http://bugs.winehq.org/show_bug.cgi?id=10844

John Doe  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |

--- Comment #7 from John Doe   2007-12-30 00:35:12 ---
(In reply to comment #6)
> (In reply to comment #5)
> > Can you try with wine-git or wait for wine 0.9.52? Alexandre put in a fix
> > today:
> >
> > http://source.winehq.org/git/wine.git/?a=commit;h=16aadb2785600cc73cfe705a3a...
>
> Tested with wine-0.9.51-190-g16aadb2 - bug appears to be fixed
>
> Thanks

Sorry, it appears that I did not investigate the exact details of this error.

Unfortunately, the subsystem version for these affected programs is 4, where
the fix is for subsystem versions less than 4.

I think the cause for my mistake is different memory utilization on my system
at the time of testing with wine-0.9.51-190-g16aadb2, which means that I still
have a program, Need for Speed II which is refusing to run under some
conditions.

What I probably should have done initially is disassembled or at least looked
at the disassembly from the affected programs to determine the exact cause of
the bug.  I'll be sure to do this next time before reporting the bug to avoid
this happening again.

So, after sifting through some assembly for Need for Speed II's nfsw.exe, I
have formed the opinion that the value of the AvailPageFile member of the
struct filled in by GlobalMemoryStatus is compared with the value 00A0000 (find
this by breaking at 0x0047F87b in the retail version) and as a result of this,
the program jumps to a path of execution which results in the programs error
message being displayed.

I think that these programmers were not expecting such large values as
e3d43000, and there is some signed vs unsigned mishandling of this number by
the program.

I'll attempt to verify if the above is the same in the demo version and the
other affected program I have and post an additional comment to confirm.

Once again, sorry if this has caused any inconvenience.

trace:heap:GlobalMemoryStatusEx <-- LPMEMORYSTATUSEX: dwLength 64, dwMemoryLoad
31, ullTotalPhys 3f35d000, ullAvailPhys 2b006000, ullTotalPageFile f809a000,
ullAvailPageFile e3d43000, ullTotalVirtual 7ffdffff, ullAvailVirtual 7ffcffff
trace:heap:GlobalMemoryStatus Length 32, MemoryLoad 31, TotalPhys 3f35d000,
AvailPhys 2b006000, TotalPageFile f809a000, AvailPageFile e3d43000,
TotalVirtual 7ffdffff, AvailVirtual 7ffcffff