MountPoint Docs

The wiki for all things MountPoint.

1. Platform Architecture

MountPoint operates across three distinct layers to ensure security, performance, and historical accuracy. These 3 layers run in a line to and from each other, here they are in order:

The API

Written in the highly optimized Go language, MountPoint's API handles all state management, user authentication (secured with JWT Bearer Tokens) and database transactions (With the lightweight and performant SQLite). It is the source of truth for player, quest and environment data.

The Client

The MountPoint client is written in Rust to ensure absolute performance and low-level advantages such as being able to emulate the UART protocol for sending data through virtualised serial ports to our environments running operating systems that lack TCP/IP. The client manages downloading and maintaining your environments, communicating with VirtualBox to ensure a seamless experience (via registering/unregistering, to not clutter up your VirtualBox GUI) and act as the middleman for sending data to and from environments!

The Agent

Every agent baked into MountPoint's environments are natively written from scratch to ensure the utmost compatibility and to take advantage of the operating system's features for maximum performance. In newer systems, the agent can communicate using HTTP, however in older, non-TCP/IP compatible systems, we utilize the vCOM port, as mentioned in The Client.

The vCOM Bridge

Vintage operating systems (for example, Microsoft Windows 2.1 or Apple System 5) cannot speak to the internet using HTTP, or even TCP/IP. To solve this, the Rust-based MountPoint Client spawns a TCP server mapping to VirtualBox's virtualized COM1 Serial Port. A good example is Windows 1.0. The agent in that environment is written using 80s K&R C to read/write to the COM port. Because the environment is configured to emulate a 16550A UART chip with a 16-byte hardware buffer, the Rust client tries to emulate it's behaviour when sending data by limiting transmission speeds to 8-byte chunks every 10 milliseconds to prevent memory overflow.

2. The Quest Engine

To conserve memory on older operating systems, agents are 'dumb'. They know absolutely nothing about quests or your profile. Instead, the client retrieves both your quest and profile data, calculates which of the quests you've completed, and how many, then puts together a payload to send to the agent using a strict formatting protocol.

USR|bennie|Lvl: 5|Pts: 120|Prog: 2/5| QST|1|FILE|C:\MP.TXT|none|none|none|Create a File|Make a file using Notepad and place it in the root of the C: drive.| QST|2|LOCK|none|none|none|none|[L] Paint Pro Pt. II|Locked.| END|

3. Check Criteria Syntax Reference

When creating a quest (coming soon to standard users!) you must use the 5-part pipe-delimited syntax. Not all checks work on all operating systems due to API differences. Refer to the tags to understand which system types are supported.

FILE (File Exists)

Win16

Checks if a specific file exists on the environment's filesystem. Uses standard fopen() logic. Works universally across almost all environments.

FILE|FILEPATH|none|none|none
FILE|C:\EXAMPLE.EXE|none|none|none

INI (Configuration Check)

Win16

Reads a standard .INI files and verifies a Key matches an Expected Value. This leverages GetPrivateProfileString in the WinAPI. Note: Modern Microsoft Windows operating systems have replaced INI files to the Registry, so this is only to be used for older systems. Windows 1.0 also only supports reading from the WIN.INI file due to API limitations.

INI|FILEPATH|SECTION|KEY|VALUE
INI|WIN.INI|windows|Beep|no

SIZE (File Size Minimum)

Win16

Checks if a file exists AND its size (in bytes) is equal to or larger than the target.

SIZE|FILEPATH|SIZE|none|none
SIZE|C:\EXAMPLE.TXT|50|none|none

EXEC (Process Running)

Win16

Checks if a specific program/process is running (loaded into memory). On legacy systems, this targets the module handle (e.g., CALC without the .exe extension). On modern systems, it targets the full process name.

EXEC|PROCESS|none|none|none
EXEC|EXPLORER|none|none|none

FIND (String Search)

Win16

Scans a text-based file for a specific word, phrase or sentence. Useful for having users write specific content into a file, or examing a text-based save file created by a program.

FIND|FILEPATH|STRING|none|none
FIND|C:\LETTER.TXT|MountPoint FTW!|none|none

VISION (AI-Powered Verification)

Win16 Win32 Unix AI

VISION is what makes some of MountPoint's more strict and impossible quests, possible. When you submit a VISION quest, the guest VM sends a message to the client telling it to create a screenshot. To allow support for older Win16 environments that don't support screenshots, the client will then send a signal to VirtualBox to make it create a screenshot of what is currently on the VM. The screenshot is then shown and presented to the user via the client to ensure the user reviews and permits the screenshot being sent to the AI.\n\n NOTE: VISION uses a third party AI model (Google Gemini 3.1 Flash Lite). Please ensure your screenshots are sent showing no sensitive information.

VISION|Does this image show Microsoft Paint on Windows 3.1 open with a drawing of a racecar?|none|none|none
VISION's best practices:
  • Be Specific & Direct: Phrase your prompt as a direct question. As short as possible with as much information as possible. Ensure the question can be answered by inspecting visual elements (Example: "Is the Calculator application visible in the screenshot of Windows 1.0 with the number '69' entered?".
  • Account for old graphics: Remember that vintage operating systems are subject to lower resolutions, and 16-color palletes. In these cases, don't ask for realism within drawings, modern colours or fine details.
  • Keep it SFW & Fun: The instructions given to the AI make the model fair, strict and fun. Reward creativity!
Coming Soon to MountPoint...

As I continue development on MountPoint, newer systems will be added with quest checks such as REG (Registry Checks) and PING (Network Checks)