Add support on Windows to install atexit handler(s) early in application’s startup.
authorlateralusX <lateralusx.github@gmail.com>
Thu, 20 Oct 2016 10:48:09 +0000 (12:48 +0200)
committerlateralusX <lateralusx.github@gmail.com>
Thu, 20 Oct 2016 10:49:09 +0000 (12:49 +0200)
commitbdbea3589f23bbd25e0325a6c1c7cb544e3bddc7
treeba0f1f0c9ab5dd02a9d62f75a29d6fa240f9d3e1
parentd19e5c42a527800e92fd980a718c5b2afabb2a53
Add support on Windows to install atexit handler(s) early in application’s startup.
This is done by adding a new argument to install specific named custom handlers,
--handlers=. There is also an argument to describe the supported handlers on current
platform, --help-handlers.

The supported handlers can be different depending on implementing platform and currently
only Windows uses this feature to install an atexit handler waiting for a keypress
before exiting process. This is however a generic concept that could be used to run handler
code early in the boot process on any platform for other purposes. Adding the argument first
in command line makes it possible to do the installation very early in the boot process, this
is used by the waitkeypress atexit handler in order to be used in cases where the arguments
itself are unsupported or incorrect formatted causing an exit of the process.

When running under Visual Studio debugger the console window will not be kept
open when the debugee process terminates. Normally this is not a problem, but there are scenarios,
especially when having errors in configuration, when you would like the console to be kept open so
you can read the output in order to detect the error.

Normally there is an option to start the console application from within Visual Studio but
not attaching the debugger (CTRL+F5) and by default Visual Studio will then inject a pause
in the execution of the process holding up the console, but for some reasons, having more
complex solutions like mono, this feature stops working, so it is not possible to keep the console
open in that scenario for more complex solutions.

This makes it a little problematic to hold the process when working within the debugger in order
to look for console output and errors. Since mono can exit the process using exit command and not
only by returning from main, the developer needs to set breakpoints on both end of main and in c-runtime
exit methods. Even if that is a possible workaround this option won't work when running the process outside
the debugger (CTRL+F5).

This commit adds a handler argument that can be used on Windows (potential on other platforms as well), atexit-waitkeypress.
The waitkeypress will hold the console and process open until a key is pressed and is very
useful when running and debugging mono from within Visual Studio. Example of output when running mono’s mono-mini-regression-test
with an assembly not found together with –handlers=atexit-waitkeypress command line argument:

failed to load assembly: gshared-nofound.exe
Overall results: tests: 0, 100% pass, opt combinations: 25
Press any key to continue . . .

Currently this is only implemented for Windows, but could be enabled for other platforms,
if similar need exist elsewhere.

Since this is a standard mono command line option it is possible to inject it using the MONO_ENV_OPTIONS environment variable as well.
mono/mini/driver.c
mono/mini/mini-runtime.c
mono/mini/mini-windows.c
mono/mini/mini.h