Verlauf der Betriebssystemmigration

Originalautor: Michael Steil
  • Übersetzung
Vom Übersetzer: Ich präsentiere Ihnen die Übersetzung eines Artikels von Michael Steil . Ich wollte schon lange einen ähnlichen Überblick über die Methoden zur Nutzung der Virtualisierung bei Kompatibilitätsproblemen erstellen. Ich habe sogar einige Anmerkungen zu diesem Thema veröffentlicht: im Lehrbuch zur Simulation, Kapitel 1 , und zu Habr in einem Post über System-VMs . Ich konnte die Frage jedoch nicht so tief enthüllen, wie es in dieser Arbeit dargestellt wird. Also habe ich beschlossen, die Übersetzung mit den Lesern zu teilen.


Hersteller von Betriebssystemen sind ein- oder zweimal im Jahrzehnt mit diesem Problem konfrontiert: Sie müssen ihre Benutzerbasis vom alten Betriebssystem auf ein ganz anderes neues Betriebssystem übertragen oder von einer CPU-Architektur auf eine andere wechseln, während sie weiterhin alte Anwendungen ohne Änderungen ausführen können. Außerdem können Sie Drittanbieter-Entwicklern dabei unterstützen, ihre Anwendungen auf das neue Betriebssystem zu portieren.

Schauen wir uns an, wie dies in den letzten 30 Jahren geschehen ist, und nehmen wir als Beispiele MS DOS / Windows, Apple Macintosh, Amiga OS und Palm OS.




Von CP / M nach PC-DOS / MS-DOS


CP / M ist ein 8-Bit-Betriebssystem von Digital Research, das auf allen Versionen von Intel 8080-basierten Systemen ausgeführt wird. 86-DOS von Seattle Computer Products, später als MS-DOS bezeichnet (auf IBM-Computern auch als PC-DOS bezeichnet). war ein Klon von CP / M für den späteren Intel 8086; Eine ähnliche Situation war bei CP / M-86 von DR selbst (dieses Betriebssystem wurde später DR-DOS genannt).

Da der Intel 8086 nicht binär kompatibel war, war er „Assembler-kompatibel“ mit dem 8080. Dies bedeutete, dass es einfach war, ein in Assembler für den 8080 oder Z80 geschriebenes 8-Bit-Programm in ein Assembler-Programm für den 8086 zu konvertieren, da diese beiden Die Architekturen waren sehr ähnlich (abwärtskompatibles Speichermodell, Registersätze leicht aufeinander abzubilden), nur die Maschinencodierungen der Befehle unterschieden sich.

Da MS-DOS dieselben ABI-Konventionen und eine Speicherkarte verwendete, war dieses Betriebssystem an der Quelle mit CP / M kompatibel. Auf CP / M-Systemen mit Zugriff auf maximal 64 kB Speicher war der Adressbereich 0x0000 bis 0x0100 (Nullseite) für die Anforderungen des Betriebssystems reserviert und enthielt unter anderem Befehlszeilenargumente. Die ausführbare Anwendung befand sich ab Adresse 0x0100 und höher, und das Betriebssystem befand sich oben im Speicher. Der Anwendungsstapel wuchs herab und begann knapp unter dem Start des Betriebssystems. Das 8086-Speichermodell unterteilt den Speicher in (überlappende) zusammenhängende Segmente mit einer Länge von 64 KB, sodass jedes dieser Segmente tatsächlich für die virtuelle Maschine 8080 ausreicht. Daher sind ausführbare MS-DOS-COM-Dateien bis zu 64 KB groß und werden ab der Adresse in den Speicher geladen 0x100 Der Bereich 0x0 - 0x100 in MS-DOS wird als Programmsegmentpräfix bezeichnet und ist der CP / M-Seite Null sehr ähnlich. Aufgrund der hohen Kompatibilität dieser Prozessoren und ihrer ABI war die Übertragung des Programms von CP / M nach DOS relativ problemlos. Ein solcher Port kann jedoch maximal 64 KB Speicher belegen (Beispiele sind 1982 Wordstar 3.0). Dies ermöglichte es jedoch, eine einzige Codebasisanwendung für beide Betriebssysteme mit nur wenigen Makrodefinitionen und zwei verschiedenen Assemblerprogrammen zu haben.

MS-DOS 2.0 brachte neue, leistungsfähigere API-Konventionen mit sich (Dateihandles anstelle von FSB- Strukturen , Unterverzeichnissen, .EXE-Format) und übertrug die meisten APIs von CP / M auf veraltete APIs. DOS blieb jedoch mit CP / M bis zur neuesten Version kompatibel.
Von CP / M nach PC-DOS / MS-DOS
Ändern SieNeue CPU
Neue OS-Codebasis
Neue AnwendungsausführungDirekt
Ausführung alter Anwendungen
(keine Änderung)
Wird nicht unterstützt
Ausführung alter TreiberWird nicht unterstützt
Tools zur AnwendungsportierungHohe Quell- und ABI-Kompatibilität

