ddraw: Don't release ddraw if a surface is still using it.

[Jens Albretsen]

> Am Samstag, 31. Mai 2008 17:03:13 schrieb Michael Karcher:
>> > Anyway it makes wine stop crashing when programs tries to do something
>> > crazy like this. Stefan Dösinger asked me to put a HeapAlloc all
>> memory
>> > between the two Release's to check if the memory of ddraw object would
>> be
>> > corrupt in Windows. It really doesn't matter if programs live by
>> chance
>> > in windows, if we can implement it so it's not by chance anymore.
>>
>> I agree on that point.
> Actually, that is dangerous. There may be situations in which this
> make-something-work has an unintended side effect, e.g. failure to restore
> the display mode because the ddraw object isn't destroyed(although it
> maybe
> should be - it's the test's job to find that out).

You're right, if we expect every program to behave.
I guess we need a hook for wined3d (if we not already have it) to restore
the state back at process termination, if there is stuff not freed,
changed video modes and such.
I believe d3d does this natively, if you change video and there is a
abnormal program termination it will restore the video mode and if you're
running with debug libraries it will tell you what you forgot to free, at
least in Windows XP.
I actually ran wine without virtual desktop at one point where program
crashed, had to hard reset because video wasn't restored,
CTRL+ALT+BACKSPACE didn't work, so now i'm running everything in a virtual
desktop, so I guess there isn't any hook and we expect all programs to
behave.
The hook could probably be put wined3d_main.c/DllMain() fdwReason ==
DLL_PROCESS_DETACH so it closes wined3d correctly, in the event of
abnormal program execution.

> Another possibility are apps that intend to cause an exception, like copy
> protection systems.

Anyway still need to know if the test fails or passes in Windows.