[Bug 4436] Storage32 regression problem: ECAD app 'Easy-PC' is unable to create new project/design

[Wine Bugs]

http://bugs.winehq.org/show_bug.cgi?id=4436

------- Additional Comments From [e-mail]  2006-15-02 05:05 -------
OK, I'll change the fix to orphan the stream rather than delete it. The point
is, though is this: a badly-written app surely would not try to access the
stream after it had called the destructor for the storage object? If this is the
case, then deleting the stream will stop the memory leak. However, it looks from
your test that Windows does _not_ delete the stream and thus itself leaks
memory. I thought I had tested this earlier and found that Windows did delete
the streams, but I have just checked my notes and it turned out I was thinking
of a different issue.

That fixes one of the bugs, I'll sort out the patch and submit it. However, what
do you think the best way to handle the other issue (mismatch in grfMode of
opened stream to the grfMode of the storage object)? A test for this was in my
earlier conformance test patch: this following code works on Windows:

r = StgOpenStorage( filename, NULL, 0x00010020, NULL, 0, &stg);
    ok(r==S_OK, "StgOpenStorage failed\n");
    if(stg)
    {
        static const WCHAR stmname[] =  { 'w','i','n','e','t','e','s','t',0};
        IStream *stm = NULL;

r = IStorage_OpenStream( stg, stmname, 0,
STGM_SHARE_EXCLUSIVE|STGM_READWRITE, 0, &stm );
        ok(r == S_OK, "OpenStream should succeed - "); printf("rc from
OpenStream : %lx\n",r);

r = IStorage_Release(stg);
        ok(r == 0, "wrong ref count\n");
    }

It does not make sense that one can open a stream STGM_READWRITE within an
object opened with STGM_READ, but you can on Windows! Should we just remove the
grfMode access flag test from the OpenStream code (as I have done temporarily
just to get the app running)? I will do some testing on Windows to see if I can
identify the access mode flag combinations that succeed and fail, but is there
any knowledge about this problem anywhere else?