Von DOS zu Windows


Microsoft Windows wurde ursprünglich als grafische Shell über MS-DOS entwickelt. Alle Arbeiten mit Geräten und dem Dateisystem erfolgten durch Aufrufe der DOS-API. Daher wurden alle MS-DOS-Treiber direkt ausgeführt, und Windows konnte sie verwenden. DOS-Anwendungen können nach dem Beenden von Windows zu reinem DOS weiterhin ausgeführt werden.

Unter Windows / 386 2.1 wurde das Modell geändert. Dies war bereits der eigentliche Kernel des Betriebssystems, in dem viele virtuelle Maschinen im virtuellen 8086 (V86) -Modus nebeneinander ausgeführt wurden. Eine wurde für die MS-DOS-Sitzung und eine für jede Windows-Anwendung zugewiesen. Die virtuelle DOS-Maschine wurde von Windows für den Zugriff auf Gerätetreiber und das Dateisystem verwendet, sodass es sich fast um eine Treiberkompatibilitätsebene handelte, die in der VM ausgeführt wird. Der Benutzer kann eine beliebige Anzahl zusätzlicher DOS-VMs ausführen, um mit DOS-Anwendungen zu arbeiten. und jeder enthielt eine eigene DOS-Kopie. Windows hat Aufrufe aus dem Bildschirmspeicher sowie einige Systemaufrufe abgefangen und vom Windows-Grafiktreiber oder der ersten DOS-Haupt-VM umgeleitet.

Windows 3.x begann mit der Verwendung nativer Treiber für Windows, die Aufrufe innerhalb der DOS-VM ersetzten, und begann auch, einige DOS-Aufrufe an Geräte innerhalb von Windows umzuleiten. Bei der Standardinstallation von Windows 95 wurden keine Aufrufe an DOS-VMs mehr für die Arbeit mit Treibern und dem Dateisystem verwendet. Falls erforderlich, konnte dieser Modus jedoch weiterhin verwendet werden.

DOS war nicht nur eine Kompatibilitätsumgebung für ältere Treiber und Anwendungen, sondern bot auch eine Windows-Befehlszeile. Als Windows 95 die Unterstützung für lange Dateinamen einführte, musste ich DOS-API-Aufrufe abfangen, um neue Funktionen für Befehlszeilendienstprogramme bereitzustellen.
Von MS-DOS zu Windows
Ändern SieNeues Betriebssystem
Neue AnwendungsausführungDirekt
Ausführung alter AnwendungenVirtuelle Maschine mit altem Betriebssystem
Ausführung alter TreiberVirtuelle Maschine mit altem Betriebssystem
Tools zur AnwendungsportierungNicht vorgesehen

Von DOS nach Windows NT


Systeme der Windows NT-Familie basierten nicht auf DOS, erlaubten jedoch ab der ersten Version die Ausführung von MS-DOS-Anwendungen. Wie bei der Nicht-NT-Version von Windows arbeitete das DOS-Programm in diesem Fall im V86-Modus des Prozessors. Anstatt jedoch eine vollständige Kopie von MS-DOS in der VM zu verwenden, hat NT nur den Anwendungscode darin abgelegt, alle Systemaufrufe und Geräteaufrufe abgefangen und in NT-API-Aufrufe eingeschlossen. Tatsächlich ist diese Methode keine reine VM: Der V86-Modus wurde nur zum Erstellen des Speichermodells verwendet, das für die Unterstützung von DOS-Anwendungen erforderlich ist.

Es gibt ein weit verbreitetes Missverständnis, dass die Windows NT-Befehlszeile eine „DOS-Shell“ ist. Tatsächlich waren der Interpreter und die Hilfsprogramme native NT-Anwendungen, und das NTDVM-Subsystem (virtuelle DOS-Maschine) wurde erst gestartet, als wirklich ein DOS-Programm über die Befehlszeile gestartet werden musste.
Von DOS nach Windows NT
Ändern SieNeues Betriebssystem
Neue AnwendungsausführungDirekt
Ausführung alter AnwendungenKompatible APIs
Ausführung alter TreiberWird nicht unterstützt
Tools zur AnwendungsportierungNicht vorgesehen

Von Windows 3.1 (Win16) zu Windows 95 (Win32)


