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.
You clearly didn’t read my message…I said a “window close message.” I.e…WM_CLOSE. that is not a process signal, it’s a window management signal. Hence taskkill not working without /f on headless processes
…right…tell that to cmd.exe or the OpenVPN daemon, or the soft ether VPN daemon, or OpenConsole.exe, or Idk, I only tested 4 that immediately came to mind but my point stands. There are a lot of programs that do not have a window handle and do not bother with window messages.
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.
You clearly didn’t read my message…I said a “window close message.” I.e…WM_CLOSE. that is not a process signal, it’s a window management signal. Hence taskkill not working without /f on headless processes
Long running headless processes on windows generally still have an event loop and a window handle via which they process those messages.
…right…tell that to cmd.exe or the OpenVPN daemon, or the soft ether VPN daemon, or OpenConsole.exe, or Idk, I only tested 4 that immediately came to mind but my point stands. There are a lot of programs that do not have a window handle and do not bother with window messages.
Service (daemon) lifecycles are managed via the system services api.
Yep, I’m aware of that too, doesn’t change my initial point