[docs] winelib: Use appropriate values for 'filename' tag attributes.

Frédéric Delanoy frederic.delanoy at gmail.com
Tue Sep 3 14:28:48 CDT 2013


---
 en/winelib-bindlls.sgml | 10 +++++-----
 en/winelib-intro.sgml   | 13 +++++++------
 en/winelib-mfc.sgml     |  2 +-
 en/winelib-porting.sgml | 10 +++++-----
 en/winelib-toolkit.sgml | 34 ++++++++++++++++++----------------
 5 files changed, 36 insertions(+), 33 deletions(-)

diff --git a/en/winelib-bindlls.sgml b/en/winelib-bindlls.sgml
index 3ca663c..3638a0b 100644
--- a/en/winelib-bindlls.sgml
+++ b/en/winelib-bindlls.sgml
@@ -252,9 +252,9 @@ signed short WINAPI MyProxyWinFunc (unsigned short a, void *b, void *c,
         can link to it from a Linux program it should be OK.
       </para>
       <para>
-        Put the proxy shared object (<filename>MyWin.dll.so</filename>) in the same place as the
-        rest of the built-in DLLs.  Alternatively ensure that <envar>WINEDLLPATH</envar>
-        includes the directory containing the proxy shared object.
+        Put the proxy shared object (<filename class="libraryfile">MyWin.dll.so</filename>) in the
+        same place as the rest of the built-in DLLs.  Alternatively ensure that
+        <envar>WINEDLLPATH</envar> includes the directory containing the proxy shared object.
       </para>
       <para>
         If you have both a Windows DLL and a Linux DLL/proxy pair then you will
@@ -278,8 +278,8 @@ signed short WINAPI MyProxyWinFunc (unsigned short a, void *b, void *c,
         Unix equivalent.  Of course there is no suitable function in the true
         Microsoft Windows API, but wine provides a function for just this
         task and exports it from its copy of the kernel32 DLL.  The function
-        is <function>wine_get_unix_file_name</function> (defined in
-        <filename>winbase.h</filename>).
+        is <function>wine_get_unix_file_name</function> (defined in <filename
+        class="headerfile">winbase.h</filename>).
       </para>
     </sect1>
   </chapter>
diff --git a/en/winelib-intro.sgml b/en/winelib-intro.sgml
index 3d95746..d76a52e 100644
--- a/en/winelib-intro.sgml
+++ b/en/winelib-intro.sgml
@@ -88,8 +88,8 @@
           <listitem>
             <para>
               then the case of the filenames in your include statements may be
-              wrong: maybe they include <filename>Windows.h</filename> instead
-              of <filename>windows.h</filename>.
+              wrong: maybe they include <filename class="headerfile">Windows.h</filename>
+              instead of <filename class="headerfile">windows.h</filename>.
             </para>
           </listitem>
           <listitem>
@@ -155,8 +155,8 @@
           notepad source directory if it contains results of previous builds.
           Create a separate directory with name <literal>notepad2</literal>, so it won't conflict
           with the Wine copy of the application. Copy the sources of notepad
-          (<filename>*.c</filename>, <filename>*.h</filename>,
-          and <filename>*.rc</filename> files) to this directory.
+          (<filename class="extension">*.c</filename>, <filename class="extension">*.h</filename>,
+          and <filename class="extension">*.rc</filename> files) to this directory.
           Now run the commands mentioned above from the <filename
           class="directory">notepad2</filename> directory:
         </para>
@@ -217,8 +217,9 @@
                 directory where the sources are. So it's best if you can
                 transfer the source files and either of these directories to
                 Linux. Note that you don't need to transfer the
-                <filename>.obj</filename>, <filename>.pch</filename>, <filename>.sbr</filename>
-                and other files that also reside in
+                <filename class="extension">.obj</filename>, <filename
+                class="extension">.pch</filename>, <filename
+                class="extension">.sbr</filename> and other files that also reside in
                 these directories; especially as they tend to be quite big.
               </para>
             </listitem>
diff --git a/en/winelib-mfc.sgml b/en/winelib-mfc.sgml
index c625b47..d169c21 100644
--- a/en/winelib-mfc.sgml
+++ b/en/winelib-mfc.sgml
@@ -169,7 +169,7 @@
         $(WINE_INCLUDE_ROOT)/msvcrt</parameter>), though it means you
         will have to temporarily disable winsock support
         (<literal>#ifdef</literal> it out in
-        <filename>windows.h</filename>).
+        <filename class="headerfile">windows.h</filename>).
       </para>
       <para>
         You should use <command>g++</command> compiler more recent than 2.95.
diff --git a/en/winelib-porting.sgml b/en/winelib-porting.sgml
index 43f1a7d..d7a6124 100644
--- a/en/winelib-porting.sgml
+++ b/en/winelib-porting.sgml
@@ -76,7 +76,7 @@
       <para>
         Add <option>-mno-cygwin</option> to your compiler flags. This
         will cause <command>winebuild</command> to resolve your C
-        library calls to <filename>msvcrt.dll</filename>. Many simple
+        library calls to <filename class="libraryfile">msvcrt.dll</filename>. Many simple
         calls which behave the same have been specified as
         non-importable from msvcrt; in these cases
         <command>winebuild</command> will not resolve them and the
@@ -100,7 +100,7 @@
       <para>
         To use option 3, add the names of any symbols that you don't
         want to use from msvcrt into your applications
