Assembler-Programmierer, die aufwuchsen mit &ms-dos; und windows &windows; neigen oft dazu Shotcuts zu verwenden. Das Lesen der Tastaur-Scancodes und das direkte Schreiben in den Grafikspeicher sind zwei klassische Beispiele von Gewohnheiten, die unter &ms-dos; nicht verpönt sind, aber nicht als richtig angesehen werden. Warum dies? Sowohl das PC-BIOS als auch &ms-dos; sind notorisch langsam bei der Ausführung dieser Operationen. Sie mögen versucht sein ähnliche Angewohnheiten in der &unix;-Umgebung fortzuführen. Zum Beispiel habe ich eine Webseite gesehen, welche erklärt, wie man auf einem beliebten &unix;-Ableger die Tastatur-Scancodes verwendet. Das ist generell eine sehr schlechte Idee in einer &unix;-Umgebung! Lassen Sie mich erklären warum. Zum Einen mag es schlicht nicht möglich sein. &unix; läuft im Protected Mode. Nur der Kernel und Gerätetreiber dürfen direkt auf die Hardware zugreifen. Unter Umständen erlaubt es Ihnen ein bestimmter &unix;-Ableger Tastatur-Scancodes auszulesen, aber ein wirkliches &unix;-Betriebssystem wird dies zu verhindern wissen. Und falls eine Version es Ihnen erlaubt wird es eine andere nicht tun, daher kann eine sorgfältig erstellte Software über Nacht zu einem überkommenen Dinosaurier werden. Aber es gibt einen viel wichtigeren Grund, weshalb Sie nicht versuchen sollten, die Hardware direkt anzusprechen (natürlich nicht, wenn Sie einen Gerätetreiber schreiben), selbst auf den &unix;-ähnlichen Systemen, die es Ihnen erlauben: &unix; ist eine Abstraktion! Es gibt einen wichtigen Unterschied in der Design-Philosophie zwischen &ms-dos; und &unix;. &ms-dos; wurde entworfen als Einzelnutzer-System. Es läuft auf einem Rechner mit einer direkt angeschlossenen Tastatur und einem direkt angeschlossenem Bildschirm. Die Eingaben des Nutzers kommen nahezu immer von dieser Tastatur. Die Ausgabe Ihres Programmes erscheint fast immer auf diesem Bildschirm. Dies ist NIEMALS garantiert unter &unix;. Es ist sehr verbreitet für ein &unix;, daß der Nutzer seine Aus- und Eingaben kanalisiert und umleitet: &prompt.user; program1 | program2 | program3 > file1 Falls Sie eine Anwendung program2 geschrieben haben, kommt ihre Eingabe nicht von der Tastatur, sondern von der Ausgabe von program1. Gleichermassen geht Ihre Ausgabe nicht auf den Bildschirm, sondern wird zur Eingabe für program3, dessen Ausgabe wiederum in file1 endet. Aber es gibt noch mehr! Selbst wenn Sie sichergestellt haben, daß Ihre Eingabe und Ausgabe zum Terminal kommt bzw. gelangt, dann ist immer noch nicht garantiert, daß ihr Terminal ein PC ist: Es mag seinen Grafikspeicher nicht dort haben, wo Sie ihn erwarten, oder die Tastatur könnte keine PC-ähnlichen Scancodes erzeugen können. Es mag ein &macintosh; oder irgendein anderer Rechner sein. Sie mögen nun den Kopf schütteln: Mein Programm ist in PC-Assembler geschrieben, wie kann es auf einem &macintosh; laufen? Aber ich habe nicht gesagt, daß Ihr Programm auf &macintosh; läuft, nur sein Terminal mag ein &macintosh; sein. Unter &unix; muß der Terminal nicht direkt am Rechner angeschlossen sein, auf dem die Software läuft, er kann sgar auf einem anderen Kontinent sein oder sogar auf einem anderen Planeten. Es ist nicht ungewöhnlich, daß ein &macintosh;-Nutzer in Australien sich auf ein &unix;-System in Nordamerika (oder sonstwo) mittels telnet verbindet. Die Software läuft auf einem Rechner während das Terminal sich auf einem anderen Rechner befindet: Falls Sie versuchen sollten die Scancodes auszulesen werden Sie die falschen Eingaben erhalten! Das Gleiche gilt für jede andere Hardware: Eine Datei, welche Sie einlesen, mag auf einem Laufwerk sein, auf das Sie keinen direkten Zugriff haben. Eine Kamera, deren Bilder Sie auslesen, befindet sich möglicherweise in einem Space Shuttle, durch Satelliten mit Ihnen verbunden. Das sind die Gründe, weshalb Sie niemals unter &unix; Annahmen treffen dürfen, woher Ihre Daten kommen oder gehen. Lassen Sie immer das System den physischen Zugriff auf die Hardware regeln. Das sind Vorsichtsmassnahmen, keine absoluten Regeln. Ausnahmen sind möglich. Wenn zum Beispiel ein Texteditor bestimmt hat, daß er auf einer lokalen Maschine läuft, dann mag er die Tastatur-Scancodes direkt auslesen, um eine bessere Kontrolle zu gewährleisten. Ich erwähne diese Vorsichtsmassnahmen nicht, um Ihnen zu sagen, was sie tun oder lassen sollen, ich will Ihnen nur bewusst machen, daß es bestimmte Fallstrcike gibt, die Sie erwarten, wenn Sie soeben ihn &unix; von &ms-dos; angelangt sind. Kreative Menschen brechen oft Regeln und das ist in Ordnung, solange sie wissen welche Regeln und warum.