© 1995-2008 by The FreeBSD Project. All rights reserved.URL: http://www.FreeBSD.de
as 2007-08-08 17:33:33 UTC
FreeBSD ports repository
Modified files:
books/developers-handbook/x86 chapter.sgml
Log:
Kapitel 12.14 - 12.15 formatiert.
Revision Changes Path
1.5 +149 -118 de-docproj/books/developers-handbook/x86/chapter.sgml
Index: chapter.sgml
===================================================================
RCS file: /home/cvs/de-docproj/books/developers-handbook/x86/chapter.sgml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -I$FreeBSDde.*$ -r1.4 -r1.5
--- chapter.sgml 8 Aug 2007 17:11:20 -0000 1.4
+++ chapter.sgml 8 Aug 2007 17:33:32 -0000 1.5
@@ -6093,127 +6093,158 @@
</sect1>
<sect1 id="x86-caveats">
- <title>Vorsichtsmassnahmen</title>
+ <title>Vorsichtsmassnahmen</title>
- <para>Assembler-Programmierer, die aufwuchsen mit <acronym>&ms-dos;</acronym>
- 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 <acronym>&ms-dos;</acronym>
- nicht verpönt sind, aber nicht als richtig angesehen werden.</para>
-
- <para>Warum dies? Sowohl das <acronym>PC-BIOS</acronym> als auch <acronym>&ms-dos;</acronym>
- sind notorisch langsam bei der Ausführung dieser Operationen.</para>
-
- <para>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.</para>
-
- <para>Das ist generell eine <emphasis>sehr schlechte Idee</emphasis> in einer
- &unix;-Umgebung! Lassen Sie mich erklären warum.</para>
-
- <sect2 id="x86-protected">
- <title>&unix; ist geschützt</title>
-
- <para>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.</para>
-
- </sect2>
+ <para>Assembler-Programmierer, die aufwuchsen mit
+ <acronym>&ms-dos;</acronym> 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
+ <acronym>&ms-dos;</acronym> nicht verpönt sind, aber nicht
+ als richtig angesehen werden.</para>
+
+ <para>Warum dies? Sowohl das <acronym>PC-BIOS</acronym> als auch
+ <acronym>&ms-dos;</acronym> sind notorisch langsam bei der
+ Ausführung dieser Operationen.</para>
+
+ <para>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.</para>
+
+ <para>Das ist generell eine <emphasis>sehr schlechte
+ Idee</emphasis> in einer &unix;-Umgebung! Lassen Sie mich
+ erklären warum.</para>
+
+ <sect2 id="x86-protected">
+ <title>&unix; ist geschützt</title>
+
+ <para>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.</para>
+ </sect2>
- <sect2 id="x86-abstraction">
- <title>&unix; ist eine Abstraktion</title>
+ <sect2 id="x86-abstraction">
+ <title>&unix; ist eine Abstraktion</title>
- <para>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:</para>
-
- <para><emphasis>&unix; ist eine Abstraktion!</emphasis></para>
-
- <para>Es gibt einen wichtigen Unterschied in der Design-Philosophie zwischen
- <acronym>&ms-dos;</acronym> und &unix;. <acronym>&ms-dos;</acronym> 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.</para>
-
- <para>Dies ist NIEMALS garantiert unter &unix;. Es ist sehr verbreitet für ein &unix;,
- daß der Nutzer seine Aus- und Eingaben kanalisiert und umleitet:</para>
-
- <screen>&prompt.user; <userinput>program1 | program2 | program3 > file1</userinput></screen>
-
- <para>Falls Sie eine Anwendung <application>program2</application> geschrieben haben,
- kommt ihre Eingabe nicht von der Tastatur, sondern von der Ausgabe von
- <application>program1</application>. Gleichermassen geht Ihre Ausgabe nicht
- auf den Bildschirm, sondern wird zur Eingabe für <application>program3</application>,
- dessen Ausgabe wiederum in <filename>file1</filename> endet.</para>
-
- <para>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 <acronym>PC</acronym>-ähnlichen Scancodes
- erzeugen können. Es mag ein &macintosh; oder irgendein anderer Rechner sein.</para>
-
- <para>Sie mögen nun den Kopf schütteln: Mein Programm ist in <acronym>PC</acronym>-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.</para>
-
- <para>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
- <application>telnet</application> 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!</para>
-
- <para>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.</para>
-
- <para>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.</para>
-
- <note>
- <para>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
- <acronym>&ms-dos;</acronym> angelangt sind. Kreative Menschen brechen oft Regeln
- und das ist in Ordnung, solange sie wissen welche Regeln und warum.</para>
- </note>
+ <para>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:</para>
+
+ <para><emphasis>&unix; ist eine Abstraktion!</emphasis></para>
+
+ <para>Es gibt einen wichtigen Unterschied in der
+ Design-Philosophie zwischen <acronym>&ms-dos;</acronym> und
+ &unix;. <acronym>&ms-dos;</acronym> 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.</para>
+
+ <para>Dies ist NIEMALS garantiert unter &unix;. Es ist sehr
+ verbreitet für ein &unix;, daß der Nutzer seine
+ Aus- und Eingaben kanalisiert und umleitet:</para>
+
+ <screen>&prompt.user; <userinput>program1 | program2 | program3 > file1</userinput></screen>
+
+ <para>Falls Sie eine Anwendung
+ <application>program2</application> geschrieben haben, kommt
+ ihre Eingabe nicht von der Tastatur, sondern von der Ausgabe
+ von <application>program1</application>. Gleichermassen geht
+ Ihre Ausgabe nicht auf den Bildschirm, sondern wird zur
+ Eingabe für <application>program3</application>, dessen
+ Ausgabe wiederum in <filename>file1</filename> endet.</para>
+
+ <para>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 <acronym>PC</acronym>-ähnlichen Scancodes erzeugen
+ können. Es mag ein &macintosh; oder irgendein anderer
+ Rechner sein.</para>
+
+ <para>Sie mögen nun den Kopf schütteln: Mein
+ Programm ist in <acronym>PC</acronym>-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.</para>
+
+ <para>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
+ <application>telnet</application> verbindet. Die Software
+ läuft auf einem Rechner während das Terminal sich
----------------------------------------------
Diff block truncated. (Max lines = 200)
----------------------------------------------
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-cvs-doc" in the body of the message
Received on Wed 08 Aug 2007 - 19:35:15 CEST