# KOMPATIBILITAET — OrientOS gegen Arch Linux und Windows 11

**Stand 14.09.2026.** Grundlage: gemessener Bestand im Repo
`/root/jarvis/projects/u_DiS4in7esMF1/osum`, Zweig `main`, HEAD `ce4a232`
(nach dem Merge von `virtiogpu`). Nichts in dieser Datei ist geschaetzt,
wo eine Zahl steht, ist sie im Baum nachgezaehlt oder gemessen.

Diese Datei beantwortet EINE Frage von Justin (14.09.): *„was fehlt
gegenueber Windows und Arch, und was braucht man wirklich."*
Die Punkteliste mit IDs bleibt `OFFEN.md`; hier steht die Einordnung
und die **Reihenfolge**.

---

## 1. Was OrientOS heute hat (gemessen)

| Bereich | Stand |
|---|---|
| Kern | ~145.000 Zeilen in `kernel/` (118 Dateien), SMP ueber ACPI-MADT |
| Ring 3 | 173 Programme in `kernel/user/`, **135** davon bindet `/bin/fas` |
| Syscalls | ~174 `SYS_*`-Konstanten in `kernel/sys.fi`, **Nummern wie Linux x86-64** |
| Speicher | Seitenverwaltung, `mmap`/`brk`, Faeden + Futex (Runde POLL/FREMDLAND) |
| Platte | AHCI + IDE + NVMe + virtio-blk |
| Dateisysteme | eigenes **OFS** mit Journal (`ofs.fi`/`ofsj.fi`), **FAT**, devfs, procfs |
| Netz | eigener TCP/IP-Stack (`inet.fi`), DHCP, TLS 1.3 mit Kettenpruefung; Karten: e1000, r8169, virtio-net |
| USB | xHCI + EHCI, HID (Tastatur/Maus) |
| Ton | AC97, Intel HDA |
| Anzeige | Rahmenpuffer + Modi-Pruefung (`vmode.fi`), seit 14.09. **virtio-gpu** (`vgpu.fi`) |
| ACPI | Tafeln, Abschalten (S5), Akku/Deckel/Einschalttaste (Runde ACPI-EREIGNISSE) |
| Oberflaeche | Fensterserver **im Kern** (`wm.fi`, 9.265 Z.), Kachelbaum (`tile.fi`), Themes, `wlib`/`wig` als Toolkit, fUi als Design-System |
| System | Benutzer + Rechte, Login + Sperrbildschirm, Installer **mit Dual-Boot**, Store mit OTA, Hotplug |
| Fremde Programme | **statisch** gelinkte Linux-Binaries laufen unveraendert: Lua 5.4.7, SQLite 3.46.0, QuickJS (`tools/foreign/README.md`) |

## 2. Was gegenueber Arch Linux fehlt

Sortiert danach, wie hart es einen Umsteiger trifft.

| # | Luecke | Folge im Alltag | ID |
|---|---|---|---|
| 1 | **Dynamischer Lader (`ld.so`)** — kein `PT_INTERP`, kein System-V-Startstapel mit `auxv` | praktisch jedes echte Linux-Programm startet nicht | `F-007` |
| 2 | **Keine X11-/Wayland-Schnittstelle** | kein fremdes GUI-Programm bekommt ein Fenster — Firefox, LibreOffice, alles | `F-008` |
| 3 | **Syscall-Luecken** gegenueber Linux, nicht systematisch vermessen | jedes portierte Programm stirbt an einer anderen Stelle | `F-009` |
| 4 | **WLAN** — Rahmen und Profile da, kein Funktreiber | nur Kabel | `N-005` |
| 5 | **ext4/NTFS nicht lesbar** | Dual-Boot bringt nichts: die andere Platte bleibt unsichtbar | `K-016`/`K-017` |
| 6 | **Kein echter GPU-Treiber, kein OpenGL/Vulkan** — 3D nur in Software (`r3dsoft.fi`) | keine Spiele, keine beschleunigte Oberflaeche auf Blech | `G-012` |
| 7 | **Bluetooth, Drucker, Kamera** | Kopfhoerer, Drucken, Videoanruf | `K-006`/`K-007`/`K-008` |
| 8 | **Kein Suspend/Ruhezustand (S3/S4)** | Deckel zu heisst: aus | `K-018` |
| 9 | **Keine Plattenverschluesselung (LUKS-Aequivalent)** | gestohlener Rechner = offene Daten | `K-019` |
| 10 | **Keine Videocodecs** (H.264 und Nachfolger) | Video nur, was der Browser kann | `P-022` |
| 11 | **Kein Paket-Oekosystem, keine Container** | Software nur aus unserem Store | `O-005` |

## 3. Was gegenueber Windows 11 ZUSAETZLICH fehlt

- **Die gesamte Win32-Welt.** Ein Wine-Aequivalent ist nicht geplant: Wine
  baut eine fremde, undokumentierte API mit Millionen Zeilen nach. Unsere
  Wette ist die andere Richtung — die **Linux-Syscall-Schnittstelle**, weil
  sie dokumentiert, stabil und viel kleiner ist (Abschnitt 5).
