gamedevlists-windows

[GD-Windows] Terminating a program

[<epa...@ko...>]

I have divided my system to a launcher program and the actual (full 
screen) graphics application.

In some cases the laucher needs to terminate the graphics application.

I have been trying
       SendMessageTimeout(hwnd,WM_CLOSE,0,0,
			 SMTO_NORMAL,
			 10000,
			 &res);

and

           PostMessage(hwnd, WM_CLOSE, 0, 0) ;


but neither of these is fully reliable. In some cases
I get the Windows "End Program" dialogue on screen asking
the user if the program should really be terminated.

That is not ok for me.

Actually I don't really care if the program gets its chance of
getting cleanly shut down, but it is very much necessary that the
OpenGL (Nvidia) and sound drivers (Creative) are not left in a
corrupt state. And Windows (XP) itself must be able to get
all resources back etc.

Any ideas how to do this?

		Eero

Re: [GD-Windows] Terminating a program

[brian s. <bri...@gm...>]

On 7/29/05, epa...@ko... <epa...@ko...> wrote:
>=20
> I have divided my system to a launcher program and the actual (full
> screen) graphics application.
>=20
> In some cases the laucher needs to terminate the graphics application.
>=20
> I have been trying
> SendMessageTimeout(hwnd,WM_CLOSE,0,0,
> SMTO_NORMAL,
> 10000,
> &res);
>=20
> and
>=20
> PostMessage(hwnd, WM_CLOSE, 0, 0) ;
>=20
>=20
> but neither of these is fully reliable. In some cases
> I get the Windows "End Program" dialogue on screen asking
> the user if the program should really be terminated.


Windows pops up that dialog box because your graphics application isn't=20
processing messages, so Windows considers the app to be hung. You should=20
figure out why that's happening, and fix the bugs in your graphics app so=
=20
that it can actually process messages and shutdown cleanly.

That is not ok for me.
>=20
> Actually I don't really care if the program gets its chance of
> getting cleanly shut down, but it is very much necessary that the
> OpenGL (Nvidia) and sound drivers (Creative) are not left in a
> corrupt state. And Windows (XP) itself must be able to get
> all resources back etc.
>=20
> Any ideas how to do this?


Once you learn that there's a function called TerminateProcess() you may=20
think it's just what you need, but that is a very bad way to shut down an=
=20
application, and it is likely to leave drivers in a corrupt state.

--brian

Re: [GD-Windows] Terminating a program

[<epa...@ko...>]

brian sharon wrote:

> Windows pops up that dialog box because your graphics application isn't 
> processing messages, so Windows considers the app to be hung.  You 
> should figure out why that's happening, and fix the bugs in your 
> graphics app so that it can actually process messages and shutdown cleanly.
> 


Probably true. Actually I suspect that I have two kinds of problems
here. The other is that the shutdown request can happen already at the
application startup time. I do poll the windows messages now and then
also during that time, but the application might be in an library
reading an index from a large zip resource file or something like that
which takes some time. The other problem is that sometimes this happens
during the normal run time, might be some kind of transient dead lock
with the networking code (and Visual Studio debugger is not too helpful
here)


Is there a way of delivering WM_CLOSE so that the dialog box does not
appear even if the application does not respond? With this I would
probably solve 95% of my current problem cases. (And could concentrate
my debugging effort to the remaining 5%)

-------

Regarding the message from Jon Watte:

I would probably use the TerminateProcess as my fall back as described
on: http://support.microsoft.com/default.aspx?scid=kb;EN-US;q178893

(and if I cannot get WM_CLOSE to behave, I will end up testing what
are the real ill effects of TerminateProcess with WindowsXP...)



		Eero

Re: [GD-Windows] Terminating a program

[brian s. <bri...@gm...>]

On 7/30/05, epa...@ko... <epa...@ko...> wrote:
>=20
> Is there a way of delivering WM_CLOSE so that the dialog box does not
> appear even if the application does not respond? With this I would
> probably solve 95% of my current problem cases. (And could concentrate
> my debugging effort to the remaining 5%)


