DestroyWindow behavior differences between Win9x and Win2k/xp
Hey guys, I'm looking into a crash of Master Of Orion II on exit (both in Wine and Windows XP). The problem appears to be that the program is attempting to do a DestroyWindow on a different thread. This is not allowed by our code and that behavior is backed up by MSDN documentation. This behavior was allowed on Windows 9x however. I have confirmed that removing the thread check allows the app to exit cleanly, but of course that is not an acceptable fix. As this is a full screen app the game's window stays on top in a partially drawn state and exiting requires doing an alt-tab to the console. Opinions on the correct course of action to resolve this? Thanks Justin Chevrier
I'm looking into a crash of Master Of Orion II on exit (both in Wine and Windows XP). The problem appears to be that the program is attempting to do a DestroyWindow on a different thread. This is not allowed by our code and that behavior is backed up by MSDN documentation. This behavior was allowed on Windows 9x however. I have confirmed that removing the thread check allows the app to exit cleanly, but of course that is not an acceptable fix.
On the contrary, if Windows (in any version) allows it, and an app depends on it, then we have to emulate it. A test case that passes on Win9x that demonstrates the problem is probably sufficient to show that the check should be removed. --Juan
Juan Lang wrote:
I'm looking into a crash of Master Of Orion II on exit (both in Wine and Windows XP). The problem appears to be that the program is attempting to do a DestroyWindow on a different thread. This is not allowed by our code and that behavior is backed up by MSDN documentation. This behavior was allowed on Windows 9x however. I have confirmed that removing the thread check allows the app to exit cleanly, but of course that is not an acceptable fix.
On the contrary, if Windows (in any version) allows it, and an app depends on it, then we have to emulate it. A test case that passes on Win9x that demonstrates the problem is probably sufficient to show that the check should be removed.
--Juan
Okay, that will be my next stop. Thanks Juan and Dan. Justin
"Juan Lang" <juan.lang(a)gmail.com> writes:
I'm looking into a crash of Master Of Orion II on exit (both in Wine and Windows XP). The problem appears to be that the program is attempting to do a DestroyWindow on a different thread. This is not allowed by our code and that behavior is backed up by MSDN documentation. This behavior was allowed on Windows 9x however. I have confirmed that removing the thread check allows the app to exit cleanly, but of course that is not an acceptable fix.
On the contrary, if Windows (in any version) allows it, and an app depends on it, then we have to emulate it. A test case that passes on Win9x that demonstrates the problem is probably sufficient to show that the check should be removed.
If the app crashes on XP then it's fairly reasonable for it to crash on Wine too. The Win9x design (or lack thereof) is not something we want to support in general. -- Alexandre Julliard julliard(a)winehq.org
Alexandre Julliard wrote:
"Juan Lang" <juan.lang(a)gmail.com> writes:
I'm looking into a crash of Master Of Orion II on exit (both in Wine and Windows XP). The problem appears to be that the program is attempting to do a DestroyWindow on a different thread. This is not allowed by our code and that behavior is backed up by MSDN documentation. This behavior was allowed on Windows 9x however. I have confirmed that removing the thread check allows the app to exit cleanly, but of course that is not an acceptable fix. On the contrary, if Windows (in any version) allows it, and an app depends on it, then we have to emulate it. A test case that passes on Win9x that demonstrates the problem is probably sufficient to show that the check should be removed.
If the app crashes on XP then it's fairly reasonable for it to crash on Wine too. The Win9x design (or lack thereof) is not something we want to support in general.
Then we might as well remove "emulation" of all win versions and keep it at win2k. That's the whole point - if we have such a switch, we have to keep Wine compatible to that win version. If we can't, then we shouldn't even try to pretend. I'm not suggesting doing this for everything, but things like this do matter. Vitaliy
Vitaliy Margolen <wine-devel(a)kievinfo.com> writes:
Alexandre Julliard wrote:
If the app crashes on XP then it's fairly reasonable for it to crash on Wine too. The Win9x design (or lack thereof) is not something we want to support in general.
Then we might as well remove "emulation" of all win versions and keep it at win2k. That's the whole point - if we have such a switch, we have to keep Wine compatible to that win version. If we can't, then we shouldn't even try to pretend. I'm not suggesting doing this for everything, but things like this do matter.
We can be compatible up to a certain point, but there are some behaviors of Win9x that we cannot possibly ever support. Memory management is one example. That doesn't mean we should get rid of the version switch, there are a ton of apps that are quite happy with our level of compatibility. -- Alexandre Julliard julliard(a)winehq.org
participants (4)
-
Alexandre Julliard -
Juan Lang -
Justin Chevrier -
Vitaliy Margolen