Then, with that ddraw.dll removed, the game can still be started on Windows by setting compat option 'start in 640x80 resolution'). The game is basically unplayable this way and exhibits various heavy glitches, while it is still possible to get to the game and observe that the issue concerned here (low textures resolution) is actually not there. That is also affected by D3DDEVCAPS_TEXTURENONLOCALVIDMEM flag in HAL dwDevCaps. When that is set (which happens on Win11 at least on the device it ends up with) it doesn't actually mind GetAvailableVidMem result, even though still queries that. If that is not set (like in our case) \>2GB memory gets into signed comparison (and thus is negative) and the game considers there is not enough VRAM for textures of higher resolution.
D3DDEVCAPS_TEXTURENONLOCALVIDMEM seems like something we should be setting, at least for HAL/3D devices. IIRC that's GART/GTT memory.
As you mentioned, we do clamp the reported video memory for older Windows versions. (And IIRC that matches the actual behaviour of those versions.) Why is that not sufficient for this application?
It is not sufficient because obviously the default prefix has newer Windows and the game doesn't work OOTB. Changing it manually is sufficient of course.
Is that something we care about now? Historically we've been happy to put a note in the AppDB along the lines of "Set the Windows version to Windows 98 in winecfg". That's not an uncommon thing to try for games of that era, since those tend to rely on other quirks of Windows 9x as well.
I sent this specific patch because I was under impression that we help some range of games in default config this way, while probably nothing benefits from reporting \>2GB on ddraw specifically. We preliminary discussed that with Zeb and she wasn't against this approach at once.
I'll defer to the maintainer of course, but to me it sounds like this is papering over a different issue. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11090#note_142506