Fix typos in comments.

dlls/dplayx/dplay.c

@@ -3551,10 +3551,10 @@ static HRESULT WINAPI DirectPlay3AImpl_EnumConnections
       dpName.u2.lpszLongNameA  = NULL;
 
       /* Create the compound address for the service provider. 
-         NOTE: This is a gruesome architectural scar right now. DP uses DPL and DPL uses DP
-               nast stuff. This may be why the native dll just gets around this little bit by
-               allocating an 80 byte buffer which isn't even a filled with a valid compound 
-               address. Oh well. Creating a proper compound address is the way to go anyways 
+         NOTE: This is a gruesome architectural scar right now. DP uses DPL and DPL uses DP,
+               nasty stuff. This may be why the native dll just gets around this little bit by
+               allocating an 80 byte buffer which isn't even filled with a valid compound 
+               address. Oh well. Creating a proper compound address is the way to go anyway... 
                despite this method taking slightly more heap space and realtime :) */
       dpCompoundAddress.dwDataSize   = sizeof( GUID );
       memcpy( &dpCompoundAddress.guidDataType, &DPAID_ServiceProvider, 
@@ -3656,10 +3656,10 @@ static HRESULT WINAPI DirectPlay3AImpl_EnumConnections
       dpName.u2.lpszLongNameA  = NULL;
 
       /* Create the compound address for the service provider. 
-         NOTE: This is a gruesome architectural scar right now. DP uses DPL and DPL uses DP
-               nast stuff. This may be why the native dll just gets around this little bit by
-               allocating an 80 byte buffer which isn't even a filled with a valid compound 
-               address. Oh well. Creating a proper compound address is the way to go anyways 
+         NOTE: This is a gruesome architectural scar right now. DP uses DPL and DPL uses DP,
+               nasty stuff. This may be why the native dll just gets around this little bit by
+               allocating an 80 byte buffer which isn't even filled with a valid compound 
+               address. Oh well. Creating a proper compound address is the way to go anyway... 
                despite this method taking slightly more heap space and realtime :) */
       dpCompoundAddress.guidDataType = DPAID_LobbyProvider;
       dpCompoundAddress.dwDataSize   = sizeof( GUID );

dlls/ole32/storage.c

@@ -1582,7 +1582,7 @@ HRESULT WINAPI StgCreateDocFile16(
 	}
 	lpstg = MapSL((SEGPTR)*ppstgOpen);
 	lpstg->hf = hf;
-	/* FIXME: check for existance before overwriting? */
+	/* FIXME: check for existence before overwriting? */
 	if (!STORAGE_init_storage(hf)) {
 		CloseHandle(hf);
 		return E_FAIL;

dlls/shell32/shv_bg_cmenu.c

@@ -363,7 +363,7 @@ static HRESULT WINAPI ISVBgCm_fnGetCommandString(
 
 	TRACE("(%p)->(idcom=%x flags=%x %p name=%p len=%x)\n",This, idCommand, uFlags, lpReserved, lpszName, uMaxNameLen);
 
-	/* test the existance of the menu items, the file dialog enables 
+	/* test the existence of the menu items, the file dialog enables 
 	   the buttons according to this */
 	if (uFlags == GCS_VALIDATEA)
 	{

libtest/vartest.c

@@ -965,8 +965,8 @@ int PASCAL WinMain (HINSTANCE inst, HINSTANCE prev, LPSTR cmdline, int show)
 	{
 		/* Trying to use variants that are set to be BSTR but
 		 * do not contain a valid pointer makes the program crash
-		 * in Windows so we will skip those.  We do not need them
-		 * anyways to illustrate the behavior.
+		 * in Windows so we will skip those. We do not need them
+		 * anyway to illustrate the behavior.
 		 */
 		if( i ==  VT_BSTR )
 			i = 77;