Hi,
maybe this topic has discussed before but I did not find any threads in the devel mailing list for the last months. Additionally i followed wine development for only a few weeks. So here we go ...
oleaut.c in native Windows has some type of "heap reusage" when working with strings. This can be unconvered when placing debug messages into IMalloc_xxx functions. A sequence of SysAllocString, SysFreeString will show something like that:
Alloc olemalloc:IMalloc_fnAlloc (0x7ec47df8, 16) - addr is 0x12a1b8 Free olemalloc:IMalloc_fnGetSize (0x12a1b8) - 16 Alloc nothing Free olemalloc:IMalloc_fnGetSize (0x12a1b8) - 16
When exiting the program one can see a message like this
olemalloc:IMalloc_fnFree (0x7ec47df8, 0x12a1b8)
In Wine the heap will be released immediately. Why sould that be of any concern you may ask. This behaviour makes some buggy applications run with native oleaut32 (see bug 12460). In this case the application copies the contents of a string directly after it has been freed. Wine corrupts the heap in between and the application will crash.
My question is: Should this behaviour declared as "application is buggy & will not be fixed" or has a patch a chance to find its way into git? An idea would be an deferred free like this.
- TlsAlloc on entry of dll.
- SysFreeString TlsGetValue for last address if value is set FreeHeap(address) TlsSetValue for current address
- on exit of dll do some cleanup (heap & Tls)
Of course this behaviour is far away from the oleaut implementation and will consume some more CPU cycles.
Thanks for your feedback in inadvance.
Markus
Hello!
Markus Stockhausen wrote:
maybe this topic has discussed before but I did not find any threads in the devel mailing list for the last months. Additionally i followed wine development for only a few weeks. So here we go ...
oleaut.c in native Windows has some type of "heap reusage" when working with strings. This can be unconvered when placing debug messages into IMalloc_xxx functions. A sequence of SysAllocString, SysFreeString will show something like that:
Alloc olemalloc:IMalloc_fnAlloc (0x7ec47df8, 16) - addr is 0x12a1b8 Free olemalloc:IMalloc_fnGetSize (0x12a1b8) - 16 Alloc nothing Free olemalloc:IMalloc_fnGetSize (0x12a1b8) - 16
When exiting the program one can see a message like this
olemalloc:IMalloc_fnFree (0x7ec47df8, 0x12a1b8)
In Wine the heap will be released immediately. Why sould that be of any concern you may ask. This behaviour makes some buggy applications run with native oleaut32 (see bug 12460). In this case the application copies the contents of a string directly after it has been freed. Wine corrupts the heap in between and the application will crash.
My question is: Should this behaviour declared as "application is buggy & will not be fixed" or has a patch a chance to find its way into git?
The best thing is to write a test for this behavior and test it on different Windows versions. If even Windows 7 behaves that way I figure we'll have to provide that "feature" too. Else the application is buggy and won't work on all Windows versions either.
bye michael
An idea would be an deferred free like this.
TlsAlloc on entry of dll.
SysFreeString TlsGetValue for last address if value is set FreeHeap(address) TlsSetValue for current address
on exit of dll do some cleanup (heap & Tls)
Of course this behaviour is far away from the oleaut implementation and will consume some more CPU cycles.
Thanks for your feedback in inadvance.
Am Freitag, den 02.10.2009, 12:56 +0200 schrieb Michael Stefaniuc:
The best thing is to write a test for this behavior and test it on different Windows versions. If even Windows 7 behaves that way I figure we'll have to provide that "feature" too. Else the application is buggy and won't work on all Windows versions either.
bye michael
Hi,
nothing easier than this. But I guess it will not help us very much because we are testing bad application behaviour that only works because of Windows internal caching.
I have attached a testcase and hope it shows the expected behaviour - at least it fails in my Wine git. Hopefully we can collect the results of all Windows versions (including 7).
Markus
Markus Stockhausen wrote:
Am Freitag, den 02.10.2009, 12:56 +0200 schrieb Michael Stefaniuc:
The best thing is to write a test for this behavior and test it on different Windows versions. If even Windows 7 behaves that way I figure we'll have to provide that "feature" too. Else the application is buggy and won't work on all Windows versions either.
nothing easier than this. But I guess it will not help us very much because we are testing bad application behaviour that only works because of Windows internal caching.
*shrug* One can view that as part of the "undocumented" ABI ... Sucks, but we don't define the Win32 interface but have to follow it.
I have attached a testcase and hope it shows the expected behaviour - at least it fails in my Wine git. Hopefully we can collect the results of all Windows versions (including 7).
If it fails on Wine you need to mark it with todo_wine.
thanks bye michael
On Fri, 2009-10-02 at 12:56 +0200, Michael Stefaniuc wrote:
If even Windows 7 behaves that way I figure we'll have to provide that "feature" too. Else the application is buggy and won't work on all Windows versions either.
Even if it did not work in win-7, then it could still be worth fixing. The thing that would make it a "wont-fix" was if the fix made it directly incompatible with win-7.
There is lots of old win-3.11 and win-95 software which only runs on Wine (does not e.g. run on my work-XP machine). Changing this attitude towards legacy software would be a loss as i think it attracts many to use Wine to begin with.
I think the fix that Markus is brewing on is the the kind of details that makes Wine so great! :-)
Thanks,
/pedro
Peter Dons Tychsen wrote:
On Fri, 2009-10-02 at 12:56 +0200, Michael Stefaniuc wrote:
If even Windows 7 behaves that way I figure we'll have to provide that "feature" too. Else the application is buggy and won't work on all Windows versions either.
Even if it did not work in win-7, then it could still be worth fixing.
Of course, if the cost benefit ratio makes it worthwhile to include.
The thing that would make it a "wont-fix" was if the fix made it directly incompatible with win-7.
Not really; even that could be handled if it is important enough.
There is lots of old win-3.11 and win-95 software which only runs on Wine (does not e.g. run on my work-XP machine). Changing this attitude towards legacy software would be a loss as i think it attracts many to use Wine to begin with.
I said only that the application is buggy and didn't imply that Wine shouldn't support it. But it is way easier to get a questionable behavior of the Win32 API (iff applications depend on that) into Wine if all Windows versions implement it consistently.
I think the fix that Markus is brewing on is the the kind of details that makes Wine so great! :-)
bye michael
Markus Stockhausen <markus.stockhausen <at> collogia.de> writes:
Hi,
maybe this topic has discussed before but I did not find any threads in the devel mailing list for the last months.
Not sure, but maybe you could find some interesting related stuff in this bug:http://bugs.winehq.org/show_bug.cgi?id=3756
-
Louis Lenders -
Markus Stockhausen -
Michael Stefaniuc -
Peter Dons Tychsen