os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

*.sgml:

Browse source 
- Use trademark entities.
 - Add trademark attributions.
 - Don't join trademarks with other words, e.g. using hyphens.

trademark.ent:
 - Add trademark entity for Sun.
This commit is contained in:
Simon L. B. Nielsen 2004-02-16 00:11:08 +00:00
parent 1b0e3a763d
commit 0b473c33aa
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=20032
9 changed files with 152 additions and 137 deletions
en_US.ISO8859-1/books/developers-handbook
book.sgml
dma
chapter.sgml
introduction
chapter.sgml
ipv6
chapter.sgml
secure
chapter.sgml
sockets
chapter.sgml
tools
chapter.sgml
x86
chapter.sgml
share/sgml
trademarks.ent

16
en_US.ISO8859-1/books/developers-handbook/book.sgml
View file

@ -14,6 +14,8 @@
<!ENTITY % chapters SYSTEM "chapters.ent"> %chapters;
<!ENTITY % authors PUBLIC "-//FreeBSD//ENTITIES DocBook Author Entities//EN"> %authors
<!ENTITY % mailing-lists PUBLIC "-//FreeBSD//ENTITIES DocBook Mailing List Entities//EN"> %mailing-lists;
<!ENTITY % trademarks PUBLIC "-//FreeBSD//ENTITIES DocBook Trademark Entities//EN">
%trademarks;
<!ENTITY % chap.index "IGNORE">
]>
@ -33,8 +35,20 @@
<holder>The FreeBSD Documentation Project</holder>
</copyright>
&bookinfo.trademarks;
&bookinfo.legalnotice;
<legalnotice id="trademarks" role="trademarks">
&tm-attrib.freebsd;
&tm-attrib.apple;
&tm-attrib.ibm;
&tm-attrib.ieee;
&tm-attrib.intel;
&tm-attrib.linux;
&tm-attrib.microsoft;
&tm-attrib.opengroup;
&tm-attrib.sun;
&tm-attrib.general;
</legalnotice>
<abstract>
<para>Welcome to the Developers' Handbook. This manual is a

12
en_US.ISO8859-1/books/developers-handbook/dma/chapter.sgml
View file

