Help needed: BSTR cache testing

[Paul Vriens]

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.

-- 
Cheers,

Paul.