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

[Bruce Adams]

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

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 breadcrumbs

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.mspx?mfr=true

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 anyway.

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 search
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 they  
don't need to be
except to help us poor programmers.