"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

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

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
> 

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.

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

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.

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

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.

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