Sounds like you might be better off not using WM_CLOSE, since the OS is=20
going to complain if you ignore it for too long. But you have plenty of=20
other options if you want to handle communications between two apps you=20
control. Easiest thing is to use RegisterWindowMessage() to get a unique=20
message value for your own custom quit message, and then the child=20
application could post WM_CLOSE to itself whenever it receives that custom=
=20
quit message from the launcher app.

--brian

Re: [GD-Windows] Terminating a program

[<epa...@ko...>]

brian sharon wrote:

 > Sounds like you might be better off not using WM_CLOSE, since the OS 
is going to complain if you ignore it for too long.  But you have plenty 
of other options if you want to handle communications between two apps 
you control.  Easiest thing is to use RegisterWindowMessage() to get a 
unique message value for your own custom quit message, and then the 
child application could post WM_CLOSE to itself whenever it receives 
that custom quit message from the launcher app.
 >


Results from this seem very promising. I did add TerminateProcess as the
fallback, but so far (after doing one fix to the graphical program), I
have not yet seen it triggered.

(I have previously terminated programs on this setup (Nvidia +
WindowsXP) and I have not noticed any ill effects)

     Thanks for your and Jon's comments


             Eero

PS. I first sent this using wrong address, moderator please kill
that message...

Re: [GD-Windows] Terminating a program

[Jon W. <hp...@mi...>]

If you're on NT-based Windows, just killing the process will work. It's 
a real OS with a real kernel, so all resources will be magically 
released (barring any driver bugs, of course).(*)

If you want this on Win98 or WinME, you're screwed, though. Similarly, 
if there's any state you might want to re-use (such as files being 
written to at any point in your program), there's no guarantee of their 
consistency.

Cheers,

			/ h+


(*) This is why I usually advocate implementing "quit" as "exit(0)" 
rather than fully releasing everything, because to release everything, 
you have to walk through it, probably paging in a bunch of cruft just to 
tell the runtime library you don't need it. I hate applications that 
take 20 seconds to quit. The kernel can do a much better job of just 
making it go away on quit than you can.


epa...@ko... wrote:
> I have divided my system to a launcher program and the actual (full 
> screen) graphics application.
> 
> In some cases the laucher needs to terminate the graphics application.
> 
> I have been trying
>       SendMessageTimeout(hwnd,WM_CLOSE,0,0,
>              SMTO_NORMAL,
>              10000,
>              &res);
> 
> and
> 
>           PostMessage(hwnd, WM_CLOSE, 0, 0) ;
> 
> 
> but neither of these is fully reliable. In some cases
> I get the Windows "End Program" dialogue on screen asking
> the user if the program should really be terminated.
> 
> That is not ok for me.
> 
> Actually I don't really care if the program gets its chance of
> getting cleanly shut down, but it is very much necessary that the
> OpenGL (Nvidia) and sound drivers (Creative) are not left in a
> corrupt state. And Windows (XP) itself must be able to get
> all resources back etc.
> 
> Any ideas how to do this?
> 
>         Eero
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
> 
> 

-- 
-- The early bird gets the worm, but the second mouse gets the cheese.

Re: [GD-Windows] Terminating a program

[Emmanuel A. <e_a...@ya...>]

Is it that true ?

We have an game demo here on a PC that uses large
sound buffers.
When we kill the app using the task manager, and
launch once again the application, the framerate
become really slow, and we can't get any good
framerate but by booting the PC.

Launching with no sound (or without those big buffers)
behave correctly, so it seems related to sound.

So I came to the conclusion that sound memory wasn't
correctly released when killing the app.
Is it a driver bug ? 
And I though I had some similar issues with graphics (
but, speaking of it, maybe it was on W98 ).

Emmanuel

