Source string Read only

(itstool) path: sect2/para
329/3290
Context English State
We decide we want to go with Bender's constant after all. We want to save its values as a comma–separated file:
<prompt>%</prompt> <userinput>./medium -b -e &gt; bender</userinput>
<prompt>%</prompt> <userinput>cat bender</userinput>
focal length in millimeters,pinhole diameter in microns,F-number,normalized F-number,F-5.6 multiplier,stops from F-5.6
80,358,224,256,1562,11
30,219,137,128,586,9
40,253,158,181,781,10
50,283,177,181,977,10
60,310,194,181,1172,10
70,335,209,181,1367,10
100,400,250,256,1953,11
120,438,274,256,2344,11
140,473,296,256,2734,11
<prompt>%</prompt>
Caveats
Assembly language programmers who "grew up" under <acronym><trademark class="registered">MS-DOS</trademark></acronym> and <trademark class="registered">Windows</trademark> often tend to take shortcuts. Reading the keyboard scan codes and writing directly to video memory are two classical examples of practices which, under <acronym><trademark class="registered">MS-DOS</trademark></acronym> are not frowned upon but considered the right thing to do.
The reason? Both the <acronym>PC BIOS</acronym> and <acronym><trademark class="registered">MS-DOS</trademark></acronym> are notoriously slow when performing these operations.
You may be tempted to continue similar practices in the <trademark class="registered">UNIX</trademark> environment. For example, I have seen a web site which explains how to access the keyboard scan codes on a popular <trademark class="registered">UNIX</trademark> clone.
That is generally a <emphasis>very bad idea</emphasis> in <trademark class="registered">UNIX</trademark> environment! Let me explain why.
<trademark class="registered">UNIX</trademark> Is Protected
For one thing, it may simply not be possible. <trademark class="registered">UNIX</trademark> runs in protected mode. Only the kernel and device drivers are allowed to access hardware directly. Perhaps a particular <trademark class="registered">UNIX</trademark> clone will let you read the keyboard scan codes, but chances are a real <trademark class="registered">UNIX</trademark> operating system will not. And even if one version may let you do it, the next one may not, so your carefully crafted software may become a dinosaur overnight.
<trademark class="registered">UNIX</trademark> Is an Abstraction
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

Loading…

No matching activity found.

Browse all component changes

Things to check

Long untranslated

The string has not been translated for a long time

Reset

Multiple failing checks

The translations in several languages have failing checks

Reset

Glossary

English English
No related strings found in the glossary.

Source information

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