Lots of spelling fixes that accumulated in my tree again, made several

controls/menu.c

@@ -2238,7 +2238,7 @@ static HMENU MENU_PtMenu( HMENU hMenu, POINT16 pt )
  *
  * Execute a menu item (for instance when user pressed Enter).
  * Return the wID of the executed item. Otherwise, -1 indicating
- * that no menu item wase executed;
+ * that no menu item was executed;
  * Have to receive the flags for the TrackPopupMenu options to avoid
  * sending unwanted message.
  *

dlls/ddraw/ddraw/x11.c

@@ -493,14 +493,14 @@ static HRESULT WINAPI Xlib_IDirectDrawImpl_SetDisplayMode(
       return DDERR_UNSUPPORTEDMODE;
 
     case -1:
-      /* No convertion */
+      /* No conversion */
       This->d.pixel_convert = NULL;
       This->d.palette_convert = NULL;
       break;
 
     default:
-      DPRINTF("DirectDraw warning: running in depth-convertion mode. Should run using a %ld depth for optimal performances.\n", depth);
-      /* Set the depth convertion routines */
+      DPRINTF("DirectDraw warning: running in depth-conversion mode. Should run using a %ld depth for optimal performances.\n", depth);
+      /* Set the depth conversion routines */
       This->d.pixel_convert = ModeEmulations[c].funcs.pixel_convert;
       This->d.palette_convert = ModeEmulations[c].funcs.palette_convert;
     }

dlls/ddraw/ddraw_private.h

@@ -198,7 +198,7 @@ struct IDirectDrawPaletteImpl
     DWORD		ref;
 
     /* IDirectDrawPalette fields */
-    IDirectDrawImpl*		ddraw;	/* direct draw, no referencecount */
+    IDirectDrawImpl*		ddraw;	/* direct draw, no reference count */
     PALETTEENTRY	palents[256];
 
     /* This is to store the palette in 'screen format' */

dlls/ddraw/mesa_private.h

 /* MESA private include file
    (c) 1998 Lionel ULMER
    
-   This files contains all the structure that are not exported
+   This file contains all structures that are not exported
    through d3d.h and all common macros. */
 
 #ifndef __GRAPHICS_WINE_MESA_PRIVATE_H

dlls/dplayx/dplay.c

