Trapping Ctrl-C, how?

[Wurm]

Hi all,

Got a little problem with a lib that I'm working on. First of all, the
problem is that the lib that I have makes connections to DirectSound, and
has a host of custom built sound related functions. Now, in the lib is a
'destroy' function which when called will release all instances of
DirectSound that I have created and if that is used, then great, no problem.
The application that uses this lib is a console application running on
WindowsNT 4.0 sp6, and before connecting to this lib, if we wanted to kill
the app we simply hit Ctrl+C and it dies. But now that its been connected to
my lib, if we do a Ctrl+C instead of the app dissapearing it hangs and times
out which unfortunately is unnaceptable for our usage. So to solve this, I
either have to find a way to trap when the user hits Ctrl+C and call my own
'destroy' function before releasing the Ctrl+C back to the OS, or, have to
find a way in DirectSound to configure it so that if the controlling app
dies, the objects created are released automatically (this I've already
looked for and cant find).

So.... thanks for reading this far!, does anyone know how to do this?. Bear
in mind, I have no control over the creation of the window (I found a group
of functions which seem that they would do the job, WindowProc and friends
but they need to be fully setup at the window creation which I cant do). Ive
tried the SetWindowsHookEx family of functions but for one reason or another
I cannot get any test hooks to trigger at all and I was told that they may
not function properly with console applications.

Any input at all would be greatly appreciated, post here or if you prefer
mail me directly at: pforan AT cae DOT com

TIA!

Phil

[Eric Sosman]

Wurm wrote:

Hi all,

Got a little problem [...]

.... which happens to be Question 19.38 in the comp.lang.c
Frequently Asked Questions (FAQ) list

http://www.eskimo.com/~scs/C-faq/top.html

--
Er*********@sun.com

[Wurm]

Eric Sosman <Er*********@sun.com> wrote in message
news:3F***************@sun.com...

Wurm wrote:

Hi all,

Got a little problem [...]

... which happens to be Question 19.38 in the comp.lang.c
Frequently Asked Questions (FAQ) list

http://www.eskimo.com/~scs/C-faq/top.html

--
Er*********@sun.com

Well son-of-a......., thanks!. Ill definetly take some time and look through
that FAQ, didnt even know it was there :)

Wurm

[E. Robert Tisdale]

Eric Sosman wrote:

Wurm wrote:

Got a little problem [...]

... which happens to be Question 19.38 in the comp.lang.c
Frequently Asked Questions (FAQ) list

http://www.eskimo.com/~scs/C-faq/top.html

Excellent answer!

[CBFalconer]

Wurm wrote:

Got a little problem with a lib that I'm working on. First of all,
the problem is that the lib that I have makes connections to
DirectSound, and has a host of custom built sound related
functions. Now, in the lib is a 'destroy' function which when
called will release all instances of DirectSound that I have
created and if that is used, then great, no problem. The
application that uses this lib is a console application running
on WindowsNT 4.0 sp6, and before connecting to this lib, if we
wanted to kill the app we simply hit Ctrl+C and it dies. But
now that its been connected to my lib, if we do a Ctrl+C instead
of the app dissapearing it hangs and times out which
unfortunately is unnaceptable for our usage. So to solve this, I
either have to find a way to trap when the user hits Ctrl+C and
call my own 'destroy' function before releasing the Ctrl+C back
to the OS, or, have to find a way in DirectSound to configure it
so that if the controlling app dies, the objects created are
released automatically (this I've already looked for and cant
find).

Most of that is OT on c.l.c. Maybe you want to find another way
of signalling the program to exit.

However if Ctrl-C causes the program to perform a normal exit
(so-called), the following STANDARD function may help. From N869.

7.20.4.2 The atexit function

Synopsis

