www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - open, close, dup, dup2, lseek, read, write, fileno, etc.

reply "Janice Caron" <caron800 googlemail.com> writes:
open, close, dup, dup2, lseek, read, write, fileno, etc....

Is there any good reason why these functions are available in Phobos
for the Linux version of D only, but not for the Windows version?

These functions certainly do exists on Windows (albeit with names
preceeded by a single underscore). In C and C++, you just have to
#include <io.h>

I looked at the source code for std.streams, just to end my confusion
about what File does, and it turns out it's full of lots of
conditional code, with Windows using Windowsy functions like
CreateFileW() and CreateFileA(). I'm sure there's probably a good
reason for this - I just don't know what it is. Can anyone explain?

Thanks.
Feb 08 2008
next sibling parent Neal Alexander <wqeqweuqy hotmail.com> writes:
TJanice Caron wrote:
 open, close, dup, dup2, lseek, read, write, fileno, etc....
 
 Is there any good reason why these functions are available in Phobos
 for the Linux version of D only, but not for the Windows version?
 
 These functions certainly do exists on Windows (albeit with names
 preceeded by a single underscore). In C and C++, you just have to
 #include <io.h>
 
 I looked at the source code for std.streams, just to end my confusion
 about what File does, and it turns out it's full of lots of
 conditional code, with Windows using Windowsy functions like
 CreateFileW() and CreateFileA(). I'm sure there's probably a good
 reason for this - I just don't know what it is. Can anyone explain?
 
 Thanks.
I think theres some limitations to the POSIX subsystem on win32. Dunno heh. http://support.microsoft.com/kb/149902 http://support.microsoft.com/kb/101270 http://support.microsoft.com/kb/308259
Feb 08 2008
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
On Fri, 8 Feb 2008 12:37:17 +0000, Janice Caron wrote:

 open, close, dup, dup2, lseek, read, write, fileno, etc....
 
 Is there any good reason why these functions are available in Phobos
 for the Linux version of D only, but not for the Windows version?
No. So go ahead and code them then submit them to the Phobos development team. I might just do it myself, mwahahahaha!
 These functions certainly do exists on Windows (albeit with names
 preceeded by a single underscore). In C and C++, you just have to
 #include <io.h>
I'm pretty sure the C versions end up calling the "Windowsy" functions anyway. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Feb 08 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Janice Caron wrote:
 open, close, dup, dup2, lseek, read, write, fileno, etc....
 
 Is there any good reason why these functions are available in Phobos
 for the Linux version of D only, but not for the Windows version?
 
 These functions certainly do exists on Windows (albeit with names
 preceeded by a single underscore). In C and C++, you just have to
 #include <io.h>
 
 I looked at the source code for std.streams, just to end my confusion
 about what File does, and it turns out it's full of lots of
 conditional code, with Windows using Windowsy functions like
 CreateFileW() and CreateFileA(). I'm sure there's probably a good
 reason for this - I just don't know what it is. Can anyone explain?
Going directly to the underlying OS functions makes for faster, more efficient I/O. Calling open, close, etc., on Windows makes for poor performance, because those functions are layered on top of the Windows I/O functions.
Feb 08 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 09/02/2008, Walter Bright <newshound1 digitalmars.com> wrote:
 Going directly to the underlying OS functions makes for faster, more
 efficient I/O. Calling open, close, etc., on Windows makes for poor
 performance, because those functions are layered on top of the Windows
 I/O functions.
Thanks for the answer. Though my question wasn't "Why does std.stream.File use them?", it was "Why can't I use them?", which is a slightly different question, and I see no reason for prohibition. It is simpler easier to write platform-independent code if you can use open() and close(), because then you don't have to do version(Windows) { h = wide ? CreateFileW() : CreateFileA(); } version(linux) { h = open(); } Platform independent code is also inherently easier to test, if you don't happen to have a linux platform handy. I wasn't complaining though - it is trivially easy to import those functions with extern(C) so it's hardly a big deal. I was just curious.
Feb 08 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Janice Caron wrote:
 On 09/02/2008, Walter Bright <newshound1 digitalmars.com> wrote:
 Going directly to the underlying OS functions makes for faster, more
 efficient I/O. Calling open, close, etc., on Windows makes for poor
 performance, because those functions are layered on top of the Windows
 I/O functions.