Ab der Veröffentlichung von Windows NT 3.1 im Jahr 1993 wurde klar, dass es schließlich das klassische Windows ersetzen würde. Trotz der Tatsache, dass NT dieselbe Benutzeroberfläche mit Win16 und gute DOS-Kompatibilität hatte, erforderte jede neue Version, die veröffentlicht wurde, normalerweise einen ziemlich leistungsfähigen Computer, um zu funktionieren. Daher verlief die Migration von Windows zu Windows NT umgekehrt: Jede Windows-Version wurde mehr und mehr zu NT, bis sie sich ziemlich ähnelten. Zu diesem Zeitpunkt waren sogar die schwachen Computer dieser Zeit leistungsfähig genug, um unter NT zu arbeiten.

Ein großer Schritt zur Annäherung zwischen Windows und Windows NT war die Unterstützung der nativen Win32-API für NT. Der erste Schritt war ein kostenloses Upgrade von "Win32S" auf Windows 3.1, das eine Teilmenge (daher die "S" - Teilmenge - im Namen) der Win32-API unter klassischem Windows bereitstellte. Win32S erweiterte den Windows-Kernel um die Möglichkeit, 32-Bit-Adressräume für alle 32-Bit-Anwendungen zu erstellen (in NT hat jede Anwendung ihren eigenen Raum erstellt). Außerdem wurden Versionen einiger Bibliotheken von NT (z. B. RICHED32.DLL) sowie 32-Bit-DLLs, die Aufrufe von Win32API-Aufrufen auf niedriger Ebene (Subsysteme "GDI" und "USER") erhielten, automatisch in Aufrufe des Win16-Subsystems übersetzt ("Thunking") ").

In Windows 95 war diese Funktionalität standardmäßig verfügbar. Sie verwendete auch isolierte Adressräume für 32-Bit-Anwendungen und unterstützte eine größere Teilmenge der Win32-API. Einige Basisanwendungen wurden zu 32-Bit-Anwendungen (z. B. Explorer). Ein erheblicher Teil des Basissystems war jedoch immer noch 16-Bit-Anwendungen. Mit dem Aufkommen von Windows 95 stellten die meisten Entwickler auf die Erstellung von 32-Bit-Anwendungen um, mit denen sie auch auf Windows NT-Systemen kompiliert werden konnten.
Von Windows 3.1 (Win16) zu Windows 95 (Win32)
Ändern SieNeuer Prozessor- und Adressierungsmodus
Neue AnwendungsausführungKompatibilitätsebenen
Ausführung alter AnwendungenDirekt
Ausführung alter TreiberDirekt
PortierungsmethodenHohe Quellkompatibilität

Von Windows 9x zu Windows NT


Der zweite Schritt bei der Migration von 16-Bit-Windows zu Windows NT erfolgte beim Wechsel von Windows ME zu Windows XP (NT-Familie) im Jahr 2001. Windows NT (2000, XP ...) war ein vollständig 32-Bit-Betriebssystem mit Win32-API Erlaubt auch das Ausführen von 16-Bit-Windows-Anwendungen durch die Übersetzung von Win16-Aufrufen nach Win32 (Thunking).

Das Windows NT 3.1 / 3.5 / 4.0-Treibermodell (Windows NT Driver Model) unterschied sich vom klassischen Windows (VxD) -Ansatz, sodass Windows 98 (ein Nachfolger von Windows 95) und Windows 2000 (ein Nachfolger von Windows 4.0) beide das neue Windows-Treibermodell unterstützten. Der gleiche Treiber kann nun in beiden Betriebssystemen verwendet werden, wobei jedoch der ursprüngliche Modus für ältere Treiber beibehalten wird.

Als Microsoft Heimanwender auf NT-Systeme übertrug, verdienten die meisten Anwendungen, Spiele und Treiber unter Windows XP Geld. Das einzige, was ich neu schreiben musste, waren die Systemdienstprogramme.
Von Windows 9x zu Windows NT
Ändern SieNeues Betriebssystem
Neue AnwendungsausführungDirekt
Ausführung alter AnwendungenWin16:
Win32- API-Übersetzung: live
Ausführung alter TreiberAPI-Unterstützung vom alten Betriebssystem
Anwendungsportierungsmethoden
API-Unterstützung für hohe Quellcode-Kompatibilität vom alten Betriebssystem

Von Windows i386 (Win32) zu Windows x64 / x86_64 (Win64)


