Re: 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.

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

[Stefan Dösinger]

Am Sonntag, 1. Juni 2008 16:22:08 schrieb Jens Albretsen:
> 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.
> Nope, that doesn't work. I have a hack to do that in CrossOver, but it 
> confuses Eve Online, since Eve gets some display mode change messages at 
> shutdown, and crashes right before it would exit normally. It's not much of 
> an issue, but in rare cases the debugger gets stuck and the process becomes 
> zombie-ish.

I think on Windows this is done by some external app/module, maybe 
explorer.exe.