http://bugs.winehq.org/show_bug.cgi?id=34698
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |focht@gmx.net Ever confirmed|0 |1
--- Comment #10 from Anastasius Focht focht@gmx.net --- Hello folks,
--- quote --- Piotr:
The application allocates movable memory. Later it accesses it without call to LocalLock function.
Native msvcrt hides the bug (the application still sometimes crashes) because it uses different heap in malloc implementation --- quote ---
yep, that's the problem.
The memory block returned by LocalAlloc() is a small heap management structure (GLOBAL32_INTERN) but the application abuses it as direct buffer.
The heap management block is located near (before) the important buffer which contains class members/data, allocated early in dll init. GetFileVersionInfoA() data size overlaps with adjacent buffer(s), thus destroying this data during retrieval.
It also destroys the adjacent 'Flags' and 'LockCount' members of the GLOBAL32_INTERN management block itself because they live after the 'Pointer' member which is returned as handle (at least Wine has this structure layout).
Possible solutions:
* GlobalAlloc() allocator gets a different (private) heap * maybe even separating the pointer and handle based allocators with their own heaps * have GLOBAL32_INTERN heap management structure layout changed with 'Pointer' being the last member
There is still the possibility of breakage because the adjacent GLOBAL32_INTERN blocks would be still susceptible to overwrites when being abused as direct memory block.
Tidbit: The dll in question and others are wrapped with 'VMProtect v.1.25 - 1.x (demo) 2003-2006 PolyTech - www.polytech.ural.ru' software protection scheme probably in attempt to hide the horrible code but Wine reveals everything ;-)
Regards