On 16 December 2016 at 10:51, Józef Kucia joseph.kucia@gmail.com wrote:
Possibly yes, but then memory accounting would be inconsistent.
Not necessarily, ddraw7_GetAvailableVidMem() exposes both total and free memory, and is the only place in ddraw that exposes those. There's perhaps an argument that it would allow more resources to be created than would fit in the reported total available video memory, but I don't think that's actually true. The documentation from GetAvailableVidMem() suggests to me that memory for the primary surface is just not counted with the total.
There is also a consideration if the reported memory amount should change when the application switches the display mode. When it comes to whether this should be version specific I think we should enable this workaround only for older Windows versions. It's important to note that these applications aren't expected to work on modern Windows because GetAvailableVidMem() reports more memory than INT_MAX. It's just a workaround to make these buggy applications to work in Wine.
The limit to INT_MAX, yes, and I wouldn't necessarily expect that to be specific to ddraw. Subtracting the memory for the primary surface from the total on the other hand looks like the way ddraw is intended to work to me, regardless of the Windows version.