From 392397f46cab7f09e9e3b6214cacbd2d8354d620 Mon Sep 17 00:00:00 2001 From: Christopher Faylor Date: Sat, 18 Sep 2010 15:58:46 +0000 Subject: * overview2.sgml: Remove cheerful paragraph which implied that it was ok to casually mix Windows and POSIX. Add more words about mixing POSIX/Windows. --- winsup/doc/overview2.sgml | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) (limited to 'winsup/doc/overview2.sgml') 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. the hood it's using the Win32 API, as well as the native NT API, where appropriate. -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. - Some restrictions apply for calls to the Win32 API. For details, see , as well as . @@ -126,7 +119,15 @@ are hidden to the Win32 API. 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. +these are mostly corner cases. + +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. + Permissions and Security -- cgit v1.2.3