[docs] winedev: Use appropriate values for 'filename' tag attributes.
Frédéric Delanoy
frederic.delanoy at gmail.com
Tue Sep 3 14:28:49 CDT 2013
---
en/winedev-architecture.sgml | 61 +++++-----
en/winedev-coding.sgml | 29 ++---
en/winedev-debugger.sgml | 24 ++--
en/winedev-debugging.sgml | 2 +-
en/winedev-documentation.sgml | 14 +--
en/winedev-kernel.sgml | 264 ++++++++++++++++++++++--------------------
en/winedev-multimedia.sgml | 110 ++++++++++--------
en/winedev-ole.sgml | 8 +-
en/winedev-opengl.sgml | 24 ++--
en/winedev-otherdebug.sgml | 6 +-
en/winedev-testing.sgml | 28 ++---
en/winedev-windowing.sgml | 2 +-
12 files changed, 300 insertions(+), 272 deletions(-)
diff --git a/en/winedev-architecture.sgml b/en/winedev-architecture.sgml
index 8fc9edf..978e55a 100644
--- a/en/winedev-architecture.sgml
+++ b/en/winedev-architecture.sgml
@@ -18,7 +18,7 @@
Wine is an implementation of the Windows API, and can be
used as a library to port Windows applications to Unix. The
second meaning, obviously, is that to Windows binaries
- (<filename>.exe</filename> files), Wine does look like
+ (<filename class="extension">.exe</filename> files), Wine does look like
Windows, and emulates its behaviour and quirks rather
closely.
</para>
@@ -48,8 +48,8 @@
<listitem>
<para>
DOS executable. Those are even older programs, using
- the DOS format (either <filename>.com</filename> or
- <filename>.exe</filename> (the later being also called
+ the DOS format (either <filename class="extension">.com</filename> or
+ <filename class="extension">.exe</filename> (the later being also called
MZ)).
</para>
</listitem>
@@ -91,8 +91,10 @@
<thead>
<row>
<entry></entry>
- <entry>DOS (<filename>.COM</filename> or <filename>.EXE</filename>)</entry>
- <entry>Win16 (NE)</entry>
+ <entry>
+ DOS (<filename class="extension">.COM</filename> or <filename
+ class="extension">.EXE</filename>)</entry>
+ <entry>Win16 (NE)</entry>
<entry>Win32 (PE)</entry>
<entry>Win64 (PE)</entry>
<entry>Winelib</entry>
@@ -267,11 +269,11 @@
<para>
The windows architecture (Windows NT way) looks like the
following drawing. Note the new DLL
- (<filename>NTDLL</filename>) which allows implementing
+ (<filename class="libraryfile">NTDLL</filename>) which allows implementing
different subsystems (as win32);
- <filename>kernel32</filename> in NT architecture
+ <filename class="libraryfile">kernel32</filename> in NT architecture
implements the Win32 subsystem on top of
- <filename>NTDLL</filename>.
+ <filename class="libraryfile">NTDLL</filename>.
<screen>
+---------------------+ \
| Windows EXE | } application
@@ -389,16 +391,17 @@
<para>
Wine must at least completely replace the <quote>Big Three</quote> DLLs
- (<filename>KERNEL</filename>/<filename>KERNEL32</filename>,
- <filename>GDI</filename>/<filename>GDI32</filename>, and
- <filename>USER</filename>/<filename>USER32</filename>),
+ (<filename class="libraryfile">KERNEL</filename>/<filename class="libraryfile">KERNEL32</filename>,
+ <filename class="libraryfile">GDI</filename>/<filename
+ class="libraryfile">GDI32</filename>, and <filename
+ class="libraryfile">USER</filename>/<filename class="libraryfile">USER32</filename>),
which all other DLLs are layered on top of. But since Wine
is (for various reasons) leaning towards the NT way of
- implementing things, the <filename>NTDLL</filename> is
+ implementing things, the <filename class="libraryfile">NTDLL</filename> is
another core DLL to be implemented in Wine, and many
- <filename>KERNEL32</filename> and
- <filename>ADVAPI32</filename> features will be
- implemented through the <filename>NTDLL</filename>.
+ <filename class="libraryfile">KERNEL32</filename> and <filename
+ class="libraryfile">ADVAPI32</filename> features will be implemented through the <filename
+ class="libraryfile">NTDLL</filename>.
</para>
<para>
As of today, no real subsystem (apart the Win32 one) has
@@ -525,8 +528,8 @@
Each DLL (at least, the 32-bit version, see below) is
implemented in a Unix shared library. The file name of this
shared library is the module name of the DLL with a
- <filename>.dll.so</filename> suffix (or
- <filename>.drv.so</filename> or any other relevant extension
+ <filename class="extension">.dll.so</filename> suffix (or <filename
+ class="extension">.drv.so</filename> or any other relevant extension
depending on the DLL type). This shared library contains the
code itself for the DLL, as well as some more information,
as the DLL resources and a Wine specific DLL descriptor.
@@ -541,7 +544,7 @@
<para>
The DLL descriptor and entry point table is generated by
the <command>winebuild</command> tool, taking DLL specification
- files with the extension <filename>.spec</filename> as
+ files with the extension <filename class="extension">.spec</filename> as
input. Resources (after compilation by
<command>wrc</command>) or message tables (after
compilation by <command>wmc</command>) are also added to
@@ -573,7 +576,7 @@
<listitem>
<para>
Failing that, it will look for a real Windows
- <filename>.DLL</filename> file to use, and look
+ <filename class="extension">.DLL</filename> file to use, and look
through its imports, etc) and use the loading of
native DLLs.
</para>
@@ -686,11 +689,11 @@
<para>
More significant, less aesthetically-oriented problems can
result if the built-in Wine version of the
- <filename>SHELL</filename> DLL is loaded before the native
- version of this library. <filename>SHELL</filename>
+ <filename class="libraryfile">SHELL</filename> DLL is loaded before the native
+ version of this library. <filename class="libraryfile">SHELL</filename>
contains routines such as those used by installer utilities
to create desktop shortcuts. Some installers might fail when
- using Wine's built-in <filename>SHELL</filename>.
+ using Wine's built-in <filename class="libraryfile">SHELL</filename>.
</para>
</sect3>
@@ -702,7 +705,7 @@
a library tries to access features of the rest of the system
that are not fully implemented in Wine, the native DLL might
work much worse than the corresponding built-in one, if at
- all. For example, the native Windows <filename>GDI</filename>
+ all. For example, the native Windows <filename class="libraryfile">GDI</filename>
library must be paired with a Windows display driver, which
of course is not present under Unix and Wine.
</para>
@@ -711,8 +714,8 @@
features than the corresponding native Windows DLLs.
Probably the most important example of such behavior is the
integration of Wine with X provided by Wine's built-in
- <filename>USER</filename> DLL. Should the native Windows
- <filename>USER</filename> library take load-order
+ <filename class="libraryfile">USER</filename> DLL. Should the native Windows
+ <filename class="libraryfile">USER</filename> library take load-order
precedence, such features as the ability to use the
clipboard or drag-and-drop between Wine windows and X
windows will be lost.
@@ -804,7 +807,7 @@
mapped at any address in the address space. Remember we
are not dealing with physical memory here, but rather
virtual memory which is different for each
- process. Therefore <filename>OLEAUT32.DLL</filename> may
+ process. Therefore <filename class="libraryfile">OLEAUT32.DLL</filename> may
be loaded at one address in one process, and a totally
different one in another. Ensuring all the functions
loaded into memory can find each other is the job of the
@@ -905,10 +908,10 @@
Unix. This comes mainly because (look at the generic
architecture schemas) Wine doesn't implement the kernel
features of Windows (kernel here really means the kernel,
- not the <filename>KERNEL32</filename> DLL), but rather
+ not the <filename class="libraryfile">KERNEL32</filename> DLL), but rather
sets up a proxy layer on top of the Unix kernel to provide
- the <filename>NTDLL</filename> and
- <filename>KERNEL32</filename> features. This means that
+ the <filename class="libraryfile">NTDLL</filename> and <filename
+ class="libraryfile">KERNEL32</filename> features. This means that
Wine doesn't provide the inner infrastructure to run
native drivers, either from the Win9x family or from the
NT family.
diff --git a/en/winedev-coding.sgml b/en/winedev-coding.sgml
index dc865b1..78c507f 100644
--- a/en/winedev-coding.sgml
+++ b/en/winedev-coding.sgml
@@ -144,10 +144,10 @@ code
<title>Inline attachments with Outlook Express</title>
<para>
Outlook Express is notorious for mangling
- attachments. Giving the patch a <filename>.txt</filename>
+ attachments. Giving the patch a <filename class="extension">.txt</filename>
extension and attaching will solve the problem for most
mailers including Outlook. Also, there is a way to enable
- Outlook Express to send <filename>.diff</filename>
+ Outlook Express to send <filename class="extension">.diff</filename>
attachments.
</para>
<para>
@@ -156,7 +156,7 @@ code
<orderedlist>
<listitem>
<para>
- Make sure that <filename>.diff</filename> files have
+ Make sure that <filename class="extension">.diff</filename> files have
<quote>\r\n</quote> line endings, because if OE detects that
there are none it switches to quoted-printable format attachments.
</para>
@@ -165,9 +165,9 @@ code
<para>
Using <command>regedit</command> add key <literal>Content Type</literal>
with value <literal>text/plain</literal> to the
- <filename>.diff</filename> extension under
- <literal>HKEY_CLASSES_ROOT</literal> (same as for <filename>.txt</filename>
- extension). This tells OE to use
+ <filename class="extension">.diff</filename> extension under
+ <literal>HKEY_CLASSES_ROOT</literal> (same as for <filename
+ class="extension">.txt</filename> extension). This tells OE to use
<literal>Content-Type: text/plain</literal> instead of
<literal>application/octet-stream</literal>.
</para>
@@ -236,11 +236,11 @@ code
<para>
Operating systems change. Maybe yours doesn't have the
- <filename>foo.h</filename> header, but maybe a future
+ <filename class="headerfile">foo.h</filename> header, but maybe a future
version will have it. If you want to <userinput>#include
<foo.h></userinput>, it doesn't matter what operating
system you are using; it only matters whether
- <filename>foo.h</filename> is there.
+ <filename class="headerfile">foo.h</filename> is there.
</para>
<para>
Furthermore, operating systems change names or <quote>fork</quote> into
@@ -302,7 +302,8 @@ code
<sect2>
<title>
- <replaceable>MyOS</replaceable> doesn't have the <filename>foo.h</filename> header!
+ <replaceable>MyOS</replaceable> doesn't have the <filename
+ class="headerfile">foo.h</filename> header!
</title>
<para>
@@ -317,7 +318,7 @@ AC_CHECK_HEADER(foo.h, AC_DEFINE(HAVE_FOO_H))
<para>
If your operating system supports a header file with the
same contents but a different name, say
- <filename>bar.h</filename>, add a check for that also.
+ <filename class="headerfile">bar.h</filename>, add a check for that also.
</para>
<para>
Now you can change
@@ -343,7 +344,7 @@ AC_CHECK_HEADER(foo.h, AC_DEFINE(HAVE_FOO_H))
</para>
<para>
You will also need to add <userinput>#undef HAVE_FOO_H</userinput>
- (etc.) to <filename>include/config.h.in</filename>.
+ (etc.) to <filename class="headerfile">include/config.h.in</filename>.
</para>
<para>
Finish up with <command>autoconf</command> and
@@ -369,7 +370,7 @@ AC_CHECK_HEADER(foo.h, AC_DEFINE(HAVE_FOO_H))
<para>
Secondly, you will also need to add
<symbol>#undef HAVE_BAR</symbol> to
- <filename>include/config.h.in</filename>.
+ <filename class="headerfile">include/config.h.in</filename>.
</para>
<para>
The next step depends on the nature of the missing function.
@@ -392,7 +393,7 @@ AC_CHECK_HEADER(foo.h, AC_DEFINE(HAVE_FOO_H))
</para>
<para>
You might have to add a prototype for your function.
- If so, <filename>include/miscemu.h</filename> might be
+ If so, <filename class="headerfile">include/miscemu.h</filename> might be
the place. Don't forget to protect that definition by
<userinput>#ifndef HAVE_MEMMOVE</userinput> and
<literal>#endif</literal> also!
@@ -452,7 +453,7 @@ AC_CHECK_HEADER(foo.h, AC_DEFINE(HAVE_FOO_H))
<filename><replaceable>somefile</replaceable>_<replaceable>Xx</replaceable>.rc</filename> or
<filename><replaceable>Xx</replaceable>.rc</filename>, where <replaceable>Xx</replaceable>
is your language abbreviation (look for it in
- <filename>include/winnls.h</filename>). These are included
+ <filename class="headerfile">include/winnls.h</filename>). These are included
in a master file named <filename><replaceable>somefile</replaceable>.rc</filename> or
<filename>rsrc.rc</filename>, located in the same
directory as the language files.
diff --git a/en/winedev-debugger.sgml b/en/winedev-debugger.sgml
index e62bcab..3ed92e3 100644
--- a/en/winedev-debugger.sgml
+++ b/en/winedev-debugger.sgml
@@ -103,20 +103,20 @@
<para>
Wine implements most of the Windows debugging API. The
first part of the debugging APIs (in
- <filename>KERNEL32.DLL</filename>) allows a W-process, called
+ <filename class="libraryfile">KERNEL32.DLL</filename>) allows a W-process, called
the debugger, to control the execution of another W-process,
the debuggee. To control means stopping/resuming execution,
enabling/disabling single stepping, setting breakpoints,
reading/writing debuggee memory... Another part of the
- debugging APIs resides in <filename>DBGHELP.DLL</filename>
- (and its ancestor <filename>IMAGEHLP.DLL</filename>) and lets
+ debugging APIs resides in <filename class="libraryfile">DBGHELP.DLL</filename>
+ (and its ancestor <filename class="libraryfile">IMAGEHLP.DLL</filename>) and lets
a debugger look into symbols and types from any module (if
the module has been compiled with the proper options).
</para>
<para>
<command>winedbg</command> is a Winelib application making
- use of these APIs (<filename>KERNEL32.DLL</filename>
- debugging API and <filename>DBGHELP.DLL</filename>) to allow
+ use of these APIs (<filename class="libraryfile">KERNEL32.DLL</filename>
+ debugging API and <filename> class="libraryfile"DBGHELP.DLL</filename>) to allow
debugging both any Wine or Winelib application as well as
Wine itself (kernel and all DLLs).
</para>
@@ -811,7 +811,8 @@ call KERNEL.LSTRLEN
OF_CREATE|OF_SHARE_EXCLUSIVE|OF_READWRITE
</screen>
<para>
- This fails, since my C: drive is in this case mounted readonly.
+ This fails, since my <filename class="devicefile">C:</filename> drive is in this case
+ mounted readonly.
</para>
<screen>
|Ret KERNEL.74: OPENFILE() retval=0xffff ret=060f:09d8 ds=0927
@@ -831,7 +832,7 @@ Wine-dbg>
<para>
The code seems to find a writable harddisk and tries to create
a file there. To work around this bug, you can define
- C: as a network drive, which is ignored
+ <filename class="devicefile">C:</filename> as a network drive, which is ignored
by the code above.
</para>
</sect2>
@@ -2158,9 +2159,8 @@ set $BreakAllThreadsStartup = 1
<row>
<entry><command>info share</command></entry>
<entry>
- lists all the dynamic libraries loaded in the
- debugged program (including <filename>.so</filename> files, NE and PE
- DLLs)
+ lists all the dynamic libraries loaded in the debugged program (including
+ <filename class="extension">.so</filename> files, NE and PE DLLs)
</entry>
</row>
<row>
@@ -2591,8 +2591,8 @@ kdbg -r localhost:12345 wine
<row>
<entry>
WineDbg supports debug information from <literal>stabs</literal>
- (standard Unix format) and C, CodeView, <filename>.DBG</filename>
- (Microsoft)
+ (standard Unix format) and C, CodeView,
+ <filename class="extension">.DBG</filename> (Microsoft)
</entry>
<entry>
GDB supports debug information from <literal>stabs</literal> (standard
diff --git a/en/winedev-debugging.sgml b/en/winedev-debugging.sgml
index 21896bb..9c895ef 100644
--- a/en/winedev-debugging.sgml
+++ b/en/winedev-debugging.sgml
@@ -172,7 +172,7 @@ if(TRACE_ON(atom)){
introduced a new function called <function>debugres</function>.
</para>
<para>
- The function is defined in <filename>wine/debug.h</filename>
+ The function is defined in <filename class="headerfile">wine/debug.h</filename>
and has the following prototype:
</para>
<programlisting>
diff --git a/en/winedev-documentation.sgml b/en/winedev-documentation.sgml
index e83657b..c15cef3 100644
--- a/en/winedev-documentation.sgml
+++ b/en/winedev-documentation.sgml
@@ -191,8 +191,8 @@
<para>
The following text uses the function <function>PathRelativePathToA()</function> from
- <filename>SHLWAPI.DLL</filename> as an example. You can find this function in the Wine
- source code tree in the file <filename>dlls/shlwapi/path.c</filename>.
+ <filename class="libraryfile">SHLWAPI.DLL</filename> as an example. You can find this
+ function in the Wine source code tree in the file <filename>dlls/shlwapi/path.c</filename>.
</para>
<para>
@@ -211,9 +211,9 @@
The functions name and the DLL name are obvious. The ordinal number takes one of
two forms: Either <literal>@</literal> as in the above, or a number if the export
is exported by ordinal. You can see which to use by looking at the DLL
- <filename>.spec</filename> file. If the line on which the function is listed begins
- with a number, use it, otherwise use the <literal>@</literal> symbol, which indicates
- that this function is imported only by name.
+ <filename class="extension">.spec</filename> file. If the line on which the function is
+ listed begins with a number, use it, otherwise use the <literal>@</literal> symbol, which
+ indicates that this function is imported only by name.
</para>
<para>
@@ -490,7 +490,7 @@
Let's assume you have implemented a COM interface that you want to document; we'll
use the name <classname>IExample</classname> as an example here. Your comment would
look like the following (assuming you are exporting this object from
- <filename>EXAMPLE.DLL</filename>):
+ <filename class="libraryfile">EXAMPLE.DLL</filename>):
<programlisting>
/*************************************************************************
* IExample {EXAMPLE}
@@ -540,7 +540,7 @@
<para>
You can run <command>c2man.pl</command> manually for testing purposes; it is
- a fairly simple perl script which parses <filename>.c</filename> files
+ a fairly simple perl script which parses <filename class="extension">.c</filename> files
to create output in several formats. If you wish to try this you may want
to run it with no arguments, which will cause it to print usage information.
</para>
diff --git a/en/winedev-kernel.sgml b/en/winedev-kernel.sgml
index 4a210ef..4214834 100644
--- a/en/winedev-kernel.sgml
+++ b/en/winedev-kernel.sgml
@@ -2,18 +2,19 @@
<title>Kernel modules</title>
<para>
This section covers the kernel modules. As already stated, Wine
- implements the NT architecture, hence provides <filename>NTDLL</filename>
- for the core kernel functions, and <filename>KERNEL32</filename>, which is
+ implements the NT architecture, hence provides <filename class="libraryfile">NTDLL</filename>
+ for the core kernel functions, and <filename class="libraryfile">KERNEL32</filename>, which is
the implementation of the basis of the Win32 subsystem, on top of
- <filename>NTDLL</filename>.
+ <filename class="libraryfile">NTDLL</filename>.
</para>
<para>
This chapter is made of two types of material (depending of their point of
view). Some items will be tackled from a global point of view and then,
when needed, explaining the split of work between
- <filename>NTDLL</filename> and <filename>KERNEL32</filename>; some others
- will be tackled from a DLL point of view (<filename>NTDLL</filename> or
- <filename>KERNEL32</filename>). The choice is made so that the output is
+ <filename class="libraryfile">NTDLL</filename> and <filename
+ class="libraryfile">KERNEL32</filename>; some others will be tackled from a DLL point of view
+ (<filename class="libraryfile">NTDLL</filename> or <filename
+ class="libraryfile">KERNEL32</filename>). The choice is made so that the output is
more readable and understandable. At least, that's the intent (sigh).
</para>
@@ -27,8 +28,9 @@
<emphasis>not</emphasis> in fact at the <function>main()</function>
function but instead at some of the more straightforward DLLs that
exist on the periphery such as MSI, the widget library (in
- <filename>USER</filename> and <filename>COMCTL32</filename>) etc. The
- purpose of this section is to document and explain how Wine starts up
+ <filename class="libraryfile">USER</filename> and <filename
+ class="libraryfile">COMCTL32</filename>) etc. The purpose of this section is to document and
+ explain how Wine starts up
from the moment the user runs <userinput>wine
<replaceable>myprogram.exe</replaceable></userinput> to the point at which
<replaceable>myprogram</replaceable> gets control.
@@ -111,16 +113,16 @@
<para>
The process of starting up the emulator itself is mostly one of
chaining through various initializer functions defined in the core
- libraries and DLLs: <filename>libwine</filename>, then
- <filename>NTDLL</filename>, then <filename>KERNEL32</filename>.
- </para>
+ libraries and DLLs: <filename class="libraryfile">libwine</filename>, then
+ <filename class="libraryfile">NTDLL</filename>, then <filename
+ class="libraryfile">KERNEL32</filename>. </para>
<para>
The <command>wine</command> binary has a <function>main()</function>
function, defined in <filename>loader/main.c</filename>, so after the
preloader has run we start here. This passes the
information provided by the preloader into
- <filename>libwine</filename> and then calls
+ <filename class="libraryfile">libwine</filename> and then calls
<function>wine_init()</function>, defined in
<filename>libs/wine/loader.c</filename>. This is where the emulation
really starts:
@@ -132,7 +134,7 @@
<function>wine_init()</function> does some very basic setup tasks such
as initializing the debugging infrastructure, yet more address space
manipulation (see the information on the 4G/4G VM split in the address
- space chapter), before loading <filename>NTDLL</filename> - the core
+ space chapter), before loading <filename class="libraryfile">NTDLL</filename> - the core
of both Wine and the Windows NT series - and jumping to the
<function>__wine_process_init()</function> function defined
in <filename>dlls/ntdll/loader.c</filename>
@@ -150,9 +152,9 @@
<para>
Finally, it loads and jumps to
<function>__wine_kernel_init()</function> in
- <filename>KERNEL32.DLL</filename>: this is defined in
+ <filename class="libraryfile">KERNEL32.DLL</filename>: this is defined in
<filename>dlls/kernel32/process.c</filename>. This is where the bulk
- of the work is done. The <filename>KERNEL32</filename> initialization
+ of the work is done. The <filename class="libraryfile">KERNEL32</filename> initialization
code retrieves the startup info for the process from the server,
initializes the registry, sets up the drive mapping system and locale
data, then begins loading the requested application itself. Each
@@ -306,9 +308,10 @@ ExitProcess( entry( peb ) );
use will be avoided. We later on (re/de)allocate those areas as
needed. One problem is that some of these mappings are put in place
automatically by the dynamic linker: for instance any libraries that
- Wine is linked to (like <filename>libc</filename>,
- <filename>libwine</filename>, <filename>libpthread</filename> etc)
- will be mapped into memory before Wine even gets control. In order to
+ Wine is linked to (like <filename class="libraryfile">libc</filename>,
+ <filename class="libraryfile">libwine</filename>, <filename
+ class="libraryfile">libpthread</filename> etc) will be mapped into memory before Wine even
+ gets control. In order to
solve that, Wine overrides the default ELF initialization sequence at
a low level and reserves the needed areas by using direct syscalls
into the kernel (i.e. without linking against any other code to do it)
@@ -349,9 +352,9 @@ ExitProcess( entry( peb ) );
</para>
<para>
Then Wine graps a few elements from the Unix world: the environment,
- the program arguments. Then the <filename>ntdll.dll.so</filename> is
+ the program arguments. Then the <filename class="libraryfile">ntdll.dll.so</filename> is
loaded into memory using the standard shared library dynamic
- loader. When loaded, <filename>NTDLL</filename> will mainly first
+ loader. When loaded, <filename class="libraryfile">NTDLL</filename> will mainly first
create a decent Windows environment:
<itemizedlist>
<listitem>
@@ -372,7 +375,7 @@ ExitProcess( entry( peb ) );
</itemizedlist>
</para>
<para>
- Then <filename>Kernel32</filename> is loaded (but now using the
+ Then <filename class="libraryfile">Kernel32</filename> is loaded (but now using the
Windows dynamic loading capabilities) and a Wine specific entry point
is called <function>__wine_kernel_init</function>. This function will
actually handle all the logic of the process loading and execution,
@@ -474,7 +477,7 @@ ExitProcess( entry( peb ) );
one, named <filename>foo</filename> will be a symbolic link to the
Wine loader (<command>wine</command>). The second one, named
<filename>foo.exe.so</filename>, is the equivalent of the
- <filename>.dll.so</filename> files we've already described for
+ <filename class="extension">.dll.so</filename> files we've already described for
DLLs. As in Windows, an executable is, among other things, a module
with its import and export information, as any DLL, it makes sense
Wine uses the same mechanisms for loading native executables and
@@ -822,7 +825,7 @@ if (res != ERROR_SUCCESS) return res;
<para>
The code to translate signals into exceptions is a part of
- <filename>NTDLL</filename>, and can be found in
+ <filename class="libraryfile">NTDLL</filename>, and can be found in
<filename>dlls/ntdll/signal_i386.c</filename>. This file sets up
handlers for various signals during Wine startup, and for the ones
that indicate exceptional conditions translates them into
@@ -902,16 +905,16 @@ if (res != ERROR_SUCCESS) return res;
At the beginning was DOS, where each file has to sit on a drive,
called from a single letter. For separating device names from
directory or file names, a ':' was appended to this single letter,
- hence giving the (in)-famous <filename>C:</filename> drive
+ hence giving the (in)-famous <filename class="devicefile">C:</filename> drive
designations. Another great invention was to use some fixed names
for accessing devices: not only where these named fixed, in a way
you couldn't change the name if you'd wish to, but also, they were
insensible to the location where you were using them. For example,
- it's well known that <filename>COM1</filename> designates the first
- serial port, but it's also true that
- <filename>c:\foo\bar\com1</filename> also designates the first
+ it's well known that <filename class="devicefile">COM1</filename> designates the first
+ serial port, but it's also true that <filename
+ class="devicefile">c:\foo\bar\com1</filename> also designates the first
serial port. It's still true today: on XP, you still cannot name a
- file <filename>COM1</filename>, whatever the directory!!!
+ file <literal>COM1</literal>, whatever the directory!!!
</para>
<para>
Well later on (with Windows 95), Microsoft decided to overcome some
@@ -955,7 +958,7 @@ if (res != ERROR_SUCCESS) return res;
<listitem>
<para>
This hierarchy includes several distinct elements. For
- example, <filename>\Device\Hardisk0\Partition0</filename>
+ example, <filename class="devicefile">\Device\Hardisk0\Partition0</filename>
refers to the first partition on the first physical hard disk
of the system.
</para>
@@ -970,7 +973,7 @@ if (res != ERROR_SUCCESS) return res;
<listitem>
<para>
This hierarchy is not directly accessible for the Win32 API,
- but only the <filename>NTDLL</filename> API. The Win32 API
+ but only the <filename class="libraryfile">NTDLL</filename> API. The Win32 API
only allows to manipulate part of this hierarchy (the rest
being hidden from the Win32 API). Of course, the part you see
from Win32 API looks very similar to the one that DOS
@@ -980,10 +983,11 @@ if (res != ERROR_SUCCESS) return res;
<listitem>
<para>
Mounting a disk is performed by creating a symbol link in this
- hierarchy from <filename>\Global??\C:</filename> (the name
+ hierarchy from <filename class="devicefile">\Global??\C:</filename> (the name
seen from the Win32 API) to
- <filename>\Device\Harddiskvolume1</filename> which determines
- the partition on a physical disk where C: is going to be seen.
+ <filename class="devicefile">\Device\Harddiskvolume1</filename> which determines
+ the partition on a physical disk where <filename class="devicefile">C:</filename>
+ is going to be seen.
</para>
</listitem>
<listitem>
@@ -1041,7 +1045,7 @@ if (res != ERROR_SUCCESS) return res;
<listitem>
<para>
<filename>c:bar</filename> is a drive relative path. Note
- that the case where <filename>c:</filename> is the drive of
+ that the case where <filename class="devicefile">c:</filename> is the drive of
the current directory is rather easy; it's implemented the
same way as the case just below (relative path). In the rest
of this chapter, drive relative path will only cover the case
@@ -1052,7 +1056,7 @@ if (res != ERROR_SUCCESS) return res;
Windows 9x (as well as on DOS), the system maintains a process
wide set of default directories per drive. Hence, in this
case, it will resolve <filename>c:bar</filename> to the
- default directory on drive <filename>c:</filename> plus file
+ default directory on drive <filename class="devicefile">c:</filename> plus file
<filename>bar</filename>. Of course, the default per drive
directory is updated each time a new current directory is set
(only the current directory of the drive specified is
@@ -1067,7 +1071,7 @@ if (res != ERROR_SUCCESS) return res;
<itemizedlist>
<listitem>
<para>
- If <filename>c:</filename> is the drive of the default
+ If <filename class="devicefile">c:</filename> is the drive of the default
directory, the final path is the current directory plus
<filename>bar</filename>.
</para>
@@ -1085,7 +1089,7 @@ if (res != ERROR_SUCCESS) return res;
complexity on the second case. If the
<envar>=C:</envar> environment variable is defined, then
it's value is used as a default directory for drive
- <filename>C:</filename>. This is handy, for example,
+ <filename class="devicefile">C:</filename>. This is handy, for example,
when writing a DOS shell, where having a current drive
per drive is still implemented, even on NT. This
mechanism (through environment variables) is implemented
@@ -1095,8 +1099,8 @@ if (res != ERROR_SUCCESS) return res;
inherited at process creation, the current directories
settings are inherited by child processes, hence
mimicking the behavior of the old DOS shell. There's no
- mechanism (in <filename>NTDLL</filename> or
- <filename>KERNEL32</filename>) to set up, when current
+ mechanism (in <filename class="libraryfile">NTDLL</filename> or
+ <filename class="libraryfile">KERNEL32</filename>) to set up, when current
directory changes, the relevant environment variables.
This behavior is clearly band-aid, not a full featured
extension of current directory behavior.
@@ -1116,16 +1120,16 @@ if (res != ERROR_SUCCESS) return res;
</listitem>
<listitem>
<para>
- <filename>\\.\<replaceable>device</replaceable></filename> denotes a physical
- device installed in the system (as seen from the Win32 subsystem). A
- standard NT system will map it to the
- <filename>\??\<replaceable>device</replaceable></filename> NT path. Then, as a
- standard configuration,
- <filename>\??\<replaceable>device</replaceable></filename> is likely to be a
- link to in a physical device described and hooked into the
- <filename>\Device\</filename> tree. For example,
- <filename>COM1</filename> is a link to
- <filename>\Device\Serial0</filename>.
+ <filename class="devicefile">\\.\<replaceable>device</replaceable></filename>
+ denotes a physical device installed in the system (as seen from the Win32
+ subsystem). A standard NT system will map it to the
+ <filename class="devicefile">\??\<replaceable>device</replaceable></filename> NT
+ path. Then, as a standard configuration,
+ <filename class="devicefile">\??\<replaceable>device</replaceable></filename> is
+ likely to be a link to in a physical device described and hooked into the
+ <filename class="devicefile">\Device\</filename> tree. For example,
+ <filename class="devicefile">COM1</filename> is a link to
+ <filename class="devicefile">\Device\Serial0</filename>.
</para>
</listitem>
<listitem>
@@ -1168,7 +1172,7 @@ if (res != ERROR_SUCCESS) return res;
<entry><filename>\Global??\J:\foo\bar.txt</filename></entry>
<entry>
Simple concatenation using the drive of the default
- directory (here J:)
+ directory (here <filename class="devicefile">J:</filename>)
</entry>
</row>
<row>
@@ -1218,8 +1222,8 @@ if (res != ERROR_SUCCESS) return res;
<listitem>
<para>
On Windows 9x (and DOS),
- <filename class="directory">\toto</filename> is the default
- directory on drive <filename>J:</filename>.
+ <filename class="directory">\toto</filename> is the default
+ directory on drive <filename class="devicefile">J:</filename>.
</para>
</listitem>
<listitem>
@@ -1301,8 +1305,8 @@ if (res != ERROR_SUCCESS) return res;
The Wine configuration process is responsible for setting
<filename>$(WINEPREFIX)/dosdevices/c:</filename> to be a symbolic
link pointing to the directory in Unix hierarchy the user wants to
- expose as the <filename>C:</filename> drive in the DOS forest of
- drives.
+ expose as the <filename class="devicefile">C:</filename> drive in the DOS forest of
+ drives.
</para>
<para>
This scheme allows:
@@ -1334,8 +1338,8 @@ if (res != ERROR_SUCCESS) return res;
<filename>\\<replaceable>host</replaceable>\<replaceable>share</replaceable>\foo\bar\MyRemoteFile.txt</filename>
into
<filename>$(WINEPREFIX)/dosdevices/unc/<replaceable>host</replaceable>/<replaceable>share</replaceable>/foo/bar/MyRemoteFile.txt</filename>.
- It's then up to the user to decide where
-<filename>$(WINEPREFIX)/dosdevices/unc/<replaceable>host</replaceable>/<replaceable>share</replaceable></filename>
+ It's then up to the user to decide where <filename
+ class="directory">$(WINEPREFIX)/dosdevices/unc/<replaceable>host</replaceable>/<replaceable>share</replaceable></filename>
shall point to (or be). For example, it can either be a symbolic link to a
directory inside the local machine (just for emulation purpose), or
a symbolic link to the mount point of a remote disk (done through
@@ -1516,7 +1520,7 @@ if (res != ERROR_SUCCESS) return res;
from the command line, and one doesn't need to convert the path into
the Windows form. However, Wine checks that the Unix path given can
be accessed from one of the defined drives, insuring that only part
- of the Unix <filename>/</filename> hierarchy can be accessed.
+ of the Unix <filename class="devicefile">/</filename> hierarchy can be accessed.
</para>
<para>
As a side note, as Unix doesn't widely provide a Unicode interface
@@ -1723,28 +1727,30 @@ if (res != ERROR_SUCCESS) return res;
<para>
Firstly, Wine implements the Win32 to NT mapping as described above,
hence every device path (in NT sense) is of the following form:
- <filename>/??/<replaceable>devicename</replaceable></filename> (or
- <filename>/DosDevices/<replaceable>devicename</replaceable></filename>). As Windows
- device names are case insensitive, Wine also converts them to lower case
+ <filename class="devicefile">/??/<replaceable>devicename</replaceable></filename> (or
+ <filename
+ class="devicefile">/DosDevices/<replaceable>devicename</replaceable></filename>). As
+ Windows device names are case insensitive, Wine also converts them to lower case
before any operation. Then, the first operation Wine tries is to
check whether
- <filename>$(WINEPREFIX)/dosdevices/<replaceable>devicename</replaceable></filename>
+ <filename
+ class="devicefile">$(WINEPREFIX)/dosdevices/<replaceable>devicename</replaceable></filename>
exists. If so, it's used as the final Unix path for the device. The
configuration process is in charge of creating for example, a
symbolic link between
- <filename>$(WINEPREFIX)/dosdevices/PhysicalDrive0</filename> and
- <filename>/dev/hda0</filename>. If such a link cannot be found, and
+ <filename class="devicefile">$(WINEPREFIX)/dosdevices/PhysicalDrive0</filename> and
+ <filename class="devicefile">/dev/hda0</filename>. If such a link cannot be found, and
the device name looks like a DOS disk name (like
- <filename>C:</filename>), Wine first tries to get the Unix device
- from the path <filename>$(WINEPREFIX)/dosdevices/c:</filename>
+ <filename class="devicefile">C:</filename>), Wine first tries to get the Unix device
+ from the path <filename class="devicefile">$(WINEPREFIX)/dosdevices/c:</filename>
(i.e. the device which is mounted on the target of the symbol link);
if this doesn't give a Unix device, Wine checks whether
- <filename>$(WINEPREFIX)/dosdevices/c::</filename> exists. If so,
+ <filename class="devicefile">$(WINEPREFIX)/dosdevices/c::</filename> exists. If so,
it's assumed to be a link to the actual Unix device. For example,
- for a CD Rom, <filename>$(WINEPREFIX)/dosdevices/e::</filename>
- would be a symbolic link to <filename>/dev/cdrom</filename>. If
+ for a CD Rom, <filename class="devicefile">$(WINEPREFIX)/dosdevices/e::</filename>
+ would be a symbolic link to <filename class="devicefile">/dev/cdrom</filename>. If
this doesn't exist (we're still handling a device name of the
- <filename>C:</filename> form), Wine tries to get the Unix device
+ <filename class="devicefile">C:</filename> form), Wine tries to get the Unix device
from the system information (<filename>/etc/mtab</filename> and
<filename>/etc/fstab</filename> on Linux). We cannot apply this
method in all the cases, because we have no insurance that the
@@ -1752,17 +1758,17 @@ if (res != ERROR_SUCCESS) return res;
Rom which he/she want only to use as audio CD player (i.e. never
mounted), thus not having any information of the device itself. If
all of this doesn't work either, some basic operations are checked:
- if the devicename is <filename>NUL</filename>, then
- <filename>/dev/null</filename> is returned. If the device name is a
- default serial name (<filename>COM1</filename> up to
- <filename>COM9</filename>) (resp. printer name
- <filename>LPT1</filename> up to <filename>LPT9</filename>), then
- Wine tries to open the Nth serial (resp. printer) in the system.
- Otherwise, some basic old DOS name support is done
- <filename>AUX</filename> is transformed into
- <filename>COM1</filename> and <filename>PRN</filename> into
- <filename>LPT1</filename>), and the whole process is retried with
- those new names.
+ if the devicename is <filename class="devicefile">NUL</filename>, then
+ <filename class="devicefile">/dev/null</filename> is returned. If the device name is a
+ default serial name (<filename class="devicefile">COM1</filename> up to
+ <filename class="devicefile">COM9</filename>) (resp. printer name
+ <filename class="devicefile">LPT1</filename> up to <filename
+ class="devicefile">LPT9</filename>), then Wine tries to open the Nth serial (resp.
+ printer) in the system. Otherwise, some basic old DOS name support is done
+ <filename class="devicefile">AUX</filename> is transformed into
+ <filename class="devicefile">COM1</filename> and <filename
+ class="devicefile">PRN</filename> into <filename class="devicefile">LPT1</filename>),
+ and the whole process is retried with those new names.
</para>
<para>
To sum up:
@@ -1780,59 +1786,59 @@ if (res != ERROR_SUCCESS) return res;
</thead>
<tbody>
<row>
- <entry><filename><replaceable>any_path</replaceable>AUX</filename></entry>
- <entry><filename>\Global??\AUX</filename></entry>
+ <entry><filename class="devicefile"><replaceable>any_path</replaceable>AUX</filename></entry>
+ <entry><filename class="devicefile">\Global??\AUX</filename></entry>
<entry>
- Treated as an alias to <filename>COM1</filename>
+ Treated as an alias to <filename class="devicefile">COM1</filename>
</entry>
</row>
<row>
- <entry><filename><replaceable>any_path</replaceable>PRN</filename></entry>
- <entry><filename>\Global??\PRN</filename></entry>
- <entry>Treated as an alias to <filename>LPT1</filename></entry>
+ <entry><filename class="devicefile"><replaceable>any_path</replaceable>PRN</filename></entry>
+ <entry><filename class="devicefile">\Global??\PRN</filename></entry>
+ <entry>Treated as an alias to <filename class="devicefile">LPT1</filename></entry>
</row>
<row>
- <entry><filename><replaceable>any_path</replaceable>COM<replaceable>N</replaceable></filename></entry>
- <entry><filename>\Global??\COM<replaceable>N</replaceable></filename></entry>
+ <entry><filename class="devicefile"><replaceable>any_path</replaceable>COM<replaceable>N</replaceable></filename></entry>
+ <entry><filename class="devicefile">\Global??\COM<replaceable>N</replaceable></filename></entry>
<entry>
- <filename>$(WINEPREFIX)/dosdevices/com<replaceable>N</replaceable></filename>
+ <filename class="devicefile">$(WINEPREFIX)/dosdevices/com<replaceable>N</replaceable></filename>
(if the symbol link exists) or the <replaceable>N</replaceable>th serial
line in the system (on Linux,
- <filename>/dev/ttyS<replaceable>N-1</replaceable></filename>).
+ <filename class="devicefile">/dev/ttyS<replaceable>N-1</replaceable></filename>).
</entry>
</row>
<row>
- <entry><filename><replaceable>any_path</replaceable>LPT<replaceable>N</replaceable></filename></entry>
- <entry><filename>\Global??\LPT<replaceable>N</replaceable></filename></entry>
+ <entry><filename class="devicefile"><replaceable>any_path</replaceable>LPT<replaceable>N</replaceable></filename></entry>
+ <entry><filename class="devicefile">\Global??\LPT<replaceable>N</replaceable></filename></entry>
<entry>
- <filename>$(WINEPREFIX)/dosdevices/lpt<replaceable>N</replaceable></filename>
+ <filename class="devicefile">$(WINEPREFIX)/dosdevices/lpt<replaceable>N</replaceable></filename>
(if the symbol link exists) or the <replaceable>N</replaceable>th printer
in the system (on Linux,
- <filename>/dev/lp<replaceable>N-1</replaceable></filename>).
+ <filename class="devicefile">/dev/lp<replaceable>N-1</replaceable></filename>).
</entry>
</row>
<row>
- <entry><filename><replaceable>any_path</replaceable>NUL</filename></entry>
- <entry><filename>\Global??\NUL</filename></entry>
- <entry><filename>/dev/null</filename></entry>
+ <entry><filename class="devicefile"><replaceable>any_path</replaceable>NUL</filename></entry>
+ <entry><filename class="devicefile">\Global??\NUL</filename></entry>
+ <entry><filename class="devicefile">/dev/null</filename></entry>
</row>
<row>
- <entry><filename>\\.\E:</filename></entry>
- <entry><filename>\Global??\E:</filename></entry>
+ <entry><filename class="devicefile">\\.\E:</filename></entry>
+ <entry><filename class="devicefile">\Global??\E:</filename></entry>
<entry>
- <filename>$(WINEPREFIX)/dosdevices/e::</filename> (if the
+ <filename class="devicefile">$(WINEPREFIX)/dosdevices/e::</filename> (if the
symbolic link exists) or guessing the device from
<filename>/etc/mtab</filename> or
<filename>/etc/fstab</filename>.
</entry>
</row>
<row>
- <entry><filename>\\.\<replaceable>device_name</replaceable></filename></entry>
+ <entry><filename class="devicefile">\\.\<replaceable>device_name</replaceable></filename></entry>
<entry>
- <filename>\Global??\<replaceable>device_name</replaceable></filename>
+ <filename class="devicefile">\Global??\<replaceable>device_name</replaceable></filename>
</entry>
<entry>
- <filename>$(WINEPREFIX)/dosdevices/<replaceable>device_name</replaceable></filename>
+ <filename class="devicefile">$(WINEPREFIX)/dosdevices/<replaceable>device_name</replaceable></filename>
(if the symbol link exists).
</entry>
</row>
@@ -1903,28 +1909,28 @@ if (res != ERROR_SUCCESS) return res;
</sect2>
</sect1>
<sect1 id="ntdll">
- <title><filename>NTDLL</filename> module</title>
+ <title><filename class="libraryfile">NTDLL</filename> module</title>
<para>
- <filename>NTDLL</filename> provides most of the services you'd expect
- from a kernel. In lots of cases, <filename>KERNEL32</filename> APIs are
- just wrappers to <filename>NTDLL</filename> APIs. There are however,
- some difference in the APIs (the <filename>NTDLL</filename> ones have
+ <filename class="libraryfile">NTDLL</filename> provides most of the services you'd expect
+ from a kernel. In lots of cases, <filename class="libraryfile">KERNEL32</filename> APIs are
+ just wrappers to <filename class="libraryfile">NTDLL</filename> APIs. There are however,
+ some difference in the APIs (the <filename class="libraryfile">NTDLL</filename> ones have
quite often a bit wider semantics than their
- <filename>KERNEL32</filename> counterparts). All the detailed functions
+ <filename class="libraryfile">KERNEL32</filename> counterparts). All the detailed functions
we've described since the beginning of this chapter are in fact
- implemented in <filename>NTDLL</filename>, plus a great numbers of
+ implemented in <filename class="libraryfile">NTDLL</filename>, plus a great numbers of
others we haven't written about yet.
</para>
</sect1>
<sect1>
- <title><filename>KERNEL32</filename> Module</title>
+ <title><filename class="libraryfile">KERNEL32</filename> Module</title>
<para>
- As already explained, <filename>KERNEL32</filename> maps quite a few of
- its APIs to <filename>NTDLL</filename>. There are however a couple of
+ As already explained, <filename class="libraryfile">KERNEL32</filename> maps quite a few of
+ its APIs to <filename class="libraryfile">NTDLL</filename>. There are however a couple of
things which are handled directly in
- <filename>KERNEL32</filename>. Let's cover a few of them...
+ <filename class="libraryfile">KERNEL32</filename>. Let's cover a few of them...
</para>
<sect2 id="consoles">
<title>Console</title>
@@ -2046,8 +2052,9 @@ if (res != ERROR_SUCCESS) return res;
</entry>
<entry>
Fully supported (each new console creation will be handled
- by the creation of a new <filename>USER32</filename> window)
- </entry>
+ by the creation of a new <filename class="libraryfile">USER32</filename>
+ window)
+ </entry>
<entry>
Fully supported, except for the creation of a new console,
which will be rendered on the same Unix terminal as the
@@ -2135,7 +2142,7 @@ if (res != ERROR_SUCCESS) return res;
<function>AllocConsole()</function>, Wine then launches
<command>wineconsole</command>, and attaches the current
program to this console. In this mode, the
- <filename>USER32</filename> mode is always selected as Wine
+ <filename class="libraryfile">USER32</filename> mode is always selected as Wine
cannot tell the current state of the Unix console.
</para>
</listitem>
@@ -2146,27 +2153,27 @@ if (res != ERROR_SUCCESS) return res;
<constant>CREATE_NEW_CONSOLE</constant> flag, will end-up calling
<function>AllocConsole()</function> in the child process, hence
creating a <command>wineconsole</command> with the
- <filename>USER32</filename> backend.
+ <filename class="libraryfile">USER32</filename> backend.
</para>
<para>
Another interesting point to note is that Windows implements handles
to console objects (input and screen buffers) only in the
- <filename>KERNEL32</filename> DLL, and those are not sent nor seen
- from the <filename>NTDLL</filename> level, albeit, for example,
+ <filename class="libraryfile">KERNEL32</filename> DLL, and those are not sent nor seen
+ from the <filename class="libraryfile">NTDLL</filename> level, albeit, for example,
console are waitable on input. How is this possible? Well, Windows
NT is a bit tricky here. Regular handles have an interesting
property: their integral value is always a multiple of four (they
are likely to be offsets from the beginning of a table). Console
handles, on the other hand, are not multiple of four, but have the
two lower bit set (being a multiple of four means having the two
- lower bits reset). When <filename>KERNEL32</filename> sees a handle
+ lower bits reset). When <filename class="libraryfile">KERNEL32</filename> sees a handle
with the two lower bits set, it then knows it's a console handle and
takes appropriate decisions. For example, in the various
<function>kernel32!WaitFor*()</function> functions, it transforms
any console handle (input and <emphasis>output</emphasis> -
strangely enough handles to console screen buffers are waitable)
into a dedicated wait event for the targetted console. There's an
- (undocumented) <filename>KERNEL32</filename> function
+ (undocumented) <filename class="libraryfile">KERNEL32</filename> function
<function>GetConsoleInputWaitHandle()</function> which returns the
handle to this event in case you need it. Another interesting
handling of those console handles is in
@@ -2368,7 +2375,7 @@ if (res != ERROR_SUCCESS) return res;
<command>winevdm</command> as a Win32
thread. <command>winevdm</command> then implements its own
scheduling facilities (in fact, the code for this feature is in the
- <filename>krnl386.exe</filename> DLL). Since the required Win16
+ <filename class="libraryfile">krnl386.exe</filename> DLL). Since the required Win16
scheduling is non pre-emptive, this doesn't require any underlying
OS kernel support.
</para>
@@ -2440,19 +2447,20 @@ if (res != ERROR_SUCCESS) return res;
</para>
<para>
Wine implements also most of the DOS support in a Wine specific DLL
- (<filename>winedos</filename>). This DLL is called under certain
+ (<filename class="libraryfile">winedos</filename>). This DLL is called under certain
conditions, like:
<itemizedlist>
<listitem>
<para>
In <command>winevdm</command>, when trying to launch a DOS
- application (<filename>.EXE</filename> or
- <filename>.COM</filename>, <filename>.PIF</filename>).
- </para>
+ application (<filename class="extension">.EXE</filename> or
+ <filename class="extension">.COM</filename>, <filename
+ class="extension">.PIF</filename>).
+ </para>
</listitem>
<listitem>
<para>
- In <filename>kernel32</filename>, when an attempt is made in the
+ In <filename class="libraryfile">kernel32</filename>, when an attempt is made in the
binary code to call some DOS or BIOS interrupts (like Int 21h
for example).
</para>
diff --git a/en/winedev-multimedia.sgml b/en/winedev-multimedia.sgml
index 5282cad..4cb277c 100644
--- a/en/winedev-multimedia.sgml
+++ b/en/winedev-multimedia.sgml
@@ -35,11 +35,12 @@
<title>Overview</title>
<para>
- The multimedia stuff is split into 3 layers:
<itemizedlist>
<listitem>
<para>
- the high level abstraction layer: mmdevapi, dsound and winmm DLLs.
+ the high level abstraction layer: <filename class="libraryfile">mmdevapi</filename>,
+ <filename class="libraryfile">dsound</filename> and <filename
+ class="libraryfile">winmm</filename> DLLs.
</para>
</listitem>
<listitem>
@@ -50,10 +51,13 @@
</listitem>
<listitem>
<para>
- the low level layer: device drivers, currently implemented in winealsa.drv,
- winecoreaudio.drv, and wineoss.drv DLLs. It also has some helper DLLs (like msacm32
- and msvfw32), which can make use of external DLLs like mciavi32 or
- application-provided DLLs.
+ the low level layer: device drivers, currently implemented in
+ <filename class="libraryfile">winealsa.drv</filename>,
+ <filename class="libraryfile">winecoreaudio.drv</filename>, and
+ <filename class="libraryfile">wineoss.drv</filename> DLLs. It also has some helper
+ DLLs (like <filename class="libraryfile">msacm32</filename> and <filename
+ class="libraryfile">msvfw32</filename>), which can make use of external DLLs like
+ <filename class="libraryfile">mciavi32</filename> or application-provided DLLs.
</para>
</listitem>
</itemizedlist>
@@ -66,8 +70,10 @@
</para>
<para>
- The dsound and winmm legacy APIs are implemented on top of mmdevapi, the new Windows audio
- system introduced with Windows Vista (Multimedia Device API).
+ The <filename class="libraryfile">dsound</filename> and
+ <filename class="libraryfile">winmm</filename> legacy APIs are implemented on top of
+ <filename class="libraryfile">mmdevapi</filename>, the new Windows audio system introduced
+ with Windows Vista (Multimedia Device API).
</para>
</sect1>
@@ -254,7 +260,7 @@ Kernel space | Client applications
<para>
The low level drivers abstract the hardware specific features
from the rest of the multimedia code. Those are implemented on top
- of mmdevapi, as new versions of windows do.
+ of <filename class="libraryfile">mmdevapi</filename>, as new versions of Windows do.
</para>
<para>
@@ -264,9 +270,10 @@ Kernel space | Client applications
</para>
<para>
- There are two specific low level drivers (msacm32.drv for wave input/output,
- midimap.drv for MIDI output only). These drivers (also present
- in Windows):
+ There are two specific low level drivers (<filename
+ class="libraryfile">msacm32.drv</filename> for wave input/output, <filename
+ class="libraryfile">midimap.drv</filename> for MIDI output only). These drivers (also
+ present in Windows):
<itemizedlist>
<listitem>
<para>
@@ -305,8 +312,8 @@ 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
- <filename><sys/soundcard.h></filename> file). Source code resides in
- <filename>dlls/wineoss.drv</filename>.
+ <filename class="headerfile"><sys/soundcard.h></filename> file). Source code
+ resides in <filename class="libraryfile">dlls/wineoss.drv</filename>.
</para>
</listitem>
<listitem>
@@ -314,13 +321,13 @@ Kernel space | Client applications
Advanced Linux Sound Architecture (<ulink
url="http://www.alsa-project.org/">ALSA</ulink>) as
supplied in the Linux kernel. Source code resides in
- <filename>dlls/winealsa.drv</filename>.
+ <filename class="libraryfile">dlls/winealsa.drv</filename>.
</para>
</listitem>
<listitem>
<para>
Core Audio as introduced in Mac OS X 10.3. Source code resides in
- <filename>dlls/winecoreaudio.drv</filename>.
+ <filename class="libraryfile">dlls/winecoreaudio.drv</filename>.
</para>
</listitem>
</itemizedlist>
@@ -329,19 +336,20 @@ Kernel space | Client applications
</sect2>
<sect2>
- <title>Wave mapper (msacm32.drv)</title>
+ <title>Wave mapper (<filename class="libraryfile">msacm32.drv</filename>)</title>
<para>
The Wave mapper device allows to load on-demand audio codecs
in order to perform software conversion for the types the
actual low level driver (hardware). Those codecs are
- provided through the standard ACM drivers in msacm32 DLL.
+ provided through the standard ACM drivers in <filename
+ class="libraryfile">msacm32</filename> DLL.
</para>
<para>
Wave mapper driver implementation can be found in
<filename class="directory">dlls/msacm32.drv</filename> directory. This
- driver heavily relies on msacm DLL found in
+ driver heavily relies on <filename class="libraryfile">msacm</filename> DLL found in
<filename class="directory">dlls/msacm32</filename>.
This DLL loads ACM
drivers which provide the conversion to PCM format (which is
@@ -352,7 +360,7 @@ Kernel space | Client applications
</sect2>
<sect2>
- <title>MIDI mapper (midimap)</title>
+ <title>MIDI mapper (<filename class="libraryfile">midimap</filename>)</title>
<para>
Midi mapper allows to map each one of 16 MIDI channels to a
@@ -401,17 +409,17 @@ Kernel space | Client applications
<tbody>
<row>
<entry>CdAudio</entry>
- <entry>mcicda</entry>
+ <entry><filename class="libraryfile">mcicda</filename></entry>
<entry>MCI interface to a CD audio player</entry>
<entry><filename class="directory">dlls/mcicda</filename></entry>
<entry>
- Relies on NTDLL CdRom raw interface (through
- <function>DeviceIoControl</function>).
+ Relies on <filename class="libraryfile">NTDLL</filename> CD-ROM raw interface
+ (through <function>DeviceIoControl</function>).
</entry>
</row>
<row>
<entry>WaveAudio</entry>
- <entry>mciwave</entry>
+ <entry><filename class="libraryfile">mciwave</filename></entry>
<entry>
MCI interface for wave playback and record
</entry>
@@ -420,18 +428,18 @@ Kernel space | Client applications
</row>
<row>
<entry>Sequencer</entry>
- <entry>mciseq</entry>
+ <entry><filename class="libraryfile">mciseq</filename></entry>
<entry>Midi Sequencer (playback)</entry>
<entry><filename class="directory">dlls/mciseq</filename></entry>
<entry>It uses the low level midi APIs</entry>
</row>
<row>
<entry>AviVideo</entry>
- <entry>mciavi32</entry>
+ <entry><filename class="libraryfile">mciavi32</filename></entry>
<entry>AVI playback and record</entry>
<entry><filename class="directory">dlls/mciavi32</filename></entry>
<entry>
- It rather heavily relies on msvfw32 DLL to work.
+ It rather heavily relies on <filename class="libraryfile">msvfw32</filename> DLL to work.
</entry>
</row>
</tbody>
@@ -460,10 +468,11 @@ Kernel space | Client applications
<title>High level layers</title>
<sect2>
- <title>winmm</title>
+ <title><filename class="libraryfile">winmm</filename></title>
<para>
- The high level layers encompass basically the winmm
+ The high level layers encompass basically the <filename
+ class="libraryfile">winmm</filename>
DLL exported APIs. It also provides the skeleton for
the core functionality for multimedia playback and
recording. Note that native WINMM and MMSYSTEM do not
@@ -473,11 +482,13 @@ Kernel space | Client applications
</para>
<para>
- winmm and mmsystem.dll16 in Wine can handle both 32- and 16-bit
+ <filename class="libraryfile">winmm</filename> and <filename
+ class="libraryfile">mmsystem.dll16</filename> in Wine can handle both 32- and 16-bit
drivers (for low level and MCI drivers). Wine will handle all
- the conversions transparently for all the calls to winmm
- and mmsystem.dll16, as it knows what the driver interface is (32-
- or 16-bit) and it manages the information sent accordingly.
+ the conversions transparently for all the calls to <filename
+ class="libraryfile">winmm</filename> and <filename
+ class="libraryfile">mmsystem.dll16</filename>, as it knows what the driver interface is
+ (32- or 16-bit) and it manages the information sent accordingly.
</para>
<para>
@@ -497,11 +508,11 @@ Kernel space | Client applications
</sect2>
<sect2>
- <title>DSOUND</title>
+ <title><filename class="libraryfile">dsound</filename></title>
<para>
- Wine also provide a DSound (DirectX) DLL with the proper
- COM implementation.
+ Wine also provide a <filename class="libraryfile">dsound</filename> (DirectX) DLL with the
+ proper COM implementation.
</para>
</sect2>
@@ -515,7 +526,7 @@ Kernel space | Client applications
<title>Contents</title>
<para>
- The msacm32 DLL provides a way to
+ The <filename class="libraryfile">msacm32</filename> DLL provides a way to
map a given wave format to another format. It also provides
filtering capabilities. Those DLLs only implement the proper
switch between a caller and a driver providing the
@@ -538,25 +549,26 @@ Kernel space | Client applications
</thead>
<tbody>
<row>
- <entry>imaadp32</entry>
+ <entry><filename class="libraryfile">imaadp32</filename></entry>
<entry>IMA ADPCM (adaptative PCM)</entry>
</row>
<row>
- <entry>msadp32</entry>
+ <entry><filename class="libraryfile">msadp32</filename></entry>
<entry>Microsoft ADPCM (adaptative PCM)</entry>
</row>
<row>
- <entry>msg711</entry>
+ <entry><filename>msg711</filename></entry>
<entry>Microsoft G.711 (A-Law and μ-Law)</entry>
</row>
<row>
- <entry>msgsm32</entry>
+ <entry><filename class="libraryfile">msgsm32</filename></entry>
<entry>Microsoft GSM 06.10</entry>
</row>
<row>
- <entry>winemp3</entry>
+ <entry><filename class="libraryfile">winemp3</filename></entry>
<entry>
- Wine MP3 (MPEG Layer 3), based on mpglib library
+ Wine MP3 (MPEG Layer 3), based on <filename
+ class="libraryfile">mpglib</filename> library
</entry>
</row>
</tbody>
@@ -579,7 +591,7 @@ Kernel space | Client applications
<title>Caching</title>
<para>
- msacm32 keeps some data cached for all known ACM
+ <filename class="libraryfile">msacm32</filename> keeps some data cached for all known ACM
drivers. Under the key
<screen>
Software\Microsoft\AudioCompressionManager\DriverCache\<replaceable>driver_name</replaceable>
@@ -637,7 +649,7 @@ Kernel space | Client applications
<title>Contents</title>
<para>
- msvfw32 provides
+ <filename class="libraryfile">msvfw32</filename> provides
encode/decode video streams. Those DLLs only implement the
proper switch between a caller and a driver providing the
implementation of the requested format coding/decoding
@@ -659,15 +671,15 @@ Kernel space | Client applications
</thead>
<tbody>
<row>
- <entry>msrle32</entry>
+ <entry><filename class="libraryfile">msrle32</filename></entry>
<entry>Microsoft RLE (Run-Length encoded)</entry>
</row>
<row>
- <entry>msvidc32</entry>
+ <entry><filename class="libraryfile">msvidc32</filename></entry>
<entry>Microsoft Video-1</entry>
</row>
<row>
- <entry>iccvid</entry>
+ <entry><filename class="libraryfile">iccvid</filename></entry>
<entry>Radius Cinepak Video Decoder</entry>
</row>
</tbody>
@@ -929,7 +941,7 @@ HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\MediaProperties\PrivatePrope
<screen>
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\Midi\Ports\<replaceable>driver_name</replaceable>
</screen>
- a link to and <filename>.IDF</filename> file which allows
+ a link to and <filename class="extension">.IDF</filename> file which allows
to remap channels internally (for example 9 -> 16), to
change instruments identification, event controllers
values. See <filename>dlls/midimap/midimap.c</filename> for the
diff --git a/en/winedev-ole.sgml b/en/winedev-ole.sgml
index ef59f29..4e0bfde 100644
--- a/en/winedev-ole.sgml
+++ b/en/winedev-ole.sgml
@@ -458,7 +458,7 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
The tricky part is exactly how to encode those parameters in the buffer,
and how to convert standard <literal>stdcall</literal>/<literal>cdecl</literal> method
calls to network packets and back again. This is the job of the
- <filename>RPCRT4.DLL</filename> file:
+ <filename class="libraryfile">RPCRT4.DLL</filename> file:
the <firstterm>Remote Procedure Call Runtime</firstterm>.
</para>
@@ -488,7 +488,8 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
currently based on the
RPC runtime, as while few programs use DCOM even fewer use
RPC directly so it was developed some time after
- OLE32/OLEAUT32 were. Eventually this will have to be fixed,
+ <filename class="libraryfile">OLE32</filename>/<filename
+ class="libraryfile">OLEAUT32</filename> were. Eventually this will have to be fixed,
otherwise our DCOM will never be compatible with
Microsoft's. Bear this in mind as you read through the code
however.
@@ -695,7 +696,8 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
RPC methods. For instance, in the case of inter-thread marshalling (not
covered here) the RPC connection code isn't used, only the NDR
marshallers are, so <classname>IRpcChannelBuffer</classname> in that case isn't actually
- implemented by RPCRT4 but rather just by the COM/OLE DLLS.
+ implemented by <filename class="libraryfile">RPCRT4</filename> but rather just by the
+ COM/OLE DLLS.
</para>
<para>
diff --git a/en/winedev-opengl.sgml b/en/winedev-opengl.sgml
index c74cc2c..257a2a4 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 class="headerfile">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 class="headerfile">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 class="headerfile">glext.h</filename></term>
<listitem>
<para>
the list of all registered OpenGL extensions
@@ -55,7 +55,7 @@
</variablelist>
<para>
- The latter file (<filename>glext.h</filename>) is, as of
+ The latter file (<filename class="headerfile">glext.h</filename>) is, as of
now, not necessary to build Wine. But as this file can be
easily obtained from SGI
(<ulink url="http://oss.sgi.com/projects/ogl-sample/ABI/glext.h"></ulink>),
@@ -67,9 +67,8 @@
<title>OpenGL library itself</title>
<para>
- To check for the presence of <quote>libGL</quote> on the system, the
- script checks if it defines the
- <function>glXCreateContext</function> function.
+ To check for the presence of <filename class="libraryfile">libGL</filename> on the system,
+ the script checks if it defines the <function>glXCreateContext</function> function.
</para>
</sect2>
@@ -139,7 +138,7 @@
</listitem>
<listitem>
<para>
- In the <filename>OpenGL32.DLL</filename> itself for all
+ In the <filename class="libraryfile">OpenGL32.DLL</filename> itself for all
other functionalities (context creation / deletion,
querying of extension functions, ...). This is done in
<filename>dlls/opengl32/wgl.c</filename>.
@@ -179,7 +178,7 @@
<para>
<filename>opengl32.spec</filename> gives Wine's linker
the signature of all function in the
- <filename>OpenGL32.DLL</filename> library so that the
+ <filename class="libraryfile">OpenGL32.DLL</filename> library so that the
application can link them. Only 'core' functions are
listed here.
</para>
@@ -262,7 +261,10 @@ Please report (lionel.ulmer at free.fr) !
</sect2>
<sect2>
- <title><filename>opengl32.dll.so</filename> is built but it is still not working</title>
+ <title>
+ <filename class="libraryfile">opengl32.dll.so</filename> is built but it is still not
+ working
+ </title>
<para>
This may be caused by some missing functions required by
@@ -276,7 +278,7 @@ Please report (lionel.ulmer at free.fr) !
<orderedlist>
<listitem>
<para>
- create a dummy <filename>.c</filename> file:
+ create a dummy <filename class="extension">.c</filename> file:
</para>
<programlisting>
int main(void)
diff --git a/en/winedev-otherdebug.sgml b/en/winedev-otherdebug.sgml
index 3bdcb74..c753a8c 100644
--- a/en/winedev-otherdebug.sgml
+++ b/en/winedev-otherdebug.sgml
@@ -67,7 +67,7 @@
The main problem with this scheme is that the function must actually
be called from another program. Many of these functions are seldom
used. An attempt was made to aggressively query each function in a
- given library (<filename>ntdll.dll</filename>) by passing 64 arguments,
+ given library (<filename class="libraryfile">ntdll.dll</filename>) by passing 64 arguments,
all 0, to each function. Unfortunately, Windows NT quickly goes to a
blue screen of death, even if the program is run from a
non-administrator account.
@@ -302,10 +302,10 @@ test_hkey_main_Value_W(name1W, string1W, sizeof(string1W));
in question is run by this test and works as expected. You
should be in the same directory as in the previous command
example. The only difference is that we have to remove the
- <filename>*.gcda</filename> files in order to start
+ <filename class="extension">*.gcda</filename> files in order to start
the count over. (If we leave the files then the number of times
the line is run is just added, e.g. line 545 below would be run
- 19 times.) We remove the <filename>*.gcov</filename> files
+ 19 times.) We remove the <filename class="extension">*.gcov</filename> files
because they are out of date and need to be recreated.
</para>
<screen>
diff --git a/en/winedev-testing.sgml b/en/winedev-testing.sgml
index 9350f00..8d4e1f3 100644
--- a/en/winedev-testing.sgml
+++ b/en/winedev-testing.sgml
@@ -270,10 +270,10 @@
to use the most recent compatible Visual Studio
<ulink url="http://msdn.microsoft.com/vstudio/downloads/updates/sp/">service pack</ulink>.
If are using Visual Studio Express and you need specific libraries like
- <filename>ntdll.lib</filename> that don't ship with Visual Studio Express, you will need the
- <ulink url="http://www.microsoft.com/whdc/devtools/ddk/default.mspx">Windows Driver
-Development Kit (DDK)</ulink>
- which is part of the
+ <filename class="libraryfile">ntdll.lib</filename> that don't ship with Visual Studio
+ Express, you will need the <ulink
+ url="http://www.microsoft.com/whdc/devtools/ddk/default.mspx">Windows Driver Development
+ Kit (DDK)</ulink> which is part of the
<ulink url="http://www.microsoft.com/whdc/resources/downloads.mspx">Windows Developer
Kit</ulink>.
</para></listitem>
@@ -366,9 +366,9 @@ Kit</ulink>.
</para></listitem>
<listitem><para>
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>).
+ directory, and copy the file <filename class="headerfile">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>
Copy some existing test from the Wine source tree, or
@@ -385,7 +385,7 @@ Kit</ulink>.
<listitem><para>
Once that's working, try running the program under Wine without
recompiling it. See? No Wine source required at all,
- save for that one header, <filename>wine/test.h</filename>.
+ save for that one header, <filename class="headerfile">wine/test.h</filename>.
</para></listitem>
<listitem><para>
If you want to use the Microsoft C++ Toolkit under Wine,
@@ -404,8 +404,8 @@ 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 <filename>.c</filename>
- file in the tests directory and add that file to the
+ existing file, then add them to that file. Otherwise create a new <filename
+ class="extension">.c</filename> file in the tests directory and add that file to the
<varname>CTESTS</varname> variable in <filename>Makefile.in</filename>.
</para>
<para>
@@ -434,8 +434,8 @@ START_TEST(paths)
called <filename>paths.c</filename>.
</para>
<para>
- Tests should start by including the <filename>wine/test.h</filename> header.
- This header will provide you access to all the testing framework
+ Tests should start by including the <filename class="headerfile">wine/test.h</filename>
+ header. This header will provide you access to all the testing framework
functions. You can then include the windows header you need, but make
sure to not include any Unix or Wine specific header: tests must
compile on Windows.
@@ -522,8 +522,8 @@ thread.c:123: Test failed: rc=0 error=120 disabled=0
it's a call to <function>GetThreadPriorityBoost</function>, that the test failed not
because the API returned the wrong value, but because it returned an
error code. Furthermore we see that <function>GetLastError()</function> returned
- <errorcode>120</errorcode> which <filename>winerror.h</filename> defines as
- <errorname>ERROR_CALL_NOT_IMPLEMENTED</errorname>. So the source of
+ <errorcode>120</errorcode> which <filename class="headerfile">winerror.h</filename> defines
+ as <errorname>ERROR_CALL_NOT_IMPLEMENTED</errorname>. 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.
diff --git a/en/winedev-windowing.sgml b/en/winedev-windowing.sgml
index 71738bc..d92e434 100644
--- a/en/winedev-windowing.sgml
+++ b/en/winedev-windowing.sgml
@@ -647,7 +647,7 @@ WINEDEBUG=+key,+keyboard wine > key.log 2>&1
<para>
Note that the <constant>LANG_*</constant> and
<constant>SUBLANG_*</constant> definitions are in
- <filename>include/winnls.h</filename>, which you might need
+ <filename class="headerfile">include/winnls.h</filename>, which you might need
to know to find out which numbers your language is assigned,
and find it in the WINEDEBUG output. The numbers will be
<literal>(SUBLANG * 0x400 + LANG)</literal>, so, for example
--
1.8.4
More information about the wine-patches
mailing list