WSL wrapper

The WSL wrapper lets you run Linux applications on Windows computers using WSL. BOINC provides a WSL wrapper executable.

The WSL wrapper

• chooses a WSL distro to use
• launches an app in that distro
• monitors the app (e.g. CPU usage) and reports its status to the BOINC client
• monitors suspend/resume/abort requests from the BOINC client and performs them.

App versions

A WSL app version must include

• The WSL wrapper, marked as the app version's main program.
• A 'control script', the top-level executable that runs in WSL. Its logical name must be main and it must have the <copy_file/> attribute.
• Additional files: data files or 'worker' executables.

Command line args of the WSL wrapper

--os_name regexp
--os_version regexp

Use only WSL distros whose OS name and version match the regular expressions.

--pass_thru X

Append X to the command used to run the app's control script (see below). X may specify multiple options, e.g. `` --pass_thru '--foo 1 --blah 2'

## The control script

The control script 'main' must
* Resolve input and output link files as needed,
and connect the resulting paths to worker executables.
* Execute the worker executable(s).

Typically 'main' is a bash or perl script,
since those are the languages present in stock WSL distros.

In bash, you can resolve link files with this function:

resolve () { sed 's/<soft_link>//; s/</soft_link>//' $1 | tr -d '\r\n' }

This takes a logical file name (the name of a link file)
and returns the path of the physical file in the project directory.

For example, suppose your application has a binary with
logical name ```worker```
that takes input and output filenames as command-line arguments.
These files have logical names ```in``` and ```out```.
The control script might look like:

#! /bin/bash resolve () { sed 's/<soft_link>//; s/</soft_link>//' $1 | tr -d '\r\n' } $(resolve worker) --nsecs 60 $(resolve in) $(resolve out)

If instead the work reads from stdin and writes to stdout,
the last line might be

$(resolve worker) --nsecs 60 &lt; $(resolve in) > $(resolve out)

If the job involves several executables run in sequence,
the control script might look like

#! /bin/bash ... if [ ! -f prog1_done ]; then prog1; touch prog1_done fi if [ ! -f prog2_done ]; then prog2; touch prog2_done fi ...

This prevents rerunning steps that have already been completed.

If none of the above features are needed
(input and output files all use ```<copy_file/>```,
and there's only one computing step)
then ```main``` can simply be the (binary) worker executable.