I already answered that. I'll try again. In the latter case (when CDT
sends gdb the CTRL-C), if GDB is _not_ sharing a console with the inferior,
only GDB will get the CTRL_C_EVENT (that's how Windows works). Before
the patch that Joel pointed you at (GDB 6.8 does not have that patch),
a CTRL_C_EVENT sent to GDB when the inferior is running does nothing.
The patch Joel pointed you at, made it so that when GDB gets a
CTRL_C_EVENT, and, gdb knows it is not sharing a console with the
inferior, then gdb knows that the inferior hasn't seen the CTRL_C_EVENT
as well, so it needs to take the job of interrupting the inferior
itself with DebugBreakProcess. GDB 6.8 does not have that patch
applied, GDB simply ignores the CTRL_C_EVENT --- it does nothing,
as you say. Try a more recent GDB, and things will probably work
a bit better. Building a Cygwin GDB is very easy, there's nothing
to it (install a few devel packages using Cygwin's setup.exp;
./configure; make). It would be quite helpful if frontend people
once in a while tried out top of tree (or recent) GDBs.
In a Windows command shell session (the former case you describe
as working), GDB _is sharing_ a console with the inferior, so
ctrl-c generates an event in all processes in the console
process group. That is, the inferior also gets a CTRL_C_EVENT
automatically generated by Windows itself. GDB intercepts this
event, like any other debug event, and reports it as SIGINT to the
frontend. In this case, GDB _also_ receives the CTRL_C_EVENT event,
but, since it knows it is sharing the console with the inferior, it
simply ignores it. Again, older GDBs, like 6.8, _always_ ignored
this CTRL_C_EVENT they themselves get; they didn't even install a
handler.