„Wir brauchen Prepar3D in einer 64Bit-Version“, tönt es aus der Szene. Das haben auch einige Flusianer unter unserem Prepar3D-Artikel kommentiert. Doch was hat es eigentlich mit 64Bit auf sich und wie kompliziert muss man sich solch eine Umstellung vorstellen? Mit welchen Problemen hätten wir hinsichtlich zahlreicher Add-Ons zu kämpfen, wenn eine 64Bit Version von Prepar3D erschiene? Philipp Münzel ist ein erfahrener X-Plane 10 Entwickler und Programmierer. Er hat sich etwas Zeit genommen und flusinews.de erklärt, was wir im Bezug auf 64 Bit wissen müssen.
Als Programmierer hat Philipp Münzel unter anderem am bekannten vasFMC mitgearbeitet sowie die Systeme des CRJ Regionaljet für X-Plane 10 erstellt. Auf der FS Konferenz 2015 in Paderborn erläuterte er bereits Fragen zu OOMs und 64Bit Software.
flusinews.de: Hallo Philipp. Was müssen wir erwarten, wenn eine 64Bit Version von Prepar3D erscheint? Müssten alle komplexen Add-Ons, welche extern programmierte Module beinhalten, komplett umgeschrieben werden?
Hallo,
„komplett umgeschrieben“ halte ich für etwas übertrieben. Ich kann hier gerne eine Einschätzung geben, muss aber vorausschicken, dass ich weder für Prepar3d, noch für FSX ein Experte bin. Ich bin Programmierer bei X-Plane, daher kann ich keine verlässlichen Einschätzungen zu anderen Plattformen geben. Ich gebe lediglich weiter, wie wir den Umstieg auf 64bit auf unserer Plattform erlebt haben.
Zunächst muss man feststellen, dass 64bit nicht die Lösung aller Probleme ist. 64bit sorgt weder für bessere FPS, noch dafür, dass alles schlagartig besser aussieht. 64bit löst genau ein einziges, klar definiertes Problem: Die maximale Größe des adressierbaren Arbeitsspeichers. Während man mit 32bit auf maximal 4GB beschränkt ist (Betriebssystemabhängig in der Praxis sogar noch deutlich weniger), verschiebt 64bit diese Grenze zu heute unvorstellbaren 16 Exabytes, also 16 Millionen Terabytes. Wenn ein 32bit-Programm mehr als 4GByte Speicher will, stürzt es unweigerlich ab, egal wie viel RAM tatsächlich im Rechner steckt. Es ist auch egal, wie viel virtueller Speicher oder als Auslagerungsdatei in Windows konfiguriert ist. Diesen Absturz kennen wir als den „OOM“, den Out-of-Memory Fehler.
Das kann mit 64bit nicht mehr vorkommen. Mit 64bit können wir so viel Speicher benutzen, wie tatsächlich RAM im Rechner steckt, plus zusätzlich noch so viel, wie das Betriebssystem virtuellen Speicher bereitstellt, ohne abzustürzen. Wenn man mehr benutzt, als RAM im Rechner steckt, wird es zwar sehr langsam, aber stürzt nicht ab.
Ein Programm auf 64bit umzustellen, ist theoretisch erst einmal ganz einfach: Man muss den Code mit einem 64bit-Compiler in Maschinencode für 64bit-Prozessoren übersetzen. Das ist eine Einstellung in der Entwicklungsumgebung. Theoretisch setzt man das Häkchen bei 64bit, klickt auf „Rebuild“, geht einen Kaffee holen und danach hat man ein 64bit-Programm.
In der Praxis ist es aber meistens so, dass im geschriebenen Code Annahmen getroffen wurden, die unter 64bit nicht mehr zutreffen. Man muss also in der Regel den gesamten Code einmal nach unsicheren Annahmen abklopfen, und beispielsweise alle Rechnungen, mit denen Zeiger auf Speicheradressen, sogenannte Pointer, berechnet werden, nochmal genau anschauen und gegebenenfalls so modifizieren, dass sie unter 32bit und 64bit immer das richtige Ergebnis liefern. Bei einem komplexen Programm kann das durchaus ein paar Wochen in Anspruch nehmen. Hat man noch viele externe Abhängigkeiten, also Programmbibliotheken die man nicht selbst geschrieben hat, kaskadiert das Problem natürlich.
Wenn das Programm, in unserem Fall also der Simulator selbst, dann umgestellt ist, stellt sich die Frage, welche externen Erweiterungen von der Umstellung betroffen sind. Alles, was reine Daten sind, also Beispielsweise Texturen, Landklassen, 3d-Gebäude oder -Objekte, Sound-Dateien, Panel-Graphiken, Flugpläne für den AI-Verkehr, all das funktioniert ohne Anpassung direkt auch mit einem 64-bit Simulator. Das gleiche dürfte auch für XML-Gauges gelten, die einige Add-On-Flugzeuge verwenden.
Schwierig wird es, wann immer kompilierter Code geladen wird. Das sind in erster Linie Module wie FSUIPC für externe Programme, DLLs wie AES zur Animation von Szenerien, und C-Gauges (Anmerkung: extern programmierte Instrumente), wie sie alle komplexen Flieger benötigen. Das kann erst einmal nicht mehr geladen werden, sondern dieser Code muss neu kompiliert werden für 64bit, mit allen Folgen die ich oben erwähnt habe.
Dann hat FSX/Prepar3d noch die Eigenschaft, dass er Maschinencode einbettet, wo man ihn erst einmal nicht erwartet, und das ist in den BGL-Dateien von Szenerien. Das wird für alle möglichen dynamischen Effekte in Szenerien genutzt, wie blickwinkelabhängige Lichter, windabhängige Windsäcke, oder animierte Jetways. Auch hier kann ich mir vorstellen, dass es erforderlich sein wird, die BGLs mit einem neuen Szenerie-Compiler nochmal zu übersetzen, andernfalls werden wohl nur die komplett statischen Elemente ohne weiteres funktionieren.
In X-Plane hat es etwa ein Jahr gedauert, bis alle Add-On-Anbieter einmal durch diesen Zyklus durch waren.
Wir hatten aber auch den Vorteil, dass es kommerzielle Add-Ons eigentlich erst seit drei Jahren überhaupt in der Form gibt. Das heißt, alle Anbieter sind noch aktiv, und sich den Code einmal zur Brust nehmen, modernisieren und neu übersetzen, war für viele überhaupt kein Problem, da es sowieso aktive Weiterentwicklung gab. 
Unter dem FSX stelle ich es mir sehr schwierig vor, Anbieter, die vielleicht vor 7 Jahren ein Add-On herausgebracht haben und mittlerweile etwas ganz anderes machen, zu überreden, ihren Quellcode von irgendwelchen uralten Backups herunterzukratzen, zu überarbeiten und neu zu übersetzen. Ich beispielsweise wüsste nicht mehr, wie ich allen Code, den ich vielleicht zu Studentenzeiten geschrieben habe, zuverlässig auf 64bit zum Laufen bekäme. Daher kann ich mir vorstellen, dass es eine Handvoll Add-Ons geben wird, die wahrscheinlich nie umgestellt werden, weil es einfach 7 Jahre nach dem Release gar kein Team mehr gibt, das man zusammentrommeln könnte.
Auf der anderen Seite kann man das aber auch positiv sehen: Mit der Umstellung auf 64bit hat man dann nur die Add-Ons, die auch wirklich die aktuellsten Techniken einsetzen, die am besten programmiert sind, und an denen man auch noch am längsten Spaß haben wird.
Ich kann mir aber auch vorstellen, dass Prepar3d eine Technik einsetzen könnte, die „thunking“ heißt, mit der man 32bit-Module in 64bit-Code hereinladen kann. Das zuverlässig zum Laufen zu bekommen, so dass auch alle schweinischen Tricks funktionieren, die der alten Code benutzt, halte ich aber für extrem schwierig. Wir haben uns bei X-Plane bewusst dagegen entschieden, 32bit-Plugins über thunking zu laden, da das einen nie endenden Rattenschwanz an Kompatibilitätsproblemen nach sich gezogen hätte. Daher wäre ich, würde ich bei Lockheed arbeiten, sehr vorsichtig mit dieser Idee.
Philipp Münzel
Wir bedanken uns recht herzlich bei Philipp Münzel für seine detaillierte Erklärung zu 64Bit und den daraus resultierenden Konsequenzen.
Bilder: CptCaptain
Bisher 3 Kommentare
Hm, nun ja – P3D basiert auf dem FSX und da es das damalige Entwickler-Team nicht mehr gibt, dürfte das Umschreiben des Codes dann wohl einer Sisyphusarbeit gleich kommen.
Damit stellt sich die Frage, ob LM dieses Geld investieren wird/will – oder ob sich die Verantwortlichen sagen, „da ist es billiger im Geheimen, gleich einen neuen Sim zu entwerfen“ – und mittels des heutigen P3D (und der Simmer-Community) dafür nur die nötigen Erfahrungen zu sammeln.
Wäre ich Entscheider bei LM und will einen Simulator für Schulungszwecke haben, würde ich mich zumindest so entscheiden, denn wenn schon Schulen, dann so realitätsnah wie es die Technik gestattet (vllt. ähnlich Outerra?). Ein Schulungssimulator der auf veralteter Programmtechnik beruht und erst kompliziert „modernisiert“ werden muss, macht nicht wirklich Sinn und ist die erheblichen Kosten nicht wert.
Da stimme ich dir zu, Manfred.
Outerra ist allerdings lediglich eine Grafikengine, in die derzeit auch Fluggeräte eingebunden werden können. Um daraus aber einen Flugsimulator zu programmieren, müsste noch sehr viel getan werden.
Hallo Frank,
ist schon klar, aber es war auch nur ein Beispiel für den Stand der Technik.
Auf welcher Plattform so ein neuer Flusi entwickelt würde oder ob er eine völlige Neuentwicklung sein würde, das dürfte man wohl nur – wenn überhaupt – in den heiligen Vorstandshallen von LM wissen 😉