https://bugs.winehq.org/show_bug.cgi?id=48788
--- Comment #4 from Paul Gofman gofmanp@gmail.com --- Created attachment 66713 --> https://bugs.winehq.org/attachment.cgi?id=66713 Test
(In reply to Per Christian Henden from comment #3)
I'm pondering how Windows handles this.
I was probably wrong saying that it works by chance on Windows, maybe not.
It is important to note that the (only) surface game locks is primary surface, 640x480 8 bit paletted.
This is a ddraw1 game released in 1997. Besides the grass been greener those days, ddraw primary surfaces were providing direct access to video memory mapped directly to the CPU address space and immediately visible on screen. 640x480x8 bit takes 300k in size, while video cards of that era should have normally had at least 1mb. So it was very unlikely that accessing the surface data a few scanlines off would cause an immediate crash, and not possible that it would touch some data other than the other video memory surface data. Since long ago ddraw primary surfaces are not mapped that way anymore and this behaviour is sort of emulated in Windows, but I can guess they can provide an extra space for the surfaces for compatibility with such program naughtiness. I attached the unit test which accesses more data past the end of primary surface and this works fine for me on Windows 7, while crashes under Wine. It is not a full proof of course but still.
Not sure but maybe it is something that can be done in Wine.
A partially displayed menu is a step forward :) Did selecting the menu items work?
Yes, the menu works, just a bit glitchy. If to use a supposed way of running GOG compatibility ddraw (setting native override for ddraw) the most of the menu is visible if you set somewhat higher resolution for virtual desktop.
I read that in another case/version the menu was a bit off, but the game could still be played.
The game itself past the menu seems to be fine.