Hi,This MS documentation looks like it's slightly retro. I've been trying to decypher this stuff myself for a decade, so I might offer some points:.
Odd. First they say it's not supported, then they go on to define how it works. Probably what they mean is that Win32 _GUI_ applications have no way to have receive SIGINT from Ctrl+C, because that's handled as just another keystroke by the GUI system (sometimes you'll see the older documentation use Win32 as a term implying GUI). Win32 console apps appear to respond to Ctrl+C much like unices do.Andrew Dunstan wrote:* Note SIGINT is not supported for any Win32 application, including * Windows 98/Me and Windows NT/2000/XP.When a CTRL+C interrupt occurs, * Win32 operating systems generate a new thread to specifically handle* that interrupt. This can cause a single-thread application such as UNIX,* to become multithreaded, resulting in unexpected behavior.
Since Win32 will create a new thread for you, if you prepare your app for that, I don't see a reason you can't make pure Win32 system calls from that thread. You mainly want to be careful to not confuse a single-threaded C runtime. Note that the doc http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_CRT_signal.asp says not to "use any function that generates a system call (e.g., *_getcwd*, *time*)", it doesn't say not to make system calls themselves. It doesn't look like a "signal" is not a kernel primitive on NT, it's a feature of the CRT implemented in userspace with lower-level OS primitives.
A kernel Event (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createevent.asp) is a common tool for this sort of thing.* I have no idea how to handle this. (Strange they call UNIX an application!)* So this will need some testing on Windows. * One alternative might be to set a flag that we periodically check for.
- Marsh