Thanks for the answer. Though my question wasn't "Why does std.stream.File use them?", it was "Why can't I use them?", which is a slightly different question, and I see no reason for prohibition.
You can use them - they are in the C runtime library for Windows. Just put in the declarations for them. You'll be disappointed, though. They are NOT part of Windows, they are C runtime functions which mostly emulate the linux ones. You're better off skipping the middleman.
 It is simpler easier to write platform-independent code if you can use
 open() and close(), because then you don't have to do
 
     version(Windows) { h = wide ? CreateFileW() : CreateFileA(); }
     version(linux) { h = open(); }
 
 Platform independent code is also inherently easier to test, if you
 don't happen to have a linux platform handy.
To write platform independent code, why not use the D I/O facilities? That is the point of them. If they are deficient, it is better to enhance them than use open/close/read/write/dup. open/close/etc. are NOT platform independence. They are low level unix api functions. For example, for open() on windows, you have to go through one layer to CreateFileA() (and a lot of messing about trying to convert unix-style modes and permissions to windows-style), and internal to Windows, CreateFileA() executes a conversion to go to CreateFileW().
 I wasn't complaining though - it is trivially easy to import those
 functions with extern(C) so it's hardly a big deal. I was just
 curious.
I advise against using them because they are the wrong abstraction to use. For example, they are a direct reflection of the linux filesystem, not the Windows filesystem.
Feb 08 2008
next sibling parent reply Alexander Panek <alexander.panek brainsware.org> writes:
Walter Bright wrote:
 Janice Caron wrote:
 On 09/02/2008, Walter Bright <newshound1 digitalmars.com> wrote:
 Going directly to the underlying OS functions makes for faster, more
 efficient I/O. Calling open, close, etc., on Windows makes for poor
 performance, because those functions are layered on top of the Windows
 I/O functions.
Thanks for the answer. Though my question wasn't "Why does std.stream.File use them?", it was "Why can't I use them?", which is a slightly different question, and I see no reason for prohibition.
You can use them - they are in the C runtime library for Windows. Just put in the declarations for them. You'll be disappointed, though. They are NOT part of Windows, they are C runtime functions which mostly emulate the linux ones. You're better off skipping the middleman.
 It is simpler easier to write platform-independent code if you can use
 open() and close(), because then you don't have to do

     version(Windows) { h = wide ? CreateFileW() : CreateFileA(); }
     version(linux) { h = open(); }

 Platform independent code is also inherently easier to test, if you
 don't happen to have a linux platform handy.
To write platform independent code, why not use the D I/O facilities? That is the point of them. If they are deficient, it is better to enhance them than use open/close/read/write/dup. open/close/etc. are NOT platform independence. They are low level unix api functions. For example, for open() on windows, you have to go through one layer to CreateFileA() (and a lot of messing about trying to convert unix-style modes and permissions to windows-style), and internal to Windows, CreateFileA() executes a conversion to go to CreateFileW().
 I wasn't complaining though - it is trivially easy to import those
 functions with extern(C) so it's hardly a big deal. I was just
 curious.
I advise against using them because they are the wrong abstraction to use. For example, they are a direct reflection of the linux filesystem, not the Windows filesystem.
I am not certainly sure, but I do think open, close & co are POSIX functions, not Linux functions per se. They're available on almost all modern Unices. So actually, they are what one would call cross platform. They're just a step-child on Windows, coming with the POSIX subsystem. Just my two nitpicking cents. :)
Feb 09 2008
parent Leandro Lucarella <llucax gmail.com> writes:
Alexander Panek, el  9 de febrero a las 12:20 me escribiste:
 Walter Bright wrote:
Janice Caron wrote:
On 09/02/2008, Walter Bright <newshound1 digitalmars.com> wrote:
Going directly to the underlying OS functions makes for faster, more
efficient I/O. Calling open, close, etc., on Windows makes for poor
performance, because those functions are layered on top of the Windows
I/O functions.
Thanks for the answer. Though my question wasn't "Why does std.stream.File use them?", it was "Why can't I use them?", which is a slightly different question, and I see no reason for prohibition.
You can use them - they are in the C runtime library for Windows. Just put in the declarations for them. You'll be disappointed, though. They are NOT part of Windows, they are C runtime functions which mostly emulate the linux ones. You're better off skipping the middleman.
It is simpler easier to write platform-independent code if you can use
open() and close(), because then you don't have to do

    version(Windows) { h = wide ? CreateFileW() : CreateFileA(); }
    version(linux) { h = open(); }

