Skip to main content

QB-Winget Overview

QB-Winget is a QB64/InForm desktop GUI wrapper around winget (Windows Package Manager) — a retro-styled interface for searching, selecting, queueing, persisting, and executing package installs, built entirely in QB64 BASIC.

:::info Lives at D:\BASIC, governed as DRS QB-Winget's source lives under D:\BASIC rather than D:\DRS — the only project in this documented set with that split between physical location and governance group. It's still evaluated against the Desktop Application Release Standard since it's a packaged desktop application, regardless of which drive folder it lives in. :::

Who it's for​

An operator who wants a GUI over winget without leaving a retro-BASIC-flavored toolset — described in its own ecosystem role as "an experiment in making CLI tooling visible and repeatable" rather than a production package manager replacement.

The core concept​

QB64 doesn't give direct structured access to another process's output, so the entire tool is built around file-based IPC: winget commands are shelled out to with their output redirected to files, which QB-Winget then parses back into structured in-memory results.

GUI (QB64 / InForm)
   │  shell out, redirect output
   ▼
winget search / winget install  →  winget_search_output.txt / winget_install_output.txt
   │
   ▼  parsed back into structured results
GUI displays results → operator queues packages → saved_packages.txt (persisted queue)
   │
   ▼
sequential install execution, one queued package at a time

Debug logging (debug_log.txt, debug_qb64.txt) captures parser and execution state — useful given how fragile shelling-out-and-parsing-text approaches can be against CLI output format changes.

Why this shape​

QB64/InForm is an unusual choice for 2026 desktop tooling, and that's the point — this project reads as much like a deliberate retro-computing exercise in the Aptlantis portfolio as it does a practical winget frontend. The file-based IPC approach is a direct consequence of the QB64 runtime's limited process-interaction primitives, not a design preference; the project's own NEXT_EVOLUTION doc reportedly proposes refactoring command execution into a shared layer reusable across Aptlantis, suggesting this text-file approach is understood internally as a constraint to eventually move past.