- Merge the following from the English version:

	r17170 -> r17270	head/ja_JP.eucJP/books/handbook/basics/chapter.xml

	Binary Formats section is not translated and commented out.
        This section will be removed from this chapter.

1 files changed, 144 insertions, 1 deletions

diff --git a/ja_JP.eucJP/books/handbook/basics/chapter.xml b/ja_JP.eucJP/books/handbook/basics/chapter.xml
index 82328a50a7..434c347d4c 100644
--- a/ja_JP.eucJP/books/handbook/basics/chapter.xml
+++ b/ja_JP.eucJP/books/handbook/basics/chapter.xml
@@ -3,7 +3,7 @@
      The FreeBSD Documentation Project
      The FreeBSD Japanese Documentation Project
 
-     Original revision: r17170
+     Original revision: r17270
      $FreeBSD$
 -->
 <chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="basics">
@@ -1622,6 +1622,149 @@ console none                            unknown off secure</programlisting>
     </sect2>
   </sect1>
 
+<!--
+  <sect1 id="binary-formats">
+    <title>Binary Formats</title>
+
+    <para>To understand why FreeBSD uses the <filename>ELF</filename>
+      format, you must first know a little about the 3 currently
+      <quote>dominant</quote> executable formats for Unix:</para>
+
+    <itemizedlist>
+      <listitem>
+        <para>&man.a.out.5;</para>
+
+        <para>The oldest and <quote>classic</quote> Unix object
+          format.  It uses a short and compact header with a magic
+          number at the beginning that is often used to characterize
+          the format (see &man.a.out.5; for more details).  It
+          contains three loaded segments: .text, .data, and .bss plus
+          a symbol table and a string table.</para>
+      </listitem>
+
+      <listitem>
+        <para><acronym>COFF</acronym></para>
+
+        <para>The SVR3 object format.  The header now comprises a
+          section table, so you can have more than just .text, .data,
+          and .bss sections.</para>
+      </listitem>
+
+      <listitem>
+        <para><acronym>ELF</acronym></para>
+
+        <para>The successor to <acronym>COFF</acronym>, featuring
+          multiple sections and 32-bit or 64-bit possible values.  One
+          major drawback: <acronym>ELF</acronym> was also designed
+          with the assumption that there would be only one ABI per
+          system architecture.  That assumption is actually quite
+          incorrect, and not even in the commercial SYSV world (which
+          has at least three ABIs: SVR4, Solaris, SCO) does it hold
+          true.</para>
+
+        <para>FreeBSD tries to work around this problem somewhat by
+          providing a utility for <emphasis>branding</emphasis> a
+          known <acronym>ELF</acronym> executable with information
+          about the ABI it is compliant with.  See the manual page for
+          &man.brandelf.1; for more information.</para>
+      </listitem>
+    </itemizedlist>
+
+    <para>FreeBSD comes from the <quote>classic</quote> camp and used
+      the &man.a.out.5; format, a technology tried and proven through
+      many generations of BSD releases, until the beginning of the 3.X
+      branch. Though it was possible to build and run native
+      <acronym>ELF</acronym> binaries (and kernels) on a FreeBSD
+      system for some time before that, FreeBSD initially resisted the
+      <quote>push</quote> to switch to <acronym>ELF</acronym> as the
+      default format. Why?  Well, when the Linux camp made their
+      painful transition to <acronym>ELF</acronym>, it was not so much
+      to flee the <filename>a.out</filename> executable format as it
+      was their inflexible jump-table based shared library mechanism,
+      which made the construction of shared libraries very difficult
+      for vendors and developers alike. Since the
+      <acronym>ELF</acronym> tools available offered a solution to the
+      shared library problem and were generally seen as <quote>the way
+      forward</quote> anyway, the migration cost was accepted as
+      necessary and the transition made.  FreeBSD's shared library
+      mechanism is based more closely on Sun's
+      <application>SunOS</application>-style shared library mechanism
+      and, as such, is very easy to use.</para>
+
+    <para>So, why are there so many different formats?</para>
+
+    <para>Back in the dim, dark past, there was simple hardware.  This
+      simple hardware supported a simple, small system. a.out was
+      completely adequate for the job of representing binaries on this
+      simple system (a PDP-11). As people ported Unix from this simple
+      system, they retained the a.out format because it was sufficient
+      for the early ports of Unix to architectures like the Motorola
+      68k, VAXen, etc.</para>
+
+    <para>Then some bright hardware engineer decided that if he could
+      force software to do some sleazy tricks, then he would be able
+      to shave a few gates off the design and allow his CPU core to
+      run faster. While it was made to work with this new kind of
+      hardware (known these days as RISC), <filename>a.out</filename>
+      was ill-suited for this hardware, so many formats were developed
+      to get to a better performance from this hardware than the
+      limited, simple <filename>a.out</filename> format could
+      offer. Things like <acronym>COFF</acronym>,
+      <acronym>ECOFF</acronym>, and a few obscure others were invented
+      and their limitations explored before things seemed to settle on
+      <acronym>ELF</acronym>.</para>
+
+    <para>In addition, program sizes were getting huge and disks (and
+      physical memory) were still relatively small so the concept of a
+      shared library was born. The VM system also became more
+      sophisticated. While each one of these advancements was done
+      using the <filename>a.out</filename> format, its usefulness was
+      stretched more and more with each new feature.  In addition,
+      people wanted to dynamically load things at run time, or to junk
+      parts of their program after the init code had run to save in
+      core memory and swap space. Languages became more sophisticated
+      and people wanted code called before main automatically. Lots of
+      hacks were done to the <filename>a.out</filename> format to
+      allow all of these things to happen, and they basically worked
+      for a time. In time, <filename>a.out</filename> was not up to
+      handling all these problems without an ever increasing overhead
+      in code and complexity. While <acronym>ELF</acronym> solved many
+      of these problems, it would be painful to switch from the system
+      that basically worked. So <acronym>ELF</acronym> had to wait
+      until it was more painful to remain with
+      <filename>a.out</filename> than it was to migrate to
+      <acronym>ELF</acronym>.</para>
+
+    <para>However, as time passed, the build tools that FreeBSD
+      derived their build tools from (the assembler and loader
+      especially) evolved in two parallel trees. The FreeBSD tree
+      added shared libraries and fixed some bugs. The GNU folks that
+      originally write these programs rewrote them and added simpler
+      support for building cross compilers, plugging in different
+      formats at will, etc. Since many people wanted to build cross
+      compilers targeting FreeBSD, they were out of luck since the
+      older sources that FreeBSD had for as and ld were not up to the
+      task. The new gnu tools chain (binutils) does support cross
+      compiling, <acronym>ELF</acronym>, shared libraries, C++
+      extensions, etc. In addition, many vendors are releasing
+      <acronym>ELF</acronym> binaries, and it is a good thing for
+      FreeBSD to run them.</para>
+
+    <para><acronym>ELF</acronym> is more expressive than a.out and
+      allows more extensibility in the base system. The
+      <acronym>ELF</acronym> tools are better maintained, and offer
+      cross compilation support, which is important to many people.
+      <acronym>ELF</acronym> may be a little slower than a.out, but
+      trying to measure it can be difficult. There are also numerous
+      details that are different between the two in how they map
+      pages, handle init code, etc. None of these are very important,
+      but they are differences. In time support for
+      <filename>a.out</filename> will be moved out of the GENERIC
+      kernel, and eventually removed from the kernel once the need to
+      run legacy <filename>a.out</filename> programs is past.</para>
+  </sect1>
+-->
+
   <sect1 xml:id="basics-more-information">
     <title>さらに詳しい情報を得るには...</title>