- **Treibersignierung, Secure Boot, TPM-Attestierung.** Das ist kein
  Programmierproblem: ein selbstgebautes System kann keine Attestierung
  vorweisen, der irgendjemand traut.
- **Folge, die sich nicht wegprogrammieren laesst: Kernel-Anti-Cheat
  (Vanguard, Faceit, EAC/BattlEye im Kernelmodus) ist prinzipiell aus.**
  Nicht „schwer" — aus. Auch unter Linux mit Proton laeuft es nicht.
  Was denkbar bliebe: Einzelspieler-Titel, aber erst nach Vulkan + einer
  Wine-artigen Schicht + DXVK, also in der Reihenfolge, in der Proton ueber
  Jahre entstanden ist.

## 4. Was wir gegenueber beiden HABEN

Damit die Liste nicht nur in eine Richtung zeigt:

- **Ein Fenstersystem mit echtem Kachelbaum** statt Snap-Vorlagen
  (`docs/TILING.md`: „ein Template ist eine Aufzaehlung, und eine
  Aufzaehlung endet").
- **Die Trennung stimmt schon wie bei Wayland** — die Anwendung malt in
  ihren Puffer und sieht den Bildschirm nicht. X11 kann das bis heute nicht.
- **Ein Abbild von 130 MiB**, das auf echtem Blech bootet.
- **Ein eigener Browser** (Certus), statt Chromium einzubetten.
- **Alles ist nachmessbar**: jede Runde liefert Zusagen mit Zahlen und
  Gegenproben, nicht Behauptungen.

## 5. Der kuerzeste Weg zu „richtiges OS"

**Nicht Wine. Nicht alles nachbauen. Drei Bausteine:**

1. **Dynamischer Lader + `auxv`** (`F-007`) — danach laufen dynamisch
   gelinkte Linux-Programme. Der billigste Weg ist vermutlich, das echte
   `ld-musl-x86_64.so.1` als Interpreter zu benutzen und nur die fehlenden
   Syscalls zu liefern, statt einen Lader nachzubauen.
2. **Syscall-Luecken schliessen** (`F-009`) — gemessen, nicht geraten:
   jeden unbekannten Syscall der Zielprogramme protokollieren, Tabelle
   bauen, genau die bauen. Erfahrungsgemaess stirbt so etwas an
   `arch_prctl` (TLS ueber `%fs`), nicht an der Menge.
3. **Wayland-Server in Ring 3** (`F-008`), der das Protokoll auf die
   vorhandenen `WM_*`-Syscalls uebersetzt. Wayland und nicht X11, weil das
   Protokoll viel kleiner ist **und unsere Architektur schon so gebaut ist**.
   Kritische Vorfragen, die zuerst zu messen sind: Dateideskriptoren ueber
   den Socket (`SCM_RIGHTS`) und gemeinsam genutzter Speicher fuer
   `wl_shm`-Puffer.

**Danach** sind Firefox, LibreOffice und tausende echte Programme in
Reichweite — ohne dass wir eine einzige fremde API nachbauen.

Erst danach lohnen die teuren Brocken: echter GPU-Treiber -> Vulkan ->
(eventuell) eine Windows-Schicht.

## 6. Die Regel, die das alles zusammenhaelt

Aus `FREMDSOFTWARE.md` Abschnitt -1, unveraendert gueltig:
**Kompatibilitaet ueber SCHMALE Schnittstellen, nicht ueber Nachbau.**
Wir bauen nie das fremde System nach, wir bedienen die duennste Stelle, an
der die fremde Software ohnehin schon andockt.

## 7. Runden, die dazu am 14.09.2026 gestartet wurden

| Runde | Zweig | Ziel | Messlatte |
|---|---|---|---|
| **DYNLADER** | `dynlader` | dynamischer Lader + fehlende Syscalls | dynamisch gelinktes BusyBox, >=10 Applets byteweise gleich wie auf dem Wirt |
| **WAYLAND** | `wayland` | Wayland-Server auf `WM_*` | ein echter, unveraenderter Wayland-Client zeigt ein Fenster, im Foto geprueft |
| **WMPLUGIN** | `wmplugin` | Erweiterungen fuer den Fensterserver (Vorbild Hyprland/`hyprpm`), aber in **Ring 3** | Plugin an/aus zur Laufzeit; abstuerzendes und haengendes Plugin toeten den Schreibtisch nicht |
| **FREMDFS** | `fremdfs` | ext4 + NTFS lesen | bekannter Baum, jede SHA-256 stimmt; kaputter Superblock wird abgewiesen |

Bewusst **nicht** gestartet: **WLAN**. `docs/WLAN-BEFUND.md` sagt es selbst —
es fehlen 802.11-MAC, Firmwareladen, WPA2/3-Supplicant und Regulatorik,
und auf dem Bauserver steckt **keine WLAN-Karte**. Jede Runde dort
produziert Code, den niemand nachmessen kann. Das wird sinnvoll, sobald
OrientOS auf Justins eigenem Rechner laeuft — dann wird gezielt der Chip
gebaut, der wirklich drinsteckt.