@ -24,7 +24,7 @@
Computer (PC), the IBM PC/AT and all of its successors and
clones.</para>
<para>The PC DMA subsystem is based on the Intel 8237 DMA controller. The
<para>The PC DMA subsystem is based on the &intel; 8237 DMA controller. The
8237 contains four DMA channels that can be programmed independently and
any one of the channels may be active at any moment. These channels are
numbered 0, 1, 2 and 3. Starting with the PC/AT, IBM added a second
@ -221,7 +221,7 @@
peripheral, the data must be first copied from where it resides into a
buffer located below 16Meg, and then the DMA can copy the data from
the buffer to the hardware. In FreeBSD, these reserved buffers are
called <quote>Bounce Buffers</quote>. In the MS-DOS world, they are
called <quote>Bounce Buffers</quote>. In the &ms-dos; world, they are
sometimes called <quote>Smart Buffers</quote>.</para>
<note>
@ -632,7 +632,7 @@
<row>
<entry>0x0f</entry>
<entry>read</entry>
<entry>Read All Mask Register Bits (only in Intel
<entry>Read All Mask Register Bits (only in &intel;
82374)</entry>
</row>
</tbody>
@ -824,7 +824,7 @@
<row>
<entry>0xda</entry>
<entry>read</entry>
<entry>Temporary Register (not present in Intel
<entry>Temporary Register (not present in &intel;
82374)</entry>
</row>
@ -849,7 +849,7 @@
<row>
<entry>0xdf</entry>
<entry>read</entry>
<entry>Read All Mask Register Bits (only in Intel
<entry>Read All Mask Register Bits (only in &intel;
82374)</entry>
</row>
</tbody>
@ -918,7 +918,7 @@
<sect3>
<title>0x400&ndash;0x4ff 82374 Enhanced DMA Registers</title>
<para>The Intel 82374 EISA System Component (ESC) was introduced in
<para>The &intel; 82374 EISA System Component (ESC) was introduced in
early 1996 and includes a DMA controller that provides a superset of
8237 functionality as well as other PC-compatible core peripheral
components in a single package. This chip is targeted at both EISA

2
en_US.ISO8859-1/books/developers-handbook/introduction/chapter.sgml
View file

@ -40,7 +40,7 @@
<sect1 id="introduction-bsdvision">
<title>The BSD Vision</title>
<para>To produce the best &unix;-like operating system package
<para>To produce the best &unix; like operating system package
possible, with due respect to the original software tools
ideology as well as usability, performance and
stability.</para>

4
en_US.ISO8859-1/books/developers-handbook/ipv6/chapter.sgml
View file

@ -1564,8 +1564,8 @@ ECN allowed copy TOS bits except for ECN use inner TOS bits with some
for reference purposes.</para>
<para>Altiga, Ashley-laurent (vpcom.com), Data Fellows (F-Secure),
Ericsson ACC, FreeS/WAN, HITACHI, IBM AIX, IIJ, Intel,
Microsoft WinNT, NIST (linux IPsec + plutoplus), Netscreen, OpenBSD,
Ericsson ACC, FreeS/WAN, HITACHI, IBM &aix;, IIJ, Intel,
&microsoft; &windowsnt;, NIST (linux IPsec + plutoplus), Netscreen, OpenBSD,
RedCreek, Routerware, SSH, Secure Computing, Soliton, Toshiba,
VPNet, Yamaha RT100i</para>
</sect3>

10
en_US.ISO8859-1/books/developers-handbook/secure/chapter.sgml
View file

@ -12,7 +12,7 @@
<sect1 id="secure-synopsis"><title>Synopsis</title>
<para>This chapter describes some of the security issues that
have plagued Unix programmers for decades and some of the new
have plagued &unix; programmers for decades and some of the new
tools available to help programmers avoid writing exploitable
code.</para>
</sect1>
@ -28,11 +28,11 @@
code should be reused whenever possible to avoid common
mistakes that others may have already fixed.</para>
<para>One of the pitfalls of the Unix environment is how easy it
<para>One of the pitfalls of the &unix; environment is how easy it
is to make assumptions about the sanity of the environment.
Applications should never trust user input (in all its forms),
system resources, inter-process communication, or the timing of
events. Unix processes do not execute synchronously so logical
events. &unix; processes do not execute synchronously so logical
operations are rarely atomic.</para>
</sect1>
@ -434,12 +434,12 @@ int main() {
no way to specify exactly what "very limited" means.</para>
</sect2>
<sect2><title>POSIX.1e Process Capabilities</title>
<sect2><title>&posix;.1e Process Capabilities</title>
<indexterm><primary>POSIX.1e Process Capabilities</primary></indexterm>
<indexterm><primary>TrustedBSD</primary></indexterm>
<para>Posix has released a working draft that adds event
<para>&posix; has released a working draft that adds event
auditing, access control lists, fine grained privileges,
information labeling, and mandatory access control.</para>
<para>This is a work in progress and is the focus of the <ulink

20
en_US.ISO8859-1/books/developers-handbook/sockets/chapter.sgml
View file

@ -22,8 +22,8 @@
machine, they do not have to run under the same operating
system. Thanks to <acronym>BSD</acronym> sockets, your FreeBSD
software can smoothly cooperate with a program running on a
Macintosh, another one running on a Sun workstation, yet another
one running under Windows 2000, all connected with an
&macintosh;, another one running on a &sun; workstation, yet another
one running under &windows; 2000, all connected with an
Ethernet-based local area network.</para>
<para>But your software can equally well cooperate with processes
@ -319,7 +319,7 @@
<sect1 id="sockets-model">
<title>The Sockets Model</title>
<para><acronym>BSD</acronym> sockets are built on the basic Unix
<para><acronym>BSD</acronym> sockets are built on the basic &unix;
model: <emphasis>Everything is a file.</emphasis> In our
example, then, sockets would let us receive an <emphasis>HTTP
file</emphasis>, so to speak. It would then be up to us to
@ -652,7 +652,7 @@ struct in_addr {
<para>What would the result look like?</para>
<para>Well, that depends, of course. On a Pentium, or other
<para>Well, that depends, of course. On a &pentium;, or other
x86, based computer, it would look like this:</para>
<mediaobject>
@ -732,7 +732,7 @@ struct in_addr {
fields of the <varname>sockaddr</varname> structure. You
do not have to worry about the byte order there (of
course, on FreeBSD <varname>sa_family</varname> is only 1
byte anyway, but many other Unix systems do not have
byte anyway, but many other &unix; systems do not have
<varname>sa_len</varname> and use 2 bytes for
<varname>sa_family</varname>, and expect the data in
whatever order is native to the computer).</para>
@ -847,13 +847,13 @@ struct in_addr {
problem.</para>
<para>Suppose, you wrote a sockets-based program in C. You
know it is going to run on a Pentium, so you enter all
know it is going to run on a &pentium;, so you enter all
your constants in reverse and force them to the
<emphasis>network byte order</emphasis>. It works
well.</para>
<para>Then, some day, your trusted old Pentium becomes a
rusty old Pentium. You replace it with a system whose
<para>Then, some day, your trusted old &pentium; becomes a
rusty old &pentium;. You replace it with a system whose
<emphasis>host order</emphasis> is the same as the
<emphasis>network order</emphasis>. You need to recompile
all your software. All of your software continues to
@ -1454,7 +1454,7 @@ Connection closed by foreign host.
<acronym>IP</acronym>v4 and succeeded. The daemon
works.</para>
<para>If you have access to another Unix system via
<para>If you have access to another &unix; system via
<application>telnet</application>, you can use it to test
accessing the server remotely. My computer does not have a
static <acronym>IP</acronym> address, so this is what I
@ -1748,7 +1748,7 @@ struct servent * getservbyname(const char *name, const char *proto);
<function>accept</function>, it now exits.
</para>
<para>Under Unix, a process does not really
<para>Under &unix;, a process does not really
<emphasis>exit</emphasis>. Instead, it
<emphasis>returns</emphasis> to its parent. Typically, a parent
process <function>wait</function>s for its child process, and

42
en_US.ISO8859-1/books/developers-handbook/tools/chapter.sgml
View file

@ -27,7 +27,7 @@
<para>This chapter is an introduction to using some of the
programming tools supplied with FreeBSD, although much of it
will be applicable to many other versions of Unix. It does
will be applicable to many other versions of &unix;. It does
<emphasis>not</emphasis> attempt to describe coding in any
detail. Most of the chapter assumes little or no previous
programming knowledge, although it is hoped that most
@ -39,18 +39,18 @@
<para>FreeBSD offers an excellent development environment.
Compilers for C, C++, and Fortran and an assembler come with the
basic system, not to mention a Perl interpreter and classic Unix
basic system, not to mention a Perl interpreter and classic &unix;
tools such as <command>sed</command> and <command>awk</command>.
If that is not enough, there are many more compilers and
interpreters in the Ports collection. FreeBSD is very
compatible with standards such as <acronym>POSIX</acronym> and
compatible with standards such as <acronym>&posix;</acronym> and
<acronym>ANSI</acronym> C, as well with its own BSD heritage, so
it is possible to write applications that will compile and run
with little or no modification on a wide range of
platforms.</para>
<para>However, all this power can be rather overwhelming at first
if you have never written programs on a Unix platform before.
if you have never written programs on a &unix; platform before.
This document aims to help you get up and running, without
getting too deeply into more advanced topics. The intention is
that this document should give you enough of the basics to be
@ -58,7 +58,7 @@
<para>Most of the document requires little or no knowledge of
programming, although it does assume a basic competence with
using Unix and a willingness to learn!</para>
using &unix; and a willingness to learn!</para>
</sect1>
@ -103,11 +103,11 @@
start if you have not done any programming before. This kind
of environment is typically found with languages like Lisp,
Smalltalk, Perl and Basic. It could also be argued that the
Unix shell (<command>sh</command>, <command>csh</command>) is itself an
&unix; shell (<command>sh</command>, <command>csh</command>) is itself an
interpreter, and many people do in fact write shell
<quote>scripts</quote> to help with various
<quote>housekeeping</quote> tasks on their machine. Indeed, part
of the original Unix philosophy was to provide lots of small
of the original &unix; philosophy was to provide lots of small
utility programs that could be linked together in shell
scripts to perform useful tasks.</para>
</sect2>
@ -170,7 +170,7 @@
<para>Lisp is an extremely powerful and sophisticated
language, but can be rather large and unwieldy.</para>
<para>Various implementations of Lisp that can run on UNIX
<para>Various implementations of Lisp that can run on &unix;
systems are available as packages for FreeBSD.
<ulink URL="ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/packages/Latest/gcl.tgz">GNU Common Lisp</ulink>,
<ulink URL="ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/packages/Latest/clisp.tgz">CLISP</ulink>
@ -665,11 +665,11 @@
<para>Each of these will both produce an executable
<filename>foobar</filename> from the C++ source file
<filename>foobar.cc</filename>. Note that, on Unix
<filename>foobar.cc</filename>. Note that, on &unix;
systems, C++ source files traditionally end in
<filename>.C</filename>, <filename>.cxx</filename> or
<filename>.cc</filename>, rather than the
MS-DOS style
&ms-dos; style
<filename>.cpp</filename> (which was already used for
something else). <command>gcc</command> used to rely on
this to work out what kind of compiler to use on the
@ -827,7 +827,7 @@ int main() {
</question>
<answer>
<para>Unlike MS-DOS, Unix does not
<para>Unlike &ms-dos;, &unix; does not
look in the current directory when it is trying to find
out which executable you want it to run, unless you tell
it to. Either type <command>./foobar</command>, which
@ -856,7 +856,7 @@ int main() {
</question>
<answer>
<para>Most Unix systems have a program called
<para>Most &unix; systems have a program called
<command>test</command> in <filename>/usr/bin</filename>
and the shell is picking that one up before it gets to
checking the current directory. Either type:</para>
@ -880,7 +880,7 @@ int main() {
<answer>
<para>The name <firstterm>core dump</firstterm> dates back
to the very early days of Unix, when the machines used
to the very early days of &unix;, when the machines used
core memory for storing data. Basically, if the program
failed under certain conditions, the system would write
the contents of core memory to disk in a file called
@ -910,7 +910,7 @@ int main() {
<answer>
<para>This basically means that your program tried to
perform some sort of illegal operation on memory; Unix
perform some sort of illegal operation on memory; &unix;
is designed to protect the operating system and other
programs from rogue programs.</para>
@ -960,7 +960,7 @@ bar[27] = 6;
strcpy(foo, "bang!");
</programlisting>
<para>Unix compilers often put string literals like
<para>&unix; compilers often put string literals like
<literal>"My string"</literal> into read-only areas
of memory.</para>
</listitem>
@ -994,7 +994,7 @@ free(foo);
<qandaentry>
<question>
<para>Sometimes when I get a core dump it says
<errorname>bus error</errorname>. It says in my Unix
<errorname>bus error</errorname>. It says in my &unix;
book that this means a hardware problem, but the
computer still seems to be working. Is this
true?</para>
@ -1304,9 +1304,9 @@ DISTFILES= scheme-microcode+dist-7.3-freebsd.tgz
<step>
<para>Any special configuration needed for the source is
done. (Many Unix program distributions try to work out
which version of Unix they are being compiled on and which
optional Unix features are present&mdash;this is where
done. (Many &unix; program distributions try to work out
which version of &unix; they are being compiled on and which
optional &unix; features are present&mdash;this is where
they are given the information in the FreeBSD ports
scenario).</para>
</step>
@ -1671,7 +1671,7 @@ else if (pid == 0) { /* child */
<sect2>
<title>Emacs</title>
<para>Unfortunately, Unix systems do not come with the kind of
<para>Unfortunately, &unix; systems do not come with the kind of
everything-you-ever-wanted-and-lots-more-you-did-not-in-one-gigantic-package
integrated development environments that other systems
have.
@ -1808,7 +1808,7 @@ else if (pid == 0) { /* child */
<para>If you are wondering what on earth the
<keysym>Meta</keysym> key is, it is a special key that many
Unix workstations have. Unfortunately, PC's do not have one,
&unix; workstations have. Unfortunately, PC's do not have one,
so it is usually the <keycap>alt</keycap> key (or if you are
unlucky, the <keysym>escape</keysym> key).</para>

182
en_US.ISO8859-1/books/developers-handbook/x86/chapter.sgml
View file

@ -32,22 +32,22 @@ This chapter was written by &a.stanislav;.
<title>Synopsis</title>
<para>
Assembly language programming under Unix is highly undocumented. It
Assembly language programming under &unix; is highly undocumented. It
is generally assumed that no one would ever want to use it because
various Unix systems run on different microprocessors, so everything
various &unix; systems run on different microprocessors, so everything
should be written in C for portability.
</para>
<para>
In reality, C portability is quite a myth. Even C programs need
to be modified when ported from one Unix to another, regardless of
to be modified when ported from one &unix; to another, regardless of
what processor each runs on. Typically, such a program is full
of conditional statements depending on the system it is
compiled for.
</para>
<para>
Even if we believe that all of Unix software should be written in C,
Even if we believe that all of &unix; software should be written in C,
or some other high-level language, we still need assembly language
programmers: Who else would write the section of C library
that accesses the kernel?
@ -56,7 +56,7 @@ that accesses the kernel?
<para>
In this chapter I will attempt to show you
how you can use assembly language writing
Unix programs, specifically under FreeBSD.
&unix; programs, specifically under FreeBSD.
</para>
<para>
@ -94,7 +94,7 @@ into machine language.
<para>
Two very different assemblers are available for FreeBSD. One is
<citerefentry><refentrytitle>as</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
which uses the traditional Unix assembly language syntax. It
which uses the traditional &unix; assembly language syntax. It
comes with the system.
</para>
@ -150,8 +150,8 @@ issuing <function role="opcode">int 80h</function> directly.
<para>
This convention is very convenient, and quite superior to the
Microsoft convention used by <acronym>MS DOS</acronym>.
Why? Because the Unix convention allows any program written in
&microsoft; convention used by <acronym>&ms-dos;</acronym>.
Why? Because the &unix; convention allows any program written in
any language to access the kernel.
</para>
@ -177,7 +177,7 @@ open:
<para>
This is a very clean and portable way of coding. If you need to
port the code to a Unix system which uses a different interrupt,
port the code to a &unix; system which uses a different interrupt,
or a different way of passing parameters, all you need to change
is the kernel procedure.
</para>
@ -216,9 +216,9 @@ have Linux emulation installed.
</para>
<para>
Linux is a Unix-like system. However, its kernel uses the same
Linux is a &unix; like system. However, its kernel uses the same
system-call convention of passing parameters in registers
<acronym>MS DOS</acronym> does. As with the Unix convention,
<acronym>&ms-dos;</acronym> does. As with the &unix; convention,
the function number is placed in <varname role="register">EAX</varname>.
The parameters, however, are not passed on the stack but in
<varname role="register">EBX, ECX, EDX, ESI, EDI, EBP</varname>:
@ -235,7 +235,7 @@ open:
<para>
This convention has a great disadvantage over
the Unix way, at least as far as assembly language programming
the &unix; way, at least as far as assembly language programming
is concerned: Every time you make a kernel call
you must <function role="opcode">push</function> the registers, then
<function role="opcode">pop</function> them later. This makes your code
@ -258,7 +258,7 @@ linked, you need to brand the executable:
<para>
If you are coding specifically for FreeBSD, you should always
use the Unix convention: It is faster, you can store global
use the &unix; convention: It is faster, you can store global
variables in registers, you do not have to brand
the executable, and you do not impose the installation of
the Linux emulation package on the target system.
@ -293,7 +293,7 @@ from <filename>syscalls.master</filename>.
</para>
<para>
You can find the master file for the default Unix calling
You can find the master file for the default &unix; calling
convention in
<filename>/usr/src/sys/kern/syscalls.master</filename>.
If you need to use the other convention implemented
@ -371,7 +371,7 @@ we passed an invalid parameter, etc.
<para>
The traditional place to look for information about various
system calls under Unix systems are the manual pages.
system calls under &unix; systems are the manual pages.
FreeBSD describes its system calls in section 2, sometimes
in section 3.
</para>
@ -389,7 +389,7 @@ and sets <varname>errno</varname> to indicate the error.
</blockquote>
<para>
The assembly language programmer new to Unix and FreeBSD will
The assembly language programmer new to &unix; and FreeBSD will
immediately ask the puzzling question: Where is
<varname>errno</varname> and how do I get to it?
</para>
@ -445,7 +445,7 @@ Actually, nowhere...
<para>
<varname>errno</varname> is part of the C language, not the
Unix kernel. When accessing kernel services directly, the
&unix; kernel. When accessing kernel services directly, the
error code is returned in <varname role="register">EAX</varname>,
the same register the proper
return value generally ends up in.
@ -487,7 +487,7 @@ Portability is generally not one of the strengths of assembly language.
Yet, writing assembly language programs for different platforms is
possible, especially with <application>nasm</application>. I have written
assembly language libraries that can be assembled for such different
operating systems as Windows and FreeBSD.
operating systems as &windows; and FreeBSD.
</para>
<para>
@ -497,7 +497,7 @@ similar architectures.
</para>
<para>
For example, FreeBSD is Unix, Linux is Unix-like. I only
For example, FreeBSD is &unix;, Linux is &unix; like. I only
mentioned three differences between them (from an assembly language
programmer's perspective): The calling convention, the
function numbers, and the way of returning values.
@ -843,10 +843,10 @@ returns, so the code ends there.
<note>
<para>
If you have come to Unix from <acronym>MS DOS</acronym>
If you have come to &unix; from <acronym>&ms-dos;</acronym>
assembly language background, you may be used to writing directly
to the video hardware. You will never have to worry about
this in FreeBSD, or any other flavor of Unix. As far as
this in FreeBSD, or any other flavor of &unix;. As far as
you are concerned, you are writing to a file known as
<filename>stdout</filename>. This can be the video screen, or
a <application>telnet</application> terminal, or an actual file,
@ -914,10 +914,10 @@ Hello, World!
</sect1>
<sect1 id="x86-unix-filters">
<title>Writing Unix Filters</title>
<title>Writing &unix; Filters</title>
<para>
A common type of Unix application is a filter&mdash;a program
A common type of &unix; application is a filter&mdash;a program
that reads data from the <filename>stdin</filename>, processes it
somehow, then writes the result to <filename>stdout</filename>.
</para>
@ -1048,10 +1048,10 @@ control key down):
<note>
<para>
If you are migrating to Unix from <acronym>MS DOS</acronym>,
If you are migrating to &unix; from <acronym>&ms-dos;</acronym>,
you may be wondering why each line ends with <constant>0A</constant>
instead of <constant>0D 0A</constant>.
This is because Unix does not use the cr/lf convention, but
This is because &unix; does not use the cr/lf convention, but
a "new line" convention, which is <constant>0A</constant> in hexadecimal.
</para>
</note>
@ -1115,7 +1115,7 @@ _start:
</programlisting>
<para>
We have stored the space in the <varname role="register">CL</varname> register. We can
do this safely because, unlike Microsoft Windows, Unix system
do this safely because, unlike &microsoft.windows;, &unix; system
calls do not modify the value of any register they do not use
to return a value in.
</para>
@ -1283,7 +1283,7 @@ for our use.
We take advantage of the fact that the system does not modify the
registers: We use registers for what, otherwise, would have to be
global variables stored in the <varname>.data</varname> section. This is
also why the Unix convention of passing parameters to system calls
also why the &unix; convention of passing parameters to system calls
on the stack is superior to the Microsoft convention of passing
them in the registers: We can keep the registers for our own use.
</para>
@ -1614,7 +1614,7 @@ But... Where are they?
</para>
<para>
Before a Unix system starts a program, it <function role="opcode">push</function>es some
Before a &unix; system starts a program, it <function role="opcode">push</function>es some
data on the stack, then jumps at the <varname>_start</varname>
label of the program. Yes, I said jumps, not calls. That means the
data can be accessed by reading <varname>[esp+offset]</varname>,
@ -1646,7 +1646,7 @@ enough for our purposes right now.
<note>
<para>
If you have come from the <acronym>MS DOS</acronym> programming
If you have come from the <acronym>&ms-dos;</acronym> programming
environment, the main difference is that each argument is in
a separate string. The second difference is that there is no
practical limit on how many arguments there can be.
@ -1938,10 +1938,10 @@ You already know everything you need to know to implement them.
</sect1>
<sect1 id="x86-environment">
<title>Unix Environment</title>
<title>&unix; Environment</title>
<para>
An important Unix concept is the environment, which is defined by
An important &unix; concept is the environment, which is defined by
<emphasis>environment variables</emphasis>. Some are set by the system, others
by you, yet others by the <application>shell</application>, or any program
that loads another program.
@ -1981,7 +1981,7 @@ may be missing. We need to account for that possibility.
<para>
I could just show you some code that prints the environment
the same way the Unix <application>env</application> command does. But
the same way the &unix; <application>env</application> command does. But
I thought it would be more interesting to write a simple
assembly language CGI utility.
</para>
@ -2281,7 +2281,7 @@ using the name <userinput>asm</userinput> and password
<para>
We have already done some basic file work: We know how
to open and close them, how to read and write them using
buffers. But Unix offers much more functionality when it
buffers. But &unix; offers much more functionality when it
comes to files. We will examine some of it in this section,
and end up with a nice file conversion utility.
</para>
@ -2294,20 +2294,20 @@ supposed to do.
</para>
<para>
One of the first programs I wrote for Unix was
One of the first programs I wrote for &unix; was
<ulink url="ftp://ftp.int80h.org/unix/tuc/"><application>tuc</application></ulink>,
a text-to-Unix file converter. It converts a text
file from other operating systems to a Unix text file.
a text-to-&unix; file converter. It converts a text
file from other operating systems to a &unix; text file.
In other words, it changes from different kind of line endings
to the newline convention of Unix. It saves the output
in a different file. Optionally, it converts a Unix text
to the newline convention of &unix;. It saves the output
in a different file. Optionally, it converts a &unix; text
file to a <acronym>DOS</acronym> text file.
</para>
<para>
I have used <application>tuc</application> extensively, but always
only to convert from some other <acronym>OS</acronym>
to Unix, never the other way. I have always wished
to &unix;, never the other way. I have always wished
it would just overwrite the file instead of me having
to send the output to a different file. Most of the time,
I end up using it like this:
@ -2344,7 +2344,7 @@ DOS</acronym> text files), but will fail occasionally.
</para>
<para>
The problem is that not all non-Unix text files end their
The problem is that not all non &unix; text files end their
line with the carriage return / line feed sequence. Some
use carriage returns without line feeds. Others combine several
blank lines into a single carriage return followed by several
@ -2511,7 +2511,7 @@ instead of one.
Finally, we are in the <symbol>lf</symbol> state after
we have received a line feed that was not preceded by a
carriage return. This will happen when our file already is
in Unix format, or whenever several lines in a row are
in &unix; format, or whenever several lines in a row are
expressed by a single carriage return followed by several
line feeds, or when line ends with a line feed /
carriage return sequence. Here is how we need to handle
@ -2666,7 +2666,7 @@ file and to write to an output file.
</para>
<para>
Unix allows us to map a file, or a section of a file,
&unix; allows us to map a file, or a section of a file,
into memory. To do that, we first need to open the file with the
appropriate read/write flags. Then we use the <function role="syscall">mmap</function>
system call to map it into the memory. One nice thing about
@ -2699,18 +2699,18 @@ suggesting we use the original
<para>
If you examine your copy of <filename>syscalls.master</filename>,
you will find two separate syscalls named <function role="syscall">mmap</function>.
This is because of evolution of Unix: There was the traditional
This is because of evolution of &unix;: There was the traditional
<acronym>BSD</acronym> <function role="syscall">mmap</function>,
syscall 71. That one was superceded by the <acronym>POSIX</acronym> <function role="syscall">mmap</function>,
syscall 71. That one was superceded by the <acronym>&posix;</acronym> <function role="syscall">mmap</function>,
syscall 197. The FreeBSD system supports both because
older programs were written by using the original <acronym>BSD</acronym>
version. But new software uses the <acronym>POSIX</acronym> version,
version. But new software uses the <acronym>&posix;</acronym> version,
which is what we will use.
</para>
<para>
The <filename>syscalls.master</filename> file lists
the <acronym>POSIX</acronym> version like this:
the <acronym>&posix;</acronym> version like this:
</para>
<programlisting>
@ -2763,9 +2763,9 @@ That includes the file size.
<para>
Again, <filename>syscalls.master</filename> lists two versions
of <function role="syscall">fstat</function>, a traditional one
(syscall 62), and a <acronym>POSIX</acronym> one
(syscall 62), and a <acronym>&posix;</acronym> one
(syscall 189). Naturally, we will use the
<acronym>POSIX</acronym> version:
<acronym>&posix;</acronym> version:
</para>
<programlisting>
@ -3153,7 +3153,7 @@ align 4
<warning><para>
Do not use this program on files stored on a disk formated
by <acronym>MS DOS</acronym> or Windows. There seems to be a
by <acronym>&ms-dos;</acronym> or &windows;. There seems to be a
subtle bug in the FreeBSD code when using <function role="syscall">mmap</function>
on these drives mounted under FreeBSD: If the file is over
a certain size, <function role="syscall">mmap</function> will just fill the memory
@ -3174,22 +3174,22 @@ Do one thing at a time, and do it well.
</para>
<para>
This, indeed, is very much how Unix works as well. While
a typical Windows application is attempting to do everything
This, indeed, is very much how &unix; works as well. While
a typical &windows; application is attempting to do everything
imaginable (and is, therefore, riddled with bugs), a
typical Unix program does only one thing, and it does it
typical &unix; program does only one thing, and it does it
well.
</para>
<para>
The typical Unix user then essentially assembles his own
The typical &unix; user then essentially assembles his own
applications by writing a shell script which combines the
various existing programs by piping the output of one
program to the input of another.
</para>
<para>
When writing your own Unix software, it is generally a
When writing your own &unix; software, it is generally a
good idea to see what parts of the problem you need to
solve can be handled by existing programs, and only
write your own programs for that part of the problem
@ -3227,7 +3227,7 @@ from those lines.
<para>
Therefore, I needed to write my own software to extract the 11th
field from the <acronym>CSV</acronym> file. However, going with the Unix
field from the <acronym>CSV</acronym> file. However, going with the &unix;
spirit, I only needed to write a simple filter that would do the
following:
</para>
@ -3329,7 +3329,7 @@ names rather than data.
The <parameter>-i</parameter> and <parameter>-o</parameter>
options let me specify the input and the output files. Defaults
are <filename>stdin</filename> and <filename>stdout</filename>,
so this is a regular Unix filter.
so this is a regular &unix; filter.
</para>
<para>
@ -4337,7 +4337,7 @@ As experts are offering several different values for the
</para>
<para>
It is traditional in Unix programming to have two main ways
It is traditional in &unix; programming to have two main ways
of choosing program parameters, plus to have a default for
the time the user does not make a choice.
</para>
@ -5238,11 +5238,11 @@ We can generalize all these optimizations into one rule:
<tip>
<para>
<emphasis>PostScript</emphasis> is a stack&ndash;oriented
<emphasis>&postscript;</emphasis> is a stack&ndash;oriented
programming language. There are many more books
available about PostScript than about the
available about &postscript; than about the
<acronym>FPU</acronym> assembly language: Mastering
PostScript will help you master the <acronym>FPU</acronym>.
&postscript; will help you master the <acronym>FPU</acronym>.
</para>
</tip>
@ -6194,7 +6194,7 @@ is optional.
</para>
<para>
Whenever Unix is asked to run an executable
Whenever &unix; is asked to run an executable
file which starts with the <function>#!</function>,
it assumes the file is a script. It adds the
command to the rest of the first line of the
@ -6238,7 +6238,7 @@ and run it as if it were a program:
<screen>&prompt.user; <userinput>chmod 755 medium</userinput>
&prompt.user; <userinput>./medium</userinput></screen>
<para>
Unix will interpret that last command as:</para>
&unix; will interpret that last command as:</para>
<screen>&prompt.user; <userinput>/usr/local/bin/pinhole -b -i ./medium</userinput></screen>
<para>
@ -6260,7 +6260,7 @@ Now, let us enter:</para>
<screen>&prompt.user; <userinput>./medium -c</userinput></screen>
<para>
Unix will treat that as:</para>
&unix; will treat that as:</para>
<screen>&prompt.user; <userinput>/usr/local/bin/pinhole -b -i ./medium -c</userinput></screen>
<para>
@ -6310,39 +6310,39 @@ focal length in millimeters,pinhole diameter in microns,F-number,normalized F-nu
<para>
Assembly language programmers who "grew up" under
<acronym>MS DOS</acronym> and Windows often tend to take shortcuts.
<acronym>&ms-dos;</acronym> and &windows; 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>MS DOS</acronym> are not frowned upon but considered the
<acronym>&ms-dos;</acronym> are not frowned upon but considered the
right thing to do.
</para>
<para>
The reason? Both the <acronym>PC BIOS</acronym> and
<acronym>MS DOS</acronym> are notoriously
<acronym>&ms-dos;</acronym> are notoriously
slow when performing these operations.
</para>
<para>
You may be tempted to continue similar practices in the
Unix environment. For example, I have seen a web site which
explains how to access the keyboard scan codes on a popular Unix clone.
&unix; environment. For example, I have seen a web site which
explains how to access the keyboard scan codes on a popular &unix; clone.
</para>
<para>
That is generally a <emphasis>very bad idea</emphasis>
in Unix environment! Let me explain why.
in &unix; environment! Let me explain why.
</para>
<sect2 id="x86-protected">
<title>Unix Is Protected</title>
<title>&unix; Is Protected</title>
<para>
For one thing, it may simply not be possible. Unix runs in
For one thing, it may simply not be possible. &unix; runs in
protected mode. Only the kernel and device drivers are allowed
to access hardware directly. Perhaps a particular Unix clone
to access hardware directly. Perhaps a particular &unix; clone
will let you read the keyboard scan codes, but chances are a real
Unix operating system will not. And even if one version may let you
&unix; 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.
</para>
@ -6350,23 +6350,23 @@ become a dinosaur overnight.
</sect2>
<sect2 id="x86-abstraction">
<title>Unix Is an Abstraction</title>
<title>&unix; Is an Abstraction</title>
<para>
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 Unix-like
you are writing a device driver), even on the &unix; like
systems that let you do it:
</para>
<para>
<emphasis>Unix is an abstraction!
<emphasis>&unix; is an abstraction!
</emphasis></para>
<para>
There is a major difference in the philosophy of design
between <acronym>MS DOS</acronym> and Unix.
<acronym>MS DOS</acronym> was designed as a single-user
between <acronym>&ms-dos;</acronym> and &unix;.
<acronym>&ms-dos;</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
@ -6374,8 +6374,8 @@ virtually always ends up on that screen.
</para>
<para>
This is NEVER guaranteed under Unix. It is quite common
for a Unix user to pipe and redirect program input and output:
This is NEVER guaranteed under &unix;. It is quite common
for a &unix; user to pipe and redirect program input and output:
</para>
<screen>&prompt.user; <userinput>program1 | program2 | program3 > file1</userinput></screen>
@ -6394,24 +6394,24 @@ 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 Macintosh,
<acronym>PC</acronym>-style scan codes. It may be a &macintosh;,
or any other computer.
</para>
<para>
Now you may be shaking your head: My software is in
<acronym>PC</acronym> assembly language, how can
it run on a Macintosh? But I did not say your software
would be running on a Macintosh, only that its terminal
may be a Macintosh.
it run on a &macintosh;? But I did not say your software
would be running on a &macintosh;, only that its terminal
may be a &macintosh;.
</para>
<para>
Under Unix, the terminal does not have to be directly
Under &unix;, 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 Macintosh user in
Australia connects to a Unix system in North America (or
planet. It is perfectly possible that a &macintosh; user in
Australia connects to a &unix; 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,
@ -6426,7 +6426,7 @@ via satellites.
</para>
<para>
That is why under Unix you must never make any assumptions about
That is why under &unix; 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.
</para>
@ -6438,8 +6438,8 @@ 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 Unix
form <acronym>MS DOS</acronym>. Of course, creative people often break
of certain pitfalls that await you if you have just arrived to &unix;
form <acronym>&ms-dos;</acronym>. Of course, creative people often break
rules, and it is OK as long as they know they are breaking
them and why.
</para>
@ -6458,7 +6458,7 @@ This tutorial would never have been possible without the
help of many experienced FreeBSD programmers from the
&a.hackers;, many of whom have patiently
answered my questions, and pointed me in the right direction
in my attempts to explore the inner workings of Unix
in my attempts to explore the inner workings of &unix;
system programming in general and FreeBSD in particular.
</para>

1
share/sgml/trademarks.ent
View file

@ -290,6 +290,7 @@
<!ENTITY netra "<trademark>Netra</trademark>">
<!ENTITY solaris "<trademark>Solaris</trademark>">
<!ENTITY staroffice "<trademark>StarOffice</trademark>">
<!ENTITY sun "<trademark>Sun</trademark>">
<!ENTITY sun.blade "<trademark>Sun&nbsp;Blade</trademark>">
<!ENTITY sun.enterprise "<trademark>Sun&nbsp;Enterprise</trademark>">
<!ENTITY sun.fire "<trademark>Sun&nbsp;Fire</trademark>">