Minor documentation typos

[Bill Medland]

Bill Medland (billmedland at mercuryspeed.com)
Correct a couple of minor documentation typos

Index: wine/documentation/threading.sgml
===================================================================
RCS file: /home/wine/wine/documentation/threading.sgml,v
retrieving revision 1.2
diff -u -r1.2 threading.sgml
--- wine/documentation/threading.sgml	15 Jun 2004 18:26:52 -0000	1.2
+++ wine/documentation/threading.sgml	23 Feb 2005 19:51:25 -0000
@@ -81,7 +81,7 @@
       contents of a given slot will be different in each thread, so you can use this to store data
       that is only meaningful in the context of a single thread. On recent versions of Linux the
       __thread keyword provides a convenient interface to this functionality - a more portable API
-      is exposed in the pthread library. However, these facilities is not used by Wine, rather, we
+      is exposed in the pthread library. However, these facilities are not used by Wine, rather, we
       implement Win32 TLS entirely ourselves.
     </para>
   </sect1>
@@ -125,11 +125,11 @@
     </para>
 
     <para>
-      Let's start with a bit of history. Back in the dark ages when Wines threading support was
+      Let's start with a bit of history. Back in the dark ages when Wine's threading support was
       first implemented a problem was faced - Windows had much more capable threading APIs than
       Linux did. This presented a problem - Wine works either by reimplementing an API entirely
       or by mapping it onto the underlying systems equivalent. How could Win32 threading be
-      implemented using a library which did not have all the neeed features? The answer, of
+      implemented using a library which did not have all the needed features? The answer, of
       course, was that it couldn't be.
     </para>
 
@@ -156,11 +156,11 @@
     </para>
 
     <para>
-      The solution was simple yet ingenius: Wine would provide its own implementation of the pthread
+      The solution was simple yet ingenious: Wine would provide its own implementation of the pthread
       library <emphasis>inside</emphasis> its own binary. Due to the semantics of ELF symbol
-      scoping, this would cause Wines own implementations to override any implementation loaded
+      scoping, this would cause Wine's own implementations to override any implementation loaded
       later on (like the real libpthread.so). Therefore, any calls to the pthread APIs in
-      external libraries would be linked to Wines instead of the systems pthreads library, and
+      external libraries would be linked to Wine's instead of the system's pthreads library, and
       Wine implemented pthreads by using the standard Windows threading APIs it in turn
       implemented itself.
     </para>
@@ -177,7 +177,7 @@
 
     <para>
       The fake pthread implementation can be found in loader/kthread.c, which is used to
-      produce to wine-kthread binary. In contrast, loader/pthread.c produces the wine-pthread
+      produce the wine-kthread binary. In contrast, loader/pthread.c produces the wine-pthread
       binary which is used on newer NPTL systems.
     </para>