-        <filename>.spec</filename> file. For example, if you wanted
+        <filename class="extension">.spec</filename> file. For example, if you wanted
         the MS specific functions, but not file I/O, you could have a
         list like:
       </para>
@@ -121,9 +121,9 @@
       <para>
         If you get undefined references to Win32 API calls when
         building your application: if you have a VC++
-        <filename>.dsp</filename> file, check it for all the
-        <filename>.lib</filename> files it imports, and add them to
-        your applications <filename>.spec</filename>
+        <filename class="extension">.dsp</filename> file, check it for all the
+        <filename class="extension">.lib</filename> files it imports, and add them to
+        your applications <filename class="extension">.spec</filename>
         file. <command>winebuild</command> gives you a warning for
         unused imports so you can delete the ones you don't need
         later. Failing that, just import all the DLLs you can find in
diff --git a/en/winelib-toolkit.sgml b/en/winelib-toolkit.sgml
index 8180d49..77c5fa4 100644
--- a/en/winelib-toolkit.sgml
+++ b/en/winelib-toolkit.sgml
@@ -8,18 +8,18 @@
         <title id="vc-projects.title">Support for Visual C++ projects</title>
         <para>
           Winemaker supports the Visual C++ project
-          files! Supported filetypes are <filename>.dsp</filename>,
-          <filename>.dsw</filename>, <filename>.vcproj</filename>
-          and <filename>.sln</filename>. It detects the defines to be used,
+          files! Supported filetypes are <filename class="extension">.dsp</filename>,
+          <filename class="extension">.dsw</filename>, <filename class="extension">.vcproj</filename>
+          and <filename class="extension">.sln</filename>. It detects the defines to be used,
           any custom include path, the list of libraries to link with,
           and exactly which source files to use to build a specific target.
         </para>
         <para>
           It is recommended to use Winemaker with a
           project file if available. If you have to choose between a
-          <filename>.dsp</filename> file and a <filename>.vcproj</filename>,
-          then you should use the <filename>.dsp</filename>,
-          because it offers more information.
+          <filename class="extension">.dsp</filename> file and a <filename
+          class="extension">.vcproj</filename>, then you should use the <filename
+          class="extension">.dsp</filename>, because it offers more information.
         </para>
         <para>
           The usage is very easy, just replace the path to the source folder
@@ -61,7 +61,7 @@
         </para>
         <para>
           If it does not find any executable or DLL winemaker will look for 
-          files with a <filename>.mak</filename> extension. If they are not
+          files with a <filename class="extension">.mak</filename> extension. If they are not
           disguised Visual C++ projects (and currently even if they are),
           <command>winemaker</command> will assume that a target by that name should be built
           in this directory. But it will not know whether this target is an 
@@ -109,7 +109,8 @@
         </para>
         <para>
           Finally <command>winemaker</command> also looks for more exotic files
-          like <filename>.h</filename> headers, <filename>.inl</filename> files
+          like <filename class="extension">.h</filename> headers, <filename
+          class="extension">.inl</filename> files
           containing inline functions and a few others. These are not put in 
           the regular source file lists since they are not compiled directly. 
           But it will still remember them so that they are processed
@@ -232,8 +233,9 @@ EXES                  = hello.exe
           This is where the targets for this directory are listed. The names 
           are pretty self-explanatory. <varname>SUBDIRS</varname> is usually 
           only present in the top-level makefile. For libraries and
-          executables, specify the full name, including the <filename>.dll</filename>,
-          <filename>.a</filename> or <filename>.exe</filename>
+          executables, specify the full name, including the <filename
+          class="extension">.dll</filename>, <filename class="extension">.a</filename> or
+          <filename class="extension">.exe</filename>
           extension. Note that these names must be in all lowercase.
         </para>
         <programlisting>
@@ -343,8 +345,8 @@ all: $(SUBDIRS) $(DLLS:%=%.so) $(LIBS) $(EXES)
       <title id="wrc.title">Compiling resource files: <command>wrc</command></title>
       <para>
         To compile resources you should use the Wine Resource Compiler, 
-        <command>wrc</command> for short, which produces a binary
-        <filename>.res</filename> file.
+        <command>wrc</command> for short, which produces a binary <filename
+        class="extension">.res</filename> file.
         This resource file is then used by <command>winebuild</command> when compiling
         the spec file (see <xref linkend="spec-file" endterm="spec-file.title">).
       </para>
@@ -419,7 +421,7 @@ WRCFLAGS      = -r -L
 
       <para>
         Using GIF files in resources is problematic. For best results,
-        convert them to BMP and change your <filename>.res</filename>
+        convert them to BMP and change your <filename class="extension">.res</filename>
         file.
       </para>
       <para>
@@ -716,9 +718,9 @@ ORDINAL extern EXPORTNAME SYMBOLNAME
         To link an executable you need to link together: your object files, 
         any Windows libraries that your application depends
         on, gdi32 for instance, and any additional library that you use. All 
-        the libraries you link with should be available as
-        <filename>.so</filename> libraries.  If one of them is available
-        only in <filename>.dll</filename> form then consult
+        the libraries you link with should be available as <filename
+        class="extension">.so</filename> libraries.  If one of them is available
+        only in <filename class="extension">.dll</filename> form then consult
         <xref linkend="bindlls" endterm="bindlls.title">.
       </para>
       <para>
-- 
1.8.4




More information about the wine-patches mailing list