On Unix the behavior of the kill command is a result of the operating system’s signal handling — the command simply sends a signal to a running process. In the absence of other parameters, the TERM signal is used, and while the option -9 is pretty common (sends the KILL signal to terminate unconditionally), it is also possible to send any other signal number to a process. There are loads of other semi-standardized ones, but an application can “listen” to any signal it wants.
The main interesting thing with regard to terminating processes is that there’s more than one way to do it in the Unix world, and it’s easy to make the distinction between a soft “query for close” and a hard kill by using different signals. While it would theoretically be possible to use the same approach on Windows, in practice this is seldom done — I was able to find one references to such a thing only in the context of more or less complex Unix compatibility layers for Windows, such as the one made by MKS.
Now I was looking for a Windows command that would somehow be able to terminate a process on Windows without killing it in a “hard” way. Obviously it’s a good idea to give applications the chance to close their files, save their settings, whatever they want to do when closing. But looking at the usual candidates like pskill or the Windows PowerShell stop-process cmdlet didn’t provide me any help. Finally I found that it is possible to do this with the standard Windows command taskkill. It’s actually even the default behavior: The command line taskkill /im notepad2.exe will terminate the process in such a way that notepad asks me to save changes first (if there are any). To achieve the unconditional kill behavior the switch /f is needed.