Der Übergang von 32-Bit- zu 64-Bit-Windows ist derzeit im Gange. Windows XP war das erste verfügbare Microsoft-Betriebssystem für die Intel 64 / AMD64-Architektur. Alle nachfolgenden Systeme (Vista, 7, 8, 10) sind in 32- und 64-Bit-Versionen verfügbar. In 64-Bit-Editionen arbeitet der Kernel wie alle Systembibliotheken und die meisten Anwendungen im 64-Bit-Modus. Die 32-Bit-API wird vom WOW64-Subsystem (Windows-on-Windows 64) unterstützt. Eine 32-Bit-Anwendung verbindet sich mit 32-Bit-Bibliotheken. API-Aufrufe auf niedriger Ebene werden jedoch über WOW64 in ihre Gegenstücke für 64-Bit-DLLs übersetzt.

Da die Treiber im selben Adressraum wie der Kernel ausgeführt werden, war es schwierig, 32-Bit-Treiber zu unterstützen. Die Unterstützung für DOS- und Win16-Anwendungen in 64-Bit-Versionen des Betriebssystems wurde ebenfalls eingestellt.
Von Windows i386 (Win32) zu Windows x64 / x86_64 (Win64)
Ändern SieNeuer Prozessor- und Adressierungsmodus
Neue AnwendungsausführungDirekt
Ausführung alter AnwendungenBroadcast anrufen
Ausführung alter TreiberWird nicht unterstützt
AnwendungsportierungsmethodenHohe Quellkompatibilität

Von Apple Macintosh für 68K zu Macintosh auf PowerPC


Apple hat seine Computer zwischen 1994 und 1996 von Motorola 68k-Prozessoren auf Motorola / IBM PowerPC umgestellt. Da das Macintosh-Betriebssystem System 7 hauptsächlich in Assembler für 68 KB geschrieben wurde, konnte es nicht einfach in ein Betriebssystem für PowerPC konvertiert werden. Stattdessen wurde das meiste durch eine Simulation durchgeführt. Der neue „Nano-Core“ empfing und verarbeitete Interrupts und führte eine minimale Speicherverwaltung durch, wobei die Funktionen von PowerPC abstrahiert wurden. Der integrierte 68k-Emulator führte das alte Betriebssystem aus, das für die Kommunikation mit dem Nano-Core modifiziert wurde. Daher wurde System 7.1.2 für PowerPC tatsächlich paravirtualisiert und auf einer sehr dünnen Schicht des Hypervisors ausgeführt.

In der ersten Version von Mac OS für PowerPC wurde der größte Teil des Systemcodes im 68k-Emulator ausgeführt, einschließlich der Treiber. Ein Teil des für die Leistung wichtigen Codes wurde für die direkte Ausführung umgeschrieben. Der ausführbare Loader konnte Programme mit PowerPC erkennen und direkt ausführen. Der Großteil der Kommunikation mit dem Betriebssystem lief immer noch über den Emulator. In späteren Versionen von Mac OS wurde immer mehr Code von 68 KB auf PowerPC kopiert.
Von Macintosh für 68k zu Macintosh für PowerPC
Ändern SieNeuer Prozessor
Neue AnwendungsausführungBroadcast anrufen
Ausführung alter AnwendungenParavirtualisiertes altes Betriebssystem im Emulator
Ausführung alter TreiberParavirtualisiertes altes Betriebssystem im Emulator
AnwendungsportierungsmethodeHohe Quellkompatibilität

Von klassischem Mac OS zu Mac OS X


Ähnlich wie Microsoft Benutzer von Windows zu Windows NT migrierte, wechselte Apple von dem klassischen Mac OS zu Mac OS X. Während das klassische Mac OS ein hackisches Betriebssystem mit kooperativem Multitasking war, ohne Speicherschutz, und noch teilweise ausgeführt Der Systemcode im 68k-Emulator von Mac OS X basierte auf NEXTSTEP, einem modernen UNIX-ähnlichen Betriebssystem mit einer völlig anderen API.

Als Apple sich für eine Migration entschied, portierten sie die Systembibliotheken des klassischen Mac OS („Toolbox“), entfernten Anrufe, die auf einem modernen Betriebssystem nicht unterstützt werden konnten, und ersetzten sie durch Alternativen. Die neue API wurde als „Carbon“ bezeichnet. Die gleiche API wurde 1998 in klassischem Mac OS 8.1 verfügbar, so dass Entwickler ihre Anwendungen für die Ausführung unter Mac OS X aktualisieren und gleichzeitig die Kompatibilität mit dem klassischen Mac OS aufrechterhalten konnten. Als Mac OS X im Jahr 2004 veröffentlicht wurde, konnten Carbonized-Anwendungen zu diesem Zeitpunkt auf beiden Betriebssystemen ohne erneute Kompilierung ausgeführt werden. Dies erinnert an den Ansatz von Microsoft, das klassische Windows näher an Windows NT heranzuführen.

