Rust prototype

Implementation

The builder appends a Zstandard-compressed bundle to a compiled native Windows PE runtime. The runtime can run completely offline without Bun or Node.js on the target system.

Build on Windows

With the stable Rust toolchain and the private repository checked out:

cargo test --workspace --all-targets
cargo build --release -p bsis

cargo run -p bsis -- build --config examples/hello/bsis.json --runtime target/release/bsis.exe --output BSIS-Hello-Setup.exe

A Linux-compiled binary is not a replacement for the required Windows runtime.

Inspect and install

.\BSIS-Hello-Setup.exe inspect
.\BSIS-Hello-Setup.exe install --target "$env:LOCALAPPDATA\BSIS-Hello-Test" --yes
Get-Content "$env:LOCALAPPDATA\BSIS-Hello-Test\app\hello.txt"
.\BSIS-Hello-Setup.exe uninstall --target "$env:LOCALAPPDATA\BSIS-Hello-Test" --yes

Running Setup.exe without a command starts a simple interactive console prompt. Supplying --yes skips the confirmation prompt. When started by double-clicking from Windows Explorer, the updated prototype displays either INSTALLATION COMPLETE or INSTALLATION FAILED OR CANCELLED, then waits for you to press Enter before closing. Explicit command-line invocations still return normally without pausing.

Optional WebView2 graphical installer

The experimental runtime also supports a separate, opt-in GUI:

.\BSIS-Hello-Setup.exe gui

The GUI uses an offline bundled HTML/CSS wizard with WebView2, but the WebView2 Runtime must already be installed on the PC. It displays real product metadata, asks for a new or empty installation folder, and invokes the same Rust installation engine as console mode. The default no-argument experience remains console-only.

See Installer UI for details and limitations, and the Uninstaller guide for the separate native removal program.

What happens after pressing Y?

If you accept the default path, the included hello-world sample installs to:

%LOCALAPPDATA%\Programs\bsis.hello\app\hello.txt

To open the folder in Windows Explorer, press Win+R and paste %LOCALAPPDATA%\Programs\bsis.hello\app.

The example contains only hello.txt to verify the install/uninstall pipeline. No desktop icon, Start Menu shortcut or app launcher is installed yet. An existing empty folder is now accepted, but a folder containing files is deliberately rejected. The interactive installer explains the problem and asks for another folder rather than proceeding. The prototype does not overwrite existing files or repair installations.

The completion summary shows the actual destination and a PowerShell-compatible uninstall command. The new command begins with &, because PowerShell requires the call operator before a quoted executable path. New installations include a separate Uninstall.exe in the installation folder. You can double-click it to confirm removal, or run the installed Uninstall.exe in PowerShell with uninstall --target <path> --yes. Older installations may still require Setup.exe.

Extract the GitHub Actions ZIP before running Setup.exe. Opening the EXE directly inside a ZIP may launch it from a temporary extraction directory, which can disappear after closing. The installer now warns about temporary locations. For new installations, the installed Uninstall.exe works without keeping the temporary Setup.exe. Extracting the ZIP remains preferable for reliable testing.

Choosing an existing folder

If you manually create a folder before installation, you can select it provided that it is empty. For example, a freshly created C:\Users\YourName\Desktop\MyBSISTest directory is acceptable.

If a selected directory already contains files, the installer tells you it is not empty, then asks for another location. Pick a new folder name or an existing empty directory.

The engine extracts files to a temporary sibling directory first. If the chosen empty folder already exists, it temporarily moves that original folder aside and tries to restore it if committing the completed installation fails. This is an experimental installation model, not a hardened transactional update system.

Safeguards and limits

• Installations target new or existing empty directories. Nonempty folders, files, symlinks and Windows reparse points are rejected. The parent directory must already exist for an explicitly provided target.
• Files are unpacked into a staging directory and verified before they are moved into place.
• A receipt lists installed files. Uninstall checks hashes and refuses to delete modified tracked files.
• New installations include a native Uninstall.exe with a receipt-verified checksum. It is not yet registered with Windows Apps & Features. Older installations without this helper can still be removed using their Setup.exe.
• A basic WebView2 GUI preview exists, but custom application-supplied UI, UAC, shortcuts, registry integration, Windows services, signing, LZMA2, updater and public plugin APIs do not.
• SHA-256 checksums detect corruption but do not authenticate a publisher.

Do not use this prototype for production distribution.