Platform independent code is also inherently easier to test, if you
don't happen to have a linux platform handy.
To write platform independent code, why not use the D I/O facilities? That is the point of them. If they are deficient, it is better to enhance them than use open/close/read/write/dup. open/close/etc. are NOT platform independence. They are low level unix api functions. For example, for open() on windows, you have to go through one layer to CreateFileA() (and a lot of messing about trying to convert unix-style modes and permissions to windows-style), and internal to Windows, CreateFileA() executes a conversion to go to CreateFileW().
I wasn't complaining though - it is trivially easy to import those
functions with extern(C) so it's hardly a big deal. I was just
curious.
I advise against using them because they are the wrong abstraction to use. For example, they are a direct reflection of the linux filesystem, not the Windows filesystem.
I am not certainly sure, but I do think open, close & co are POSIX functions, not Linux functions per se. They're available on almost all modern Unices. So actually, they are what one would call cross platform. They're just a step-child on Windows, coming with the POSIX subsystem.
Yes, and this reminds me why there is no "posix" version (like in Tango AFAIK). It seems to me a little lame to have a "linux" version where mostly all the imports have *posix* functions and can be used in any *posix* sysm (which is even more wide than Unices, as said here Windows has a -poor- posix API, and QNX 6 -clearly not a Unix- is posix too). Posix is a great way to do portable code. I think it would be great if D had better (and D-ish) Posix "bindings". -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- La máquina de la moneda, mirá como te queda! -- Sidharta Kiwi
Feb 09 2008
prev sibling parent reply "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Sat, 09 Feb 2008 06:34:57 -0000, Walter Bright  =

<newshound1 digitalmars.com> wrote:

 Janice Caron wrote:
 On 09/02/2008, Walter Bright <newshound1 digitalmars.com> wrote:
 Going directly to the underlying OS functions makes for faster, more=
 efficient I/O. Calling open, close, etc., on Windows makes for poor
 performance, because those functions are layered on top of the Windo=
ws
 I/O functions.
Thanks for the answer. Though my question wasn't "Why does std.stream.File use them?", it was "Why can't I use them?", which is =
a
 slightly different question, and I see no reason for prohibition.
You can use them - they are in the C runtime library for Windows. Just=
=
 put in the declarations for them. You'll be disappointed, though. They=
=
 are NOT part of Windows, they are C runtime functions which mostly  =
 emulate the linux ones.

 You're better off skipping the middleman.

 It is simpler easier to write platform-independent code if you can us=
e
 open() and close(), because then you don't have to do
      version(Windows) { h =3D wide ? CreateFileW() : CreateFileA(); }=
     version(linux) { h =3D open(); }
  Platform independent code is also inherently easier to test, if you
 don't happen to have a linux platform handy.
To write platform independent code, why not use the D I/O facilities? =
=
 That is the point of them. If they are deficient, it is better to  =
 enhance them than use open/close/read/write/dup.

 open/close/etc. are NOT platform independence. They are low level unix=
=
 api functions. For example, for open() on windows, you have to go  =
 through one layer to CreateFileA() (and a lot of messing about trying =
to =
 convert unix-style modes and permissions to windows-style), and intern=
al =
 to Windows, CreateFileA() executes a conversion to go to CreateFileW()=
.
 I wasn't complaining though - it is trivially easy to import those
 functions with extern(C) so it's hardly a big deal. I was just
 curious.
I advise against using them because they are the wrong abstraction to =
=
 use. For example, they are a direct reflection of the linux filesystem=
, =
 not the Windows filesystem.