[#1]
#include <stdlib.h>
int atexit(void (*func)(void));

Description

[#2] The atexit function registers the function pointed to
by func, to be called without arguments at normal program
termination.

Environmental limits

[#3] The implementation shall support the registration of at
least 32 functions.

Returns

[#4] The atexit function returns zero if the registration
succeeds, nonzero if it fails.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Keith Thompson]

CBFalconer <cb********@yahoo.com> writes:
[...]

Most of that is OT on c.l.c. Maybe you want to find another way
of signalling the program to exit.

However if Ctrl-C causes the program to perform a normal exit
(so-called), the following STANDARD function may help. From N869.

7.20.4.2 The atexit function

[...]

Ctrl-C typically causes a signal to be sent to the currently running
program. That generally doesn't result in a normal exit, so it
bypasses any atexit()-registered functions.

--
Keith Thompson (The_Other_Keith) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Richard Heathfield]

CBFalconer wrote:

Most of that is OT on c.l.c. Maybe you want to find another way
of signalling the program to exit.
<snip>
[#2] The atexit function registers the function pointed to
by func, to be called without arguments at normal program
termination.

Does a SIGTERM signal count as "normal termination"?

Perhaps the guy just needs to read[1] up on signal().
[1] I first typed this as "reed". I think I must be getting fnetic in my old
aj.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Dan Pop]

In <3F***************@sun.com> Eric Sosman <Er*********@sun.com> writes:

Wurm wrote:

Hi all,

Got a little problem [...]

... which happens to be Question 19.38 in the comp.lang.c
Frequently Asked Questions (FAQ) list

http://www.eskimo.com/~scs/C-faq/top.html

What the FAQ doesn't say is that the implementation of SIGINT in
Windows is broken: the signal handler will be executed in a new thread,
rather than having the program execution suspended until the signal
handler returns. This has bitten more than one unsuspecting Windows
programmer...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <bm**********@hercules.btinternet.com> Richard Heathfield <do******@address.co.uk.invalid> writes:

CBFalconer wrote:

Most of that is OT on c.l.c. Maybe you want to find another way
of signalling the program to exit.
<snip>

[#2] The atexit function registers the function pointed to
by func, to be called without arguments at normal program
termination.

Does a SIGTERM signal count as "normal termination"?

How can you send a SIGTERM signal to a Windows program? CTRL-C is
supposed to send a SIGINT.

Anyway, the simple delivery of any of them does not cause normal program
termination: they're merely asking the program to terminate. It's up to
the program to decide what to do.
Perhaps the guy just needs to read[1] up on signal().

Preferably, from the Windows documentation, for a reason mentioned
in another post.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[CBFalconer]

Dan Pop wrote:

Eric Sosman <Er*********@sun.com> writes:

Wurm wrote:

Got a little problem [...]

... which happens to be Question 19.38 in the comp.lang.c
Frequently Asked Questions (FAQ) list

http://www.eskimo.com/~scs/C-faq/top.html

What the FAQ doesn't say is that the implementation of SIGINT in
Windows is broken: the signal handler will be executed in a new
thread, rather than having the program execution suspended until
the signal handler returns. This has bitten more than one
unsuspecting Windows programmer...

Which, I assume, means that the handler must set a "global" flag,
and that the program must check that at predetermined places to
handle such a CTL-C operation.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Richard Heathfield]

Dan Pop wrote:

Richard Heathfield writes:

CBFalconer wrote:
<snip>

[#2] The atexit function registers the function pointed to
by func, to be called without arguments at normal program
termination.

Does a SIGTERM signal count as "normal termination"?

How can you send a SIGTERM signal to a Windows program? CTRL-C is
supposed to send a SIGINT.

Yes, you're right. Two likely candidates to choose from, so obviously I
chose the wrong one.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Dan Pop]

In <3F**************@yahoo.com> CBFalconer <cb********@yahoo.com> writes:

Dan Pop wrote:

Eric Sosman <Er*********@sun.com> writes:

>Wurm wrote:
>>
>> Got a little problem [...]
>
> ... which happens to be Question 19.38 in the comp.lang.c
> Frequently Asked Questions (FAQ) list
>
> http://www.eskimo.com/~scs/C-faq/top.html

What the FAQ doesn't say is that the implementation of SIGINT in
Windows is broken: the signal handler will be executed in a new
thread, rather than having the program execution suspended until
the signal handler returns. This has bitten more than one
unsuspecting Windows programmer...

Which, I assume, means that the handler must set a "global" flag,
and that the program must check that at predetermined places to
handle such a CTL-C operation.

A strategy that doesn't work very well if the program is stuck into an
input call that never returns, for one reason or another...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Wurm]

Thanks all, the signal() calls did the trick!. Ill definetly read up on that
FAQ
"Wurm" <a@b.c> wrote in message news:bl**********@dns3.cae.ca...

Hi all,

Got a little problem with a lib that I'm working on. First of all, the
problem is that the lib that I have makes connections to DirectSound, and
has a host of custom built sound related functions. Now, in the lib is a
'destroy' function which when called will release all instances of
DirectSound that I have created and if that is used, then great, no problem. The application that uses this lib is a console application running on
WindowsNT 4.0 sp6, and before connecting to this lib, if we wanted to kill
the app we simply hit Ctrl+C and it dies. But now that its been connected to my lib, if we do a Ctrl+C instead of the app dissapearing it hangs and times out which unfortunately is unnaceptable for our usage. So to solve this, I
either have to find a way to trap when the user hits Ctrl+C and call my own 'destroy' function before releasing the Ctrl+C back to the OS, or, have to
find a way in DirectSound to configure it so that if the controlling app
dies, the objects created are released automatically (this I've already
looked for and cant find).

So.... thanks for reading this far!, does anyone know how to do this?. Bear in mind, I have no control over the creation of the window (I found a group of functions which seem that they would do the job, WindowProc and friends
but they need to be fully setup at the window creation which I cant do). Ive tried the SetWindowsHookEx family of functions but for one reason or another I cannot get any test hooks to trigger at all and I was told that they may
not function properly with console applications.

Any input at all would be greatly appreciated, post here or if you prefer
mail me directly at: pforan AT cae DOT com

TIA!

Phil