process-killer should be compiled with subsystem:Windows

[Agritite]

Under some circumstances a console would flash up then disappear when calling ctrlc, that's because process-killer is a console application so between program startup and FreeConsole a console may still be allocated if there isn't one to use. Now I'm not entirely sure the criteria for this to happen, but one condition that I do know is when an electron app is packaged as an UWP app (.appx), probably due to UWP apps shenanigans. Whether the process to kill is spawned with spawn or execFile might also matter, but I haven't thoroughly tested it. Anyway, I think making process-killer a subsystem:windows app would just prevent this from happening at all.

I'm able to compile my own process-killer.exe with this:

#include <string>

#include <Windows.h>
#include <winrt/base.h>

int wWinMain(HINSTANCE, HINSTANCE, PWSTR, int)
try {
	if (__argc < 2) {
		throw winrt::hresult_invalid_argument{};
	}

	const DWORD pid = std::stoul(__wargv[1]);
	winrt::check_bool(::AttachConsole(pid));
	winrt::check_bool(::SetConsoleCtrlHandler(nullptr, TRUE));
	winrt::check_bool(::GenerateConsoleCtrlEvent(CTRL_C_EVENT, 0));

	return 0;
} catch (const winrt::hresult_error& he) {
	return he.code().value;
}

and pass it to native.ctrlc, which works, and doesn't flash any console when packaged as appx.

It should be possible to do the same in rust.

[cowboyd]

Nice take! Is this something that you would be willing to submit a PR for?

[Agritite]

I'm not really familiar with rust but I'll see what I can do.

[cowboyd]

I don't know that it's critical for it to be in rust. Only that calling rust code from JavaScript is really simple.

[Agritite]

Rust is fine here; that saves us from having to introduce another build system, but you're right, if you really want you can write process-killer with brainfuck.