Da jedoch nicht zu erwarten war, dass zum Zeitpunkt des Eintreffens von Mac OS X alle Anwendungen auf Carbonized umgestellt werden, enthielt das neue Betriebssystem auch eine virtuelle Classic- oder Blue-Box-Maschine, auf der unmodifiziertes Mac OS 9 ausgeführt wurde und beliebige Funktionen unterstützen konnte Anzahl alter Anmeldungen. Anforderungen an das Netzwerk und das Dateisystem innerhalb der VM wurden abgefangen und an das Host-Betriebssystem umgeleitet. Durch die Integration in den Fenstermanager sahen die beiden Desktop-Umgebungen nahezu nahtlos aus.
Von klassischem Mac OS zu Mac OS X
Ändern SieNeues Betriebssystem
Neue AnwendungsausführungDirekt
Ausführung alter AnwendungenKlassisch: VMs mit dem alten
Carbon OS : Gemeinsame API für beide Systeme
Ausführung alter TreiberVirtuelle Maschine für altes Betriebssystem
AnwendungsportierungsmethodeGemeinsame API für beide Systeme

Migration von Mac OS X von PowerPC auf Intel IA-32


Im Jahr 2005 kündigte Apple einen zweiten Übergang von einer CPU-Architektur zu einer anderen an, diesmal von PowerPC zu Intel IA-32. Da dieses Betriebssystem hauptsächlich in C und Objective-C geschrieben wurde, konnte es problemlos auf IA-32 portiert werden. Apple behauptet, dass sie immer die Betriebssystemversion für IA-32 unterstützt haben, beginnend mit der allerersten Veröffentlichung.

Um alte Anwendungen auszuführen, die noch nicht auf IA-32 portiert wurden, hat Apple den Rosetta-Emulator in das neue Betriebssystem aufgenommen. Dieses Mal war es nicht eng mit dem Kernel verbunden, wie dies beim Übergang von 68k zu PowerPC der Fall war. Der Kernel bot nur die Möglichkeit, einen externen Rekompiler für die Anwendung auszuführen, wenn sich herausstellte, dass er für PowerPC bestimmt war. Rosetta übertrug den gesamten Anwendungs- und Bibliothekscode und stellte eine Schnittstelle für die Interaktion mit dem Betriebssystemkern bereit.
Mac OS X mit PowerPC auf Intel IA-32
Ändern SieNeue CPU-Architektur
Neue AnwendungsausführungDirekt
Ausführung alter AnwendungenEmulator für Benutzermodus
Ausführung alter TreiberWird nicht unterstützt
AnwendungsportierungsmethodeHohe Quellportabilität

Mac OS X 32 Bit unter Mac OS X 64 Bit


Der nächste Übergang für Apple war die Migration von der 32-Bit-Architektur von Intel auf die 64-Bit-Version. Es geschah unter Mac OS X 10.4 im Jahr 2006. Obwohl das gesamte Betriebssystem wie bei Windows auf 64-Bit portiert werden konnte, entschied sich Apple für einen Ansatz, der dem Wechsel zu Windows 95 ähnlicher ist: Der Kernel blieb 32-Bit, erhielt jedoch Unterstützung für 64-Bit-Anwendungen. Alle Systemanwendungen und Treiber blieben 32-Bit, aber einige Bibliotheken erhielten auch 64-Bit-Optionen. Daher hat eine 64-Bit-Anwendung, die mit 64-Bit-Bibliotheken verknüpft ist, 64-Bit-Systemaufrufe durchgeführt, die von 32-Bit im Kernel konvertiert wurden.

Mac OS X 10.5 lieferte ab sofort alle Bibliotheken in der 64-Bit-Version, der Kernel blieb 32-Bit. In Version 10.6 wurde der Kernel auf 64-Bit konvertiert und die Verwendung von 64-Bit-Treibern wurde obligatorisch.
Mac OS X 32 Bit unter Mac OS X 64 Bit
Ändern SieNeuer CPU- und Adressierungsmodus
Ausführung neuer ProgrammeBroadcast anrufen
Ausführung alter ProgrammeDirekt
Ausführung alter TreiberDirekt
AnwendungsportierungsmethodeKohlenstoff: Nicht unterstützt
Kakao: Quellcode-Kompatibilität

AmigaOS mit 68k auf PowerPC


