On Sat Apr 18 15:14:18 2026 +0000, Joerg Rueppel wrote:
The target it writes to is in the COM object. It has no correlation to ref counting. It's either a bug in the game, or intentional misappropriation of allocated memory. Could be a padding area in the com object or something unused or unrelated. Fact is, with individual allocs the game loads its data as intended. Fact is also that with this patch the game will write into the heap header. So we should either allocate 4 bytes extra and return the data with an offset or keep the code as is but add buffer areas between the elements in the data buffer and then _not_ create individual allocs. I'm curious how Wine usually handles cases like that. Cool, nice sleuthing!
I don't think that there is a general Wine rule, we have to figure out something that makes sense in this particular instance. At a very high level, we don't need (or want) to replicate all the implementation details that don't matter in practice. In this case I think either option is okay, so the extra 4 bytes allocation + offset should be simpler. At any rate, the new test currently in this MR can stay as a `todo_wine` even if we don't end up fixing it, so that we don't forget in case that particular quirk comes back to bite us at some later point. BTW, this reminded me that sometimes the memory location "before" a returned address can be used to store extra data (see e.g. https://gitlab.winehq.org/wine/wine/-/blob/47ad1f1d5724fabd206d8ea2c198fad2b... for one such use I introduced many years ago). I quickly hacked tracing the value at `data[-1]` in the tests, it looks like the lower 16 bits change every run, while the high 16 bits seem to be consistent and appear to be flags of some sort. I think we can leave it at that :sweat_smile: -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10278#note_137032