digitalmars.D - open, close, dup, dup2, lseek, read, write, fileno, etc.
- Janice Caron (12/12) Feb 08 2008 open, close, dup, dup2, lseek, read, write, fileno, etc....
- Neal Alexander (5/21) Feb 08 2008 I think theres some limitations to the POSIX subsystem on win32. Dunno h...
- Derek Parnell (10/17) Feb 08 2008 No. So go ahead and code them then submit them to the Phobos development
- Walter Bright (5/19) Feb 08 2008 Going directly to the underlying OS functions makes for faster, more
- Janice Caron (13/17) Feb 08 2008 Thanks for the answer. Though my question wasn't "Why does
- Walter Bright (17/37) Feb 08 2008 You can use them - they are in the C runtime library for Windows. Just
- Alexander Panek (6/50) Feb 09 2008 I am not certainly sure, but I do think open, close & co are POSIX
- Leandro Lucarella (15/50) Feb 09 2008 Yes, and this reminds me why there is no "posix" version (like in Tango
- Bruce Adams (36/70) Feb 09 2008 ws
- David Wilson (6/24) Feb 11 2008 ANSI C (including the standard library) wasn't standardised until
- Steven Schveighoffer (23/39) Feb 11 2008 According to Wikipedia, Windows NT was released in 1993, which is the fi...
- Jussi Jumppanen (10/17) Feb 11 2008 I might be wrong, but I thought the Win16 API had an OpenFile
- Don Clugston (7/29) Feb 12 2008 Early Windows versions had no documented file handling functions other t...
- Bruce Adams (38/65) Feb 12 2008 Same as what uninformed M$ bashing?
- Bruce Adams (58/133) Feb 12 2008 =
- Sean Kelly (8/100) Feb 12 2008 I believe this was replaced by Microsoft Services for Unix Applications
- Bruce Adams (56/131) Feb 12 2008 =
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
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
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
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
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
Janice Caron wrote:On 09/02/2008, Walter Bright <newshound1 digitalmars.com> wrote: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.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.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
Walter Bright wrote:Janice Caron wrote: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. :)On 09/02/2008, Walter Bright <newshound1 digitalmars.com> wrote: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.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.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 09 2008
Alexander Panek, el 9 de febrero a las 12:20 me escribiste:Walter Bright wrote: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 KiwiJanice Caron wrote: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.On 09/02/2008, Walter Bright <newshound1 digitalmars.com> wrote: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.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.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 09 2008
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=wsefficient I/O. Calling open, close, etc., on Windows makes for poor performance, because those functions are layered on top of the Windo=aI/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 ==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.eIt is simpler easier to write platform-independent code if you can us=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
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
"David Wilson"wroteOn 2/9/08, Bruce Adams 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). 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. -SteveUnfortunately 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?
Feb 11 2008
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
Jussi Jumppanen wrote:Steven Schveighoffer Wrote: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.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 12 2008
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: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.htmlUnfortunately 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.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.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 12 2008
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 =n.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=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==I am always glad of languages that successful wrap a POSIX like API on=knowing both APIs well I'm not in a position to comment.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
Bruce Adams wrote:On Wed, 13 Feb 2008 00:52:45 -0000, Bruce Adams <tortoise_74 yeah.who.co.uk> wrote: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. SeanOn Mon, 11 Feb 2008 15:52:54 -0000, David Wilson <dw botanicus.net> wrote: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 managerOn 2/9/08, Bruce Adams <tortoise_74 yeah.who.co.uk> wrote: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.htmlUnfortunately 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.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.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 12 2008
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 =n.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=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==I am always glad of languages that successful wrap a POSIX like API on=knowing both APIs well I'm not in a position to comment.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