Unfortunately this is so. A long time ago the POSIX standard was invente= d (or rather brought together from some early Unixes) and though low-level= (not OO for a start) it is solid and reliable. The idea being if you want to write portable code you write it using onl= y = POSIX functionality. M$ in their finite wisdom chose to tear up the standard and invent their= = own and then pretend they supported it. The result is it is practically = impossible to write portable code without having another wrapper layer inbetween. = This is where language standard libraries are a godsend. Though its hard to find= = good portable implementations of non-blocking IO and file locking. I suspect this may be an area where Tango is ahead of Phobos but not = knowing both APIs well I'm not in a position to comment.
Feb 09 2008
parent reply "David Wilson" <dw botanicus.net> writes:
On 2/9/08, Bruce Adams <tortoise_74 yeah.who.co.uk> wrote:

 Unfortunately this is so. A long time ago the POSIX standard was invented
 (or rather brought together from some early Unixes) and though low-level
 (not OO for a start) it is solid and reliable.
 The idea being if you want to write portable code you write it using only
 POSIX
 functionality.
 M$ in their finite wisdom chose to tear up the standard and invent their
 own
 and then pretend they supported it. The result is it is practically
 impossible
 to write portable code without having another wrapper layer inbetween.
ANSI C (including the standard library) wasn't standardised until 1990. The first versions of MS-DOS appeared in 1982. POSIX didn't appear until 1988. Which standard are you referring to, or is this just more of the same uninformed Microsoft bashing? David.
 This is
 where language standard libraries are a godsend. Though its hard to find
 good
 portable implementations of non-blocking IO and file locking.
 I suspect this may be an area where Tango is ahead of Phobos but not
 knowing
 both APIs well I'm not in a position to comment.
Feb 11 2008
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"David Wilson"wrote
 On 2/9/08, Bruce Adams wrote:

 Unfortunately this is so. A long time ago the POSIX standard was invented
 (or rather brought together from some early Unixes) and though low-level
 (not OO for a start) it is solid and reliable.
 The idea being if you want to write portable code you write it using only
 POSIX
 functionality.
 M$ in their finite wisdom chose to tear up the standard and invent their
 own
 and then pretend they supported it. The result is it is practically
 impossible
 to write portable code without having another wrapper layer inbetween.
ANSI C (including the standard library) wasn't standardised until 1990. The first versions of MS-DOS appeared in 1982. POSIX didn't appear until 1988. Which standard are you referring to, or is this just more of the same uninformed Microsoft bashing?
According to Wikipedia, Windows NT was released in 1993, which is the first OS (I believe) that contained CreateFile, etc. Those functions were different from DOS which had no names for the functions, just interrupts (there was a DOS3Call in windows 3.x which wrapped the interrupt call). It would have been very easy for Microsoft to implement unix-like system calls in NT instead of what they have, but I believe they did so either because they did not want to restrict themselves to a standard API out of their control, or they just didn't consider it at the time. It could be 'not invented here' syndrome. CreateFile and friends have a lot more arguments and flexibility than the POSIX counter parts. These are just choices that a company made at the time. Were they right or wrong? I'd say they were both right and wrong. But you can't change it now :) And I don't think there is any problem with using POSIX functions on Windows, it isn't any different than using D classes that wrap those functions. I don't think there is any purposefully bad implementation in the unix-like calls, what makes D or phobos so much better in their wrapper implementation that one should prefer the D wrapper over the C call? The logical choice if you want to use D is to use the D wrappers as they fit with the rest of the standard library, but if you want to use the C calls, there really should be no significant performance hit IMO. -Steve
Feb 11 2008
parent reply Jussi Jumppanen <jussij zeusedit.com> writes:
Steven Schveighoffer Wrote:

 According to Wikipedia, Windows NT was released in 1993, which 
 is the first OS (I believe) that contained CreateFile, etc.  
 Those functions were different from DOS which had no names 
 for the functions, just interrupts (there was a DOS3Call in 
 windows 3.x which wrapped the interrupt call).
I might be wrong, but I thought the Win16 API had an OpenFile function which let you get away from having to use interrupts, and it dates back to the days of Windows 3.0 maybe even earlier.
 It would have been very easy for Microsoft to implement 
 unix-like system calls in NT instead of what they have, 