Die Amiga-Plattform verwendete in der Commodore-Ära von 1985 bis 1994 dasselbe Betriebssystem für die 68k-CPU. Seit 1997 gibt es jedoch ein Upgrade für ein Motherboard mit einer PowerPC-Architektur-CPU. Dieses Betriebssystem hat seinen Quellcode nicht für Dritte bereitgestellt, sodass es nicht möglich war, ihn auf PowerPC zu portieren. Aus diesem Grund lief Amiga OS selbst weiterhin auf einem dedizierten 68k-Chip, und der erweiterte Programmlader erkannte den PowerPC-Code und übertrug ihn auf die zweite CPU. Alle Systemaufrufe wurden über die Bibliotheksschicht zurück auf 68.000 geroutet.

AmigaOS 4 (2006) ist der echte AmigaOS-Port auf PowerPC. Dieser Übergang war sehr aufwändig, da ein Großteil des Quellcodes des Betriebssystems zunächst von der BCPL-Sprache in die C-Sprache konvertiert werden musste. Die Anwendungsunterstützung für 68k erfolgt durch die Emulation von Binärcode und die Weiterleitung von API-Aufrufen.
AmigaOS c 68k auf PowerPC (Version 3.x)
Ändern SieNeue CPU
Neue AnwendungsausführungBroadcast-Systemaufrufe (auf der neuen CPU)
Ausführung alter AnwendungenDirekt (auf der alten CPU)
Ausführung alter TreiberDirekt
AnwendungsportierungsmethodeHohe Quellkompatibilität

AmigaOS c68k auf PowerPC (Version 4.0)
Ändern SieNeue CPU
Neue AnwendungsausführungDirekt
Ausführung alter AnwendungenEmulator auf Benutzerebene
Ausführung alter TreiberWird nicht unterstützt
AnwendungsportierungsmethodeHohe Quellkompatibilität

Palm OS mit 68 KB auf ARM


Palm stellte 2002 unter Palm OS 5 von 68.000 Prozessoren auf ARM um. Das Betriebssystem wurde auf ARM portiert, und der 68k-PACE-Emulator (Palm Application Compatibility Environment) wurde zur Ausführung älterer Anwendungen mitgeliefert. Palm empfahl den Entwicklern jedoch nicht, zum Schreiben von Anwendungen für ARM zu wechseln, und stellte nicht einmal eine Umgebung für die Ausführung solcher Anwendungen bereit, die auf dem Betriebssystem ausgeführt werden. Es wurde argumentiert, dass die meisten Anwendungen für Palm OS die meiste Zeit im (bereits optimierten "nativen") Code des Betriebssystems verbracht haben und daher beim Portieren keine spürbaren Geschwindigkeitsgewinne erzielt worden wären.

Für Anwendungen, die die CPU intensiv nutzen oder Code zum Komprimieren oder Verschlüsseln von Daten enthalten, stellte Palm eine Methode zur Verfügung, mit der kleine Teile des ARM-Codes in einer 68-KB-Anwendung ausgeführt werden können. Ähnliche ARMlets (später PNOlets genannt - „Palm Native Objects“) könnten aus dem Code für 68k aufgerufen werden. Sie boten eine minimale Datenübertragungsschnittstelle (eine Ganzzahl pro Eingang und eine Ganzzahl pro Ausgang). Die Entwickler selbst mussten sich um die Übertragung großer Strukturen im Speicher kümmern und die Probleme der Bytereihenfolge (Endianness) und deren Ausrichtung lösen. Prozeduren aus dem ARM-Code konnten weder den Code für 68k aufrufen noch API-Aufrufe an das Betriebssystem senden.

Die Anbindung an die 68k-Architektur (die nicht der verwendeten Hardware eigen ist) als Hauptarchitektur für die meisten Anwendungen bedeutete die Verwendung der virtuellen Architektur von Benutzeranwendungen in der Art von Java oder .NET. Der Übergang zu ARM war für Entwickler von Drittanbietern nahezu unsichtbar. Theoretisch ermöglichte dieser Ansatz Palm, die Host-Architektur bei Bedarf in Zukunft zu minimalen Kosten erneut zu ändern.
Palm OS mit 68 KB auf ARM
Ändern SieNeue CPU
Neue AnwendungsausführungNicht unterstützt (PNOlet für Prozeduren)
Ausführung alter AnwendungenEmulation auf Benutzerebene
Ausführung alter TreiberWird nicht unterstützt
AnwendungsportierungsmethodeNicht unterstützt (PNOlet für Prozeduren)

Schlussfolgerungen


Lassen Sie uns die Übergänge zwischen dem Betriebssystem und der CPU und die Herangehensweise verschiedener Hersteller an die Migrationsaufgabe untersuchen.

Bittiefe (Adressraumbreite)


