BSTR & Heap - a restart

[Markus Stockhausen]

Am Freitag, den 09.10.2009, 15:44 +0200 schrieb Alexandre Julliard:
> If the test case is based on observing internal behavior that's not
> acceptable either. Even if someone else fixes it, the test would force
> the fixer to replicate internal details.
> 

Hi,

I can see all of your concerns and the message of what not to do is
understood. If my enthusiasm to reveal the reason for the error got me
too far I'm sorry and this is my official excuse. I'll try to rewind any
knowledge to the point where it all started. 

And that was here:

The original goal of my journey was to understand why BSTR memory
structures constantly survived a SysFree cycle in Windows while they got
overwritten for some case in Wine. From what I read in bugzilla the
argumentation always explained, that this comes from heap management.
The tip to solve this with native oleaut, further links to MSDN
documentation about SetOaNoCache() and the KB article
http://support.microsoft.com/kb/937360 led the way that heap was not
freed upon calling SysFreeString. 

With this bit of knowledge I ask if the following testcase will be
valid. It should not care about any code inside the "black box":

  ...
  for (i=10;i<100;i++) {
    s1 = SysAllocStringLen(sz128,i);
    SysFreeString(s1);

    HeapAlloc(GetProcessHeap(),0,10);

    s2 = SysAllocStringLen(sz128,i);
    SysFreeString(s1);
    ok(s1==s2, "got a new memory address\n");
  }
  ...

The only development goal this testcase has, is to request a function
that provides the same memory address in two subsequent Alloc/Dealloc
calls with the same string size. Noone should be forced to implement
something that goes anywhere close to native implementation.

A start maybe.