@@ -41,7 +41,7 @@ typedef struct IDirectPlay4Impl IDirectPlay4Impl;
 /*****************************************************************************
  * IDirectPlay implementation structure
  *
- * The philosophy behind this extra pointer derefernce is that I wanted to
+ * The philosophy behind this extra pointer dereference is that I wanted to
  * have the same structure for all types of objects without having to do
  * alot of casting. I also only wanted to implement an interface in the
  * object it was "released" with IUnknown interface being implemented in the 1 version.

dlls/winmm/wineoss/audio.c

@@ -680,7 +680,7 @@ static DWORD wodOpen(WORD wDevID, LPWAVEOPENDESC lpDesc, DWORD dwFlags)
     audio = open(SOUND_DEV, O_WRONLY|O_NDELAY, 0);
     if (audio == -1) {
 	WARN("can't open (%d)!\n", errno);
-	return MMSYSERR_ALLOCATED ;
+	return MMSYSERR_ALLOCATED;
     }
 
     WOutDev[wDevID].wFlags = HIWORD(dwFlags & CALLBACK_TYPEMASK);

dlls/winmm/wineoss/midi.c

@@ -253,7 +253,7 @@ static	BOOL OSS_MidiInit(void)
 	minfo.device = i;
 	status = ioctl(midiSeqFD, SNDCTL_MIDI_INFO, &minfo);
 	if (status == -1) {
-	    ERR("ioctl on midi info failed.\n");
+	    ERR("ioctl on midi info for device %d failed.\n", i);
 	    midiCloseSeq();
 	    return TRUE;
 	}

documentation/config

@@ -90,11 +90,10 @@ Device=/dev/xx
 
 Use this ONLY for floppy and cdrom devices. Using it on Extended2 partitions can
 have dire results (When a windows app tries to do a lowlevel write, they do it
-in a FAT way -- FAT does not mix with Extended2). Currently, it is useless when
-used on cdrom's, however functionality could be implemented later to allow wine
-to automatically find the cdrom label.
-NOTE: This setting is not terribly important, almost all apps will have no
-problem if it remains unspecified. If you are unsure about specifying device
+in a FAT way -- FAT does not mix with Extended2).
+NOTE: This setting is not really important, almost all apps will have no
+problem if it remains unspecified. For CD-ROMs you might want to add it to get
+automatic label detection, though. If you are unsure about specifying device
 names, just leave out this setting for your drives.
 
 Here is a setup for Drive X, a generic hard drive:

documentation/distributors

 		A small WINE distribution guide.
 
 While packaging WINE for one of the Linux distributions I came across
-several points which have been clarified yet. Particular a how-to for WINE
-packaging distributors is missing. This document tries to give a brief
-overview over the rationales I thought up and how I tried to implement it.
+several points which have not been clarified yet. Particularly a how-to
+for WINE packaging distributors is missing. This document tries to give
+a brief overview over the rationales I thought up and how I tried to
+implement it.
 (While the examples use "rpm" most of this stuff can be applied to other
 packagers too.)
 
@@ -16,11 +17,11 @@ environment !
 
 A WINE install should:
 a. Not have a world writeable directory (-tree).
-b. Require only as much user input as possible. It would be very good if it
+b. Require only as much user input as needed. It would be very good if it
    would not require any at all. Just let the system administrator do "rpm
    -i wine.rpm" and let any user be able to run "wine sol.exe" instantly.
-c. Give the user as much flexibility to install his own applications, do
-   his own configuring etc.
+c. Give the user as much flexibility as possible to install his own
+   applications, do his own configuring etc.
 d. Come as preconfigured as possible, so the user does not need to change
    any configuration files.
 e. Use only as much diskspace as needed per user.
@@ -68,7 +69,7 @@ Example (split this into %build and %install section for rpm):
 
 Here we unfortunately do need to create wineuser.reg and winesystem.reg
 from the WINE distributed winedefault.reg. This can be done using
-./regapi once for one example user and the reusing his .wine/user.reg
+./regapi once for one example user and then reusing his .wine/user.reg
 and .wine/system.reg files. [FIXME: this needs to be done better]
 
 	install -m 644 wine.sytemreg $BR/etc/wine/
@@ -175,7 +176,7 @@ WINE. This script should:
 
 - Symlink all .dll and .exe files from the original windows installation to
   the windows directory. Why? Some program reference "%windowsdir%/file.dll"
-  or "%systemdir%/file.dll" directly and fail if there are not present.
+  or "%systemdir%/file.dll" directly and fail if they are not present.
 
   This will give a huge number of symlinks, yes. However, if an installer
   later overwrites on of those files, it will overwrite the symlink (so

documentation/fonts

@@ -12,11 +12,11 @@ How To Convert Windows Fonts
 If you have access to a Windows installation you should use 
 fnt2bdf utility (found in the 'tools)' directory to convert
 bitmap fonts (VGASYS.FON, SSERIFE.FON, and SERIFE.FON) into 
-the format that X Window System can recognize. 
+the format that the X Window System can recognize. 
 
 Step 1. Extract bitmap fonts with 'fnt2bdf'.
 
-Step 2. Convert .bdf files produced by the Step 1 into
+Step 2. Convert .bdf files produced by Step 1 into
 	.pcf files with 'bdftopcf'.
 
 Step 3. Copy .pcf files to the font server directory which

documentation/no-windows

@@ -35,9 +35,10 @@ designed to make this possible. Here are some tips by Juergen Schmied
 (and others) on how to proceed. This assumes that your C:\windows
 directory in the configuration file does not point to a native Windows
 installation but is in a separate Unix file system. (For instance,
-C:\windows is really /home/ego/wine/drives/c).
+"C:\windows" is really subdirectory "windows" located in
+"/home/ego/wine/drives/c").
 
-- Run the application with   -debugmsg +module,+file   to find out
+- Run the application with   --debugmsg +module,+file   to find out
   which files are needed. Copy the required DLL's one by one to the
   C:\windows\system directory. Do not copy KERNEL/KERNEL32, GDI/GDI32,
   or USER/USER32. These implement the core functionality of the

misc/registry.c

@@ -128,7 +128,7 @@ static void REGISTRY_Init(void) {
 	RegSetValueExA(hkey,"Identifier",0,REG_SZ,"SystemType WINE",strlen("SystemType WINE"));
 	RegCloseKey(hkey);
 
-	/* \\SOFTWARE\\Microsoft\\Window NT\\CurrentVersion
+	/* \\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion
 	 *						CurrentVersion
 	 *						CurrentBuildNumber
 	 *						CurrentType
@@ -248,7 +248,7 @@ static char* _wine_read_USTRING( char *buf, LPWSTR *str )
 			s++;
 			if (!*s) {
 				/* Dangling \ ... may only happen if a registry
-				 * write was short. FIXME: What do to?
+				 * write was short. FIXME: What to do?
 				 */
 				 break;
 			}
