On Sat May 2 18:42:49 2026 +0000, Joerg Rueppel wrote:
Given all this, it sounds safer adding padding areas in the internal buffer, and not doing the individual allocs. Then the game can write to it as much as it wants after releasing the object. I haven't looked into how involved that path would get though. Interesting. Great investigation, again :smile:
Yeah, I still think that adding some padding before the data is the way to go. If fixing that directly at parse time is too complicated we can maybe make it work with separate allocations if we can also fix `IDirectXFileData` refcounting. It turns out that parent nodes apparently are supposed to keep references to their children (see [d3dxof-tests.txt](/uploads/a839f73f0f51d012d899b81850579663/d3dxof-tests.txt), specifically the refcounting tests at the end). If we're lucky, the game releases the various objects in the "proper" order such that there is no use-after-free on Windows, and we can avoid it too by replicating this implementation detail. We usually don't go about matching native to this level of detail, but when applications depend on it we effectively have to. Also I haven't tested the game, so this might be entirely moot. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10278#note_138789