[2/3] [docs] winedev: Add/fix some 'filename' tags
Frédéric Delanoy
frederic.delanoy at gmail.com
Sat Aug 17 02:28:40 CDT 2013
---
en/winedev-architecture.sgml | 8 ++++----
en/winedev-debugger.sgml | 13 +++++++------
en/winedev-documentation.sgml | 18 ++++++++++--------
en/winedev-kernel.sgml | 8 ++++----
en/winedev-multimedia.sgml | 18 +++++++++---------
en/winedev-ole.sgml | 10 +++++-----
en/winedev-opengl.sgml | 10 +++++-----
en/winedev-testing.sgml | 21 +++++++++++----------
en/winedev-windowing.sgml | 6 +++---
9 files changed, 58 insertions(+), 54 deletions(-)
diff --git a/en/winedev-architecture.sgml b/en/winedev-architecture.sgml
index b9169a4..eaf76bd 100644
--- a/en/winedev-architecture.sgml
+++ b/en/winedev-architecture.sgml
@@ -91,7 +91,7 @@
<thead>
<row>
<entry></entry>
- <entry>DOS (.COM or .EXE)</entry>
+ <entry>DOS (<filename>.COM</filename> or <filename>.EXE</filename>)</entry>
<entry>Win16 (NE)</entry>
<entry>Win32 (PE)</entry>
<entry>Win64 (PE)</entry>
@@ -442,7 +442,7 @@
synchronization, and process/thread management. When the
Wine server launches, it creates a Unix socket for the
current host based on (see below) your home directory's
- <filename>.wine</filename> subdirectory (or wherever the
+ <filename class="directory">.wine</filename> subdirectory (or wherever the
<envar>WINEPREFIX</envar> environment variable points to)
- all Wine processes launched later connects to the Wine
server using this socket. If a Wine server was not
@@ -453,7 +453,7 @@
</para>
<para>
The master socket mentioned above is
- created within the <filename>/tmp</filename> directory
+ created within the <filename class="directory">/tmp</filename> directory
with a name that reflects the configuration directory.
This means that there can actually be several separate
copies of the Wine server running; one per combination of
@@ -519,7 +519,7 @@
expected; this is, obviously, what the entire Wine
implementation is all about. Wine contains a range of DLL
implementations. You can find the DLLs implementation in the
- <filename>dlls/</filename> directory.
+ <filename class="directory">dlls/</filename> directory.
</para>
<para>
Each DLL (at least, the 32-bit version, see below) is
diff --git a/en/winedev-debugger.sgml b/en/winedev-debugger.sgml
index b67fd01..b8cf880 100644
--- a/en/winedev-debugger.sgml
+++ b/en/winedev-debugger.sgml
@@ -1187,8 +1187,9 @@ winedbg myprog.exe
(<command>winedbg</command> can of course be used, but
any other Windows debugging API aware debugger will do).
The path to the debugger you choose to use must be reachable
- via one of the DOS drives configured under /dosdevices in
- your $WINEPREFIX or ~/.wine folder.
+ via one of the DOS drives configured under <filename
+ class="directory">/dosdevices</filename> in your <envar>WINEPREFIX</envar> or
+ <filename class="directory">~/.wine</filename> folder.
</para>
</listitem>
</varlistentry>
@@ -1909,7 +1910,7 @@ set $BreakAllThreadsStartup = 1
<entry><command>list foo.c:1, 56</command></entry>
<entry>
lists source lines from line 1 up to 56 in file
- foo.c
+ <filename>foo.c</filename>
</entry>
</row>
</tbody>
@@ -2171,7 +2172,7 @@ set $BreakAllThreadsStartup = 1
<entry><command>info share</command></entry>
<entry>
lists all the dynamic libraries loaded in the
- debugged program (including .so files, NE and PE
+ debugged program (including <filename>.so</filename> files, NE and PE
DLLs)
</entry>
</row>
@@ -2619,8 +2620,8 @@ $ gdb wine
<row>
<entry>
WineDbg supports debug information from stabs
- (standard Unix format) and Microsoft's C, CodeView,
- .DBG
+ (standard Unix format) and C, CodeView, <filename>.DBG</filename>
+ (Microsoft)
</entry>
<entry>
GDB supports debug information from stabs (standard
diff --git a/en/winedev-documentation.sgml b/en/winedev-documentation.sgml
index 98aa8a1..1fc4a98 100644
--- a/en/winedev-documentation.sgml
+++ b/en/winedev-documentation.sgml
@@ -28,7 +28,8 @@
<para>
The Wine source code tree comes with a large amount of documentation in the
- <filename>documentation/</filename> subdirectory. This used to be a collection
+ <filename class="directory">documentation/</filename> subdirectory. This used to be a
+ collection
of text files culled from various places such as the Wine Weekly News and the wine-devel
mailing list, but was reorganized some time ago into a number of books, each of which is
marked up using SGML. You are reading one of these books (the
@@ -532,7 +533,7 @@
Having edited or added new API documentation to a source code file, you
should generate the documentation to ensure that the result is what you
expected. Wine includes a tool (slightly misleadingly) called
- <command>c2man.pl</command> in the <filename>tools/</filename> directory
+ <command>c2man.pl</command> in the <filename class="directory">tools/</filename> directory
which is used to generate the documentation from the source code.
</para>
@@ -545,11 +546,12 @@
<para>
An easier way is to use Wine build system. To create man pages for a given
- dll, just type <command>make man</command> from within the dlls directory
+ DLL, just type <command>make man</command> from within the <filename
+ class="directory">dlls</filename> directory
or type <command>make manpages</command> in the root directory of the Wine
source tree. You can then check that a man page was generated for your function,
- it should be present in the <filename>documentation/man3w</filename> directory
- with the same name as the function.
+ it should be present in the <filename class="directory">documentation/man3w</filename>
+ directory with the same name as the function.
</para>
<para>
@@ -564,9 +566,9 @@
<para>
You can also generate HTML output for the API documentation, in this case the
- make command is <command>make htmlpages</command> in the dll directory,
- or from the root. The output will be
- placed by default under <filename>documentation/html</filename>. Similarly
+ <command>make</command> command is <command>make htmlpages</command> in the <filename
+ class="directory">dll</filename> directory, or from the root. The output will be placed by
+ default under <filename class="directory">documentation/html</filename>. Similarly
you can create SGML/XML Docbook source code to produce the <emphasis>Wine API
Guide</emphasis> with the command <command>make sgmlpages</command>/<command>make
xmlpages</command> respectively.
diff --git a/en/winedev-kernel.sgml b/en/winedev-kernel.sgml
index fd4d206..d01c36b 100644
--- a/en/winedev-kernel.sgml
+++ b/en/winedev-kernel.sgml
@@ -1179,7 +1179,7 @@ if (res != ERROR_SUCCESS) return res;
</entry>
<entry>
Simple concatenation using the default directory
- (here <filename>J:\mydir\mysubdir</filename>)
+ (here <filename class="directory">J:\mydir\mysubdir</filename>)
</entry>
</row>
<row>
@@ -1218,7 +1218,7 @@ if (res != ERROR_SUCCESS) return res;
<listitem>
<para>
On Windows 9x (and DOS),
- <filename>\toto</filename> is the default
+ <filename class="directory">\toto</filename> is the default
directory on drive <filename>J:</filename>.
</para>
</listitem>
@@ -1887,7 +1887,7 @@ if (res != ERROR_SUCCESS) return res;
Wine also recognizes VxDs as devices. But those VxDs must be the
Wine builtin ones (Wine will never allow to load native VxDs). Those
are configured with symbolic links in the
- <filename>$(WINEPREFIX)/dosdevices/</filename> directory, and point
+ <filename class="directory">$(WINEPREFIX)/dosdevices/</filename> directory, and point
to the actual builtin DLL. This DLL exports a single entry point,
that Wine will use when a call to
<function>DeviceIoControl</function> is made, with a handle opened
@@ -2178,7 +2178,7 @@ if (res != ERROR_SUCCESS) return res;
<function>WriteConsole()</function>
which is called, hence using the default console's code page. There
are some other spots affected, but you can look in
- <filename>dlls/kernel32</filename> to find them all. All of this is
+ <filename class="directory">dlls/kernel32</filename> to find them all. All of this is
implemented in Wine.
</para>
<para>
diff --git a/en/winedev-multimedia.sgml b/en/winedev-multimedia.sgml
index a38d7a2..f8c0fc8 100644
--- a/en/winedev-multimedia.sgml
+++ b/en/winedev-multimedia.sgml
@@ -279,7 +279,7 @@ Kernel space | Client applications
url="http://www.4front-tech.com/">4Front
Technologies</ulink>. The presence of this driver is
checked by configure (depends on the
- <sys/soundcard.h> file). Source code resides in
+ <filename><sys/soundcard.h></filename> file). Source code resides in
<filename>dlls/wineoss.drv</filename>.
</para>
</listitem>
@@ -314,10 +314,10 @@ Kernel space | Client applications
<para>
Wave mapper driver implementation can be found in
- <filename>dlls/winmm/wavemap/</filename> directory. This
+ <filename class="directory">dlls/winmm/wavemap/</filename> directory. This
driver heavily relies on MSACM and MSACM32 DLLs which can be
- found in <filename>dlls/msacm</filename> and
- <filename>dlls/msacm32</filename>. Those DLLs load ACM
+ found in <filename class="directory">dlls/msacm</filename> and
+ <filename class="directory">dlls/msacm32</filename>. Those DLLs load ACM
drivers which provide the conversion to PCM format (which is
normally supported by low level drivers). A Law, uLaw,
ADPCM, MP3... fit into the category of non PCM formats.
@@ -338,7 +338,7 @@ Kernel space | Client applications
<para>
A built-in MIDI mapper can be found in
- <filename>dlls/winmm/midimap/</filename>. It partly provides
+ <filename class="directory">dlls/winmm/midimap/</filename>. It partly provides
the same functionality as the Windows one. It allows to
pick up destination channels: you can map a given channel to
a specific playback device channel (see the configuration
@@ -377,7 +377,7 @@ Kernel space | Client applications
<entry>CdAudio</entry>
<entry>MciCDA.drv</entry>
<entry>MCI interface to a CD audio player</entry>
- <entry><filename>dlls/winmm/mcicda/</filename></entry>
+ <entry><filename class="directory">dlls/winmm/mcicda/</filename></entry>
<entry>
Relies on NTDLL CdRom raw interface (through
<function>DeviceIoControl</function>).
@@ -389,21 +389,21 @@ Kernel space | Client applications
<entry>
MCI interface for wave playback and record
</entry>
- <entry><filename>dlls/winmm/mciwave/</filename></entry>
+ <entry><filename class="directory">dlls/winmm/mciwave/</filename></entry>
<entry>It uses the low level audio API.</entry>
</row>
<row>
<entry>Sequencer</entry>
<entry>MciSeq.drv</entry>
<entry>Midi Sequencer (playback)</entry>
- <entry><filename>dlls/winmm/mciseq/</filename></entry>
+ <entry><filename class="directory">dlls/winmm/mciseq/</filename></entry>
<entry>It uses the low level midi APIs</entry>
</row>
<row>
<entry>AviVideo</entry>
<entry>MciAvi.drv</entry>
<entry>AVI playback and record</entry>
- <entry><filename>dlls/winmm/mciavi/</filename></entry>
+ <entry><filename class="directory">dlls/winmm/mciavi/</filename></entry>
<entry>
It rather heavily relies on MSVIDEO/MSVFW32 DLLs
pair to work.
diff --git a/en/winedev-ole.sgml b/en/winedev-ole.sgml
index cc6f950..c81372b 100644
--- a/en/winedev-ole.sgml
+++ b/en/winedev-ole.sgml
@@ -450,8 +450,8 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
<para>
The tricky part is exactly how to encode those parameters in the buffer,
and how to convert standard stdcall/cdecl method calls to network
- packets and back again. This is the job of the RPCRT4.DLL file - or the
- Remote Procedure Call Runtime.
+ packets and back again. This is the job of the <filename>RPCRT4.DLL</filename> file:
+ the <firstterm>Remote Procedure Call Runtime</firstterm>.
</para>
<para>
@@ -524,8 +524,8 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
<para>
The sort of marshalling/unmarshalling code that MIDL spits out can be
- seen in dlls/oleaut32/oaidl_p.c - it's not exactly what it would look
- like as that file contains DCOM proxies/stubs which are different, but
+ seen in <filename>dlls/oleaut32/oaidl_p.c</filename> - it's not exactly what it would
+ look like as that file contains DCOM proxies/stubs which are different, but
you get the idea. Proxy functions take the arguments and feed them to
the NDR marshallers (or picklers), invoke an NdrProxySendReceive and
then convert the out parameters and return code. There's a ton of goop
@@ -776,7 +776,7 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
off the stack. The CreateProxy method actually builds a vtable out of
blocks of assembly stitched together which pass control to _xCall, which
then does the marshalling. You can see all this magic in
- dlls/oleaut32/tmarshal.c
+ <filename>dlls/oleaut32/tmarshal.c</filename>.
</para>
<para>
diff --git a/en/winedev-opengl.sgml b/en/winedev-opengl.sgml
index 478a85c..ff173d0 100644
--- a/en/winedev-opengl.sgml
+++ b/en/winedev-opengl.sgml
@@ -29,7 +29,7 @@
<variablelist>
<varlistentry>
- <term><filename>gl.h:</filename></term>
+ <term><filename>gl.h</filename></term>
<listitem>
<para>
the definition of all OpenGL core functions, types and enumerants
@@ -37,7 +37,7 @@
</listitem>
</varlistentry>
<varlistentry>
- <term><filename>glx.h:</filename></term>
+ <term><filename>glx.h</filename></term>
<listitem>
<para>
how OpenGL integrates in the X Window environment
@@ -45,7 +45,7 @@
</listitem>
</varlistentry>
<varlistentry>
- <term><filename>glext.h:</filename></term>
+ <term><filename>glext.h</filename></term>
<listitem>
<para>
the list of all registered OpenGL extensions
@@ -159,7 +159,7 @@
is how it all works....
</para>
<para>
- The script is located in <filename>dlls/opengl32</filename>
+ The script is located in <filename class="directory">dlls/opengl32</filename>
and is called <command>make_opengl</command>. It requires
Perl5 to work and takes an OpenGL version as argument.
It's the version to <quote>simulate</quote>. This fixes the list of functions
@@ -290,7 +290,7 @@ int main(void)
try to compile it by linking both libwine and
opengl32 (this command line supposes that you
installed the Wine libraries in
- <filename>/usr/local/lib</filename>, YMMV):
+ <filename class="directory">/usr/local/lib</filename>, YMMV):
</para>
<programlisting>
gcc dummy.c -L/usr/local/lib -L/usr/local/lib/wine -lwine -lopengl32
diff --git a/en/winedev-testing.sgml b/en/winedev-testing.sgml
index 5e04b71..f1446bc 100644
--- a/en/winedev-testing.sgml
+++ b/en/winedev-testing.sgml
@@ -145,8 +145,9 @@
</para>
<para>
So to run all the tests related to a given Wine library, go to the
- corresponding 'tests' directory and type 'make test'. This will
- compile the tests, run them, and create an '<replaceable>xxx</replaceable>.ok'
+ corresponding <filename class="directory">tests</filename> directory
+ and type <command>make test</command>. This will compile the tests, run
+ them, and create a <filename><replaceable>xxx</replaceable>.ok</filename>
file for each test that passes successfully. And if you only want to
run the tests contained in the <filename>thread.c</filename> file of the
kernel library, you would do:
@@ -329,8 +330,8 @@ Kit</ulink>.
</para></listitem>
<listitem><para>
You can also run the tests from the command line. You will find
- them in either <filename>Output\Win32_Wine_Headers</filename> or
- <filename>Output\Win32_MSVC_Headers</filename> depending on the build
+ them in either <filename class="directory">Output\Win32_Wine_Headers</filename> or
+ <filename class="directory">Output\Win32_MSVC_Headers</filename> depending on the build
method. So to run the kernel 'path' tests you would do:
<screen>
<prompt>C:\></prompt>cd dlls\kernel\tests\Output\Win32_MSVC_Headers
@@ -364,9 +365,9 @@ Kit</ulink>.
<ulink url="http://www.microsoft.com/msdownload/platformsdk/sdkupdate">Microsoft Platform SDK</ulink>.
</para></listitem>
<listitem><para>
- Make a <filename>wine</filename> directory underneath your work directory,
- and copy the file <filename>wine/test.h</filename> from the Wine source tree there
- (you can download this file from the latest revision at
+ Make a <filename class="directory">wine</filename> directory underneath your work
+ directory, and copy the file <filename>wine/test.h</filename> from the Wine source tree
+ there (you can download this file from the latest revision at
<ulink url="http://source.winehq.org/git/?p=wine.git;a=blob_plain;f=include/wine/test.h"></ulink>).
</para></listitem>
<listitem><para>
@@ -404,7 +405,7 @@ Kit</ulink>.
<para>
When writing new checks you can either modify an existing test file or
add a new one. If your tests are related to the tests performed by an
- existing file, then add them to that file. Otherwise create a new .c
+ existing file, then add them to that file. Otherwise create a new <filename>.c</filename>
file in the tests directory and add that file to the
<varname>CTESTS</varname> variable in <filename>Makefile.in</filename>.
</para>
@@ -521,7 +522,7 @@ thread.c:123: Test failed: rc=0 error=120 disabled=0
it's a call to GetThreadPriorityBoost, that the test failed not
because the API returned the wrong value, but because it returned an
error code. Furthermore we see that GetLastError() returned 120 which
- winerror.h defines as ERROR_CALL_NOT_IMPLEMENTED. So the source of
+ <filename>winerror.h</filename> defines as ERROR_CALL_NOT_IMPLEMENTED. So the source of
the problem is obvious: this Windows platform (here Windows 98) does
not support this API and thus the test must be modified to detect
such a condition and skip the test.
@@ -538,7 +539,7 @@ thread.c:123: Test failed: rc=0 error=120 disabled=0
It may also be a good idea to dump items that may be hard to retrieve
from the source, like the expected value in a test if it is the
result of an earlier computation, or comes from a large array of test
- values (e.g. index 112 of _pTestStrA in vartest.c). In that respect,
+ values (e.g. index 112 of _pTestStrA in <filename>vartest.c</filename>). In that respect,
for some tests you may want to define a macro such as the following:
<screen>
#define eq(received, expected, label, type) \
diff --git a/en/winedev-windowing.sgml b/en/winedev-windowing.sgml
index 50ff636..7e666ea 100644
--- a/en/winedev-windowing.sgml
+++ b/en/winedev-windowing.sgml
@@ -7,9 +7,9 @@
USER implements windowing and messaging subsystems. It also
contains code for common controls and for other
miscellaneous stuff (rectangles, clipboard, WNet, etc).
- Wine USER code is located in <filename>windows/</filename>,
- <filename>controls/</filename>, and
- <filename>misc/</filename> directories.
+ Wine USER code is located in <filename class="directory">windows/</filename>,
+ <filename class="directory">controls/</filename>, and
+ <filename class="directory">misc/</filename> directories.
</para>
<sect2>
--
1.8.3.4
More information about the wine-patches
mailing list