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