On 10/09/2009 02:15 PM, Paul Vriens wrote:
On 10/09/2009 02:07 PM, Markus Stockhausen wrote:
Am Freitag, den 09.10.2009, 13:43 +0200 schrieb Paul Vriens:
Hi Markus,
Isn't there a way that you can change the tests to show this number (in some kind of loop by creating a larger second string on the go)?
It simply boils down to this one and only testcase. A SysFreeString will always preserve the contents of the heap and will put the address into some caching freelist.
It does not matter how these freelists are organized because of two reasons:
- The application does not know the state of oleaut freelists. Earlier
calls could have filled them up to some state.
- This leads to the second situation that the application cannot
anticipate. Will it get a new memory area or something from a freelist when doing a SysAllocString.
Reading bugzilla i can see that errors due to missing BSTR caching are ancient WINE companions. But only because of faulty applications. In my opinion there are three ways to go:
- close all associated bugs and blame the developers
- take some weeks and try to explore the caching behaviour of oleaut
- implement only that bit of caching that is required for the bugs
My sent in testcase is the basis for the third solution and as my code proposal shows I'm willing to spend some time to get it fixed.
Best regards.
Markus
Hi Markus,
My question about a modified test case came from your statement:
"I do not want to explain this in detail, as it is the result of looking at internal behaviour (something that is not liked very much as I understand now)."
If that sz99 (or now sz128) came from "looking at internal behaviour", I'm not sure if that would raise some eyebrows.
Ok, what about something like the attached testcase?
This one succeeds on W2K3 (didn't test on other boxes yet).
Does it prove anything?