[2/2] [docs] winedev: Assorted tagging fixes
Frédéric Delanoy
frederic.delanoy at gmail.com
Thu Sep 5 15:56:50 CDT 2013
---
en/winedev-architecture.sgml | 3 +-
en/winedev-debugger.sgml | 3 +-
en/winedev-debugging.sgml | 4 +--
en/winedev-documentation.sgml | 2 +-
en/winedev-kernel.sgml | 70 +++++++++++++++++++++++++++----------------
en/winedev-opengl.sgml | 4 +--
en/winedev-testing.sgml | 8 ++---
7 files changed, 56 insertions(+), 38 deletions(-)
diff --git a/en/winedev-architecture.sgml b/en/winedev-architecture.sgml
index 9a7ce4e..38f00a7 100644
--- a/en/winedev-architecture.sgml
+++ b/en/winedev-architecture.sgml
@@ -135,8 +135,7 @@
<row>
<entry>Windows API</entry>
<entry>
- No Windows API but the DOS API (like <function>Int
- 21h</function> traps).
+ No Windows API but the DOS API (like Int 21h traps).
</entry>
<entry>
Will call the 16-bit Windows API.
diff --git a/en/winedev-debugger.sgml b/en/winedev-debugger.sgml
index f2228b4..cb71de5 100644
--- a/en/winedev-debugger.sgml
+++ b/en/winedev-debugger.sgml
@@ -1148,7 +1148,8 @@ winedbg myprog.exe
these addresses: just calculate <replaceable>segment</replaceable>*16 +
<replaceable>offset</replaceable> in
order to get a <quote>linear DOS</quote> address. So
- e.g. 0x0f04:0x3628 results in 0xf040 + 0x3628 = 0x12668.
+ e.g. 0x0f04:0x3628 results in <inlineequation><mathphrase>0xf040 + 0x3628 =
+ 0x12668</mathphrase></inlineequation>.
And the highest address you can get is 0xfffff (1MB), of
course.
</para>
diff --git a/en/winedev-debugging.sgml b/en/winedev-debugging.sgml
index dbcd192..92120a9 100644
--- a/en/winedev-debugging.sgml
+++ b/en/winedev-debugging.sgml
@@ -95,7 +95,7 @@ MESSAGE( "Could not create graphics driver '%s'\n", buffer );
<para>
Each component is assigned a debugging channel. The
identifier of the channel must be a valid C identifier
- (reserved words like <type>int</type> or <literal>static</literal>
+ (reserved words like <literal>int</literal> or <literal>static</literal>
are permitted). To use a new channel, simply use it in
your code. It will be picked up automatically by the build process.
</para>
@@ -424,7 +424,7 @@ FIXME("(%x, %d, ...): stub\n", <replaceable>par1</replaceable>, <replaceable>par
<listitem>
<para>
try to output one line per message. That is, the format
- string should contain only one <literal>\n</literal> and it
+ string should contain only one '\n' and it
should always appear at the end of the string.
</para>
</listitem>
diff --git a/en/winedev-documentation.sgml b/en/winedev-documentation.sgml
index 09ee273..2f6aeac 100644
--- a/en/winedev-documentation.sgml
+++ b/en/winedev-documentation.sgml
@@ -967,7 +967,7 @@
</para>
<para>
Also notice the text marked off with <quote><!--
- </quote> and <quote> --></quote> characters. These
+ </quote> and <quote> --></quote> strings. These
denote SGML comments. SGML processors will completely
ignore anything between these markers, similar to
<quote>/*</quote> and <quote>*/</quote> comments in C
diff --git a/en/winedev-kernel.sgml b/en/winedev-kernel.sgml
index 958050b..09d0e1c 100644
--- a/en/winedev-kernel.sgml
+++ b/en/winedev-kernel.sgml
@@ -60,10 +60,10 @@
the user passed in from the command line. The preloader is an unusual program:
it does not have a <function>main()</function> function. In standard
ELF applications, the entry point is actually at a symbol named
- <function>_start()</function>: this is provided by the
+ <symbol>_start</symbol>: this is provided by the
standard <command>gcc</command> infrastructure and normally jumps to
<function>__libc_start_main()</function> which initializes glibc before
- passing control to the main function as defined by the programmer.
+ passing control to the <function>main</function> function as defined by the programmer.
</para>
<para>
@@ -170,8 +170,8 @@
memory (which may involve loading and initializing other DLLs, the
bulk of Wines startup code), before control reaches the end of
<function>__wine_kernel_init()</function>. This function ends with the
- new process stack being initialized, and start_process being called on
- the new stack. Nearly there!
+ new process stack being initialized, and <function>start_process</function> being called
+ on the new stack. Nearly there!
</para>
<para>
@@ -180,7 +180,7 @@
backstop handler, calls <function>LdrInitializeThunk()</function>
which performs the last part of the process initialization (such as
performing relocations and calling the <function>DllMain()</function>
- with <constant>PROCESS_ATTACH</constant>), grabs the entry point of
+ with <literal>PROCESS_ATTACH</literal>), grabs the entry point of
the executable and then on this line:
</para>
@@ -191,7 +191,7 @@ ExitProcess( entry( peb ) );
<para>
... jumps to the entry point of the program. At this point the users
program is running and the API provided by Wine is ready to be
- used. When entry returns, the <function>ExitProcess()</function> API
+ used. When <function>entry</function> returns, the <function>ExitProcess</function> API
will be used to initialize a graceful shutdown.
</para>
</sect2>
@@ -657,7 +657,7 @@ if (res != ERROR_SUCCESS) return res;
implementation of this. Essentially, the contents of a given slot will
be different in each thread, so you can use this to store data that is
only meaningful in the context of a single thread. On recent versions
- of Linux the __thread keyword provides a convenient interface to this
+ of Linux the <literal>__thread</literal> keyword provides a convenient interface to this
functionality - a more portable API is exposed in the pthread
library. However, these facilities are not used by Wine, rather, we
implement Win32 TLS entirely ourselves.
@@ -689,8 +689,8 @@ if (res != ERROR_SUCCESS) return res;
</para>
<para>
- A pointer to the TEB is stored in the %fs register and can be accessed
- using <function>NtCurrentTeb()</function> from within Wine code. %fs
+ A pointer to the TEB is stored in the <literal>%fs</literal> register and can be accessed
+ using <function>NtCurrentTeb()</function> from within Wine code. <literal>%fs</literal>
actually stores a selector, and setting it therefore requires
modifying the processes local descriptor table (LDT) - the code to do
this is in <filename>lib/wine/ldt.c</filename>.
@@ -778,7 +778,7 @@ if (res != ERROR_SUCCESS) return res;
<para>
Exceptions can be triggered by many things. They can be thrown
- explicitly by using the RaiseException API, or they can be triggered
+ explicitly by using the <function>RaiseException</function> API, or they can be triggered
by a crash (i.e. translated from a signal). They may be used internally
by a language runtime to implement language-specific exceptions. They
can also be thrown across DCOM connections.
@@ -859,7 +859,7 @@ if (res != ERROR_SUCCESS) return res;
standard APIs provide. For instance, a
<errorname>STATUS_ACCESS_VIOLATION</errorname> exception
(<errorcode>0xC0000005</errorcode>) structure contains the faulting
- address, whereas a standard Unix <literal>SIGSEGV</literal> just
+ address, whereas a standard Unix <systemitem class="event">SIGSEGV</systemitem> just
tells the app that it crashed. Usually this information is passed as
an extra parameter to the signal handler, however its location and
contents vary between kernels (BSD, Solaris, etc). This data is
@@ -929,8 +929,9 @@ if (res != ERROR_SUCCESS) return res;
things, for many years the format used on the disk itself for
storing the names has been the short name as the real one and to use
some tricky aliasing techniques to store the long name. When some
- newer disk file systems have been introduced (NTFS with NT), in
- replacement of the old FAT system (which had little evolved since
+ newer disk file systems have been introduced (<systemitem
+ class="filesystem">NTFS</systemitem> with NT), in replacement of the old <systemitem
+ class="filesystem">FAT</systemitem> system (which had little evolved since
the first days of DOS), the long name became the real name while the
short name took the alias role.
</para>
@@ -1365,13 +1366,17 @@ if (res != ERROR_SUCCESS) return res;
</thead>
<tbody>
<row>
- <entry>FAT, FAT16 or FAT32</entry>
+ <entry>
+ <systemitem class="filesystem">FAT</systemitem>,
+ <systemitem class="filesystem">FAT16</systemitem> or
+ <systemitem class="filesystem">FAT32</systemitem>
+ </entry>
<entry>Short name (8+3)</entry>
<entry>Names are always stored in upper-case</entry>
<entry>Case insensitive</entry>
</row>
<row>
- <entry>VFAT</entry>
+ <entry><systemitem class="filesystem">VFAT</systemitem></entry>
<entry>Short name (8+3) + alias on long name</entry>
<entry>
Short names are always stored in upper-case. Long names
@@ -1380,7 +1385,7 @@ if (res != ERROR_SUCCESS) return res;
<entry>Case insensitive</entry>
</row>
<row>
- <entry>NTFS</entry>
+ <entry><systemitem class="filesystem">NTFS</systemitem></entry>
<entry>Long name + alias on short name (8+3).</entry>
<entry>
Long names are stored with case preservation. Short names
@@ -1389,7 +1394,11 @@ if (res != ERROR_SUCCESS) return res;
<entry>Case insensitivity</entry>
</row>
<row>
- <entry>Linux FS (ext2fs, ext3fs, reiserfs...)</entry>
+ <entry>
+ Linux FS (<systemitem class="filesystem">ext2fs</systemitem>,
+ <systemitem class="filesystem">ext3fs</systemitem>,
+ <systemitem class="filesystem">reiserfs</systemitem>...)
+ </entry>
<entry>Long name</entry>
<entry>Case preserving</entry>
<entry>Case sensitive</entry>
@@ -1405,9 +1414,10 @@ if (res != ERROR_SUCCESS) return res;
When we say that most systems in NT are case insensitive, this
has to be understood for looking up for a file, where the
matches are made in a case insensitive mode. This is different
- from VFAT or NTFS <quote>case preservation</quote> mechanism, which stores
- the file names as they are given when creating the file, while
- doing case insensitive matches.
+ from <systemitem class="filesystem">VFAT</systemitem> or
+ <systemitem class="filesystem">NTFS</systemitem> <quote>case preservation</quote>
+ mechanism, which stores the file names as they are given when creating the file,
+ while doing case insensitive matches.
</para>
</note>
Since most file systems used in NT are case insensitive and since
@@ -1449,16 +1459,22 @@ if (res != ERROR_SUCCESS) return res;
Wine considers that Unix file names <emphasis>are</emphasis> long
filename. This seems a reasonable approach; this is also the
approach followed by most of the Unix OSes while mounting Windows
- partitions (with filesystems like FAT, FAT32 or NTFS). Therefore,
+ partitions (with filesystems like <systemitem class="filesystem">FAT</systemitem>,
+ <systemitem class="filesystem">FAT32</systemitem> or
+ <systemitem class="filesystem">NTFS</systemitem>). Therefore,
Wine tries to support short names the best it can. Basically, they
are two options:
<itemizedlist>
<listitem>
<para>
The filesystem on which the inspected directory lies in a real
- Windows FS (like FAT, or FAT32, or NTFS) and the OS has
+ Windows FS (like <systemitem class="filesystem">FAT</systemitem>, or
+ <systemitem class="filesystem">FAT32</systemitem>, or
+ <systemitem class="filesystem">NTFS</systemitem>) and the OS has
support to access the short filename (for example, Linux does
- this on FAT, FAT32 or VFAT). In this case, Wine makes full use
+ this on <systemitem class="filesystem">FAT</systemitem>,
+ <systemitem class="filesystem">FAT32</systemitem> or
+ <systemitem class="filesystem">VFAT</systemitem>). In this case, Wine makes full use
of this information and really mimics the Windows behavior:
the short filename used for any file is the same than on
Windows.
@@ -1525,8 +1541,10 @@ if (res != ERROR_SUCCESS) return res;
<para>
As a side note, as Unix doesn't widely provide a Unicode interface
to the filenames, and Windows implements filenames as Unicode
- strings (even on the physical layer with NTFS, the FATs variant are
- ANSI), we need to properly map between the two. At startup, Wine
+ strings (even on the physical layer with
+ <systemitem class="filesystem">NTFS</systemitem>, the
+ <systemitem class="filesystem">FAT</systemitem>s variant are ANSI), we need to properly
+ map between the two. At startup, Wine
defines what's called the Unix Code Page, that's is the code page
the Unix kernel uses as a reference for the strings. Then Wine uses
this code page for all the mappings it has to do between a Unicode
@@ -2106,7 +2124,7 @@ if (res != ERROR_SUCCESS) return res;
<entry>
Nothing is done, which means that
<keycombo><keycap>Ctrl</keycap><keycap>C</keycap></keycombo> will generate
- (as usual) a <literal>SIGINT</literal> which will terminate
+ (as usual) a <systemitem class="event">SIGINT</systemitem> which will terminate
the program.
</entry>
<entry>
diff --git a/en/winedev-opengl.sgml b/en/winedev-opengl.sgml
index 59bcbcb..d1a358f 100644
--- a/en/winedev-opengl.sgml
+++ b/en/winedev-opengl.sgml
@@ -294,9 +294,9 @@ int main(void)
installed the Wine libraries in
<filename class="directory">/usr/local/lib</filename>, YMMV):
</para>
- <programlisting>
+ <screen>
gcc dummy.c -L/usr/local/lib -L/usr/local/lib/wine -lwine -lopengl32
- </programlisting>
+ </screen>
</listitem>
<listitem>
<para>
diff --git a/en/winedev-testing.sgml b/en/winedev-testing.sgml
index 5fec897..609e144 100644
--- a/en/winedev-testing.sgml
+++ b/en/winedev-testing.sgml
@@ -113,10 +113,10 @@
correct parameters.
</para>
<para>
- For instance you could create an edit control and use WM_SETTEXT to
+ For instance you could create an edit control and use <literal>WM_SETTEXT</literal> to
set its contents, possibly check length restrictions, and verify the
- results using WM_GETTEXT. Similarly one could create a listbox and
- check the effect of LB_DELETESTRING on the number of items of the list,
+ results using <literal>WM_GETTEXT</literal>. Similarly one could create a listbox and
+ check the effect of <literal>LB_DELETESTRING</literal> on the number of items of the list,
selected items list, highlighted item, etc. For concrete examples,
see <filename>dlls/user32/tests/win.c</filename> and the related tests.
</para>
@@ -429,7 +429,7 @@ START_TEST(paths)
execution will start. You can put all your tests in that section but
it may be better to split related checks in functions you will call
from the <literal>START_TEST</literal> section. The parameter to
- <literal>START_TEST</literal> must match
+ <systemitem class="macro">START_TEST</systemitem> must match
the name of the C file. So in the above example the C file would be
called <filename>paths.c</filename>.
</para>
--
1.8.4
More information about the wine-patches
mailing list