- Man nimmt PDF-Dateien leicht als statische Dokumente wahr, tatsächlich enthalten sie jedoch Unterstützung für JavaScript
- Der PDF-Standard verfügt über eine eigene JavaScript-Standardbibliothek
- Moderne Browser wie Chromium und Firefox implementieren aus Sicherheitsgründen nur äußerst eingeschränkte APIs
- Nur Adobe Acrobat unterstützte die vollständige Spezifikation von JavaScript in PDFs und umfasste sehr weitreichende Funktionen wie 3D-Rendering, HTTP-Anfragen und das Erkennen sämtlicher Monitore eines Nutzers
- Auch auf Basis der eingeschränkten Browser-APIs lässt sich die gewünschte Berechnungslogik ausführen, aber der IO-Teil ist stark begrenzt
- C-Code kann zu asm.js kompiliert und innerhalb einer PDF ausgeführt werden
- Verwendet wird eine ältere Version von Emscripten (z. B. 1.39.20, die asm.js als Ziel unterstützt)
- Der TinyEMU-RISC-V-Emulator wurde angepasst, zu asm.js kompiliert und dann in einer PDF ausgeführt
- Die Methoden für Bildschirmausgabe und Eingabe sind dieselben wie bei DoomPDF (Doom in einer PDF ausführen)
- Für die Anzeige wird jede Zeile als eigenes Textfeld verwendet, und der Pixelzustand wird mit ASCII-Zeichen dargestellt
- Die Eingabe übergibt Tastendrücke über eine virtuelle Tastatur und ein Textfeld an die VM
- Es treten erhebliche Performance-Probleme auf
- Beispiel: Das Booten des Linux-Kernels dauert etwa 30 bis 60 Sekunden und ist damit mehr als 100-mal langsamer als eine normale Ausführung
- In der V8-Engine des Chrome-PDF-Viewers ist JIT deaktiviert, was die Leistung deutlich verschlechtert
- Für das Root-Dateisystem kann zwischen 64-Bit- und 32-Bit-Versionen gewählt werden
- Standardmäßig wird ein 32-Bit-Buildroot-System verwendet (ursprünglich aus dem TinyEMU-Beispiel übernommen)
- Es gibt auch eine 64-Bit-Version mit Alpine Linux, diese ist jedoch etwa doppelt so langsam und wird daher normalerweise nicht verwendet
4 Kommentare
So wahnsinnig wie Doom unter Linux, lol
Ist das Romantik oder Wahnsinn? Alter Falter…
wow...
Wow......