Fixed typos.

documentation/debug-msgs

@@ -72,7 +72,7 @@ Debugging channels
 Also, we divide the debugging messages on a component basis. Each
 component is assigned a debugging channel. The identifier of the
 channel must be a valid C identifier but note that it may also be a
-reserve word like int or static.
+reserved word like int or static.
 
 Examples of debugging channels:
 reg, updown, string
@@ -248,7 +248,7 @@ IMPORTANT NOTE:
   reason, please try not to use it. However, if you need to output a line
   in more than one dprintf_xxx calls, then USE THIS INTERFACE. DO NOT use
   other methods. This way, I will easily translate everything to the new
-  interface (when it will become available). So, if you need to use if,
+  interface (when it will become available). So, if you need to use it,
   then follow the following guidelines:
    -- wrap calls to dsprintf with a 
       if(YYY(xxx))
@@ -416,10 +416,10 @@ use : to separate categories.
 * try to avoid the style:
 
    FIXME(xxx,
-         "(fd: %d, file: %s): stub\n", fd, name);
+         "(fd=%d, file=%s): stub\n", fd, name);
 but use:
 
-  FIXME(xxx, "(fd: %d, file: %s): stub\n", fd, name);
+  FIXME(xxx, "(fd=%d, file=%s): stub\n", fd, name);
 
 The reason is that if you want to grep for things, you would search for
 FIXME but in the first case there is no additional information available,

documentation/debugging

@@ -312,16 +312,29 @@ Call KERNEL.52: FREEPROCINSTANCE(0x02cf00ba) ret=01f7:1460 ds=01ff
 Ret  KERNEL.52: FREEPROCINSTANCE() retval=0x0001 ret=01f7:1460 ds=01ff
 Call USER.1: MESSAGEBOX(0x0000,0x01ff1246 "Runtime error 219 at 0004:1056.",0x00000000,0x1010) ret=01f7:2160 ds=01ff
 
-I think that the call to MessageBox() in this example is _not_ 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 0x0004:0x1056.
-As the segment value of the address is only "4", I think that that is only an internal program value. But the offset address reveals something quite interesting:
+I think that the call to MessageBox() in this example is _not_ 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 0x0004:0x1056.
+
+As the segment value of the address is only "4", I think that that is
+only an internal program value. But the offset address reveals something
+quite interesting:
+
 Offset 1056 is _very_ close to the return address of FREELIBRARY():
 
 Call KERNEL.96: FREELIBRARY(0x031f) ret=01cf:105c ds=01ff
                                              ^^^^
-Provided that segment 0x0004 is indeed segment 0x1cf, we now we can use IDA (available at ftp://ftp.uni-koeln.de/pc/msdos/programming/assembler/ida35bx.zip) to
-disassemble the part that caused the error. We just have to find the address of
-the call to FreeLibrary(). Some lines before that the runtime error occurred.
-But be careful ! In some cases you don't have to disassemble the main program, but instead some DLL called by it in order to find the correct place where the runtime error occurred. That can be determined by finding the origin of the segment value (in this case 0x1cf).
+Provided that segment 0x0004 is indeed
+segment 0x1cf, we now we can use IDA (available at
+ftp://ftp.uni-koeln.de/pc/msdos/programming/assembler/ida35bx.zip)
+to disassemble the part that caused the error. We just have to find
+the address of the call to FreeLibrary(). Some lines before that the
+runtime error occurred.  But be careful ! In some cases you don't have
+to disassemble the main program, but instead some DLL called by it in
+order to find the correct place where the runtime error occurred. That
+can be determined by finding the origin of the segment value (in this
+case 0x1cf).
 
 c) 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

documentation/internal-dll

@@ -21,7 +21,7 @@ BOOL32 WINAPI YourLibMain(HINSTANCE32 hinstDLL,
 }
 
 
-2. Using functions from other build-in DLL's
+2. Using functions from other built-in DLL's
 --------------------------------------------
 The problem here is, that you can't know if you have to call the function from
 the internal or the external DLL. If you just call the function you will get

documentation/ioport-trace-hints

@@ -174,10 +174,10 @@ put: 05 8f
 put: 84 8f
 wait: ff
 
-From this it is easy to see that put routine is oftern gouped together in five
-sucessive calls sending information to the scanner. Once these are understood
+From this it is easy to see that put routine is often grouped together in five
+successive calls sending information to the scanner. Once these are understood
 it should be possible to process the logs further to show the higher level
-routines in an easy to see format. Once the higest level format that you
+routines in an easy to see format. Once the highest level format that you
 can derive from this process is understood, you then need to produce a
 series of scans varying only one parameter between them, so you can
 discover how to set the various parameters for the scanner.

documentation/wine_os2

@@ -34,7 +34,7 @@ What needs to be redone:
 - File functions, 
 - I/O access (do it!),
 - Communication (modem),
-- Interrupt (if int unknow, call current RealMode one...), 
+- Interrupt (if int unknown, call current RealMode one...), 
 - verify that everything is thread safe (how does Win95/NT handle multi-thread?), 
 - move X functions in some files (and make a wrapper, to use PM instead latter), 
 - return right CPU type,