[docs] [2/3] winedev: Typo and minor grammatical fixes
Kevin Lyles
kevinlyles at gmail.com
Mon Aug 13 23:46:53 CDT 2012
>From 84599b449976d0ea4e25d5e2f2796cba13bad91d Mon Sep 17 00:00:00 2001
From: Kevin Lyles <kevinlyles at gmail.com>
Date: Sun, 12 Aug 2012 15:32:48 -0500
Subject: winedev: Typo and minor grammatical fixes
---
en/winedev-graphical.sgml | 4 +-
en/winedev-kernel.sgml | 91 +++++++++++++++++++++++----------------------
en/winedev-opengl.sgml | 4 +-
en/winedev-windowing.sgml | 22 +++++-----
4 files changed, 62 insertions(+), 59 deletions(-)
diff --git a/en/winedev-graphical.sgml b/en/winedev-graphical.sgml
index 8524991..bc0d5fe 100644
--- a/en/winedev-graphical.sgml
+++ b/en/winedev-graphical.sgml
@@ -12,13 +12,13 @@
display concurrently. It is possible to compile the X
libraries to perform their own synchronization (initiated
by calling <function>XInitThreads()</function>). However,
- Wine does not use this approach. Instead Wine performs its
+ Wine does not use this approach. Instead, Wine performs its
own synchronization using the
<function>wine_tsx11_lock()</function> /
<function>wine_tsx11_unlock()</function>
functions. This locking protects library access
with a critical section, and also arranges things so that
X libraries compiled without <option>-D_REENTRANT</option>
- (eg. with global <varname>errno</varname> variable) will
+ (e.g. with global <varname>errno</varname> variable) will
work with Wine.
</para>
<para>
diff --git a/en/winedev-kernel.sgml b/en/winedev-kernel.sgml
index 31dcb75..a9a26ba 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">
@@ -186,7 +186,7 @@ ExitProcess( entry( peb ) );
</programlisting>
<para>
- ... jumps to the entry point of the program. At this point the users
+ ... jumps to the entry point of the program. At this point the user's
program is running and the API provided by Wine is ready to be
used. When entry returns, the <function>ExitProcess()</function> API
will be used to initialize a graceful shutdown.
@@ -250,7 +250,7 @@ ExitProcess( entry( peb ) );
</para>
<para>
- The exec-shield patch increases security by randomizing the kernels
+ The exec-shield patch increases security by randomizing the kernel's
mmap algorithms. Rather than consistently choosing the same addresses
given the same sequence of requests, the kernel will now choose
randomized addresses. Because the Linux dynamic linker
@@ -434,7 +434,7 @@ ExitProcess( entry( peb ) );
<sect2>
<title>Creating a child process from a running process</title>
<para>
- The steps used are closely link to what is done in the previous case.
+ The steps used are closely linked to what is done in the previous case.
</para>
<para>
There are however a few points to look at a bit more closely. The
@@ -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
@@ -782,7 +782,7 @@ if (res != ERROR_SUCCESS) return res;
<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>
@@ -838,7 +838,7 @@ if (res != ERROR_SUCCESS) return res;
its stack it triggers a fault on the stack guard page. The language
runtime can use this to grow the stack if it wants to.
- <!-- fixme: is it really the language runtime that does this? i
+ <!-- FIXME: is it really the language runtime that does this? I
can't find any code in Wine to reallocate the stack on
STATUS_GUARD_PAGE_VIOLATION -->
@@ -1042,7 +1042,7 @@ if (res != ERROR_SUCCESS) return res;
<filename>c:bar</filename> is a drive relative path. Note
that the case where <filename>c:</filename> is the drive of
the current directory is rather easy; it's implemented the
- same way as the case just below (relative path). In the rest
+ same way as the case just above (relative path). In the rest
of this chapter, drive relative path will only cover the case
where the drive in the path isn't the drive of the default
directory. The resolution of this to a full pathname defers
@@ -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 backwards. 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 -,
@@ -1090,14 +1090,14 @@ if (res != ERROR_SUCCESS) return res;
mechanism (through environment variables) is implemented
on <command>CMD.EXE</command>, where those variables are
set when you change directories with the
- <command>cd</command>. Since environment variables are
- inherited at process creation, the current directories
+ <command>cd</command> 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
mechanism (in <filename>NTDLL</filename> or
- <filename>KERNEL32</filename>) to set up, when current
+ <filename>KERNEL32</filename>) to set up, when the current
directory changes, the relevant environment variables.
- This behavior is clearly band-aid, not a full featured
+ This behavior is clearly a band-aid, not a full featured
extension of current directory behavior.
</para>
</listitem>
@@ -1212,7 +1212,7 @@ if (res != ERROR_SUCCESS) return res;
</msgtext>
</entry>
<entry>
- <msgtext>
+ <msgtext>
<para>
<itemizedlist>
<listitem>
@@ -1621,7 +1621,7 @@ if (res != ERROR_SUCCESS) return res;
Wine server, where the fd is stored. Then, Wine (on client side)
uses <function>recvmsg()</function> to pass the fd from the wine
server process to the client process. Since this operation could
- be lengthy, Wine implement some kind of cache mechanism to send it
+ be lengthy, Wine implements some kind of cache mechanism to send it
only once, but getting a fd from a handle on a file (or any other
Unix object which can be manipulated through a file descriptor)
still requires a round trip to the Wine server.
@@ -1657,7 +1657,7 @@ if (res != ERROR_SUCCESS) return res;
<sect4>
<title>Buffering</title>
<para>
- Wine doesn't do any buffering on file accesses but rely on the
+ Wine doesn't do any buffering on file accesses but relies on the
underlying Unix kernel for that (when possible). This scheme is
needed because it's easier to implement multiple accesses on the
same file at the kernel level, rather than at Wine levels. Doing
@@ -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>
@@ -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.
@@ -1761,7 +1761,7 @@ if (res != ERROR_SUCCESS) return res;
<filename>LPT1</filename> up to <filename>LPT9</filename>), then
Wine tries to open the Nth serial (resp. printer) in the system.
Otherwise, some basic old DOS name support is done
- <filename>AUX</filename> is transformed into
+ (<filename>AUX</filename> is transformed into
<filename>COM1</filename> and <filename>PRN</filename> into
<filename>LPT1</filename>), and the whole process is retried with
those new names.
@@ -1783,7 +1783,7 @@ if (res != ERROR_SUCCESS) return res;
<tbody>
<row>
<entry><filename><any_path>AUX</filename></entry>
- <entry<filename>>\Global??\AUX</filename></entry>
+ <entry><filename>\Global??\AUX</filename></entry>
<entry>
Treated as an alias to <filename>COM1</filename>
</entry>
@@ -1844,7 +1844,7 @@ if (res != ERROR_SUCCESS) return res;
</para>
<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
+ device, let's cover the operations on it. Those operations can either
be read / write, io control (and even others).
</para>
<para>
@@ -1864,7 +1864,7 @@ if (res != ERROR_SUCCESS) return res;
</listitem>
<listitem>
<para>
- Blocks' size for read and write but be of the size of a
+ Blocks' size for read and write must be of the size of a
physical block (generally 512 for a hard disk, depends on the
type of CD used), and offsets must also be a multiple of the
block size.
@@ -1885,16 +1885,16 @@ if (res != ERROR_SUCCESS) return res;
-->
<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 builtin ones (Wine will never allow loading native VxD). 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,
- that Wine will use when a call to
+ which Wine will use when a call to
<function>DeviceIoControl</function> is made, with a handle opened
to this VxD. This allows to provide some kind of compatibility for
old Win9x apps, still talking directly to VxD. This is no longer
- supported on Windows NT, newest programs are less likely to make use
- of this feature, so we don't expect lots of development in this
+ supported on Windows NT, and newer programs are less likely to make
+ use of this feature, so we don't expect lots of development in this
area, even though the framework is there and working. Note also that
Wine doesn't provide support for native VxDs (as a game, report how
many times this information is written in the documentation; as an
@@ -1914,8 +1914,8 @@ if (res != ERROR_SUCCESS) return res;
quite often a bit wider semantics than their
<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.
+ implemented in <filename>NTDLL</filename>, plus a great number of
+ others we haven't written about yet.
</para>
</sect1>
@@ -2073,7 +2073,8 @@ if (res != ERROR_SUCCESS) return res;
<entry>Fully supported</entry>
<entry>
Partly supported (this won't work too well as we don't
- control (so far) the size of underlying Unix terminal
+ control (so far) the size of the underlying Unix
+ terminal)
</entry>
</row>
<row>
@@ -2090,7 +2091,8 @@ if (res != ERROR_SUCCESS) return res;
<entry>Fully supported</entry>
<entry>
Partly supported (this won't work too well as we don't
- control (so far) the size of underlying Unix terminal
+ control (so far) the size of the underlying Unix
+ terminal)
</entry>
</row>
<row>
@@ -2163,7 +2165,7 @@ if (res != ERROR_SUCCESS) return res;
<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)
- into a dedicated wait event for the targetted console. There's an
+ into a dedicated wait event for the targeted 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
@@ -2186,8 +2188,8 @@ if (res != ERROR_SUCCESS) return res;
preferences of the console as Windows does. Those settings can
either be defined globally, or on a per process name basis.
<command>wineconsole</command> provides the choice to the user to
- pick you which registry part (global, current running program) it
- wishes to modify the settings for.
+ pick which registry part (global, current running program) they
+ wish to modify the settings for.
<table>
<title>Console registry settings</title>
<tgroup cols="3" align="left">
@@ -2203,7 +2205,7 @@ if (res != ERROR_SUCCESS) return res;
<entry>CursorSize</entry>
<entry>25</entry>
<entry>
- Percentage of cell height to which the cursor extents
+ Percentage of cell height to which the cursor extends
</entry>
</row>
<row>
@@ -2233,24 +2235,24 @@ if (res != ERROR_SUCCESS) return res;
<entry>
Name of the font to be used for display. When none is
given, <command>wineconsole</command> tries its best to
- pick up a decent font
+ pick a decent font.
</entry>
</row>
<row>
<entry>FontSize</entry>
<entry>0x0C08</entry>
<entry>
- The high word in the font's cell height, and the low word
+ The high word is the font's cell height, and the low word
is the font cell's width. The default value is 12 pixels
- in height and 8 pixels in width.
+ high and 8 pixels wide.
</entry>
</row>
<row>
<entry>FontWeight</entry>
<entry>0</entry>
<entry>
- Weigth of the font. If none is given (or 0)
- <command>wineconsole</command> picks up a decent font size
+ Weigth of the font. If none (or 0) is given
+ <command>wineconsole</command> picks a decent font size.
</entry>
</row>
<row>
@@ -2264,7 +2266,8 @@ if (res != ERROR_SUCCESS) return res;
<entry>HistoryNoDup</entry>
<entry>0</entry>
<entry>
- Whether the history should store twice the same entry
+ Whether the history should store the same entry more than
+ once
</entry>
</row>
<row>
@@ -2285,11 +2288,11 @@ if (res != ERROR_SUCCESS) return res;
<entry>QuickEdit</entry>
<entry>0</entry>
<entry>
- If null, mouse events are sent to the application. If non
+ If null, mouse events are sent to the application. If non-
null, mouse events are used to select text on the window.
- This setting must really be set on a application per
- application basis, because it deals with the fact the CUI
- application will use or not the mouse events.
+ This setting must really be set on a per-application
+ basis, because it deals with whether or not the CUI
+ application will use the mouse events.
</entry>
</row>
<row>
diff --git a/en/winedev-opengl.sgml b/en/winedev-opengl.sgml
index d26b742..5f9cb0a 100644
--- a/en/winedev-opengl.sgml
+++ b/en/winedev-opengl.sgml
@@ -118,7 +118,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 the same context three times)
and you have still some work to do :-)
</para>
@@ -132,7 +132,7 @@
<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
diff --git a/en/winedev-windowing.sgml b/en/winedev-windowing.sgml
index 10ddf5b..270699a 100644
--- a/en/winedev-windowing.sgml
+++ b/en/winedev-windowing.sgml
@@ -18,7 +18,7 @@
<para><filename>windows/win.c</filename></para>
<para><filename>windows/winpos.c</filename></para>
<para>
- Windows are arranged into parent/child hierarchy with one
+ Windows are arranged into a parent/child hierarchy with one
common ancestor for all windows (desktop window). Each
window structure contains a pointer to the immediate
ancestor (parent window if <constant>WS_CHILD</constant>
@@ -46,14 +46,14 @@
Horizontal arrows denote sibling relationship, vertical
lines - ancestor/child. To summarize, all windows with the
same immediate ancestor are sibling windows, all windows
- which do not have desktop as their immediate ancestor are
- child windows. Popup windows behave as topmost top-level
+ which do not have the desktop as their immediate ancestor are
+ child windows. Popup windows behave as top-level
windows unless they are owned. In this case the only
requirement is that they must precede their owners in the
top-level sibling list (they are not topmost). Child
windows are confined to the client area of their parent
- windows (client area is where window gets to do its own
- drawing, non-client area consists of caption, menu,
+ windows. The client area is where a window gets to do its own
+ drawing; the non-client area consists of caption, menu,
borders, intrinsic scrollbars, and
minimize/maximize/close/help buttons).
</para>
@@ -80,9 +80,9 @@
child1->popup->child2->child3->wnd1->child4->wnd2->desktop.
</para>
<para>
Wine specifics: in default and managed mode each top-level
- window gets its own X counterpart with desktop window
+ window gets its own X counterpart with the desktop window
being basically a fake stub. In desktop mode, however,
- only desktop window has an X window associated with it.
+ only the desktop window has an X window associated with it.
Also, <function>SetWindowPos()</function> should
eventually be implemented via
<function>Begin/End/DeferWindowPos()</function> calls and
@@ -154,14 +154,14 @@
child1->popup->child2->child3->wnd1->child4->wnd2->desktop.
became visible it adds this area to the update region of this
window and then generates <constant>WM_ERASEBKGND</constant> and
<constant>WM_PAINT</constant> messages. In addition,
- <constant>WM_NCPAINT</constant> message is sent when the
+ the <constant>WM_NCPAINT</constant> message is sent when the
uncovered area intersects a nonclient part of the window.
Application must reply to the <constant>WM_PAINT</constant>
message by calling the
<function>BeginPaint()</function>/<function>EndPaint()</function>
pair of functions. <function>BeginPaint()</function> returns a DC
that uses accumulated update region as a clipping region. This
- operation cleans up invalidated area and the window will not
+ operation cleans up the invalidated area and the window will not
receive another <constant>WM_PAINT</constant> until the window
manager creates a new update region.
</para>
@@ -258,7 +258,7 @@
child1->popup->child2->child3->wnd1->child4->wnd2->desktop.
(<constant>WM_NCPAINT</constant> too if the update region
intersects with the non-client area). A timer event is
raised when one of the queue timers expire. Depending on
- the timer parameters <function>DispatchMessage</function>
+ the timer parameters, <function>DispatchMessage</function>
either calls the callback function or the window
procedure. If there are no messages pending the
task/thread sleeps until messages appear.
@@ -288,7 +288,7 @@
child1->popup->child2->child3->wnd1->child4->wnd2->desktop.
<blockquote>
<attribution>by David Charlap</attribution>
<para>
- " Here's the problem in a nutshell, and there is no
+ "Here's the problem in a nutshell, and there is no
good solution. Every possible solution creates a
different problem.
</para>
--
1.7.8.6
More information about the wine-patches
mailing list