Source string Read only

(itstool) path: sect1/para
142/1420
Context English State
But there is a much more important reason not to try accessing the hardware directly (unless, of course, you are writing a device driver), even on the <trademark class="registered">UNIX</trademark> like systems that let you do it:
<emphasis><trademark class="registered">UNIX</trademark> is an abstraction!</emphasis>
There is a major difference in the philosophy of design between <acronym><trademark class="registered">MS-DOS</trademark></acronym> and <trademark class="registered">UNIX</trademark>. <acronym><trademark class="registered">MS-DOS</trademark></acronym> was designed as a single-user system. It is run on a computer with a keyboard and a video screen attached directly to that computer. User input is almost guaranteed to come from that keyboard. Your program's output virtually always ends up on that screen.
This is NEVER guaranteed under <trademark class="registered">UNIX</trademark>. It is quite common for a <trademark class="registered">UNIX</trademark> user to pipe and redirect program input and output:
<prompt>%</prompt> <userinput>program1 | program2 | program3 &gt; file1</userinput>
If you have written <application>program2</application>, your input does not come from the keyboard but from the output of <application>program1</application>. Similarly, your output does not go to the screen but becomes the input for <application>program3</application> whose output, in turn, goes to <filename>file1</filename>.
But there is more! Even if you made sure that your input comes from, and your output goes to, the terminal, there is no guarantee the terminal is a PC: It may not have its video memory where you expect it, nor may its keyboard be producing <acronym>PC</acronym>-style scan codes. It may be a <trademark class="registered">Macintosh</trademark>, or any other computer.
Now you may be shaking your head: My software is in <acronym>PC</acronym> assembly language, how can it run on a <trademark class="registered">Macintosh</trademark>? But I did not say your software would be running on a <trademark class="registered">Macintosh</trademark>, only that its terminal may be a <trademark class="registered">Macintosh</trademark>.
Under <trademark class="registered">UNIX</trademark>, the terminal does not have to be directly attached to the computer that runs your software, it can even be on another continent, or, for that matter, on another planet. It is perfectly possible that a <trademark class="registered">Macintosh</trademark> user in Australia connects to a <trademark class="registered">UNIX</trademark> system in North America (or anywhere else) via <application>telnet</application>. The software then runs on one computer, while the terminal is on a different computer: If you try to read the scan codes, you will get the wrong input!
Same holds true about any other hardware: A file you are reading may be on a disk you have no direct access to. A camera you are reading images from may be on a space shuttle, connected to you via satellites.
That is why under <trademark class="registered">UNIX</trademark> you must never make any assumptions about where your data is coming from and going to. Always let the system handle the physical access to the hardware.
These are caveats, not absolute rules. Exceptions are possible. For example, if a text editor has determined it is running on a local machine, it may want to read the scan codes directly for improved control. I am not mentioning these caveats to tell you what to do or what not to do, just to make you aware of certain pitfalls that await you if you have just arrived to <trademark class="registered">UNIX</trademark> form <acronym><trademark class="registered">MS-DOS</trademark></acronym>. Of course, creative people often break rules, and it is OK as long as they know they are breaking them and why.
Acknowledgements
This tutorial would never have been possible without the help of many experienced FreeBSD programmers from the <link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/freebsd-hackers">FreeBSD technical discussions mailing list</link>, many of whom have patiently answered my questions, and pointed me in the right direction in my attempts to explore the inner workings of <trademark class="registered">UNIX</trademark> system programming in general and FreeBSD in particular.
Thomas M. Sommers opened the door for me . His <link xlink:href="https://web.archive.org/web/20090914064615/http://www.codebreakers-journal.com/content/view/262/27">How do I write "Hello, world" in FreeBSD assembler?</link> web page was my first encounter with an example of assembly language programming under FreeBSD.
Jake Burkholder has kept the door open by willingly answering all of my questions and supplying me with example assembly language source code.
Appendices
<personname><firstname>Dave</firstname><othername role="MI">A</othername><surname>Patterson</surname></personname>
<personname><firstname>John</firstname><othername role="MI">L</othername><surname>Hennessy</surname></personname>
<year>1998</year><holder>Morgan Kaufmann Publishers, Inc.</holder>
1-55860-428-6
Morgan Kaufmann Publishers, Inc.
Computer Organization and Design
The Hardware / Software Interface
1-2
<personname><firstname>W.</firstname><othername role="Middle">Richard</othername><surname>Stevens</surname></personname>
<year>1993</year><holder>Addison Wesley Longman, Inc.</holder>
0-201-56317-7
Addison Wesley Longman, Inc.
Advanced Programming in the Unix Environment
<personname><firstname>Marshall</firstname><othername role="Middle">Kirk</othername><surname>McKusick</surname></personname>

Loading…

No matching activity found.

Browse all component changes

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect1/para
Flags
read-only
Source string location
book.translate.xml:14840
String age
a year ago
Source string age
a year ago
Translation file
books/developers-handbook.pot, string 2235