Ps : And for the original question, I would also use a
specific message in order to tell the application to
shut down properly...



--- Jon Watte <hp...@mi...> a écrit :

> 
> If you're on NT-based Windows, just killing the
> process will work. It's 
> a real OS with a real kernel, so all resources will
> be magically 
> released (barring any driver bugs, of course).(*)
> 
> If you want this on Win98 or WinME, you're screwed,
> though. Similarly, 
> if there's any state you might want to re-use (such
> as files being 
> written to at any point in your program), there's no
> guarantee of their 
> consistency.
> 
> Cheers,
> 
> 			/ h+
> 
> 
> (*) This is why I usually advocate implementing
> "quit" as "exit(0)" 
> rather than fully releasing everything, because to
> release everything, 
> you have to walk through it, probably paging in a
> bunch of cruft just to 
> tell the runtime library you don't need it. I hate
> applications that 
> take 20 seconds to quit. The kernel can do a much
> better job of just 
> making it go away on quit than you can.
> 
> 
> epa...@ko... wrote:
> > I have divided my system to a launcher program and
> the actual (full 
> > screen) graphics application.
> > 
> > In some cases the laucher needs to terminate the
> graphics application.
> > 
> > I have been trying
> >       SendMessageTimeout(hwnd,WM_CLOSE,0,0,
> >              SMTO_NORMAL,
> >              10000,
> >              &res);
> > 
> > and
> > 
> >           PostMessage(hwnd, WM_CLOSE, 0, 0) ;
> > 
> > 
> > but neither of these is fully reliable. In some
> cases
> > I get the Windows "End Program" dialogue on screen
> asking
> > the user if the program should really be
> terminated.
> > 
> > That is not ok for me.
> > 
> > Actually I don't really care if the program gets
> its chance of
> > getting cleanly shut down, but it is very much
> necessary that the
> > OpenGL (Nvidia) and sound drivers (Creative) are
> not left in a
> > corrupt state. And Windows (XP) itself must be
> able to get
> > all resources back etc.
> > 
> > Any ideas how to do this?
> > 
> >         Eero
> > 
> > 
> > 
> > 
> >
>
-------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux
> Migration Strategies
> > from IBM. Find simple to follow Roadmaps,
> straightforward articles,
> > informative Webcasts and more! Get everything you
> need to get up to
> > speed, fast.
>
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > _______________________________________________
> > Gamedevlists-windows mailing list
> > Gam...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> > Archives:
> >
>
http://sourceforge.net/mailarchive/forum.php?forum_id=555
> > 
> > 
> 
> -- 
> -- The early bird gets the worm, but the second
> mouse gets the cheese.
> 
> 
>
-------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux
> Migration Strategies
> from IBM. Find simple to follow Roadmaps,
> straightforward articles,
> informative Webcasts and more! Get everything you
> need to get up to
> speed, fast.
>
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
>
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
>
http://sourceforge.net/mailarchive/forum.php?forum_id=555
> 



	

	
		
___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com

RE: [GD-Windows] Terminating a program

[George G. <ge...@ba...>]

While letting the OS (XP, 2000 or NT) clean up the process is generally
quick, there are dangers with device states, as in your example with the
sound.  While the OS can enforce its own issues relatively well (memory
heap, file handles, GDI handles, etc), resources allocated and
configured by drivers are beyond the direct control of the kernel, and
as such can very often be left in unstable states when an app is
terminated.

While I'm sure that programming instructors everywhere will grimace in
pain, not cleaning up your memory allocations is acceptable in the
manner that Jon suggested (ie, faster to let the OS do it than to walk
through pages and pages of memory freeing all the small bits).  However,
my own experience is that it is very wise to clean up your devices
before you close - for example, properly de-allocate and shut down
DirectX or OpenGL, DirectSound/DirectShow, network resources, etc.  Not
doing so could certainly leave some PC's in a less than stable state.

-- George.

