Ironically it’s actually the opposite. Linux has signals, and with the exception of SIGKILL and I think SIGABRT they can all be handled gracefully. Windows on the other hand doesn’t have signals, it can only TerminateProcess() which is forceful. The illusion of graceful termination on windows is done by sending a Window close message to all of the windows belonging to a given process, however in the event the process has no windows, only forceful termination is available due to the lack of a real mechanism to gracefully terminate processes. That’s why the taskkill command tells you a process requires forceful termination when you run it against something headless.
You’re right about Linux but you’re wrong about windows. It is sent to the event loop in windows https://learn.microsoft.com/en-us/windows/win32/winmsg/window-notifications. It’s been a long time since it was my job, but you actually had to pass a certification that your application exited gracefully in response to these messages as part of the partner program back in the day.
Windows does, in fact, have signals. They’re just not all the same as Unix signals, and the behavior is different. Here’s a write-up.
You’re correct there is no “please terminate but you don’t have to” signal in Windows. Windowless processes sometimes make up their own nonstandard events to implement the functionality. As you mentioned, windowed processes have WM_CLOSE.
Memory access violations (akin to SIGSEGV), and other system exceptions can be handled through Structured Exception Handling.
TIL about the console signaling stuff, good to know. I am aware of SEH but that seemed a little too in the weeds for this discussion since that’s as you say akin to SIGSEGV
The NT kernel was all built to emulate object orientation (read Smalltalk, not C++) style message passing. That’s because it was the 90s, and it’s the new technology kernel.
So yeah, expect everything to have more flexibility sending data around, and no standardization at all so you can’t have any generic functionality.
It also means the OS is in total control of the things it’s running. This goes for running programs, shutting down, and crashing. The only crashes I have on my Linux are when I use up memory, and I’m still convinced that even though everything looks seized up, if I left it for hours or days it would probably end up resolving itself. I’ve had some cases where the OS saw the program wasn’t going in a good direction fast enough and killed it.
Most linux systems have two OOM killers, one in the kernel that will execute as a last resort when your system is already frozen up, and one in systemd that should run earlier to prevent your system from freezing up. That one works sometimes, I think it does an okay job actually.
Plus, if something seemingly can’t be terminated with that, 99% of the time it’s a kernel level lockup (e.g. disk IO). At which point you only have 2 options: kill it via a kernel debugger or (the more likely scenario) perform a reboot.
Ironically it’s actually the opposite. Linux has signals, and with the exception of SIGKILL and I think SIGABRT they can all be handled gracefully. Windows on the other hand doesn’t have signals, it can only TerminateProcess() which is forceful. The illusion of graceful termination on windows is done by sending a Window close message to all of the windows belonging to a given process, however in the event the process has no windows, only forceful termination is available due to the lack of a real mechanism to gracefully terminate processes. That’s why the taskkill command tells you a process requires forceful termination when you run it against something headless.
You’re right about Linux but you’re wrong about windows. It is sent to the event loop in windows https://learn.microsoft.com/en-us/windows/win32/winmsg/window-notifications. It’s been a long time since it was my job, but you actually had to pass a certification that your application exited gracefully in response to these messages as part of the partner program back in the day.
sig bart
Windows does, in fact, have signals. They’re just not all the same as Unix signals, and the behavior is different. Here’s a write-up.
You’re correct there is no “please terminate but you don’t have to” signal in Windows. Windowless processes sometimes make up their own nonstandard events to implement the functionality. As you mentioned, windowed processes have WM_CLOSE.
Memory access violations (akin to SIGSEGV), and other system exceptions can be handled through Structured Exception Handling.
TIL about the console signaling stuff, good to know. I am aware of SEH but that seemed a little too in the weeds for this discussion since that’s as you say akin to SIGSEGV
The NT kernel was all built to emulate object orientation (read Smalltalk, not C++) style message passing. That’s because it was the 90s, and it’s the new technology kernel.
So yeah, expect everything to have more flexibility sending data around, and no standardization at all so you can’t have any generic functionality.
It also means the OS is in total control of the things it’s running. This goes for running programs, shutting down, and crashing. The only crashes I have on my Linux are when I use up memory, and I’m still convinced that even though everything looks seized up, if I left it for hours or days it would probably end up resolving itself. I’ve had some cases where the OS saw the program wasn’t going in a good direction fast enough and killed it.
Most linux systems have two OOM killers, one in the kernel that will execute as a last resort when your system is already frozen up, and one in systemd that should run earlier to prevent your system from freezing up. That one works sometimes, I think it does an okay job actually.
That’s fucked up
Plus, if something seemingly can’t be terminated with that, 99% of the time it’s a kernel level lockup (e.g. disk IO). At which point you only have 2 options: kill it via a kernel debugger or (the more likely scenario) perform a reboot.