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.