Cloud Application Repository

With minimal installation, can run a selection of online application everywhere, remotely. Slowly.

• Home

https://github.com/wenuam/wm_app

1. Install the latest version of WinFsp (you MUST have admin/root rights though)
2. Clone or download/extract this repository to have access to its whole structure
3. Explore the folder tree and run a batch/bash file to execute the corresponding cloud application
4. Wait a bit until the application starts (executed from %HomeDrive%\Volumes\wm_app)

Usually it is the AMD64 (aka x86_64, aka x64) binaries that are presented, unless no other option available.

Whenever possible, the Linux binaries are available alongside the Windows binaires, sharing common data files.

List of currently available cloud applications :

Directory tree of a mounted application is as follow:

• 📁 %HomeDrive%\Volumes: all users
  • 📁 wm_app
    • 📁 application: actual mount point
      • 📁 version or tag
        • 🛠️ The application files...
• 📁 %AppData%: user files (Roaming)
  • 📁 wm_app
    • 📁 repository (complete name starting with "wm_app")
      • 📁 log
        • 📁 %year%-%month%
          • 📃 The wm_app_*-[version|tag]-%date%_%time%.[stdout|stderr|hubfs].log files...

Each batch/bash file is a cloud application startup script.

It will mount a repository based on its path and filename (with optional version).

Say wm_app/dev/lng/pi/Picat-3.6.8_240527.bat will mount wm_app_dev_lng_pi__Picat into %HomeDrive%\Volumes\wm_app\Picat and run %HomeDrive%\Volumes\wm_app\Picat\3.6.8_240527\Picat.exe.

If no version is specified, say wm_app/dev/lng/pi/Picat.bat, by default the latest tag will be used and run %HomeDrive%\Volumes\wm_app\Picat\latest\Picat.exe.

Beware, some system commands (ie. where in Windows) can execute VERY slowly (about 30 s) on mounted remote repositories. This may only happens during the startup phase so be patient. Get a coffee, touch some grass...

• console: is set to 0, the batch/bash file will wait for user input at exit.

• cli: compose the command line to run with the name of other environment variables (may also use those defined in the configuration file, see below).

• debug: if set (regardless of its content, unused), the script will output debug strings during the startup and clean-up phases.

• deferred: if set, optional wm_app dependencies will be unmounted after specified SECONDS.

It can be useful to leave a dependency used by another wm_app mounted for a little while, long enough to start the other application, hence not having to remount it just after having unmounted it.

When the other application is launched with its batch/bash file, the deferred unmount is cancelled, for the time being.

When no more application is using a dependency, and no deferred unmount is pending, it is effectively unmounted.

• detached: if set (regardless of its content, unused), the application will run in a separate process (unstable).

• exe: if set, the batch/bash file will run the requested executable instead of the one based on the name of the repository.

• log: if set to stdout and/or stderr, will redirect corresponding output to log files (see Folders above).

• A configuration file can be located alongside the batch/bash file.

Its filename shall reflect the batch/bash filename, including the version number, or "more", separated with dashes.

First will be loaded the base.cfg file, then the base-version.cfg file, finally the base-version-more.cfg file, if available.

This way it will replace generic settings with gradually more specific, depending on the use case.

Say Picat-3.6.8_240527.bat will try to load Picat.cfg first, then Picat-3.6.8_240527.cfg.

Hence you can set common settings for all versions in the generic base.cfg configuration file.

The base-version-more.cfg configuration is for "more" specific use cases, like setting virtual environnements and such.

For this though, the batch/bash filename shall reflect the expected configuration file to load.

Thus Picat-3.6.8_240527-sat_demo.bat will also load Picat-3.6.8_240527-sat_demo.cfg, if present.

If it is not based on an available version, it will use the latest tag by default, use this with care though.

That's to say Picat-sat_demo.bat will mount wm_app_dev_lng_pi__Picat/latest, yet load Picat-sat_demo.cfg, not Picat-latest-sat_demo.cfg.

• As for the configuration file's content, the format is pretty straightforward:

./bin
path=../test
wm_app_dev_lng_pi__Picat
wm_app_dev_lng_pi__Picat/3.6.8_240527
wm_app_dev_lng_pi__Picat/3.6.8_240527/Picat.exe
exe=bin/Picat.exe
test=2
console=
deferred=30

If a line doesn't set a variable, it is assumed to set the path variable by default.

If a path variable is set, it will be appended to the path environnement variable (at the end).

Relative paths (starting with ./..) are resolved from the common mount point (ie. %HomeDrive%\Volumes\wm_app).

If the path starts with "wm_app" is it assumed being a wm_app dependency to be mounted automatically BEFORE the application starts. Can be quite long depending on network speed and planets alignment. Get coffee, touch grass...

If no version is specified (ie. just wm_app_dev_lng_pi__Picat), the latest one will be appended to the path environnement variable (ie. %HomeDrive%\Volumes\wm_app\Picat\latest).

If a specific executable name is specified (ie. .../Picat.exe) and one is already accessible amongst the path environnement variable, its path will be removed in order to leave only the specified executable available.

Variables are initialized with the configuration file's content (ie. test will be set to 2, console unset, etc).

Hence it is possible to set the deferred environnement variable this way, as it'll be used only at the application's exit.

Some internal commands are buggy on remote mount points (.ie where in Windows) so a similar one has been coded to be able to tweak its internals.

Some internal commands are pending deprecation (.ie wmic in Windows) so they will be replaced with a proper alternative in the future.

When I say PROPER I mean "fast", "efficient", "lightweight", "readable", "maintainable", "long-lasting", not randomly engineered aberrations "fixing" dummy Kanban tickets to please clueless bosses. As the proverb goes “if it ain't broke, don't fix it”...