There are many programming languages that don't by default produce native executables. Among them are Python, Java, Ruby, Perl, Raku, ... The list goes on. When creating an application in any of those languages one will at one point typically hit the issue that the application can only be started by calling a the language interpreter and passing a few arguments. The usual solution is to write a small wrapper shell script on *nix and a bat file on Windows. That's a quick solution. But getting such wrapper scripts really right is not trivial. Typical pitfalls are:
- The script depends on the current working directory
- It requires Bash and thus can't work in e.g. BusyBox
- It fails to process args that contain special chars (e.g.
<or>(or many others) combined with bat files is fun) - It insta returns to the prompt and then ghost writes to the terminal on Windows
A few years ago I started working on a tool to help generating robust wrappers. I've finally pushed it over the finish line.
It's called Executable Runner Generator. The name could have been chosen better, but we'll have to live with it now. It's written in the Raku language, but the generated wrappers are independent of the language. Currently it can generate wrappers that work on Windows x86_64 and all sorts of POSIX systems.
In general the task of the wrapper is to put together a command line (and runtime environment like CWD and env vars) and execute the program. How exactly that happens is configured via a set of options. The wrapper has the ability to:
- Construct paths relative to the wrappers file system location
- Change path separators on Windows
- Change the current working directory
- Specify the command line arguments to pass to the program
- Forward the arguments passed to the wrapper
- Add and remove environment variables
A webservice
As not everyone is keen to install Raku on their system just to generate a wrapper, I've set up a small website that exposes the functionality:
Call for help
On Windows the generator relies on a native executable written in C to do it's magic. There is no exec syscall on Windows. The program works around this by staying alive, letting the child process inherit it's file descriptors and once the child finishes, returns with it's exit code. I'm pretty sure this "exec emulation" isn't perfect. But as I'm not a Windows low level expert I don't even know what I'm missing. Signals? Security contexts? I don't know.
So: If you are knowledgeable of the lower Windows APIs, I'd love to get feedback on the implementation or maybe even a patch. You can reach me on many channels.
Top comments (0)