* overview2.sgml: Remove cheerful paragraph which implied that it was ok to

casually mix Windows and POSIX.  Add more words about mixing POSIX/Windows.

1 files changed, 9 insertions, 8 deletions

diff --git a/winsup/doc/overview2.sgml b/winsup/doc/overview2.sgml
index b89799e45..9e968f72f 100644
--- a/winsup/doc/overview2.sgml
+++ b/winsup/doc/overview2.sgml
@@ -108,13 +108,6 @@ process-specific information.</para>
 the hood it's using the Win32 API, as well as the native NT API, where
 appropriate.</para>
 
-<para>Because processes run under the standard Win32 subsystem, they
-can access both the UNIX compatibility calls provided by Cygwin as well as
-any of the Win32 API calls.  This gives the programmer some flexibility in
-designing the structure of their program in terms of the APIs used.  For
-example, they could write a Win32-specific GUI using Win32 API calls on top of
-a UNIX back-end that uses Cygwin.</para>
-
 <note><para>Some restrictions apply for calls to the Win32 API.
 For details, see <xref linkend="setup-env-win32"></xref>,
 as well as <xref linkend="pathnames-win32-api"></xref>.</para></note>
@@ -126,7 +119,15 @@ are hidden to the Win32 API.
 
 <para>Due to some restrictions in Windows, it's not always possible
 to strictly adhere to existing UNIX standards like POSIX.1.  Fortunately
-these are mostely border cases.</para>
+these are mostly corner cases.</para>
+
+<para>Note that many of the things that Cygwin does to provide POSIX
+compatibility do not mesh well with the native Windows API.  If you mix
+POSIX calls with Windows calls in your program it is possible that you
+will see uneven results.  In particular, Cygwin signals will not work
+with Windows functions which block and Windows functions which accept
+filenames may be confused by Cygwin's support for long filenames.</para>
+
 </sect2>
 
 <sect2 id="ov-hi-perm"><title>Permissions and Security</title>