[Feature Proposal] Application launcher

[alanjfs]

Hi @mosra,

I mentioned this briefly in the chat, and am planning on implementing this either as a one-off for my application, or as an open source library for others to use, if it turns out it can remain separate enough. Then I was thinking whether it would make a good fit for Magnum in general, hence opening this issue to chat about it.

What is a Launcher?

It's an executable for calling another executable.

Why would you want one?

I'm glad you asked!

• Crash Guard - Handle crashes, or any exit with a return value other than 0
• Freeze Guard - Monitor for unresponsiveness, possibly do something about it
• Save-on-crash - Automatically save on crash, by knowing where in memory the launched executable stores its data; it's bound to be read-only upon having crashed
• Bug Report - Provide a "Submit a Bug Report" form on crash
• Splash Screen - Provide users with instant feedback of launch, whilst awaiting assets and drivers to load and initialise, using OS-native window facilities. Maybe even options, like resolution or display or which GPU to pick
• Version chooser - For when a user has multiple versions of your software installed, including betas or alphas.
• Requirements - Determine whether minimum system requirements are met, or evaluate whether third-party dependencies like the VS2015 redistributable is installed. Otherwise download and install it prior to launching.
• Seggregate internet/network access - Some customers may not be able to run internet-able software on their machines, for e.g. security or paranioa. They could launch the main exe directly, given special conditions (e.g. an offline licence)
• ... More?

In a nutshell, lots of interesting things could be done via a separate executable that would be difficult or plain impossible to do from within the same executable.

How does this fit within Magnum?

I'm not sure. I would like it to be an entirely separate project, something operating almost entirely outside of the main executable. As an add-on, without any (or minimal) effect on the main exe.

One example I use frequently is this.

• https://github.com/71/scoop-better-shimexe

On Linux, you can wrap any command into an executable script. Windows doesn't have the same luxury, where .bat files have to ask Are you sure you'd like to exit this script? after each run, and doesn't allow for overrides like DPI scaling. This fixes that, giving you an exe that calls a command much like it would on Linux.

It's a launcher, one exe calling another, with customisable glue inbetween the two. It's where I would start from.

Anyway, just a thought, let me know yours. :)

[mosra]

The crash handler (backtrace printing etc.) is something I'm planning to add into Corrade::Main, in a multiplatform way, as I very often need to see a backtrace after an application or a test crashes. In that case it would be the app itself (well, its zombie) doing the backtrace retrieval, will all restrictions (allocation, filesystem access...) that come out of it. This could be later extended to work across processes, but I've never done (or saw) anything like that myself, so I don't know how feasible it is to do in a cross-platform way.

I'm afraid the complete package doesn't really fit into Magnum's scope. One of the main reasons is that it would need some UI and that's where opinions start to differ wildly and there's too many possibilities to choose from, yet none is ideal / cross-platform enough (accessible? stylable? power-efficient? choose at most one). OTOH, the low-level building blocks to aid with building the launcher, such as detecting system version, or something similar to python's subprocess for launching processes and managing their input/output, those all do fit into the scope. So I guess we could turn those into TODO items with well-defined scope to act on.

Windows doesn't have the same luxury

IIRC *.lnk files allowed to do this? Passing arguments, environment vars and the like.

[williamjcm]

something similar to python's subprocess for launching processes and managing their input/output

Not gonna lie, this is something I'd be interested in.

[mosra]

Related to the subprocess handling: https://github.com/sheredom/subprocess.h