Help needed: BSTR cache testing

[Paul Vriens]

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?

-- 
Cheers,

Paul.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20091009/700b1d6a/attachment.asc>