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
| Klasse | Basis | Zweck |
|---|---|---|
TLyxOSBackend | — | Das Lyx-OS-Backend |
| Signatur | Zweck |
|---|---|
NewLyxOSBackend(): TLyxOSBackend | Erzeugt das Lyx-OS-Backend |
–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.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.
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.