Der Übergang in einen neuen Prozessormodus ist für das Betriebssystem am einfachsten, da alte Anwendungen weiterhin direkt ausgeführt und API-Aufrufe übersetzt werden können. Gleichzeitig kann das Betriebssystem selbst entweder den alten Modus weiter verwenden, um Systemaufrufe von neuen Anwendungen in das alte Format umzuwandeln, oder auf eine neue Bit-Kapazität umschalten und Anrufe in alte Anwendungen umwandeln. Es gibt auch zwei Möglichkeiten, die Anrufe selbst abzufangen. Es ist möglich, API-Aufrufe auf hoher Ebene (z. B. das Erstellen eines GUI-Fensters) abzufangen, dies ist jedoch schwierig, da es viele solcher Aufrufe gibt und es schwierig ist, den richtigen Konverter für so viele Funktionen zu schreiben.

Alternativ kann das Betriebssystem Systemaufrufe auf niedriger Ebene konvertieren. In diesem Fall ist die abgefangene Schnittstelle sehr eng. Da jedoch alte Anwendungen mit alten Bibliotheken verknüpft sind und neue mit neuen Bibliotheken, belegen deren Speicherung und Verwendung doppelt so viel Speicherplatz (Speicher), wenn der Benutzer gleichzeitig alte und neue Anwendungen ausführt.
Neuer Prozessormodus oder neue Bittiefe
OSAlter ModusNeuer ModusRufrichtung
Anrufübernahmerate
Windows16 bit32 bitneu zu altBibliotheken
Windows NT32 bit64 bitalt zu neuKern
Mac OS X32 bit64 bitneu zu altKern

Beim Wechsel von 16 auf 32 Bit in Windows blieb das Betriebssystem 16 Bit, und Aufrufe wurden von einem 32-Bit-Format in eine 16-Bit-API konvertiert. Bei der Konvertierung von Windows NT von 32 auf 64 Bit wurde das gesamte Betriebssystem zu 64 Bit, und alte Systemaufrufe wurden in neue konvertiert. Unter Mac OS X wurde derselbe Übergang anders ausgeführt: Das Betriebssystem blieb 32-Bit und 64-Bit-Systemaufrufe wurden auf Kernelebene übertragen.

Die für Windows NT und Mac OS X verwendeten Ansätze sind ähnlich, da 32-Bit-Anwendungen in beiden Fällen weiterhin 32-Bit-Bibliotheken verwendeten und 64-Bit-Anwendungen weiterhin die neuen 64-Bit-Bibliotheken verwendeten. Der Unterschied lag im neuen Kernel-Modus. Im Fall von Windows gab es einen Vorteil in Form der Möglichkeit, mehr als 4 GB Speicher im Kernelmodus zu verwenden, und einer gewissen Beschleunigung durch die Verwendung des neuen 64-Bit-Registersatzes. Unter Mac OS X ist es weiterhin möglich, die alten 32-Bit-Treiber ohne Änderungen zu verwenden. Und ja, der zweite Schritt, Mac OS X, hat später komplett auf den 64-Bit-Kernel und die Treiber umgestellt.

CPU


Das Ändern des verwendeten Prozessors ist schwieriger, da der alte Maschinencode auf der neuen Architektur nicht mehr ausgeführt werden kann. Einige Betriebssysteme waren nicht so einfach zu übertragen.
Neuer Prozessor
OSAlte CPUNeue CPUMethode zum Starten alter AnwendungenAnrufübernahmerate
CP/M, DOS8080/Z808086Перекомпиляция-
Macintosh68KPowerPCИсполнение ОС и приложения внутри эмуляции-
Mac OS XPowerPCi386Эмуляция уровня пользователяядро
Amiga68KPowerPCДвойной ЦПУ и трансляция вызововбиблиотеки
Palm68KARMЭмуляция уровня пользователябиблиотеки

Mac OS X für Intel und Palm OS für ARM wurden so plattformunabhängig geschrieben, dass sie auf die neue Architektur portierbar sind. Beide beinhalteten Recompiler, die den alten Code ausführten. Dies ist der einfachste Ansatz. Amiga OS konnte nicht auf diese Weise portiert werden, da sein Quellcode nicht verfügbar war. Daher umfasste das System beide Prozessoren - das ursprüngliche Betriebssystem und sein Code wurden auf dem alten Prozessor ausgeführt, und der neue Code funktionierte auf dem neuen Prozessor und sendete Systemaufrufe an die alte CPU.

Für den klassischen Macintosh (von 68k bis PowerPC) war der Quellcode verfügbar, konnte jedoch nicht einfach geändert werden. Die Umstellung erfolgte daher ähnlich wie bei Amiga, jedoch auf einer CPU. Der größte Teil des Betriebssystems wurde im Emulator ausgeführt, neue Anwendungen wurden direkt gestartet und Systemaufrufe wurden vom Emulator zurückgerufen.