Windows NT 3.0 at the API level is almost a straight copy of OS/2, the joint venture between IBM and Microsoft of the late 1980's. So IBM is also very much to blame for the Windows we have today ;) Jussi
Feb 11 2008
parent Don Clugston <dac nospam.com.au> writes:
Jussi Jumppanen wrote:
 Steven Schveighoffer Wrote:
 
 According to Wikipedia, Windows NT was released in 1993, which 
 is the first OS (I believe) that contained CreateFile, etc.  
 Those functions were different from DOS which had no names 
 for the functions, just interrupts (there was a DOS3Call in 
 windows 3.x which wrapped the interrupt call).
I might be wrong, but I thought the Win16 API had an OpenFile function which let you get away from having to use interrupts, and it dates back to the days of Windows 3.0 maybe even earlier.
Early Windows versions had no documented file handling functions other than OpenFile. There were undocumented function calls _lclose(), _lseek() etc which were not documented until Windows3.0, but were present in ancient versions of Windows. In those early days, Microsoft recommended that you use the C library functions for file handling.
 It would have been very easy for Microsoft to implement 
 unix-like system calls in NT instead of what they have, 
Windows NT 3.0 at the API level is almost a straight copy of OS/2, the joint venture between IBM and Microsoft of the late 1980's. So IBM is also very much to blame for the Windows we have today ;) Jussi
Feb 12 2008
prev sibling parent reply "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Mon, 11 Feb 2008 15:52:54 -0000, David Wilson <dw botanicus.net> wrote:

 On 2/9/08, Bruce Adams <tortoise_74 yeah.who.co.uk> wrote:

 Unfortunately this is so. A long time ago the POSIX standard was  
 invented
 (or rather brought together from some early Unixes) and though low-level
 (not OO for a start) it is solid and reliable.
 The idea being if you want to write portable code you write it using  
 only
 POSIX
 functionality.
 M$ in their finite wisdom chose to tear up the standard and invent their
 own
 and then pretend they supported it. The result is it is practically
 impossible
 to write portable code without having another wrapper layer inbetween.
ANSI C (including the standard library) wasn't standardised until 1990. The first versions of MS-DOS appeared in 1982. POSIX didn't appear until 1988. Which standard are you referring to, or is this just more of the same uninformed Microsoft bashing? David.
Same as what uninformed M$ bashing? Windows NT 3.1 appeared around 1993 - http://www.microsoft.com/windows/WinHistoryDesktop.mspx Microsoft were required to include a POSIX subsystem in order be used in the defence industry. I cannot find a reference for that. I think it may have been from Inside the Windows NT Kernel. Anyway, the POSIX sub-system in windows despite misquotes to the contrary is hideously broken in several key areas that make it unusable for anything non-trivial. This is why cygwin exists. There are numerous examples but the one that most often trip people up are non-blocking IO and signal handling. Nowhere will you find documentation of these incompatabilities on MSDN. They will happily describe the basic API and state that it complies with POSIX 1001.3 whilst blissfully remaining broken. Unaccountably the 'posix' functions in win32 all have a leading underscores. Just compare the documentation for read and _read. Note the distinct absence of any mention of non-blocking IO. The only reliable way to do this on windows is to use the win32 API and even then I believe (I may be wrong here) you need multiple threads. http://msdn2.microsoft.com/en-us/library/wyssk1bs.aspx vs http://www.opengroup.org/onlinepubs/7990989775/xsh/read.html
 This is
 where language standard libraries are a godsend. Though its hard to find
 good
 portable implementations of non-blocking IO and file locking.
 I suspect this may be an area where Tango is ahead of Phobos but not
 knowing
 both APIs well I'm not in a position to comment.
I am always glad of languages that successful wrap a POSIX like API on both platforms. However, they tend to stumble on the same trip-wires mentioned above. At leat in their documentation they have the humility (or rather clarity) to admit that some functionality will only work on one platform or the other. Regards, Bruce.
Feb 12 2008
next sibling parent reply "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Wed, 13 Feb 2008 00:52:45 -0000, Bruce Adams  =

<tortoise_74 yeah.who.co.uk> wrote:

 On Mon, 11 Feb 2008 15:52:54 -0000, David Wilson <dw botanicus.net>  =
 wrote:

 On 2/9/08, Bruce Adams <tortoise_74 yeah.who.co.uk> wrote:

 Unfortunately this is so. A long time ago the POSIX standard was  =
 invented
 (or rather brought together from some early Unixes) and though  =
 low-level
 (not OO for a start) it is solid and reliable.
 The idea being if you want to write portable code you write it using=
