open, close, dup, dup2, lseek, read, write, fileno, etc.

[Sean Kelly]

Bruce Adams wrote:
> On Wed, 13 Feb 2008 00:52:45 -0000, Bruce Adams 
> <tortoise_74 at yeah.who.co.uk> wrote:
> 
>> On Mon, 11 Feb 2008 15:52:54 -0000, David Wilson <dw at botanicus.net> 
>> wrote:
>>
>>> On 2/9/08, Bruce Adams <tortoise_74 at 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