[docs] winedev: Assorted spelling fixes.
Frédéric Delanoy
frederic.delanoy at gmail.com
Fri Jul 5 03:40:05 CDT 2013
---
en/winedev-architecture.sgml | 46 +++++++--------
en/winedev-coding.sgml | 28 ++++-----
en/winedev-debugger.sgml | 132 +++++++++++++++++++++---------------------
en/winedev-debugging.sgml | 16 ++---
en/winedev-documentation.sgml | 40 ++++++-------
en/winedev-kernel.sgml | 110 +++++++++++++++++------------------
en/winedev-multimedia.sgml | 53 +++++++++--------
en/winedev-ole.sgml | 26 +++++----
en/winedev-opengl.sgml | 38 ++++++------
en/winedev-otherdebug.sgml | 2 +-
en/winedev-testing.sgml | 24 ++++----
en/winedev-windowing.sgml | 2 +-
12 files changed, 260 insertions(+), 257 deletions(-)
diff --git a/en/winedev-architecture.sgml b/en/winedev-architecture.sgml
index d4bf8e1..78787dd 100644
--- a/en/winedev-architecture.sgml
+++ b/en/winedev-architecture.sgml
@@ -1,6 +1,6 @@
<chapter id="architecture">
<title>Overview</title>
- <para>Brief overview of Wine's architecture...</para>
+ <para>Brief overview of Wine architecture...</para>
<sect1 id="basic-overview">
<title>Wine Overview</title>
@@ -64,7 +64,7 @@
<para>
Windows PE executable. These are programs were
introduced in Windows 95 (and became the native
- formats for all later Windows version), even if 16 bit
+ formats for all later Windows versions), even if 16 bit
applications were still supported. PE stands for
Portable Executable, in a sense where the format of
the executable (as a file) is independent of the CPU
@@ -312,7 +312,7 @@
<listitem>
<para>
Several subsystems (Win32, Posix...) can be run on NT,
- while not on Win 9x
+ while not on Win 9x.
</para>
</listitem>
<listitem>
@@ -342,7 +342,7 @@
<para>
Wine implementation is closer to the Windows NT
architecture, even if several subsystems are not implemented
- yet (remind also that 16bit support is implemented in a 32-bit
+ yet (remind also that 16 bit support is implemented in a 32 bit
Windows EXE, not as a subsystem). Here's the overall picture:
<screen>
+---------------------+ \
@@ -406,11 +406,11 @@
</para>
<para>
The Wine server provides the backbone for the implementation
- of the core DLLs. It mainly implementents inter-process
+ of the core DLLs. It mainly implements inter-process
synchronization and object sharing. It can be seen, from a
functional point of view, as a NT kernel (even if the APIs
- and protocols used between Wine's DLL and the Wine server
- are Wine specific).
+ and protocols used between Wine DLLs and the Wine server
+ are Wine-specific).
</para>
<para>
Wine uses the Unix drivers to access the various hardware
@@ -424,7 +424,7 @@
All DLLs provided by Wine try to stick as much as possible
to the exported APIs from the Windows platforms. There are
rare cases where this is not the case, and have been
- propertly documented (Wine DLLs export some Wine specific
+ properly documented (Wine DLLs export some Wine specific
APIs). Usually, those are prefixed with
<function>__wine</function>.
</para>
@@ -532,7 +532,7 @@
as the DLL resources and a Wine specific DLL descriptor.
</para>
<para>
- The DLL descriptor, when the DLL is instanciated, is used to
+ The DLL descriptor, when the DLL is instantiated, is used to
create an in-memory PE header, which will provide access to
various information about the DLL, including but not limited
to its entry point, its resources, its sections, its debug
@@ -548,14 +548,14 @@
the descriptor by <command>winebuild</command>.
</para>
<para>
- Once an application module wants to import a DLL, Wine
+ When an application module wants to import a DLL, Wine
will look:
<itemizedlist>
<listitem>
<para>
through its list of registered DLLs (in fact, both
the already loaded DLLs, and the already loaded
- shared libraries which has registered a DLL
+ shared libraries which have registered a DLL
descriptor). Since, the DLL descriptor is
automatically registered when the shared library is
loaded - remember, registration call is put inside a
@@ -583,21 +583,21 @@
<para>
After the DLL has been identified (assuming it's still a
native one), it's mapped into memory using a
- <function>dlopen()</function> call. Note, that Wine doesn't
+ <function>dlopen()</function> call. Note that Wine doesn't
use the shared library mechanisms for resolving and/or
importing functions between two shared libraries (for two
DLLs). The shared library is only used for providing a way
to load a piece of code on demand. This piece of code,
- thanks the DLL descriptor, will provide the same type of
+ thanks to the DLL descriptor, will provide the same type of
information a native DLL would. Wine can then use the same
code for native and builtin DLL to handle imports/exports.
</para>
<para>
Wine also relies on the dynamic loading features of the Unix
shared libraries to relocate the DLLs if needed (the same
- DLL can be loaded at different address in two different
- processes, and even in two consecutive run of the same
- executable if the order of loading the DLLs differ).
+ DLL can be loaded at different addresses in two different
+ processes, and even in two consecutive runs of the same
+ executable if the order in which the DLLs are loaded differs).
</para>
<para>
The DLL descriptor is registered in the Wine realm using
@@ -608,7 +608,7 @@
the descriptor to the Wine DLL loader. Hence, before the
<function>dlopen</function> call returns, the DLL descriptor
will be known and registered. This also helps to deal with
- the cases where there's still dependencies (at the ELF
+ the cases where there are still dependencies (at the ELF
shared lib level, not at the embedded DLL level) between
different shared libraries: the embedded DLLs will be
properly registered, and even loaded (from a Windows point
@@ -616,7 +616,7 @@
</para>
<para>
Since Wine is 32-bit code itself, and if the compiler
- supports Windows' calling convention, <type>stdcall</type>
+ supports Windows calling convention, <type>stdcall</type>
(<command>gcc</command> does), Wine can resolve imports
into Win32 code by substituting the addresses of the Wine
handlers directly without any thunking layer in
@@ -646,12 +646,12 @@
needs to relay between 16-bit and 32-bit code. These
thunks switch between the app's 16-bit stack and Wine's
32-bit stack, copies and converts arguments as appropriate
- (an int is 16 bit 16-bit and 32 bits in 32-bit, pointers
+ (an int is 16 bit in 16-bit and 32 bits in 32-bit, pointers
are segmented in 16 bit (and also near or far) but are 32
bit linear values in 32 bit), and handles the Win16
mutex. Some finer control can be obtained on the
conversion, see <command>winebuild</command> reference
- manual for the details. Suffice to say that the kind of
+ manual for the details. Suffices to say that the kind of
intricate stack content juggling this results in, is not
exactly suitable study material for beginners.
</para>
@@ -763,7 +763,7 @@
</para>
<para>
See <ulink url="http://www.winehq.org/docs/wineusr-guide/">
- The Wine User Guide</ulink> for informations
+ The Wine User Guide</ulink> for information
on how to change the settings.
</para>
</sect3>
@@ -783,7 +783,7 @@
memory in RAM chips is split into
<emphasis>frames</emphasis>, and the memory that each
process sees is split into <emphasis>pages</emphasis>. Each
- process has its own 4 gigabytes of address space (4gig being
+ process has its own 4 gigabytes of address space (4 GB being
the maximum space addressable with a 32 bit pointer). Pages
can be mapped or unmapped: attempts to access an unmapped
page cause an
@@ -860,7 +860,7 @@
kernel (from <constant>0x80000000</constant>). Why is the
kernel mapped into every address space? Mostly for
performance: while it's possible to give the kernel its own
- address space too - this is what Ingo Molnars 4G/4G VM
+ address space too - this is what Ingo Molnar's 4G/4G VM
split patch does for Linux - it requires that every system
call into the kernel switches address space. As that is a
fairly expensive operation (requires flushing the
diff --git a/en/winedev-coding.sgml b/en/winedev-coding.sgml
index 2dc12a6..69f2479 100644
--- a/en/winedev-coding.sgml
+++ b/en/winedev-coding.sgml
@@ -18,13 +18,13 @@
<itemizedlist>
<listitem>
<para>
- A meaningful subject (very short description of patch)
+ A meaningful subject (very short description of patch)
</para>
</listitem>
<listitem>
<para>
A long (paragraph) description of what was wrong and what
- is now better. (recommended)
+ is now better (recommended).
</para>
</listitem>
<listitem>
@@ -93,8 +93,8 @@
</listitem>
<listitem>
<para>
- C++ style comments are discouraged since some compilers
- choke on them.
+ C++ style comments are forbidden since some compilers
+ choke on them.
</para>
</listitem>
<listitem>
@@ -220,7 +220,7 @@ code
tests can be done by running <command>make test</command>. You may
need to run <command>make testclean</command> to undo the results
of a previous test run. See the <quote>testing</quote> guide for
- more details on Wine's conformance tests.
+ more details on Wine conformance tests.
</para>
</sect1>
@@ -281,7 +281,7 @@ code
</itemizedlist>
<para>
You will need Gnu Autoconf, which you can get from your
- friendly Gnu mirror. This program takes Wine's
+ friendly Gnu mirror. This program takes Wine
<filename>configure.ac</filename> file and produces a
<filename>configure</filename> shell script that users use
to configure Wine to their system.
@@ -291,8 +291,8 @@ code
<symbol>#ifdef MyOS</symbol>" rule. Wine, for example, needs
the internals of the signal stack -- that cannot easily be
described in terms of features. Moreover, you cannot use
- <filename>autoconf</filename>'s <symbol>HAVE_*</symbol>
- symbols in Wine's headers, as these may be used by Winelib
+ <filename>autoconf</filename> <symbol>HAVE_*</symbol>
+ symbols in Wine headers, as these may be used by Winelib
users who may not be using a <filename>configure</filename>
script.
</para>
@@ -345,7 +345,7 @@ AC_CHECK_HEADER(foo.h, AC_DEFINE(HAVE_FOO_H))
</para>
<para>
You will also need to add <symbol>#undef HAVE_FOO_H</symbol>
- (etc.) to <filename>include/config.h.in</filename>
+ (etc.) to <filename>include/config.h.in</filename>.
</para>
<para>
Finish up with <command>make configure</command> and
@@ -365,13 +365,13 @@ AC_CHECK_HEADER(foo.h, AC_DEFINE(HAVE_FOO_H))
<command>autoconf</command> checks for. In
<filename>configure.in</filename> you search for
<function>AC_CHECK_FUNCS</function> and add
- <function>memmove</function>. (You will notice that someone
- already did this for this particular function.)
+ <function>memmove</function> (you will notice that someone
+ already did this for this particular function).
</para>
<para>
Secondly, you will also need to add
<symbol>#undef HAVE_BAR</symbol> to
- <filename>include/config.h.in</filename>
+ <filename>include/config.h.in</filename>.
</para>
<para>
The next step depends on the nature of the missing function.
@@ -383,8 +383,8 @@ AC_CHECK_HEADER(foo.h, AC_DEFINE(HAVE_FOO_H))
<listitem>
<para>
It's easy to write a complete implementation of the
- function. (<function>memmove</function> belongs to
- this case.)
+ function (<function>memmove</function> belongs to
+ this case).
</para>
<para>
You add your implementation in
diff --git a/en/winedev-debugger.sgml b/en/winedev-debugger.sgml
index b877063..5f3b243 100644
--- a/en/winedev-debugger.sgml
+++ b/en/winedev-debugger.sgml
@@ -15,8 +15,8 @@
processes/threads from a Windows point of view.
</para>
<para>
- Each Windows' thread is implemented as a Unix thread, meaning
- that all threads of a same Windows' process share the same
+ Each Windows thread is implemented as a Unix thread, meaning
+ that all threads of a same Windows process share the same
(unix) address space.
</para>
<para>
@@ -25,17 +25,17 @@
<itemizedlist>
<listitem>
<para>
- <varname>W-process</varname> means a process in Windows' terminology
+ <varname>W-process</varname> means a process in Windows terminology
</para>
</listitem>
<listitem>
<para>
- <varname>U-process</varname> means a process in Unix' terminology
+ <varname>U-process</varname> means a process in Unix terminology
</para>
</listitem>
<listitem>
<para>
- <varname>W-thread</varname> means a thread in Windows' terminology
+ <varname>W-thread</varname> means a thread in Windows terminology
</para>
</listitem>
</itemizedlist>
@@ -58,12 +58,12 @@
</listitem>
<listitem>
<para>
- the Windows's thread id (<varname>tid</varname>)
+ the Windows thread id (<varname>tid</varname>)
</para>
</listitem>
</itemizedlist>
<para>
- Each Windows' process has also a Windows' process id
+ Each Windows process has also a Windows process id
(<varname>wpid</varname> in the following). It must be clear
that <varname>upid</varname> and <varname>wpid</varname> are
different and shall not be used instead of the other.
@@ -71,9 +71,9 @@
<para>
<varname>Wpid</varname> and <varname>tid</varname> are
defined (Windows) system wide. They must not be confused
- with process or thread handles which, as any handle, is an
- indirection to a system object (in this case process or
- thread). A same process can have several different handles
+ with process or thread handles which, as any handle, are
+ indirections to system objects (in this case processes or
+ threads). A same process can have several different handles
on the same kernel object. The handles can be defined as
local (the values is only valid in a process), or system
wide (the same handle can be used by any
@@ -91,7 +91,7 @@
<itemizedlist>
<listitem>
<para>
- the Windows' debugging API.
+ the Windows debugging API.
</para>
</listitem>
<listitem>
@@ -101,7 +101,7 @@
</listitem>
</itemizedlist>
<para>
- Wine implements most of the Windows' debugging API. The
+ 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
the debugger, to control the execution of another W-process,
@@ -115,9 +115,9 @@
</para>
<para>
<command>winedbg</command> is a Winelib application making
- use of these APIs (<filename>KERNEL32.DLL</filename>'s
+ use of these APIs (<filename>KERNEL32.DLL</filename>
debugging API and <filename>DBGHELP.DLL</filename>) to allow
- debugging both any Wine or Winelib applications as well as
+ debugging both any Wine or Winelib application as well as
Wine itself (kernel and all DLLs).
</para>
</sect2>
@@ -125,13 +125,13 @@
<sect1 id="dbg-modes">
- <title>WineDbg's modes of invocation</title>
+ <title>WineDbg modes of invocation</title>
<sect2>
<title>Starting a process</title>
<para>
- Any application (either a Windows' native executable, or a
+ Any application (either a Windows native executable, or a
Winelib application) can be run through
<command>winedbg</command>. Command line options and tricks
are the same as for wine:
@@ -150,7 +150,7 @@ winedbg hl.exe -windowed
command line argument: <command>winedbg</command> is started
without any attached process. You can get a list of running
<varname>W-processes</varname> (and their
- <varname>wpid</varname>'s) using the <command>info
+ <varname>wpid</varname>) using the <command>info
process</command> command, and then, with the
<command>attach</command> command, pick up the
<varname>wpid</varname> of the <varname>W-process</varname>
@@ -172,7 +172,7 @@ winedbg hl.exe -windowed
<varname>W-process</varname> is debugged. If so, the
exception event is sent to the debugger, which takes care of
it: end of the story. This mechanism is part of the standard
- Windows' debugging API.
+ Windows debugging API.
</para>
<para>
If the <varname>W-process</varname> is not debugged, Wine
@@ -227,7 +227,7 @@ winedbg hl.exe -windowed
</variablelist>
<note>
<para>
- since some of Wine's code uses exceptions and
+ since some of Wine code uses exceptions and
<function>try/catch</function> blocks to provide some
functionality, <command>winedbg</command> can be entered
in such cases with segv exceptions. This happens, for
@@ -370,7 +370,7 @@ winedbg hl.exe -windowed
If so the offending function may also uses one of these alternate
channels. Look through the the function for
<function>TRACE_(<channel>)(" ... /n");</function> and add any
- additional channels to the commandline.
+ additional channels to the command line.
</para>
</listitem>
<listitem>
@@ -431,7 +431,7 @@ winedbg hl.exe -windowed
<para>
Start the program with <command>winedbg</command> instead of
<command>wine</command>. When the program locks up switch to the
- winedbg's terminal and press
+ winedbg terminal and press
<keycombo><keycap>Ctrl</keycap><keycap>C</keycap></keycombo>. This
will stop the program and let you debug the program as you would for
a crash.
@@ -439,23 +439,23 @@ winedbg hl.exe -windowed
</sect2>
<sect2>
- <title>Program reports an error with a Messagebox</title>
+ <title>Program reports an error with a message box</title>
<para>
Sometimes programs are reporting failure using more or
- less nondescript messageboxes. We can debug this using the
+ less nondescript message boxes. We can debug this using the
same method as Crashes, but there is one problem... For
setting up a message box the program also calls Wine
producing huge chunks of debug code.
</para>
<para>
Since the failure happens usually directly before setting up
- the Messagebox you can start winedbg and set a
+ the message box you can start winedbg and set a
breakpoint at <function>MessageBoxA</function> (called by win16
and win32 programs) and proceed with
<command>continue</command>. With <parameter>WINEDEBUG=+all</parameter>
Wine will now stop directly before setting
- up the Messagebox. Proceed as explained above.
+ up the message box. Proceed as explained above.
</para>
<para>
You can also run wine using <command>WINEDEBUG=+relay wine
@@ -478,7 +478,7 @@ winedbg hl.exe -windowed
</para>
<para>
Disassembling win32 programs is possible using
- eg. <application>GoVest</> by Ansgar Trimborn. It can be found
+ e.g. <application>GoVest</> by Ansgar Trimborn. It can be found
<ulink url="http://www.oocities.com/govest/">here</>.
</para>
<para>
@@ -565,7 +565,7 @@ call KERNEL.LSTRLEN
<para>
Let's debug the infamous Word <filename>SHARE.EXE</filename>
- messagebox:
+ message box:
</para>
<screen>
|marcus at jet $ wine winword.exe
@@ -592,7 +592,7 @@ call KERNEL.LSTRLEN
|Call KERNEL.91: INITTASK() ret=0157:0022 ds=08a7
| AX=0000 BX=3cb4 CX=1f40 DX=0000 SI=0000 DI=08a7 ES=11d7 EFL=00000286
|CallTo16(func=090f:085c,ds=0dcf,0x0000,0x0000,0x0000,0x0000,0x0800,0x0000,0x0000,0x0dcf)
-|... <----- Much debugoutput
+|... <----- Much debug output
|Call KERNEL.136: GETDRIVETYPE(0x0000) ret=060f:097b ds=0927
^^^^^^ Drive 0 (A:)
|Ret KERNEL.136: GETDRIVETYPE() retval=0x0002 ret=060f:097b ds=0927
@@ -609,7 +609,7 @@ call KERNEL.LSTRLEN
^^^^^^^ Drive 2 (C:)
|Ret KERNEL.136: GETDRIVETYPE() retval=0x0003 ret=060f:097b ds=0927
^^^^^^ DRIVE_FIXED
- (specified as a harddisk)
+ (specified as a hard disk)
|Call KERNEL.97: GETTEMPFILENAME(0x00c3,0x09278364"doc",0x0000,0927:8248) ret=060f:09b1 ds=0927
^^^^^^ ^^^^^ ^^^^^^^^^
@@ -655,7 +655,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
- <medialabel>C:</medialabel> as a networkdrive, which is ignored
+ <medialabel>C:</medialabel> as a network drive, which is ignored
by the code above.
</para>
</sect2>
@@ -694,12 +694,12 @@ winedbg winfile.exe
</listitem>
<listitem>
<para>
- If you try to run a program and it quits after showing an error messagebox,
+ If you try to run a program and it quits after showing an error message box,
the problem can usually be identified in the return value of one of the
functions executed before <function>MessageBox()</function>.
That's why you should re-run the program with e.g.
<programlisting>
-WINEDEBUG=+relay wine <program name> &>relmsg
+WINEDEBUG=+relay wine <program name> &>relmsg
</programlisting>
Then do a <command>more relmsg</command> and search for the
last occurrence of a call to the string "MESSAGEBOX". This is a line like
@@ -735,14 +735,14 @@ Call USER.1: MESSAGEBOX(0x0000,0x01ff1246 "Runtime error 219 at 0004:1056.",0x00
in this example is <emphasis>not</emphasis> caused by a
wrong result value of some previously executed function
(it's happening quite often like that), but instead the
- messagebox complains about a runtime error at
+ message box complains about a runtime error at
<literal>0x0004:0x1056</literal>.
</para>
<para>
As the segment value of the address is only
<literal>4</literal>, I think that that is only an internal
program value. But the offset address reveals something
- quite interesting: Offset <literal>1056</literal> is
+ quite interesting: offset <literal>1056</literal> is
<emphasis>very</emphasis> close to the return address of
<function>FREELIBRARY()</function>:
<programlisting>
@@ -768,7 +768,7 @@ Call KERNEL.96: FREELIBRARY(0x031f) ret=01cf:105c ds=01ff
If you have created a relay file of some crashing
program and want to set a breakpoint at a certain
location which is not yet available as the program loads
- the breakpoint's segment during execution, you may set a
+ the breakpoint segment during execution, you may set a
breakpoint to <function>GetVersion16/32</function> as
those functions are called very often.
</para>
@@ -970,7 +970,7 @@ winedbg myprog.exe
</para>
<para>
Now the strange thing is the calculation that's behind
- these addresses: Just calculate segment*16 + offset in
+ these addresses: just calculate segment*16 + offset in
order to get a "linear DOS" address. So
e.g. 0x0f04:0x3628 results in 0xf040 + 0x3628 = 0x12668.
And the highest address you can get is 0xfffff (1MB), of
@@ -994,7 +994,7 @@ winedbg myprog.exe
<title>Windows Debugging configuration</title>
<para>
- The Windows' debugging API uses a registry entry to know
+ The Windows debugging API uses a registry entry to know
which debugger to invoke when an unhandled exception occurs
(see <link endterm="dbg-exception-title"
linkend="dbg-on-exception"></link> for some details). Two
@@ -1004,7 +1004,7 @@ winedbg myprog.exe
[MACHINE\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug]
</programlisting>
<para>
- Determine the behavior:
+ determine the behavior:
</para>
<variablelist>
<varlistentry>
@@ -1017,7 +1017,7 @@ winedbg myprog.exe
information to the debugger). You should put here a
complete path to your debugger
(<command>winedbg</command> can of course be used, but
- any other Windows' debugging API aware debugger will do).
+ 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.
@@ -1166,7 +1166,7 @@ set $BreakAllThreadsStartup = 1
exception. When the
<varname>BreakOnFirstChance</varname> exception is
<literal>TRUE</literal>, then winedbg is entered for
- both first and last chance execptions (to
+ both first and last chance exceptions (to
<literal>FALSE</literal>, it's only entered for last
chance exceptions).
</para>
@@ -1296,7 +1296,7 @@ set $BreakAllThreadsStartup = 1
<para>
All CPU registers are also available, using $ as a
prefix. You can use <command>info regs</command> to
- get a list of avaible CPU registers
+ get a list of available CPU registers
</para>
</listitem>
</varlistentry>
@@ -1318,7 +1318,7 @@ set $BreakAllThreadsStartup = 1
<para>
<table>
- <title>WineDbg's misc. commands</title>
+ <title>WineDbg misc. commands</title>
<tgroup cols="2" align="left">
<tbody>
<row>
@@ -1361,7 +1361,7 @@ set $BreakAllThreadsStartup = 1
<para>
<table>
- <title>WineDbg's flow control commands</title>
+ <title>WineDbg flow control commands</title>
<tgroup cols="2" align="left">
<tbody>
<row>
@@ -1465,7 +1465,7 @@ set $BreakAllThreadsStartup = 1
<para>
<table>
- <title>WineDbg's break & watch points</title>
+ <title>WineDbg break & watch points</title>
<tgroup cols="2" align="left">
<tbody>
<row>
@@ -1570,7 +1570,7 @@ set $BreakAllThreadsStartup = 1
<para>
<table>
- <title>WineDbg's stack manipulation</title>
+ <title>WineDbg stack manipulation</title>
<tgroup cols="2" align="left">
<tbody>
<row>
@@ -1635,13 +1635,13 @@ set $BreakAllThreadsStartup = 1
<para>
<table>
- <title>WineDbg's directory & source file manipulation</title>
+ <title>WineDbg directory & source file manipulation</title>
<tgroup cols="2" align="left">
<tbody>
<row>
<entry><command>show dir</command></entry>
<entry>
- prints the list of dir:s where source files are
+ prints the list of dirs where source files are
looked for
</entry>
</row>
@@ -1650,14 +1650,14 @@ set $BreakAllThreadsStartup = 1
<command>dir <pathname></command>
</entry>
<entry>
- adds <pathname> to the list of dir:s
+ adds <pathname> to the list of dirs
where to look for source files
</entry>
</row>
<row>
<entry><command>dir</command></entry>
<entry>
- deletes the list of dir:s where to look for source
+ deletes the list of dirs where to look for source
files
</entry>
</row>
@@ -1728,7 +1728,7 @@ set $BreakAllThreadsStartup = 1
You can specify the end target (to change the 10 lines
value) using the ','. For example:
<table>
- <title>WineDbg's list command examples</title>
+ <title>WineDbg list command examples</title>
<tgroup cols="2" align="left">
<tbody>
<row>
@@ -1768,7 +1768,7 @@ set $BreakAllThreadsStartup = 1
</para>
<para>
<table>
- <title>WineDbg's displays</title>
+ <title>WineDbg displays</title>
<tgroup cols="2" align="left">
<tbody>
<row>
@@ -1834,7 +1834,7 @@ set $BreakAllThreadsStartup = 1
<para>
<table>
- <title>WineDbg's dissassembly</title>
+ <title>WineDbg dissassembly</title>
<tgroup cols="2" align="left">
<tbody>
<row>
@@ -1871,7 +1871,7 @@ set $BreakAllThreadsStartup = 1
<para>
<table>
- <title>WineDbg's memory management</title>
+ <title>WineDbg memory management</title>
<tgroup cols="2" align="left">
<tbody>
<row>
@@ -1977,17 +1977,17 @@ set $BreakAllThreadsStartup = 1
</sect2>
<sect2>
- <title>Information on Wine's internals</title>
+ <title>Information on Wine internals</title>
<para>
<table>
- <title>WineDbg's Win32 objects management</title>
+ <title>WineDbg Win32 objects management</title>
<tgroup cols="2" align="left">
<tbody>
<row>
<entry><command>info class</command></entry>
<entry>
- lists all Windows' classes registered in Wine
+ lists all Windows classes registered in Wine
</entry>
</row>
<row>
@@ -1997,7 +1997,7 @@ set $BreakAllThreadsStartup = 1
</command>
</entry>
<entry>
- prints information on Windows's class <id>
+ prints information on Windows class <id>
</entry>
</row>
<row>
@@ -2119,7 +2119,7 @@ set $BreakAllThreadsStartup = 1
<para>
<table>
- <title>WineDbg's debug channels' management</title>
+ <title>WineDbg debug channels management</title>
<tgroup cols="2" align="left">
<tbody>
<row>
@@ -2170,7 +2170,7 @@ set $BreakAllThreadsStartup = 1
any Win32 application. To enable this mode, just add
<parameter>--gdb</parameter> to winedbg command line. You'll
end up on a GDB prompt. You'll have to use the GDB commands
- (not WineDbg's).
+ (not WineDbg ones).
</para>
<para>
@@ -2196,7 +2196,7 @@ set $BreakAllThreadsStartup = 1
<para>
A few Wine extensions available through the monitor command.
<table>
- <title>WineDbg's debug channels' management</title>
+ <title>WineDbg debug channels' management</title>
<tgroup cols="2" align="left">
<tbody>
<row>
@@ -2324,7 +2324,7 @@ kdbg -r localhost:32878 wine
process (representing the correct windows thread) (you can
"guess" it from a <command>ps fax</command> for example:
When running the emulator, usually the first two
- <varname>upids</varname> are for the Windows' application
+ <varname>upids</varname> are for the Windows application
running the desktop, the first thread of the application is
generally the third <varname>upid</varname>; when running a
Winelib program, the first thread of the application is
@@ -2354,7 +2354,7 @@ kdbg -r localhost:32878 wine
In the unfortunate case (no direct thread support in
<command>gdb</command> because one of the above conditions
is false), you'll have to spawn a different
- <command>gdb</command> session for each Windows' thread
+ <command>gdb</command> session for each Windows thread
you wish to debug (which means no synchronization for
debugging purposes between the various threads).
</para>
@@ -2423,7 +2423,7 @@ $ gdb wine
<title>Using other Windows debuggers</title>
<para>
- You can use any Windows' debugging API compliant debugger
+ You can use any Windows debugging API compliant debugger
with Wine. Some reports have been made of success with
VisualStudio debugger (in remote mode, only the hub runs
in Wine). GoVest fully runs in Wine.
@@ -2440,14 +2440,14 @@ $ gdb wine
</row>
<row>
<entry>
- WineDbg debugs a Windows' process: the various
+ WineDbg debugs a Windows process: the various
threads will be handled by the same WineDbg session,
and a breakpoint will be triggered for any thread of
the W-process
</entry>
<entry>
- gdb debugs a Windows' thread: a separate gdb session
- is needed for each thread of a Windows' process and
+ gdb debugs a Windows thread: a separate gdb session
+ is needed for each thread of a Windows process and
a breakpoint will be triggered only for the w-thread
debugged
</entry>
diff --git a/en/winedev-debugging.sgml b/en/winedev-debugging.sgml
index 6a7d58c..5a13f59 100644
--- a/en/winedev-debugging.sgml
+++ b/en/winedev-debugging.sgml
@@ -60,7 +60,7 @@ MESSAGE( "Could not create graphics driver '%s'\n", buffer );
These are warning messages. You should report a
warning when something unwanted happens, and the
function cannot deal with the condition. This
- is seldomly used since proper functions can usually
+ is seldom used since proper functions can usually
report failures back to the caller. Think twice before
making the message a warning.
</para>
@@ -81,7 +81,7 @@ MESSAGE( "Could not create graphics driver '%s'\n", buffer );
<listitem>
<para>
There messages are intended for the end user. They do not
- belong to any channel. As with warnings, you will seldomly
+ belong to any channel. As with warnings, you will seldom
need to output such messages.
</para>
</listitem>
@@ -95,15 +95,15 @@ MESSAGE( "Could not create graphics driver '%s'\n", buffer );
<para>
Each component is assigned a debugging channel. The
identifier of the channel must be a valid C identifier
- (reserved word like <type>int</type> or <type>static</type>
- are premitted). To use a new channel, simply use it in
+ (reserved words like <type>int</type> or <type>static</type>
+ are permitted). To use a new channel, simply use it in
your code. It will be picked up automatically by the build process.
</para>
<para>
Typically, a file contains code pertaining to only one component,
and as such, there is only one channel to output to. You can declare
- a default chanel for the file using the
+ a default channel for the file using the
<symbol>WINE_DEFAULT_DEBUG_CHANNEL()</symbol> macro:
<programlisting>
#include "wine/debug.h"
@@ -156,7 +156,7 @@ if(TRACE_ON(atom)){
}
</programlisting>
You should normally need to test only if <literal>TRACE_ON</literal>,
- all the others are very seldomly used. With careful coding, you
+ all the others are very seldom used. With careful coding, you
can avoid the use of these macros, which is generally desired.
</para>
</sect1>
@@ -209,7 +209,7 @@ LPSTR debugres(const void *id);
characters, or they may be too long. Similarly, Unicode
strings need to be converted to ASCII for usage with
the debugging API. For all this, you can use the
- <function>debugstr_[aw]n?</function> familly of functions:
+ <function>debugstr_[aw]n?</function> family of functions:
<programlisting>
HANDLE32 WINAPI YourFunc(LPCSTR s)
{
@@ -232,7 +232,7 @@ HANDLE32 WINAPI YourFunc(LPCSTR s)
<para>
You can do the same using the task manager
(<command>taskmgr</command>) and selecting your application in
- the application list. Right clicking on the application, and
+ the applications list. Right clicking on the application, and
selecting the debug option in the popup menu, will let you
select the modifications you want on the debug channels.
</para>
diff --git a/en/winedev-documentation.sgml b/en/winedev-documentation.sgml
index bf7f9d1..c19bc9c 100644
--- a/en/winedev-documentation.sgml
+++ b/en/winedev-documentation.sgml
@@ -2,7 +2,7 @@
<title>Documenting Wine</title>
<para>
- This chapter describes how you can help improve Wine's documentation.
+ This chapter describes how you can help improve Wine documentation.
</para>
<para>
@@ -19,7 +19,7 @@
a successful experience in installing, setting up and using software. Because Wine is a
complicated, evolving entity, providing quality up to date documentation is vital to
encourage more people to persevere with using and contributing to the project.
- The following sections describe in detail how to go about adding to or updating Wine's
+ The following sections describe in detail how to go about adding to or updating Wine
existing documentation.
</para>
@@ -146,7 +146,7 @@
<listItem><para>
Additional notes such as interaction with other parts of the system, differences
- between Wine's implementation and Win32s, errors in MSDN documentation,
+ between Wine and Win32 implementations, errors in MSDN documentation,
undocumented cases and bugs that Wine corrects or is compatible with.
</para></listitem>
@@ -220,7 +220,7 @@
<para>
The functions name and the DLL name are obvious. The ordinal number takes one of
two forms: Either <command>@</command> 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's
+ 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 <command>@</command> symbol, which indicates
that this function is imported only by name.
@@ -531,7 +531,7 @@
As a special case, if you use the DLL name as the comment name, the comment will
be treated as documentation on the DLL itself. When the documentation for the DLL
is processed, the contents of the comment will be placed before the generated
- statistics, exports and other information that makes up a DLL's documentation page.
+ statistics, exports and other information that makes up a DLL documentation page.
</para>
</sect2>
@@ -554,7 +554,7 @@
</para>
<para>
- An easier way is to use Wine's build system. To create man pages for a given
+ 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
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,
@@ -811,9 +811,9 @@
class="starttag">para</sgmltag>. This start tag indicates
that the immediately following text should be classified
according to the tag. In regular SGML, each opening tag
- must have a matching end tag to show where the start tag's
- contents end. End tags begin with
- <quote><literal></</literal></quote> markup, e.g.,
+ must have a matching end tag to show where the tag
+ contents ends. End tags begin with
+ <quote><literal></</literal></quote> markup, e.g.
<sgmltag class="endtag">para</sgmltag>.
</para>
<para>
@@ -830,7 +830,7 @@
the SGML specification, adds a so-called <firstterm>empty
tag</firstterm>, for elements that contain no text
content. The entire element is a single tag, ending with
- <quote><literal>/></literal></quote>, e.g.,
+ <quote><literal>/></literal></quote>, e.g.
<sgmltag><xref/></sgmltag>. However, use of this
tag style restricts you to XML DocBook processing, and
your document may no longer compile with SGML-only
@@ -1070,7 +1070,7 @@
DocBook guide, at <ulink
url="http://docbook.org">http://docbook.org</ulink>. To
see how they are used in practice, download the SGML
- source for this manual (the Wine Developer Guide) and
+ source for this manual (the Wine Developer's Guide) and
browse through it, comparing it to the generated HTML (or
PostScript or PDF).
</para>
@@ -1138,7 +1138,7 @@
<listitem>
<para>
If the chapters in your book fall into major
- categories or groupings (as in the Wine Developer
+ categories or groupings (as in the Wine Developer's
Guide), you can place each collection of chapters
into a <sgmltag class="starttag">part</sgmltag>
element.
@@ -1313,7 +1313,7 @@
<para>
Used for inserting SGML tags, etc., into a SGML
document without resorting to a lot of entity
- quoting, e.g., <. You can change the
+ quoting, e.g. <. You can change the
appearance of the text with the <sgmltag
class="attribute">class</sgmltag> attribute. Some
common values of this are
@@ -1341,7 +1341,7 @@
<listitem>
<para>
Meta-text that should be replaced by the user, not
- typed in literally, e.g., in command descriptions
+ typed in literally, e.g. in command descriptions
and <parameter>--help</parameter> outputs.
</para>
</listitem>
@@ -1350,7 +1350,7 @@
<term><sgmltag class="starttag">constant</sgmltag></term>
<listitem>
<para>
- A programming constant, e.g.,
+ A programming constant, e.g.
<constant>MAX_PATH</constant>.
</para>
</listitem>
@@ -1405,7 +1405,7 @@
<term><sgmltag class="starttag">type</sgmltag></term>
<listitem>
<para>
- Programming language types, e.g., from a typedef
+ Programming language types, e.g. from a typedef
definition. May have other uses, too.
</para>
</listitem>
@@ -1415,7 +1415,7 @@
<listitem>
<para>
The name of a C-language <type>struct</type>
- declaration, e.g., <structname>sockaddr</structname>.
+ declaration, e.g. <structname>sockaddr</structname>.
</para>
</listitem>
</varlistentry>
@@ -1431,7 +1431,7 @@
<term><sgmltag class="starttag">command</sgmltag></term>
<listitem>
<para>
- An executable binary, e.g., <command>wine</command>
+ An executable binary, e.g. <command>wine</command>
or <command>ls</command>.
</para>
</listitem>
@@ -1440,7 +1440,7 @@
<term><sgmltag class="starttag">envar</sgmltag></term>
<listitem>
<para>
- An environment variable, e.g, <envar>$PATH</envar>.
+ An environment variable, e.g. <envar>$PATH</envar>.
</para>
</listitem>
</varlistentry>
@@ -1642,7 +1642,7 @@
<term><sgmltag class="starttag">ulink</sgmltag></term>
<listitem>
<para>
- Hyperlink in URL form, e.g., <ulink
+ Hyperlink in URL form, e.g. <ulink
url="http://www.winehq.org">http://www.winehq.org</ulink>.
</para>
</listitem>
diff --git a/en/winedev-kernel.sgml b/en/winedev-kernel.sgml
index 31dcb75..b9fbd15 100644
--- a/en/winedev-kernel.sgml
+++ b/en/winedev-kernel.sgml
@@ -14,7 +14,7 @@
<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
- more readable and understantable. At least, that's the intend (sigh).
+ more readable and understandable. At least, that's the intent (sigh).
</para>
<sect1 id="initialization">
@@ -226,7 +226,7 @@ ExitProcess( entry( peb ) );
deliberately left unmapped to catch null pointer dereferences. The
region from 64k to 1mb+64k are reserved for DOS compatibility and
contain various DOS data structures. Finally, the address space also
- contains mappings for the Wine binary itself, any native libaries
+ contains mappings for the Wine binary itself, any native libraries
Wine is using, the glibc malloc arena and so on.
</para>
</sect2>
@@ -310,7 +310,7 @@ ExitProcess( entry( peb ) );
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 (ie without linking against any other code to do it)
+ into the kernel (i.e. without linking against any other code to do it)
before restarting the standard initialization and letting the dynamic
linker continue. This is referred to as the preloader and is found in
<filename>loader/preloader.c</filename>.
@@ -483,7 +483,7 @@ ExitProcess( entry( peb ) );
When starting a Winelib application from the command line (say with
<command>foo arg1 arg2</command>), the Unix shell will execute
<command>foo</command> as a Unix executable. Since this is in fact the
- Wine loader, Wine will fire up. However, will notice that it hasn't
+ Wine loader, Wine will fire up. However, it will notice that it hasn't
been started as <command>wine</command> but as <command>foo</command>,
and hence, will try to load (using Unix shared library mechanism) the
second file <filename>foo.exe.so</filename>. Wine will recognize a 32
@@ -707,7 +707,7 @@ if (res != ERROR_SUCCESS) return res;
... then you are seeing the program set up an SEH handler frame. All
threads must have at least one SEH entry, which normally points to the
backstop handler which is ultimately responsible for popping up the
- all-too-familiar This program has performed an illegal operation and
+ all-too-familiar "This program has performed an illegal operation and
will be terminated" message. On Wine we just drop straight into the
debugger. A full description of SEH is out of the scope of this
section, however there are some good articles in MSJ if you are
@@ -775,14 +775,14 @@ if (res != ERROR_SUCCESS) return res;
<para>
Exceptions can be triggered by many things. They can be thrown
explicitly by using the RaiseException API, or they can be triggered
- by a crash (ie, translated from a signal). They may be used internally
+ by a crash (i.e. translated from a signal). They may be used internally
by a language runtime to implement language-specific exceptions. They
can also be thrown across DCOM connections.
</para>
<para>
Visual C++ has various extensions to SEH which it uses to implement,
- eg, object destruction on stack unwind as well as the ability to throw
+ e.g. object destruction on stack unwind as well as the ability to throw
arbitrary types. The code for this is in
<filename>dlls/msvcrt/except.c</filename>
</para>
@@ -1027,7 +1027,7 @@ if (res != ERROR_SUCCESS) return res;
<listitem>
<para>
<filename>\foo\bar</filename> is an absolute path; the full
- path is created by appending the default drive (ie. the drive
+ path is created by appending the default drive (i.e. the drive
of the current directory).
</para>
</listitem>
@@ -1058,7 +1058,7 @@ if (res != ERROR_SUCCESS) return res;
modified). On Windows NT, things differ a bit. Since NT
implements a namespace for file closer to a single tree
(instead of 26 drives), having a current directory per drive
- is a bit ackward. Hence, Windows NT default behavior is to
+ is a bit awkward. Hence, Windows NT default behavior is to
have only one current directory across all drives (in fact, a
current directory expressed in the global tree) - this
directory is of course related to a given process -,
@@ -1093,7 +1093,7 @@ if (res != ERROR_SUCCESS) return res;
<command>cd</command>. Since environment variables are
inherited at process creation, the current directories
settings are inherited by child processes, hence
- mimicing the behavior of the old DOS shell. There's no
+ 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
directory changes, the relevant environment variables.
@@ -1109,7 +1109,7 @@ if (res != ERROR_SUCCESS) return res;
<listitem>
<para>
<filename>\\host\share</filename> is <firstterm>UNC</firstterm>
- (Universal Naming Convention) path, ie. represents a file on a
+ (Universal Naming Convention) path, i.e. represents a file on a
remote share.
</para>
</listitem>
@@ -1346,8 +1346,8 @@ if (res != ERROR_SUCCESS) return res;
</para>
<para>
We've seen how Wine maps a drive letter or a UNC path onto the Unix
- hierarchy, we now have to look on a the filename is searched within
- this hierarchy. The main issue is about case sensivity. Here's a
+ hierarchy, we now have to look at how the filename is searched within
+ this hierarchy. The main issue is about case sensitivity. Here's a
reminder of the various properties for the file systems in the
field.
<table>
@@ -1384,7 +1384,7 @@ if (res != ERROR_SUCCESS) return res;
Long names are stored with case preservation. Short names
are always stored in upper-case.
</entry>
- <entry>Case insentivite</entry>
+ <entry>Case insensitivity</entry>
</row>
<row>
<entry>Linux FS (ext2fs, ext3fs, reiserfs...)</entry>
@@ -1409,26 +1409,26 @@ if (res != ERROR_SUCCESS) return res;
</para>
</note>
Since most file systems used in NT are case insensitive and since
- most Unix file systems are case sensitive, Wine undergo a case
+ most Unix file systems are case sensitive, Wine undergoes a case
insensitive search when it has found the Unix path is has to look
for. This means, for example, that for opening the
<filename>$(WINEPREFIX)/dosdevices/c:/foo/bar/myfile.txt</filename>,
Wine will recursively open all directories in the path, and check,
in this order, for the existence of the directory entry in the form
- given in the file name (ie. case sensitive), and if it's not found,
+ given in the file name (i.e. case sensitive), and if it's not found,
in a case insensitive form. This allows to also pass, in most Win32
- file API also a Unix path (instead of a DOS or NT path), but we'll
+ file API, a Unix path (instead of a DOS or NT path), but we'll
come back to this later. This also means that the algorithm
described doesn't correctly handle the case of two files in the same
- directory, which names only differ on the case of the letters. This
- means, that if, in the same directory, two files (which names match
- in a case sensitive comparison), Wine will pick-up the right one if
- the filename given matches on of the name (in a case sensitive way),
+ directory, whose names only differ on the case of the letters. This
+ means that if there are two files in the same directory whose names
+ match in a case sensitive comparison, Wine will pick up the right one
+ if the filename given matches one of the names (in a case sensitive way),
but will pickup one of the two (without defining the one it's going
to pickup) if the filename given matches none of the two names in a
case sensitive way (but in a case insensitive way). For example, if
the two filenames are <filename>my_neat_file.txt</filename> and
- <filename>My_Neat_File.txt</filename>, Wine's behavior when opening
+ <filename>My_Neat_File.txt</filename>, Wine behavior when opening
<filename>MY_neat_FILE.txt</filename> is undefined.
</para>
<para>
@@ -1436,11 +1436,11 @@ if (res != ERROR_SUCCESS) return res;
links on directories, lots of applications (and some old native
DLLs) are not ready for this feature. Mainly, they imply that the
directory structure is a tree, which has lots of consequences on
- navigating in the forest of directories (ie: there cannot be two
+ navigating in the forest of directories (i.e. there cannot be two
ways for going from directory to another, there cannot be
cycles...). In order to prevent some bad behavior for such
applications, Wine sets up an option. By default, symbolic links on
- directories are not followed by Wine. There's an options to follow
+ directories are not followed by Wine. There's an option to follow
them (see the Wine User Guide), but this could be harmful.
</para>
<para>
@@ -1522,7 +1522,7 @@ if (res != ERROR_SUCCESS) return res;
</para>
<para>
As a side note, as Unix doesn't widely provide a Unicode interface
- to the filenames, and that Windows implements filenames as Unicode
+ to the filenames, and Windows implements filenames as Unicode
strings (even on the physical layer with NTFS, the FATs variant are
ANSI), we need to properly map between the two. At startup, Wine
defines what's called the Unix Code Page, that's is the code page
@@ -1555,7 +1555,7 @@ if (res != ERROR_SUCCESS) return res;
this information to allow/forbid running a new process (as Unix does
with the exec-flag). Last but not least: hidden files. This exists
on Windows but not really on Unix! To be exact, in Windows, the
- hidden flag is a metadata associated to any file or directoy; in
+ hidden flag is a metadata associated to any file or directory; in
Unix, it's a convention based on the syntax of the file name
(whether it starts with a '.' or not). Wine implements two behaviors
(chosen by configuration). This impacts file names and directory
@@ -1582,16 +1582,16 @@ if (res != ERROR_SUCCESS) return res;
</para>
<para>
The other good reason for putting the code for actually opening a
- file in the server is that an opened files in Windows is managed
+ file in the server is that an opened file in Windows is managed
through a handle, and handles can only be created in Wine server!
</para>
<para>
Just a note about attributes on directories: while we can easily map
- the meaning of Windows' <constant>FILE_ATTRIBUTE_READONLY</constant>
- on a file, we cannot do it for a directory. Windows' semantic (when
+ the meaning of Windows <constant>FILE_ATTRIBUTE_READONLY</constant>
+ on a file, we cannot do it for a directory. Windows semantics (when
this flag is set) means do not delete the directory, while the
<constant>w</constant> attribute in Unix means don't write nor
- delete it. Therefore, Wine uses an asymetric mapping here: if the
+ delete it. Therefore, Wine uses an asymmetric mapping here: if the
directory (in Unix) isn't writable, then Wine reports the
<constant>FILE_ATTRIBUTE_READONLY</constant> attribute; on the other
way around, when asked to set a directory with
@@ -1635,7 +1635,7 @@ if (res != ERROR_SUCCESS) return res;
controls how other processes in the system will have access to the
range in the file. Since locking range on a file are defined on a
system wide manner, its implementation resides in
- <command>wineserver</command>. It tries to make use Unix file
+ <command>wineserver</command>. It tries to make use of Unix file
locking (if the underlying OS and the mounted disk where the file
sits support this feature) with <function>fcntl()</function> and
the <constant>F_SETLK</constant> command. If this isn't
@@ -1680,7 +1680,7 @@ if (res != ERROR_SUCCESS) return res;
<para>
There are several interests to this: a server can handle several
clients without requiring multi-threading techniques; you can
- handle an event driven model more easily (ie how to kill properly
+ handle an event driven model more easily (i.e. how to kill properly
a server while waiting in the lengthy <function>read()</function>
operation).
</para>
@@ -1688,14 +1688,14 @@ if (res != ERROR_SUCCESS) return res;
Note that Microsoft's support for this feature evolved along the
various versions of Windows. For example, Windows 95 or 98 only
supports overlapped I/O for serial and parallel ports, while NT
- supports also files, disks, sockets, pipes, or mailslots.
+ also supports files, disks, sockets, pipes, or mailslots.
</para>
<para>
Wine implements overlapped I/O operations. This is mainly done by
- queueing in the server a request that will be triggered when
+ queuing in the server a request that will be triggered when
something the current state changes (like data available for a
read operation). This readiness is signaled to the calling
- processing by queueing a specific APC, which will be called within
+ processing by queuing a specific APC, which will be called within
the next waiting operation the thread will have. This specific
APC will then do the hard work of the I/O operation. This scheme
allows to put in place a wait mechanism, to attach a routine to be
@@ -1717,7 +1717,7 @@ if (res != ERROR_SUCCESS) return res;
paths. There's still need to cover it for devices. As a regular
file, devices are manipulated in Windows with both read / write
operations, but also control mechanisms (speed or parity of a serial
- line; volume name of a hard disk...). Since, this is also supported
+ line, volume name of a hard disk, ...). Since this is also supported
in Linux, there's also a need to open (in a Unix sense) a device
when given a Windows device name. This section applies to DOS device
names, which are seen in NT as nicknames to other devices.
@@ -1740,18 +1740,18 @@ if (res != ERROR_SUCCESS) return res;
<filename>C:</filename>), Wine first tries to get the Unix device
from the path <filename>$(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 tries whether
+ if this doesn't give a Unix device, Wine checks whether
<filename>$(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
- this doesn't exist (we're still handling the a device name of the
+ this doesn't exist (we're still handling a device name of the
<filename>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
directory can actually be found. One could have, for example, a CD
- Rom which he/she want only to use as audio CD player (ie never
+ 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
@@ -1845,10 +1845,10 @@ if (res != ERROR_SUCCESS) return res;
<para>
Now that we know which Unix device to open for a given Windows
device, let's cover the operation on it. Those operations can either
- be read / write, io control (and even others).
+ be read / write, IO control (and even others).
</para>
<para>
- Read and write operations are supported on Real disks & CDROM
+ Read and write operations are supported on real disks & CDROM
devices, under several conditions:
<itemizedlist>
<listitem>
@@ -1864,8 +1864,8 @@ if (res != ERROR_SUCCESS) return res;
</listitem>
<listitem>
<para>
- Blocks' size for read and write but be of the size of a
- physical block (generally 512 for a hard disk, depends on the
+ Block sizes for read and write must be of the size of a
+ physical block (generally 512 for a hard disk, depending on the
type of CD used), and offsets must also be a multiple of the
block size.
</para>
@@ -1884,8 +1884,8 @@ if (res != ERROR_SUCCESS) return res;
</para>
-->
<para>
- Wine also recognizes VxD as devices. But those VxD must be the
- Wine builtin ones (Wine will never allow to load native VxD). Those
+ 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
to the actual builtin DLL. This DLL exports a single entry point,
@@ -1915,7 +1915,7 @@ if (res != ERROR_SUCCESS) return res;
<filename>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
- others we haven's written about yet.
+ others we haven't written about yet.
</para>
</sect1>
@@ -1936,7 +1936,7 @@ if (res != ERROR_SUCCESS) return res;
Windows implements console solely in the Win32 subsystem. Under NT,
the real implementation uses a dedicated subsystem
<filename>csrss.exe</filename> Client/Server Run-time SubSystem)
- which is in charge, amont other things, of animating the consoles.
+ which is in charge, among other things, of animating the consoles.
Animating includes for example handling several processes on the
same console (write operations must be atomic, but also a character
keyed on the console must be read by a single process), or sending
@@ -1959,7 +1959,7 @@ if (res != ERROR_SUCCESS) return res;
the first one is a direct mapping of the Unix console into the
Windows environment. From the windows program point of view,
it won't run in a Windows console, but it will see its
- standard input and output streams redirected to files; thoses
+ standard input and output streams redirected to files; those
files are hooked into the Unix console's output and input
streams respectively. This is handy for running programs from
a Unix command line (and use the result of the program as it
@@ -2162,15 +2162,15 @@ if (res != ERROR_SUCCESS) return res;
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's screen buffers are waitable)
+ 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
<function>GetConsoleInputWaitHandle()</function> which returns the
handle to this event in case you need it. Another interesting
- handling of those console's handles is in
+ handling of those console handles is in
<function>ReadFile()</function>
(resp. <function>WriteFile()</function>), which behavior, for
- console's handles, is transferred to
+ console handles, is transferred to
<function>ReadConsole()</function> (resp.
<function>WriteConsole()</function>). Note that's always the ANSI
version of
@@ -2240,8 +2240,8 @@ if (res != ERROR_SUCCESS) return res;
<entry>FontSize</entry>
<entry>0x0C08</entry>
<entry>
- The high word in the font's cell height, and the low word
- is the font cell's width. The default value is 12 pixels
+ The high word in the font cell height, and the low word
+ is the font cell width. The default value is 12 pixels
in height and 8 pixels in width.
</entry>
</row>
@@ -2272,7 +2272,7 @@ if (res != ERROR_SUCCESS) return res;
<entry>0</entry>
<entry>
This mask only exists for Wine console handling. It
- allows to know which combination of extra keys are need to
+ allows to know which combination of extra keys is needed to
open the configuration window on right click. The mask
can include <constant>MK_CONTROL</constant> or
<constant>MK_SHIFT</constant> bits. This can be needed
@@ -2468,7 +2468,7 @@ if (res != ERROR_SUCCESS) return res;
Wine, when running a DOS programs, needs to map the 1 MB of virtual
memory to the real memory (as seen by the DOS program). When this is
not possible (like when someone else is already using this area), the
- DOS support is not possible. Not also that by doing so, access to
+ DOS support is not possible. Note also that by doing so, access to
linear address 0 is enabled (as it's also real mode address 0 which is
valid). Hence, NULL pointer dereference faults are no longer caught.
</para>
diff --git a/en/winedev-multimedia.sgml b/en/winedev-multimedia.sgml
index 3ba4de3..95537af 100644
--- a/en/winedev-multimedia.sgml
+++ b/en/winedev-multimedia.sgml
@@ -213,7 +213,7 @@ Kernel space | Client applications
</para>
<para>
- Wine's WinMM automatically adapts the messages to be sent to
+ Wine WinMM automatically adapts the messages to be sent to
a driver so that it can convert it to 16 or 32 bit
interfaces.
</para>
@@ -240,17 +240,17 @@ Kernel space | Client applications
<para>
There are two specific low level drivers (msacm.drv for wave input/output,
midimap.drv for MIDI output only). These drivers (also present
- in Windows) allow:
+ in Windows):
<itemizedlist>
<listitem>
<para>
- choosing one low level driver between many (we'll
+ allow to choose one low level driver between many (we'll
discuss how the choice is made later on)
</para>
</listitem>
<listitem>
<para>
- add the possibility to convert stream's format (ie ADPCM =>
+ add the possibility to convert stream format (i.e. ADPCM =>
PCM) (this is useful if the format required by the
application for playback isn't supported by the soundcard).
</para>
@@ -309,7 +309,7 @@ Kernel space | Client applications
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 MSACM32 DLL.
</para>
<para>
@@ -339,7 +339,7 @@ Kernel space | Client applications
<para>
A built-in MIDI mapper can be found in
<filename>dlls/winmm/midimap/</filename>. It partly provides
- the same functionality as the Windows' one. It allows to
+ 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
bits for more details).
@@ -412,6 +412,9 @@ Kernel space | Client applications
</tbody>
</tgroup>
</table>
+ </para>
+
+ <para>
The MCI Name column is the name of the MCI driver, as it is
searched in configuration. The DLL Name column is the name of
the DLL the configuration provides as a value. The name listed
@@ -423,7 +426,7 @@ Kernel space | Client applications
Adding a new MCI driver is just a matter of writing the
corresponding DLL with the correct interface (see existing MCI
drivers for the details), and to provide the relevant setup
- information for <filename>wine.inf</filename>
+ information for <filename>wine.inf</filename>.
</para>
</sect1>
@@ -498,7 +501,7 @@ Kernel space | Client applications
<title>Contents</title>
<para>
- The MSACM32 (and its 16 bit sibbling MSACM) provide a way to
+ The MSACM32 (and its 16 bit sibling MSACM) provide 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
@@ -507,8 +510,8 @@ Kernel space | Client applications
</para>
<para>
- There's nothing specific in Wine's implementation compared
- to Windows' one. Here's however a list of the builtin format
+ There's nothing specific in Wine implementation compared
+ to Windows one. Here's however a list of the builtin format
change drivers (there's no filter driver yet):
<table frame="all">
<title>Wine ACM drivers</title>
@@ -526,16 +529,16 @@ Kernel space | Client applications
</row>
<row>
<entry>msadp32</entry>
- <entry>Microsoft's ADPCM (adaptative PCM)</entry>
+ <entry>Microsoft ADPCM (adaptative PCM)</entry>
</row>
<row>
<entry>msg711</entry>
- <entry>Microsoft's G.711 (A-Law and µ-Law)</entry>
+ <entry>Microsoft G.711 (A-Law and μ-Law)</entry>
</row>
<row>
<entry>winemp3</entry>
<entry>
- Wine's MP3 (MPEG Layer 3), based on mpglib library
+ Wine MP3 (MPEG Layer 3), based on mpglib library
</entry>
</row>
</tbody>
@@ -549,7 +552,7 @@ Kernel space | Client applications
</para>
<para>
- All builtin ACM drivers are 32 bit Unicode DLLs
+ All builtin ACM drivers are 32 bit Unicode DLLs.
</para>
</sect2>
@@ -615,7 +618,7 @@ Kernel space | Client applications
<title>Contents</title>
<para>
- The MSVFW32 (and its 16 bit sibbling MSVIDEO) provide
+ The MSVFW32 (and its 16 bit sibling MSVIDEO) provide
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
@@ -623,8 +626,8 @@ Kernel space | Client applications
</para>
<para>
- There's nothing specific in Wine's implementation compared
- to Windows' one. Here's however a list of the builtin
+ There's nothing specific in Wine implementation compared
+ to Windows one. Here's however a list of the builtin
decoding drivers:
<table frame="all">
<title>Wine VIDC drivers</title>
@@ -638,11 +641,11 @@ Kernel space | Client applications
<tbody>
<row>
<entry>msrle32</entry>
- <entry>Microsoft's RLE (Run-Length encoded)</entry>
+ <entry>Microsoft RLE (Run-Length encoded)</entry>
</row>
<row>
<entry>msvidc32</entry>
- <entry>Microsoft's Video-1</entry>
+ <entry>Microsoft Video-1</entry>
</row>
<row>
<entry>iccvid</entry>
@@ -658,7 +661,7 @@ Kernel space | Client applications
</para>
<para>
- All builtin VIDC drivers are 32 bit Unicode DLLs
+ All builtin VIDC drivers are 32 bit Unicode DLLs.
</para>
</sect2>
@@ -674,7 +677,7 @@ Kernel space | Client applications
<listitem>
<para>
In the early days on Windows 3.x, configuration was
- stored in <filename>system.in</filename> file, under
+ stored in <filename>system.ini</filename> file, under
various sections (<literal>[drivers]</literal> for low
level drivers, <literal>[mci]</literal>
(resp. <literal>[mci32]</literal>) for 16 bit (resp. 32
@@ -715,7 +718,7 @@ HKLM\Software\Microsoft\Windows NT\CurrentVersion
An out-of-the-box configuration is provided in
<filename>wine.inf</filename>, and shall be stored in registry
and <filename>system.ini</filename> at Wine installation
- time. It will setup correctly the MCI drivers' configuration
+ time. It will setup correctly the MCI drivers configuration
(as well as the wave and MIDI mappers). As the low-level
drivers depend on hardware, their setup will be handled by
<filename>winecfg</filename>.
@@ -784,7 +787,7 @@ HKLM\Software\Microsoft\Windows NT\CurrentVersion
<para>
The following sections describe which type of information
- (depending on the location) Wine's multimedia DLLs understand.
+ (depending on the location) Wine multimedia DLLs understand.
</para>
<sect2>
@@ -833,7 +836,7 @@ HKLM\Software\Microsoft\Windows NT\CurrentVersion
</para>
<para>
- ACM drivers' configuration is read (only so far) from the
+ ACM drivers configuration is read (only so far) from the
<filename>system.ini</filename> (and setup at Wine
installation from the <filename>wine.inf</filename> file).
<screen>
@@ -846,7 +849,7 @@ HKLM\Software\Microsoft\Windows NT\CurrentVersion
</para>
<para>
- Video (aka vidc) drivers' configuration is read (only so
+ Video (aka vidc) drivers configuration is read (only so
far) from the <filename>system.ini</filename> (and setup at
Wine installation from the <filename>wine.inf</filename>
file).
diff --git a/en/winedev-ole.sgml b/en/winedev-ole.sgml
index 0a80c7f..50e77bd 100644
--- a/en/winedev-ole.sgml
+++ b/en/winedev-ole.sgml
@@ -45,7 +45,7 @@
Unfortunately the layout of the virtual table is compiler
specific, the layout of g++ virtual tables is not the same
as that of an egcs virtual table which is not the same as
- that generated by Visual C++. There are work arounds to make
+ that generated by Visual C++. There are workarounds to make
the virtual tables compatible via padding but unfortunately
the one which is imposed to the Wine emulator by the Windows
binaries, i.e. the Visual C++ one, is the most compact of
@@ -496,7 +496,7 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
Platform SDK ships with a tool called "midl" which is an IDL compiler.
IDL or the "Interface Definition Language" is a tool designed
specifically for describing interfaces in a reasonably language neutral
- fashion, though in reality it bears a close resemblence to C++.
+ fashion, though in reality it bears a close resemblance to C++.
</para>
<para>
@@ -583,7 +583,7 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
<para>
When DCOM creates an object on a remote machine, the DCOM runtime on
that machine activates the object in the usual way (by looking it up in
- the registry etc) and then marshals the requested interface back to the
+ the registry etc) and then marshalls the requested interface back to the
client. Marshalling an interface takes a pointer, and produces a buffer
containing all the information DCOM needs to construct a proxy object in
the client, a stub object in the server and link the two together.
@@ -686,7 +686,8 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
</para>
<para>
- On this topic, Ove Kaaven says: It depends on the Windows version, I
+ On this topic, Ove KÃ¥ven says:
+ <blockquote><para>It depends on the Windows version, I
think. Windows 95 and Windows NT 4 certainly had very different models
when I looked. I'm pretty sure the Windows 98 version of RPCRT4 was
able to dispatch messages directly to individual apartments. I'd be
@@ -700,7 +701,8 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
old patch of mine, I let the COM/OLE dlls do the apartment dispatch,
but even then, the RPC runtime was always involved. After all, it
could be quite tricky to tell whether the call is merely interthread,
- without involving the RPC runtime...
+ without involving the RPC runtime...</para>
+ </blockquote>
</para>
<para>
@@ -725,7 +727,7 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
here. The important thing is that eventually a _StubReaderThread is
started which accepts marshalled DCOM RPCs, and then passes them to
IRpcStubBuffer::Invoke on the correct stub object which in turn
- demarshals the packet and performs the call. The threads started by our
+ demarshalls the packet and performs the call. The threads started by our
implementation of DCOM are never terminated, they just hang around until
the process dies.
</para>
@@ -759,7 +761,7 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
a parallel line of COM development known as "OLE Automation", but let's
not get into that here. Type libraries are basically binary IDL files,
except that despite there being two type library formats neither of them
- can fully express everything expressable in IDL. Anyway, with a type
+ can fully express everything expressible in IDL. Anyway, with a type
library (which can be embedded as a resource into a DLL) you have
another option beyond compiling MIDL output - you can set the
ProxyStubClsId32 registry entry for your interfaces to the CLSID of the
@@ -793,7 +795,7 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
<para>
Before a thread can use COM it must enter an apartment. Apartments are
an abstraction of a COM objects thread safety level. There are many types
- of apartment but the only two we care about right now are single threaded
+ of apartments but the only two we care about right now are single threaded
apartments (STAs) and the multi-threaded apartment (MTA).
</para>
@@ -813,7 +815,7 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
<para>
An object in the multi-threaded apartment may be accessed concurrently by
- multiple threads: eg, it's supposed to be entirely thread safe. It must also
+ multiple threads, e.g. it's supposed to be entirely thread safe. It must also
not care about thread-affinity, the object should react the same way no matter
which thread is calling it.
</para>
@@ -865,7 +867,7 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
After the SORF flags comes a count of the references represented by this marshaled
interface. Typically this will be 5 in the case of a normal marshal, but may be 0
for table-strong and table-weak marshals (the difference between these is explained below).
- The reasoning is this: In the general case, we want to know exactly when an object
+ The reasoning is this: in the general case, we want to know exactly when an object
is unmarshaled and released, so we can accurately control the lifetime of the stub
object. This is what happens when cPublicRefs is zero. However, in many cases, we
only want to unmarshal an object once. Therefore, if we strengthen the rules to say
@@ -977,7 +979,7 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
<para>
There is one IRemUnknown implementation per apartment, not per
stub manager as you might expect. This is OK because IPIDs are
- apartment not object scoped (In fact, according to the DCOM draft
+ apartment not object scoped (in fact, according to the DCOM draft
spec, they are machine-scoped, but this implies apartment-scoped).
</para>
</sect2>
@@ -1078,7 +1080,7 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
<title>Wrapup</title>
<para>
- Theres are still a lot of topics that have not been covered:
+ There are still a lot of topics that have not been covered:
</para>
<itemizedlist>
diff --git a/en/winedev-opengl.sgml b/en/winedev-opengl.sgml
index c953e96..c347984 100644
--- a/en/winedev-opengl.sgml
+++ b/en/winedev-opengl.sgml
@@ -6,8 +6,7 @@
<para>
Basically, if you have a Linux OpenGL ABI compliant libGL
- (<ulink url="http://oss.sgi.com/projects/ogl-sample/ABI/">
- http://oss.sgi.com/projects/ogl-sample/ABI/</ulink>)
+ (<ulink url="http://oss.sgi.com/projects/ogl-sample/ABI/"></ulink>)
installed on your computer, you should have everything
that is needed.
</para>
@@ -25,7 +24,7 @@
<title>Header files</title>
<para>
- The needed header files to build OpenGL support in Wine are :
+ The needed header files to build OpenGL support in Wine are:
</para>
<variablelist>
@@ -58,9 +57,8 @@
<para>
The latter file (<filename>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">
- http://oss.sgi.com/projects/ogl-sample/ABI/glext.h</ulink>),
+ easily obtained from SGI
+ (<ulink url="http://oss.sgi.com/projects/ogl-sample/ABI/glext.h"></ulink>),
and that all OpenGL should provide one, I decided to keep it here.
</para>
</sect2>
@@ -92,8 +90,8 @@
<para>
The core OpenGL function calls are the same between Windows
- and Linux. So what is the difficulty to support it in Wine ?
- Well, there are two different problems :
+ and Linux. So what is the difficulty to support it in Wine?
+ Well, there are two different problems:
</para>
<orderedlist>
@@ -118,7 +116,7 @@
<para>
Add to this some brain-dead programs (using GL calls without
- setting-up a context or deleting three time the same context)
+ setting-up a context or deleting three times the same context)
and you have still some work to do :-)
</para>
@@ -126,13 +124,13 @@
<title>The Windowing system integration</title>
<para>
- This integration is done at two levels :
+ This integration is done at two levels:
</para>
<orderedlist>
<listitem>
<para>
- At GDI level for all pixel format selection routines (ie
+ At GDI level for all pixel format selection routines (i.e.
choosing if one wants a depth / alpha buffer, the size
of these buffers, ...) and to do the 'page flipping' in
double buffer mode. This is implemented in
@@ -156,8 +154,8 @@
<para>
The thunks are the Wine code that does the calling
convention translation and they are auto-generated by a Perl
- script. In Wine's Git tree, these thunks are already
- generated for you. Now, if you want to do it yourself, there
+ script. In Wine Git tree, these thunks are already
+ generated for you. Now, if you want to do it yourself, here
is how it all works....
</para>
<para>
@@ -173,7 +171,7 @@
</para>
<para>
- This script generates three files :
+ This script generates three files:
</para>
<orderedlist>
@@ -190,7 +188,7 @@
<para>
<filename>opengl_norm.c</filename> contains all the
thunks for the 'core' functions. Your OpenGL library
- must provide ALL the function used in this file as these
+ must provide ALL the functions used in this file as these
are not queried at run time.
</para>
</listitem>
@@ -228,10 +226,10 @@ Please report (lionel.ulmer at free.fr) !
<para>
This means that the extension requested by the application
- is found in the libGL used by Linux (ie the call to
+ is found in the libGL used by Linux (i.e. the call to
<function>glXGetProcAddressARB</function> returns a
non-<constant>NULL</constant> pointer) but that this string
- was NOT found in Wine's extension registry.
+ was NOT found in Wine extension registry.
</para>
<para>
This can come from two causes:
@@ -272,13 +270,13 @@ Please report (lionel.ulmer at free.fr) !
OpenGL library does not provide.
</para>
<para>
- To check for this, do the following steps :
+ To check for this, do the following steps:
</para>
<orderedlist>
<listitem>
<para>
- create a dummy <filename>.c</filename> file :
+ create a dummy <filename>.c</filename> file:
</para>
<programlisting>
int main(void)
@@ -292,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>/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-otherdebug.sgml b/en/winedev-otherdebug.sgml
index 9ac7bcc..0543e4e 100644
--- a/en/winedev-otherdebug.sgml
+++ b/en/winedev-otherdebug.sgml
@@ -300,7 +300,7 @@ 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>filename> files in order to start
+ <filename>*.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
diff --git a/en/winedev-testing.sgml b/en/winedev-testing.sgml
index 2f5dcab..940ae49 100644
--- a/en/winedev-testing.sgml
+++ b/en/winedev-testing.sgml
@@ -9,7 +9,7 @@
applications to crash or misbehave in some way.
</para>
<para>
- The question becomes, "How do we ensure compliance with that standard?"
+ The question becomes, "How do we ensure compliance with that standard?".
The answer is, "By using the API documentation available to us and
backing that up with conformance tests." Furthermore, a conformance
test suite is the most accurate (if not necessarily the most complete)
@@ -116,7 +116,7 @@
For instance you could create an edit control and use WM_SETTEXT to
set its contents, possibly check length restrictions, and verify the
results using WM_GETTEXT. Similarly one could create a listbox and
- check the effect of LB_DELETESTRING on the list's number of items,
+ check the effect of LB_DELETESTRING on the number of items of the list,
selected items list, highlighted item, etc. For concrete examples,
see <filename>dlls/user32/tests/win.c</> and the related tests.
</para>
@@ -139,7 +139,7 @@
</para>
<para>
The tests for a specific Wine library are located in a 'tests'
- directory in that library's directory. Each test is contained in a
+ subdirectory of the library directory. Each test is contained in a
file (e.g. <filename>dlls/kernel/tests/thread.c</>). Each
file itself contains many checks concerning one or more related APIs.
</para>
@@ -267,7 +267,7 @@ thread.c: 86 tests executed, 5 marked as todo, 0 failures.
Visual Studio 6.0 Standard Edition, and with the Visual Studio 6
Service Pack 6. If you are using Visual Studio 7 or greater you
do not need the processor pack. In either case it is recommended
- to the most recent compatible Visual Studio
+ to use the most recent compatible Visual Studio
<ulink url="http://msdn.microsoft.com/vstudio/downloads/updates/sp/">service pack</>.
If are using Visual Studio Express and you need specific libraries like
<filename>ntdll.lib</> that don't ship with Visual Studio Express, you will need the
@@ -305,7 +305,7 @@ thread.c: 86 tests executed, 5 marked as todo, 0 failures.
<ulink url="http://www.microsoft.com/msdownload/platformsdk/sdkupdate/">Platform SDK</>
as well as the latest <ulink url="http://msdn.microsoft.com/library/default.asp?url=/downloads/list/directx.asp">DirectX SDK</>.
Then, <ulink url="http://msdn.microsoft.com/library/default.asp?url=/library/EN-US/sdkintro/sdkintro/installing_the_platform_sdk_with_visual_studio.asp">configure Visual Studio</>
- to use these SDK's headers and libraries. Alternately you could go
+ to use these SDK headers and libraries. Alternately you could go
to the <menuchoice><guimenu>Project</> <guimenu>Settings...</></>
menu and modify the settings appropriately, but you would then
have to redo this whenever you rerun msvcmaker.
@@ -340,8 +340,8 @@ thread.c: 86 tests executed, 5 marked as todo, 0 failures.
<sect2>
<title>With MinGW</title>
<para>
- Wine's build system already has support for building tests with a MinGW
- cross-compiler. See the section above called 'Setup of the MinGW
+ Wine build system already has support for building tests with a MinGW
+ cross-compiler. See the section above called 'Setup of the MinGW
cross-compiling environment' for instructions on how to set things up.
When you have a MinGW environment installed all you need to do is rerun
configure and it should detect the MinGW compiler and tools. Then run
@@ -363,8 +363,8 @@ thread.c: 86 tests executed, 5 marked as todo, 0 failures.
</para></listitem>
<listitem><para>
Make a directory <filename>wine</> underneath your work directory,
- and copy the file <filename>wine/test.h</> from the Wine source tree there.
- (You can download this file from the latest revision at
+ and copy the file <filename>wine/test.h</> 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">
http://source.winehq.org/git/?p=wine.git;a=blob_plain;f=include/wine/test.h</>).
</para></listitem>
@@ -389,7 +389,7 @@ thread.c: 86 tests executed, 5 marked as todo, 0 failures.
If you want to use the Microsoft C++ Toolkit under Wine,
install it under Windows, then copy it to your fake C drive;
it'll work fine there. See <ulink url="http://kegel.com/wine/cl-howto.html">CL Howto</>
- for some tips on making it easy to use from the Linux commandline.
+ for some tips on making it easy to use from the Linux command line.
</para></listitem>
</itemizedlist>
</para>
@@ -424,7 +424,7 @@ START_TEST(paths)
</screen>
</para>
<para>
- The test's entry point is the START_TEST section. This is where
+ The test entry point is the START_TEST section. This is where
execution will start. You can put all your tests in that section but
it may be better to split related checks in functions you will call
from the START_TEST section. The parameter to START_TEST must match
@@ -598,7 +598,7 @@ ok ( GetLastError() == WIN9X_ERROR || GetLastError() == NT_ERROR, ...);
If an API is only present on some Windows platforms, then use
LoadLibrary and GetProcAddress to check if it is implemented and
invoke it. Remember, tests must run on all Windows platforms.
- Similarly, conformance tests should nor try to correlate the Windows
+ Similarly, conformance tests should not try to correlate the Windows
version returned by GetVersion with whether given APIs are
implemented or not. Again, the goal of Wine is to run Windows
applications (which do not do such checks), and not be a clone of a
diff --git a/en/winedev-windowing.sgml b/en/winedev-windowing.sgml
index 10ddf5b..fe24ebc 100644
--- a/en/winedev-windowing.sgml
+++ b/en/winedev-windowing.sgml
@@ -264,7 +264,7 @@ child1->popup->child2->child3->wnd1->child4->wnd2->desktop.
task/thread sleeps until messages appear.
</para>
<para>
- There are several tricky moments (open for discussion) -
+ There are several tricky moments (open for discussion):
</para>
<itemizedlist>
--
1.8.2
More information about the wine-patches
mailing list