=
 only
 POSIX
 functionality.
 M$ in their finite wisdom chose to tear up the standard and invent  =
 their
 own
 and then pretend they supported it. The result is it is practically
 impossible
 to write portable code without having another wrapper layer inbetwee=
n.
 ANSI C (including the standard library) wasn't standardised until
 1990. The first versions of MS-DOS appeared in 1982. POSIX didn't
 appear until 1988. Which standard are you referring to, or is this
 just more of the same uninformed Microsoft bashing?


 David.
Same as what uninformed M$ bashing? Windows NT 3.1 appeared around 1993 - =
 http://www.microsoft.com/windows/WinHistoryDesktop.mspx
 Microsoft were required to include a POSIX subsystem in order be used =
in =
 the defence industry.
 I cannot find a reference for that. I think it may have been from Insi=
de =
 the Windows NT Kernel.
 Anyway, the POSIX sub-system in windows despite misquotes to the  =
 contrary is hideously broken in
 several key areas that make it unusable for anything non-trivial. This=
=
 is why cygwin exists.
 There are numerous examples but the one that most often trip people up=
=
 are non-blocking IO and
 signal handling.
 Nowhere will you find documentation of these incompatabilities on MSDN=
. =
 They will happily describe
 the basic API and state that it complies with POSIX 1001.3 whilst  =
 blissfully remaining broken.
 Unaccountably the 'posix' functions in win32 all have a leading  =
 underscores.
 Just compare the documentation for read and _read. Note the distinct  =
 absence of any mention of
 non-blocking IO. The only reliable way to do this on windows is to use=
=
 the win32 API and even then
 I believe (I may be wrong here) you need multiple threads.

   http://msdn2.microsoft.com/en-us/library/wyssk1bs.aspx

 vs

   http://www.opengroup.org/onlinepubs/7990989775/xsh/read.html

 This is
 where language standard libraries are a godsend. Though its hard to =
=
 find
 good
 portable implementations of non-blocking IO and file locking.
 I suspect this may be an area where Tango is ahead of Phobos but not=
 knowing
 both APIs well I'm not in a position to comment.
I am always glad of languages that successful wrap a POSIX like API on=
=
 both platforms.
 However, they tend to stumble on the same trip-wires mentioned above. =
At =
 leat in their documentation
 they have the humility (or rather clarity) to admit that some  =
 functionality will only work
 on one platform or the other.

 Regards,

 Bruce.
The more informed of you may be able to point out that the POSIX sub-sys= tem of NT/2000 consists of three files and is not present in XP or later. PSXSS.EXE, the POSIX subsystem server PSXDLL.DLL, the POSIX dynamic-link library POSIX.EXE, the POSIX console session manager The even more informed may be able to tell the less informed of us (e.g.= = me) where documentation for these might be located. To find even this much out you have to follow a trail of stale breadcrum= bs http://support.microsoft.com/kb/149902 google: "Understanding Windows NT POSIX Compatibility" and find a text file. http://www.freestuffjamaica.com/mynotes/Windows%20Programming/posix.txt Some articles claim strict compliance to POSIX.1 only. E.g. http://thesource.ofallevil.com/technet/archive/ntwrkstn/reskit/poscomp.m= spx?mfr=3Dtrue That is a M$ website. Not sure about the URL. Presumably that is more uninformed microsoft bashing. You will also find a security vulnerability for which the suggested = solution is disable the POSIX subsystem. This is fair enough as its useless anywa= y. http://descriptions.securescout.com/tc/14112 In summary Posix + Windows don't waste your time. There is something called SFU (services for Unix) It is also squirrelled away and impossible to find using POSIX as a sear= ch time. Until recently it was commercial only. http://en.wikipedia.org/wiki/Microsoft_Windows_Services_for_UNIX I suspect this would be a bit of a heavy download/install to require of = = users for anything not seriously entrenched in unix already. Why not be lured in by the = darkside of a rewrite in .NET instead. This is a much subtler form of anti-competitiveness than browser = integration and the like but no less insidious. Note that Apple Macs are posix compliant when the= y = don't need to be except to help us poor programmers.
Feb 12 2008
parent Sean Kelly <sean f4.ca> writes:
Bruce Adams wrote:
 On Wed, 13 Feb 2008 00:52:45 -0000, Bruce Adams 
 <tortoise_74 yeah.who.co.uk> wrote:
 
 On Mon, 11 Feb 2008 15:52:54 -0000, David Wilson <dw botanicus.net> 
 wrote:

 On 2/9/08, Bruce Adams <tortoise_74 yeah.who.co.uk> wrote:

 Unfortunately this is so. A long time ago the POSIX standard was 
 invented
 (or rather brought together from some early Unixes) and though 
 low-level
 (not OO for a start) it is solid and reliable.
 The idea being if you want to write portable code you write it using 
 only
 POSIX
 functionality.
 M$ in their finite wisdom chose to tear up the standard and invent 
 their
 own
 and then pretend they supported it. The result is it is practically
 impossible
 to write portable code without having another wrapper layer inbetween.
