Vega.Backend.LyxOS — Fensterbackend für Lyx OS

Vega läuft dort als gewöhnliche Ring-3-Anwendung unter dem Compositor. Der stellt Fenster bereit, liefert Ereignisse und liest den Fensterpuffer aus — mehr braucht die HAL nicht.

Quelldatei: Vega/Backend/LyxOS.lyx

→ Alle Units · Alle Steuerelemente · Vega VCL

Klassen

Klasse Basis Zweck
TLyxOSBackend — Das Lyx-OS-Backend

Freie Funktionen

Signatur Zweck
NewLyxOSBackend(): TLyxOSBackend Erzeugt das Lyx-OS-Backend

Zu beachten

  • Namensverwechslung: Lyx OS hat einen eigenen Compositor, der ebenfalls „vega“ heißt. Er ist nicht diese VCL, sondern deren Gegenstelle.
  • Gebaut wird derzeit noch ohne –target=lyxos — inzwischen aus Gewohnheit, nicht aus Not. Die drei Gründe von damals sind mit lyxc 1.1.4D erledigt und mit 1.1.11B nachgemessen: alloc/free übersetzen (#1718, die eigene platform/lyxos/Vega/Mem.lyx über mmap ist kein Zwang mehr), die stdlib-Importe tragen wieder (#1717) und die Builtin-IDs 3 und 6–15 sind im Backend belegt (#1715). Lyx OS startet die bisher gebauten ELF-Dateien weiterhin.
  • Das native Zielformat ist LYX!, nicht ELF: –target=lyxos erzeugt den Maschinencode-Container, den der LX-34-Loader lädt (Magic 4C 59 58 21). Print/PrintLn nehmen dort seit 1.1.4D Variable, Zahl, Ausdruck und Funktionsaufruf (#1716) — die Literal-Beschränkung gilt nicht mehr. Damit ist –target=lyxos → LYX! der richtige Weg; der ELF-Weg war der Übergang, nicht das Ziel.
  • Die Aufrufe laufen über Vega.Backend.LyxCall.

Abhängigkeiten

Importiert: Vega.Types, Vega.Events, Vega.Backend, Vega.Strings, Vega.Backend.LyxCall · Standardbibliothek: std.io

Wird importiert von: keiner anderen Vega-Unit

Letzte Aktualisierung: 2026-08-27 — Abschnitt „Zu beachten„ gegen lyxc 1.1.11B nachgemessen (#1715, #1716, #1717, #1718 behoben); Klassen, Aufzählungen, Konstanten und freie Funktionen maschinell aus Vega/Backend/LyxOS.lyx erhoben.