[PATCH 2/4] ntdll: Provide more accurate virtual memory counters.

[Akihiro Sagawa]

On Mon, 5 Jun 2017 19:41:06 +0200, Matteo Bruni wrote:
> 2017-06-05 16:15 GMT+02:00 Akihiro Sagawa <sagawa.aki at gmail.com>:
> > On Sun, 4 Jun 2017 22:51:10 -0600, Alex Henrie wrote:
> >> Out of curiosity, is there a particular application that depends on
> >> this behavior? It could be argued that reporting the value from the
> >> native operating system is better because it tells what's really
> >> happening in the process.
> >>
> >> -Alex
> >
> > Good question. I'm trying to fix Sorcery Jokers (trial) issue, bug 43119.
> > The application repeatedly trys to allocate virtual memory as much as
> > possible, and measures available memory size by GlobalMemoryStatusEx().
> >
> > This patch is better than nothing. The application stops memory
> > allocation about 384MB (0x17ffffff) free. After the allocation, it
> > succeeds to load libGL.so. However, it shows driver pointer missing
> > error when loading DRI driver, radeonsi_dri.so. I'm still in trouble
> > with this point.
> >
> > By the way, I have another idea about this issue. That is reserving
> > virtual memory area when loading wined3d.dll and release it just before
> > loading OpenGL libraries. Being hackish idea, I chose the forementioned
> > method in the beginning.
> 
> As far as hacks go, does adding some arbitrary "reserved" amount to
> pvmi.VirtualSize make any difference?

Thanks comments. Could you explain why adding "reserved" amount to
pvmi.VirtualSize helps the issue?
From my viewpoint, if we increase pvmi.VirtualSize, available virtual memory,
i.e. MEMORYSTATUSEX.ullAvailVirtual, will decline. And, VM allocation
limit doesn't change.

Thanks in advance,
Akihiro Sagawa