ANSI C (including the standard library) wasn't standardised until 1990. The first versions of MS-DOS appeared in 1982. POSIX didn't appear until 1988. Which standard are you referring to, or is this just more of the same uninformed Microsoft bashing? David.
Same as what uninformed M$ bashing? Windows NT 3.1 appeared around 1993 - http://www.microsoft.com/windows/WinHistoryDesktop.mspx Microsoft were required to include a POSIX subsystem in order be used in the defence industry. I cannot find a reference for that. I think it may have been from Inside the Windows NT Kernel. Anyway, the POSIX sub-system in windows despite misquotes to the contrary is hideously broken in several key areas that make it unusable for anything non-trivial. This is why cygwin exists. There are numerous examples but the one that most often trip people up are non-blocking IO and signal handling. Nowhere will you find documentation of these incompatabilities on MSDN. They will happily describe the basic API and state that it complies with POSIX 1001.3 whilst blissfully remaining broken. Unaccountably the 'posix' functions in win32 all have a leading underscores. Just compare the documentation for read and _read. Note the distinct absence of any mention of non-blocking IO. The only reliable way to do this on windows is to use the win32 API and even then I believe (I may be wrong here) you need multiple threads. http://msdn2.microsoft.com/en-us/library/wyssk1bs.aspx vs http://www.opengroup.org/onlinepubs/7990989775/xsh/read.html
 This is
 where language standard libraries are a godsend. Though its hard to 
 find
 good
 portable implementations of non-blocking IO and file locking.
 I suspect this may be an area where Tango is ahead of Phobos but not
 knowing
 both APIs well I'm not in a position to comment.
I am always glad of languages that successful wrap a POSIX like API on both platforms. However, they tend to stumble on the same trip-wires mentioned above. At leat in their documentation they have the humility (or rather clarity) to admit that some functionality will only work on one platform or the other. Regards, Bruce.
The more informed of you may be able to point out that the POSIX sub-system of NT/2000 consists of three files and is not present in XP or later. PSXSS.EXE, the POSIX subsystem server PSXDLL.DLL, the POSIX dynamic-link library POSIX.EXE, the POSIX console session manager
I believe this was replaced by Microsoft Services for Unix Applications (SUA), which has since been renamed to something else. The subsystem is a separate download for XP, but it's actually built into Vista. That said, it's kind of a mess, and writing mixed-mode applications isn't terribly straightforward. If you want commercial-grade POSIX support on Windows I'd suggest grabbing a copy of MKS Toolkit instead. Sean
Feb 12 2008
prev sibling parent "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Wed, 13 Feb 2008 00:52:45 -0000, Bruce Adams
<tortoise_74 yeah.who.co.uk> wrote:

 On Mon, 11 Feb 2008 15:52:54 -0000, David Wilson <dw botanicus.net>  =
 wrote:

 On 2/9/08, Bruce Adams <tortoise_74 yeah.who.co.uk> wrote:

 Unfortunately this is so. A long time ago the POSIX standard was  =
 invented
 (or rather brought together from some early Unixes) and though  =
 low-level
 (not OO for a start) it is solid and reliable.
 The idea being if you want to write portable code you write it using=