- George Geczy
- Lead Programmer, BattleGoat Studios
- www.supremeruler2010.com
- "Designing the Next Generation of Intelligent Strategy Games"


> Is it that true ?
> 
> We have an game demo here on a PC that uses large
> sound buffers.
> When we kill the app using the task manager, and
> launch once again the application, the framerate
> become really slow, and we can't get any good
> framerate but by booting the PC.

[...]

> > If you're on NT-based Windows, just killing the
> > process will work. It's
> > a real OS with a real kernel, so all resources will
> > be magically 
> > released (barring any driver bugs, of course).(*)

Re: [GD-Windows] Terminating a program

[Jon W. <hp...@mi...>]

> While letting the OS (XP, 2000 or NT) clean up the process is generally
> quick, there are dangers with device states, as in your example with the
> sound.  While the OS can enforce its own issues relatively well (memory
> heap, file handles, GDI handles, etc), resources allocated and
> configured by drivers are beyond the direct control of the kernel, and
> as such can very often be left in unstable states when an app is
> terminated.

This should simply not be true. The interface between the kernel and a 
device is, at its core, simple:

- open device
- close device
- read device
- write device
- control device

A device doesn't have to know whether "close" is because the application 
called close explicitly, or whether the kernel called close because it 
had to remove all device handles that belonged to a dying process.

However, in the Windows device model (especially the older models), 
there were reasons to go outside this basic model, and even within the 
basic model, a driver may have bugs (such as sequencing bugs) that make 
it not work right.

It's been my experience that a prime cause of bugs are all the "extras" 
that an OEM wants to add to their device: decoration of sound output; 
special throughput statistics windows for network cards; that kind of thing.

> my own experience is that it is very wise to clean up your devices
> before you close - for example, properly de-allocate and shut down
> DirectX or OpenGL, DirectSound/DirectShow, network resources, etc.  Not
> doing so could certainly leave some PC's in a less than stable state.

The reason that you have to do this (and we do when we terminate 
normally) is because of bugs in the implementation of the drivers. 
Sadly, such bugs are so common, that they contribute to the perception 
that Windows is unstable and computers just crash all the time. Grandma 
really won't have a good computer until the pace of hardware evolution 
slows down enough to let the drivers mature. This, in turn, is caused by 
the "good enough" rule -- if you're going for "perfect" then your 
competitors will ship six months before you do, as well as be cheaper, 
so as a hardware vendor, you're highly motivated to ship as soon as you 
have something that might work for a few minutes after boot.


Cheers,

			/ h+


-- 
-- The early bird gets the worm, but the second mouse gets the cheese.

RE: [GD-Windows] Terminating a program

[George G. <ge...@ba...>]

> > resources allocated and configured by drivers are beyond the direct 
> > control of the kernel, and as such can very often be left in
unstable 
> > states when an app is terminated.
> 
> This should simply not be true.

Ah, many things in life "should" not be true, but unfortunately are.

> The reason that you have to do this (and we do when we terminate 
> normally) is because of bugs in the implementation of the drivers. 
> Sadly, such bugs are so common, that they contribute to the 
> perception that Windows is unstable and computers just crash all the 
> time. 

Exactly, and of course in a user's eyes a driver bug = a bug in the app
that was using the driver.  (Mind you, this falsehood isn't helped any
by new software that mucks about with drivers and the O/S as part of
their lame copy protection schemes, but that is ENTIRELY a different
topic...)

Video and Sound driver bugs (such as terminate/cleanup bugs) are just SO
common that, for all intents and purposes, the termination issues have
to be assumed to be the "status quo" and apps have to try to work around
them.  As such, no good app should, if it can at all help it, exit
without closing down its video, sound and network APIs.  To do so is
inviting stability issues from faulty (and very common) drivers.

-- George.

- George Geczy
- Lead Programmer, BattleGoat Studios
- www.supremeruler2010.com
- "Designing the Next Generation of Intelligent Strategy Games"