@@ -1435,7 +1435,8 @@ void SHELL_LoadRegistry( void )
   REGISTRY_Init();
   SetLoadLevel(0);
 
-  if (RegCreateKeyA(HKEY_USERS, ".Default", &hkey_users_default)) hkey_users_default = 0;
+  if (RegCreateKeyA(HKEY_USERS, ".Default", &hkey_users_default))
+	  hkey_users_default = 0;
 
   GetWindowsDirectoryA( windir, MAX_PATHNAME_LEN );
 
@@ -1577,7 +1578,7 @@ void SHELL_LoadRegistry( void )
       _wine_loadreg( HKEY_USERS, SAVE_USERS_DEFAULT );
 
       /* 
-       * Load the global machine defaults directly form sysconfdir
+       * Load the global machine defaults directly from sysconfdir
        */
       _wine_loadreg( HKEY_LOCAL_MACHINE, SAVE_LOCAL_MACHINE_DEFAULT );
   }

win32/kernel32.c

@@ -144,8 +144,8 @@ static LPVOID _loadthunk(LPCSTR module, LPCSTR func, LPCSTR module32,
     if (   !(ordinal = NE_GetOrdinal(hmod, func))
         || !(TD16 = PTR_SEG_TO_LIN(NE_GetEntryPointEx(hmod, ordinal, FALSE))))
     {
-        ERR("(%s, %s, %s): Unable to find '%s'\n",
-                   module, func, module32, func);
+        ERR("Unable to find thunk data '%s' in %s, required by %s (conflicting/incorrect DLL versions !?).\n",
+                   func, module, module32);
         return 0;
     }
 
@@ -552,7 +552,7 @@ void WINAPI FT_Exit56(CONTEXT86 *context) { FT_Exit(context, 56); }
  *	00: DWORD	length		? don't know exactly
  *	04: SEGPTR	ptr		? where does it point to?
  * The pointer ptr is written into the first DWORD of 'thunk'.
- * (probably correct implemented)
+ * (probably correctly implemented)
  * [ok probably]
  * RETURNS
  *	segmented pointer to thunk?

windows/driver.c

@@ -814,7 +814,7 @@ HDRVR16 WINAPI OpenDriver16(LPCSTR lpDriverName, LPCSTR lpSectionName, LPARAM lP
 	hDriver = DRIVER_TryOpenDriver16(drvName, lParam, FALSE);
     }
     if (!hDriver)
-	ERR("Failed to open driver %s from section %s\n", lpDriverName, lpSectionName);
+	ERR("Failed to open driver %s from system.ini file, section %s\n", lpDriverName, lpSectionName);
     else 
 	TRACE("=> %08x\n", hDriver);
     return hDriver;

windows/message.c

@@ -1971,7 +1971,7 @@ DWORD WINAPI MsgWaitForMultipleObjects( DWORD nCount, HANDLE *pHandles,
       /*
        * This is a temporary solution to a big problem.
        * You see, the main thread of all Win32 programs is created as a 16 bit
-       * task. This means that if you want on an event using Win32 synchronization
+       * task. This means that if you wait on an event using Win32 synchronization
        * methods, the 16 bit scheduler is stopped and things might just stop happening.
        * This implements a semi-busy loop that checks the handles to wait on and
        * also the message queue. When either one is ready, the wait function returns.