1 files changed, 40 insertions, 40 deletions
diff --git a/README.Borland b/README.Borland
index ffb6e8d..1694d55 100644
--- a/README.Borland
+++ b/README.Borland
@@ -1,47 +1,47 @@
-In ptw32_InterlockedCompareExchange.c, I've added a section for
-Borland's compiler; it's identical to that for the MS compiler except
+In ptw32_InterlockedCompareExchange.c, I've added a section for
+Borland's compiler; it's identical to that for the MS compiler except
 that it uses /* ... */ comments instead of ; comments.
 
 [RPJ: need to define HAVE_TASM32 in config.h to use the above.]
-
-
-The other file is a makefile suitable for use with Borland's compiler
-(run "make -fBmakefile" in the directory).  It builds a single version
-of the library, pthreadBC.dll and the corresponding pthreadBC.lib
-import library, which is comparable to the pthreadVC version; I can't
-personally see any demand for the versions that include structured or
-C++ exception cancellation handling so I haven't attempted to build
-those versions of the library.  (I imagine a static version might be
-of use to some, but we can't legally use that on my commercial
-projects so I can't try that out, unfortunately.)
+
+
+The other file is a makefile suitable for use with Borland's compiler
+(run "make -fBmakefile" in the directory).  It builds a single version
+of the library, pthreadBC.dll and the corresponding pthreadBC.lib
+import library, which is comparable to the pthreadVC version; I can't
+personally see any demand for the versions that include structured or
+C++ exception cancellation handling so I haven't attempted to build
+those versions of the library.  (I imagine a static version might be
+of use to some, but we can't legally use that on my commercial
+projects so I can't try that out, unfortunately.)
 
 [RPJ: Added tests\Bmakefile as well.]
 
-Borland C++ doesn't define the ENOSYS constant used by pthreads-win32;
-rather than make more extensive patches to the pthreads-win32 source I
-have a mostly-arbitrary constant for it in the makefile.  However this
-doesn't make it visible to the application using the library, so if
-anyone actually wants to use this constant in their apps (why?)
-someone might like to make a seperate NEED_BCC_something define to add
-this stuff.
+Borland C++ doesn't define the ENOSYS constant used by pthreads-win32;
+rather than make more extensive patches to the pthreads-win32 source I
+have a mostly-arbitrary constant for it in the makefile.  However this
+doesn't make it visible to the application using the library, so if
+anyone actually wants to use this constant in their apps (why?)
+someone might like to make a seperate NEED_BCC_something define to add
+this stuff.
 
-The makefile also #defines EDEADLK as EDEADLOCK, _timeb as timeb, and
-_ftime as ftime, to deal with the minor differences between the two
-RTLs' naming conventions, and sets the compiler flags as required to
-get a normal compile of the library.
+The makefile also #defines EDEADLK as EDEADLOCK, _timeb as timeb, and
+_ftime as ftime, to deal with the minor differences between the two
+RTLs' naming conventions, and sets the compiler flags as required to
+get a normal compile of the library.
 
 [RPJ: Moved errno values and _timeb etc to pthread.h, so apps will also
 use them.]
 
-(While I'm on the subject, the reason Borland users should recompile
-the library, rather than using the impdef/implib technique suggested
-previously on the mailing list, is that a) the errno constants are
-different, so the results returned by the pthread_* functions can be
-meaningless, and b) the errno variable/pseudo-variable itself is
-different in the MS & BCC runtimes, so you can't access the
-pthreadVC's errno from a Borland C++-compiled host application
-correctly - I imagine there are other potential problems from the RTL
-mismatch too.)
+(While I'm on the subject, the reason Borland users should recompile
+the library, rather than using the impdef/implib technique suggested
+previously on the mailing list, is that a) the errno constants are
+different, so the results returned by the pthread_* functions can be
+meaningless, and b) the errno variable/pseudo-variable itself is
+different in the MS & BCC runtimes, so you can't access the
+pthreadVC's errno from a Borland C++-compiled host application
+correctly - I imagine there are other potential problems from the RTL
+mismatch too.)
 
 [RPJ: There are still problems with errno under Borland and the DLL
 will not pass the testsuite yet because of it. Setting and then reading
@@ -50,11 +50,11 @@ but DLL and application modules do not seem to be looking at the same
 location for errno, even though they are logically running in the same
 thread.]
 
-Best regards,
-Will
+Best regards,
+Will
 
--- 
-Will Bryant
-Systems Architect, eCOSM Limited
-Cell +64 21 655 443, office +64 3 365 4176
-http://www.ecosm.com/
+-- 
+Will Bryant
+Systems Architect, eCOSM Limited
+Cell +64 21 655 443, office +64 3 365 4176
+http://www.ecosm.com/