# Windows platform

Notes on the Windows platform port and behaviour quirks.

## Multi-process termination

Windows does not implement the POSIX signals functionally, even if the C standard has them. Here is the gist of it:

- SIGINT - Replaced by CTRL_C_EVENT that is tied to a console object to work, can't be reliably transmitted to child process.
- SIGTERM - Can't be submitted to process different from itself. (this is totally useless)
- SIGABRT - works but can't be customized for graceful shutdown by design.
- SIGSEGV, SIGILL and SIGFPE are used for error handling by design.

This means there is no universal way to signal processes for shutdown. For more information read https://stackoverflow.com/a/35792192 which contains excessive details on how the **console** events work.

Windows has two types of executables, ones that launch with a console and others that do not. Latter is usually called a gui app.
Regardless of  which type of executable you start, the process itself is not constrained to work in either fashion exclusively.
A console app may create windows, while a gui app may create a console object.

Ultimately the intended and supported ways to handle signal-like event is determined by the type of application:

- console: control events can be delivered and handled by registering the SetConsoleCtrlHandler
- gui: a window must implement handling of broadcast messages with the native message loop processing

These can be both set up in a process, in which case either can be used effectively. However, one problem is that
for either to work they need explicit support in the application code which is not always done properly.

For example the "javaw.exe" is a gui process, but it does not create a hidden windows to process broadcast messages. Also
neither Solr nor Tika creates a window, so these processes do not behave correctly. The RestartManager can't shut them down for example.

Signaling a console application to stop is only possible by:

1. Spawning the child process with CREATE_NEW_CONSOLE flag, so it won't inherit the console of the parent.
2. Later starting an event transmitter process that attaches itself to the console of the child and generates an event. Effectively dragging the child with itself to be terminated.

Unfortunately during session-end (logoff) or system shutdown, these event transmitter processes seem to have a trouble
starting. Windows randomly denies them from starting up without giving the programmer any way to handle the situation. A very cryptic error message will be shown to the user, which is very annoying. (0xc0000142 error code)

Even if a process implements shutdown event handling with WM_QUERYENDSESSION and WM_ENDSESSION, it should not perform window destruction or shutdown, just save their data and wait to be killed (aka SIGKILL). It is the Windows way to forcefully kill everything apparently.

### Summary

- Applications can't be notified simply or universally about shutdown (signals are broken)
- Applications must implement at least a relevant event handling for their process type in the application
- Starting processes to facilitate graceful shutdown during logoff can create a terribly worrying, cryptic error message for the user that we can't do anything about
- Gui applications that do not create at least a hidden window for event processing can't even be notified about anything even by Windows (Solr/Tika run by javaw.exe for example)

### Conclusion

- We implement all of our processes as hybrid applications. They will always create az least one hidden window to facilitate graceful shutdown messaging between processes, without the need of a transmitter process. In case it would work and would be needed the console handling is also always set up.
- Java applications (Solr and Tika) must be run with "java.exe" as console applications. The event transmitter signaling works well for arbitrary shutdown by user request.
- The core shall not manage the child processes at system-shutdown. They will all be stopped by Windows. This avoids the cryptic error message problem.
