From a4f829f497ac4e51ede1a2d173fa9f3ba66aede8 Mon Sep 17 00:00:00 2001 From: Pascal Cuoq Date: Sun, 24 Jan 1999 09:47:29 +0000 Subject: [PATCH] Fixed typos. --- documentation/internal-dll | 16 ++++++++-------- documentation/shell32 | 4 ++-- documentation/wine.man | 4 ++-- 3 files changed, 12 insertions(+), 12 deletions(-) diff --git a/documentation/internal-dll b/documentation/internal-dll index 02b891fc17f..6c37de0692a 100644 --- a/documentation/internal-dll +++ b/documentation/internal-dll @@ -1,15 +1,15 @@ -This document describes some points you should know when you are going to -implement the internal counterparts to external DLL's. Only 32 bit DLL's +This document describes some points you should know before implementing +the internal counterparts to external DLL's. Only 32 bit DLL's are considered. 1. The LibMain function ----------------------- -These are the way to do some initialising when a process or thread is attached +This is the way to do some initializing when a process or thread is attached to the dll. The function name is taken from a *.spec file line: init YourFunctionName -the you have to implement the function: +then, you have to implement the function: BOOL32 WINAPI YourLibMain(HINSTANCE32 hinstDLL, @@ -26,11 +26,11 @@ BOOL32 WINAPI YourLibMain(HINSTANCE32 hinstDLL, 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 the internal implementation. If the external DLL is loaded the executed program -will use the external and you the internal DLL. -When you -as example- fill a iconlist placed in the internal DLL the -application wont get the icons from the external DLL. +will use the external DLL and you the internal one. +When you -as an example- fill an iconlist placed in the internal DLL the +application won't get the icons from the external DLL. -To go around this you have to call the functions over pointer. +To work around this, you should always use a pointer to call such functions: /* definition of the pointer type*/ void (CALLBACK* pDLLInitComctl)(); diff --git a/documentation/shell32 b/documentation/shell32 index 676486abd15..438c5d07db5 100644 --- a/documentation/shell32 +++ b/documentation/shell32 @@ -12,7 +12,7 @@ base functionality is roughly in place. The missing parts are the icon the file copy status window. The basis comes from Marcus Meissner and I -implemented the classes and filled function stubs. +implemented the classes and filled in function stubs. 2. General Information ---------------------- @@ -71,7 +71,7 @@ implemented the classes and filled function stubs. Undocumented: MS says: the abID of SHITEMID should be treated as binary data and not - be interpreted by applications. Applys to everyone but MS itself. + be interpreted by applications. Applies to everyone but MS itself. Word95 interprets the contents of abID (Filesize/Date) so we have to go for binary compatibility here. I expect the file open/close dialog in comctl32 does so also. diff --git a/documentation/wine.man b/documentation/wine.man index f43f1cf2919..5304992c400 100644 --- a/documentation/wine.man +++ b/documentation/wine.man @@ -37,9 +37,9 @@ libc6 (aka glibc2). .PP .B X must be installed. To use Wine's support for multithreaded applications, -your X libraries must be reetrant. If you have libc6 (glibc2), or you +your X libraries must be reentrant. If you have libc6 (glibc2), or you compiled the X libraries yourself, they were probably compiled with the -reetrant option enabled. +reentrant option enabled. .PP .B libXpm must be installed. If you're using Red Hat, make sure the following