In den folgenden Situationen kann es sinnvoll sein, über den Protected Mode (PM) bescheid zu wissen:
Solange man gewöhnliche Programme für ein PM-Betriebsystem schreibt muß man sich kaum mit dem PM selbst beschäftigen. Moderne 32Bit Betriebsysteme stellen einem bis zu 4GB an Speicher für Code und Daten zur Verfügung, der nicht segmentiert ist. Für die meisten Fälle ist das mehr als genug. Da sowohl die interne Speicherverwaltung als auch die ganzen hardwarespezifischen Eigenheiten vom Betriebssytem verwaltet werden kann man den Komfort eines PM-Betriebsystem nutzen, ohne über die Hintergründe viel wissen zu müssen.
In 16Bit Betriebssystemen ist dies nicht ganz so bequem. Die Segmentgrenze von 64KB genügt oft nicht. In diesem Fall kann es durchaus hilfreich sein, zu wissen wie der Speicher vom Betriebsystem verwaltet wird. Auch bei der Fehlersuche ist dieses Wissen nützlich.
Wenn man Treiber für PM-Betriebsysteme schreibt kommt man oft mit den verschiedenen Privilegstufen (Privilege Levels, PL) und den aus ihnen resultierenden Einschränkungen und Möglichkeiten in Berührung. In manchen Fällen muß man sowohl den RealMode, den 16Bit PM, den 32Bit PM und den V86-Modus gleichzeitig berücksichtigen. In der Privilegstufe 0 (PL0) kann man direkt auf die Hardware zugreifen, was in anderen PLs verhindert werden kann. Code innerhalb der PL0 sollte besonders sorgfältig entworfen werden, weil viele Betriebsystemem im PL0 weder Taskwechsel noch Speicherschutz unterstützen. Ein Fehler an dieser Stelle kann dann das ganze Betriebsystem zum Absturz bringen!
Solange man aber keinen Speichermanager oder ähnliches implementieren will genügt es, wenn man sich auf die Kommunikation zwischen den verschiedenen Privilegstufen (zum Beispiel kann man nur auf inderektem Weg die Codeausführung vom PL0 zum PL3 übertragen), für den PL0 reservierte Anweisungen und dem grundlegendem Aufbau des Betriebssytem konzentriert.
Einen vollwertigen Speichermanager oder Multitasker zu implementieren ist jedoch wesentlich schwieriger...
Es mag komisch klingen, daß ein reines RealMode-Programm etwas mit dem PM zu tun haben könnte.
Der Grund dafür lautet: Auch wenn man sein Programm für den RealMode geschrieben hat kann es dennoch im PM laufen - DOS-Boxen verwenden meist den V86-Modus, eine Erweiterung des PM.
Auch wenn man den Unterschied in der Speicherverwaltung meist nicht bemerkt handelt es sich doch um ein Programm, das auf der Privilegstufe(PL)3 statt PL0 ausgeführt wird. Auch der EMM386 aktiviert den V86-Modus. Im V86-Modus kann man für das Betriebsystem vorgesehene Anweisungen nicht mehr ausführen, Hardware kann emuliert sein und sich folglich anders als erwartet verhalten - oder überhaupt nicht verfügbar sein (man denke nur an die Win9x DOS-Box, in der es reicht, den Zeitgeber umzuprogrammieren, damit das Betriebssystem abstürzt). Im RealMode funktionierende Spezialitäten wie automatische Hardwareerkennung, weniger gebräuchliche Hardwareeinstellungen und undokumentierte Funktionen können im V86 das Programm zum Absturz bringen. Deshalb ist es sinnvoll, sich auf Funktionen zu beschränken, die einen weitverbreiteten Standard darstellen: Für die Grafikausgabe sind die VESA- und Int13h-BIOS-Funktionen besser geeignet als die direkte Programierung der Grafikkarte wie im ModeX. Prozeduren zur Audiowiedergabe sollten so einfach und allgemein wie möglich sein, unübliche Einstellungen für den DMA oder die Soundkarte sind meist inkompatibel. Wo möglich sollte man die Funktionen des Betriebsystems verwenden.
Auch nicht unwichtig: Im PM ist das Neuladen von Segmentregistern wesentlich langsamer als im RealMode.
Ein wesentlicher Bestandteil der Programmierung mit DPMI ist das Erstellen und Laden von Deskriptoren. Man kann 16Bit Segmente für DOS-Funktionen verwenden und gleichzeitig das eigentliche Programm in 32Bit laufen lassen. Und bevor das Programm 32Bit Code und Daten verwenden kann müssen diese erst im RealMode erstellt werden. Ebenso benötigt man meist für den Zugriff auf den Grafikspeicher spezielle Deskriptoren, die den eigenen Datenbereich auf den physikalischen Grafikspeicher abbilden.
Im Allgemeinen ist unter DPMI der Code auf den PL3 beschränkt, mitsamt allen Nachteilen. Das Setzen der Deskriptoren und die Speicherverwaltung erfolgt über Betriebsystemfunktionen. Meist erledigen diese Funktionen nichts weiteres, als den entsprechenden Befehl im PL0 aufzurufen, da ein direkter Aufruf im PL3 nicht möglich ist. Viele DPMI-Server überprüfen die zu setzenden Deskriptoren nicht, sondern setzen sie nur, so daß die gesamten Schutzmechanismen effektiv umgangen werden. Deshalb sollte man beim Setzen der Speicherbereiche besonders sorgfältig vorgehen.
Unter DPMI wird häufig vom PM in den RM oder V86 gewechselt, es empfiehlt sich darum, zu wissen was intern dabei alles geändert wird.
Um in den FlatRealMode zu gelangen, startet man im RealMode, schaltet in den 32bit PM, ladet die Segmentregister mit Selektoren, die auf Deskriptoren der Basisadresse 0 und der Segmentgröße 4GB gesetzt sind, und schaltet danach wieder in den RealMode zurück ohne die Segmentregister zurückzusetzen. Eigentlich sollte man denken, daß jetzt die Segmente wieder nur 64KB groß sind, aber da der 386er während des Zurückschaltens die Segmentgrenzen nicht zurücksetzt kann man nun im 16Bit RealMode auf den gesamten Speicherbersich von maximal 4GB am Stück zugreifen.
Dies klingt zwar verlockend, ist auch sehr praktisch, aber leider gibt es einen großen Haken an der Sache: Man muß im RealMode starten, der V86 reicht nicht. Heutzutage laufen die meisten DOS-Programme entweder in einer DOS-Box eines PM-Betriebsystems oder unter DOS mit geladenem EMM386. In beiden Fällen kann man nicht in den PM umschalten, da der Prozessor schon im PM läuft und das Programm im PL3 läuft.
Wenn man möchte, daß mehr als nur ein oder zwei Prozent aller Anwender das Programm benutzen können sollte folglich lieber DPMI verwenden.