=
 only
 POSIX
 functionality.
 M$ in their finite wisdom chose to tear up the standard and invent  =
 their
 own
 and then pretend they supported it. The result is it is practically
 impossible
 to write portable code without having another wrapper layer inbetwee=
n.
 ANSI C (including the standard library) wasn't standardised until
 1990. The first versions of MS-DOS appeared in 1982. POSIX didn't
 appear until 1988. Which standard are you referring to, or is this
 just more of the same uninformed Microsoft bashing?


 David.
Same as what uninformed M$ bashing? Windows NT 3.1 appeared around 1993 - =
 http://www.microsoft.com/windows/WinHistoryDesktop.mspx
 Microsoft were required to include a POSIX subsystem in order be used =
in =
 the defence industry.
 I cannot find a reference for that. I think it may have been from Insi=
de =
 the Windows NT Kernel.
 Anyway, the POSIX sub-system in windows despite misquotes to the  =
 contrary is hideously broken in
 several key areas that make it unusable for anything non-trivial. This=
=
 is why cygwin exists.
 There are numerous examples but the one that most often trip people up=
=
 are non-blocking IO and
 signal handling.
 Nowhere will you find documentation of these incompatabilities on MSDN=
. =
 They will happily describe
 the basic API and state that it complies with POSIX 1001.3 whilst  =
 blissfully remaining broken.
 Unaccountably the 'posix' functions in win32 all have a leading  =
 underscores.
 Just compare the documentation for read and _read. Note the distinct  =
 absence of any mention of
 non-blocking IO. The only reliable way to do this on windows is to use=
=
 the win32 API and even then
 I believe (I may be wrong here) you need multiple threads.

   http://msdn2.microsoft.com/en-us/library/wyssk1bs.aspx

 vs

   http://www.opengroup.org/onlinepubs/7990989775/xsh/read.html

 This is
 where language standard libraries are a godsend. Though its hard to =
=
 find
 good
 portable implementations of non-blocking IO and file locking.
 I suspect this may be an area where Tango is ahead of Phobos but not=
 knowing
 both APIs well I'm not in a position to comment.
I am always glad of languages that successful wrap a POSIX like API on=
=
 both platforms.
 However, they tend to stumble on the same trip-wires mentioned above. =
At =
 leat in their documentation
 they have the humility (or rather clarity) to admit that some  =
 functionality will only work
 on one platform or the other.

 Regards,

 Bruce.
The more informed of you may be able to point out that the POSIX sub-sys= tem of NT/2000 consists of three files and is not present in XP or later. PSXSS.EXE, the POSIX subsystem server PSXDLL.DLL, the POSIX dynamic-link library POSIX.EXE, the POSIX console session manager The even more informed may be able to tell the less informed of us (e.g.= me) where documentation for these might be located. To find even this much out you have to follow a trail of stale breadcrum= bs http://support.microsoft.com/kb/149902 google: "Understanding Windows NT POSIX Compatibility" and find a text file. http://www.freestuffjamaica.com/mynotes/Windows%20Programming/posix.txt Some articles claim strict compliance to POSIX.1 only. E.g. http://thesource.ofallevil.com/technet/archive/ntwrkstn/reskit/poscomp.m= spx?mfr=3Dtrue That is a M$ website. Not sure about the URL. Presumably that is more uninformed microsoft bashing. You will also find a security vulnerability for which the suggested solution is disable the POSIX subsystem. This is fair enough as its useless anywa= y. http://descriptions.securescout.com/tc/14112 In summary Posix + Windows don't waste your time. There is something called SFU (services for Unix) It is also squirrelled away and impossible to find using POSIX as a sear= ch time. Until recently it was commercial only. http://en.wikipedia.org/wiki/Microsoft_Windows_Services_for_UNIX I suspect this would be a bit of a heavy download/install to require of users for anything not seriously entrenched in unix already. Why not be lured in by the darkside of a rewrite in .NET instead. This is a much subtler form of anti-competitiveness than browser integration and the like but no less insidious. Note that Apple Macs are posix compliant when the= y don't need to be except to help us poor programmers.
Feb 12 2008