MS-DOS war eine Implementierung eines alten Betriebssystems einer anderen Firma. Die Ausführung von altem Binärcode wurde nicht unterstützt. Stattdessen wurden Entwickler gebeten, ihre Anwendungen neu zu kompilieren.

Betriebssysteme


Der Übergang zu einem neuen Betriebssystem unter Beibehaltung aller Benutzer und Programme ist der schwierigste unter den Betrachteten.
Neues Betriebssystem
Altes BetriebssystemNeues BetriebssystemMethode zur Ausführung alter Anwendungen
CP / MDosKompatible API
DosWindowsVirtuelle Maschine mit altem Betriebssystem
DosWindows NTAPI-Emulation
Windows 9XWindows NTKompatible API
Mac OSMac OS XKlassisch: Virtuelle Maschine mit alter
Carbon OS : kompatibler API

Der gewählte Ansatz hängt von den Plänen ab, die alte API des alten Betriebssystems zu unterstützen. Wenn die API gut genug ist, um im neuen Betriebssystem unterstützt zu werden, sollte das neue Betriebssystem nur dieselbe API unterstützen. Dies geschah für Übergänge von CP / M nach DOS und von Windows 9x nach Windows NT. In gewisser Hinsicht wurde dies getan, um vom klassischen Mac OS auf Mac OS X zu wechseln. In diesem Fall war Carbon jedoch nicht die Haupt-API des neuen Betriebssystems, sondern nur eine der drei unterstützten (Carbon, Cocoa, Java). Praktisch alles außer Kakao ist mittlerweile veraltet.

Wenn die alte API für das neue Betriebssystem nicht gut genug ist, aber die Arbeit alter Anwendungen unterstützt werden muss, ist es sinnvoll, das alte Betriebssystem zusammen mit den zugehörigen Anwendungen in der VM zu belassen. Dies wurde im Fall von Windows zum Ausführen von DOS-Anwendungen und in Mac OS X für ältere Mac OS-Anwendungen verwendet.

Wenn die Schnittstelle des alten Betriebssystems relativ klein ist oder eine detaillierte Wiederholung der Semantik von Aufrufen nicht erforderlich ist, ist die Emulation der API möglicherweise die beste Lösung: Abfangen von Systemaufrufen der alten Anwendung mit Zuordnung zu neuen. Dies wurde verwendet, um DOS-Anwendungen für Windows NT zu aktivieren. während der Kompatibilitätsgrad durchschnittlich war.

Fazit


Es ist unerwartet zu sehen, wie viele verschiedene Migrationsmethoden für alle untersuchten Betriebssysteme durchgeführt wurden, und nicht ein einziger Ansatz, der völlig anders wiederholt wurde. Der Grund dafür ist vielleicht, dass die Bedingungen für den Übergang in jedem Fall leicht unterschiedlich waren und es viel Zeit in Anspruch nahm, die beste Lösung für jeden spezifischen Fall zu entwickeln.

Aber es gibt allgemeine Muster. Im Laufe der Zeit ist das Betriebssystem moderner und weniger ungeschickt geworden. Darüber hinaus verliefen die Migrationen in vielen kleinen Schritten, wobei große Sprünge vermieden wurden. Moderne Betriebssysteme, Windows NT und Mac OS X, können relativ einfach auf neue Architekturen portiert werden, Emulatoren helfen, alte Anwendungen auszuführen, und die Übersetzung von Systemaufrufen kann verwendet werden, um sie systemeigenen Aufrufen zuzuordnen. Dank der von Ihren Systemen verwendeten Abstraktionen kann das Betriebssystem schrittweise oder bitweise auf eine neue Architektur portiert werden und ein Teil davon kann in der alten Umgebung verbleiben und ein Teil kann auf eine neue Umgebung übertragen werden. Dieselben Abstraktionen ermöglichen es Entwicklern, ganze Subsysteme zu ersetzen und Teile des Betriebssystems neu zu erstellen, ohne die Benutzer stark zu beeinträchtigen. Diese Prozesse werden rationalisiert und ausgereifter - und leider

Literatur


Leider führen einige Links des ursprünglichen Beitrags nirgendwo hin und ich konnte die Dokumente nicht finden.

1. Pat Villani. FreeDOS-Kernel: Ein MS-DOS-Emulator für Plattformunabhängigkeit und die Entwicklung eingebetteter Systeme
2. Unterbrochene Verknüpfung mit der PowerPC-Dokumentation von Apple
3. Brian Maas. Palm OS 5 ARM-Programmierung
4. PNOLet-Beispiele

Jetzt auch beliebt: