Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

trying not to be a hater ... but

47 views
Skip to first unread message

luser droog

unread,
Jan 7, 2015, 12:07:19 AM1/7/15
to
Another option UNIX programmers look at is the Windows POSIX subsystem. However, it only supports POSIX 1003.1, which was the only POSIX version standardized when Windows NT was created. Since then, there has been little demand for extending this subsystem, because most applications have been converted to Win32.
http://msdn.microsoft.com/en-us/library/y23kc048.aspx

--
n=

Xavier Roche

unread,
Jan 7, 2015, 1:14:48 AM1/7/15
to
On 01/07/2015 06:07 AM, luser droog wrote:
> http://msdn.microsoft.com/en-us/library/y23kc048.aspx

Standard C library functions are in many cases non-POSIX compliant (despite sharing the same name and arguments) - this is the biggest issue probably.

Rainer Weikusat

unread,
Jan 7, 2015, 9:09:06 AM1/7/15
to
luser droog <mij...@yahoo.com> writes:
> Another option UNIX programmers look at is the Windows POSIX
> subsystem. However, it only supports POSIX 1003.1, which was the only
> POSIX version standardized when Windows NT was created. Since then,
> there has been little demand for extending this subsystem, because
> most applications have been converted to Win32.

Reportedly, the 'Windows POSIX subsystem' came into being for the sole
reason of allowing Microsoft to bid for US government contracts despite
a policy ruling out 'proprietary, single-supplier offerings'. Because of
this, nobody ever demanded anything from it, nobody
ever used it to run 'POSIX-compliant applications' (beyond fig leaves)
and (unsurprisingly) no native applications using it were ever
developed. Two alternate options which have been used for real
application development would be NSPR ('Netscape Portable Runtime') and
APR ('Apache Portable Runtime').

BTW, what was the point of your statement? I mean, beyond quoting the
Microsoft marketing statement that nobody ever used anything but
Windows, nothing but Windows can be used for anything and this situation
will never change?

James K. Lowden

unread,
Jan 8, 2015, 12:12:14 AM1/8/15
to
On Tue, 6 Jan 2015 21:07:16 -0800 (PST)
luser droog <mij...@yahoo.com> wrote:

> Another option UNIX programmers look at is the Windows POSIX
> subsystem. However, it only supports POSIX 1003.1

FSVO "support". I suggest fork is an important part of of the
standard,
http://pubs.opengroup.org/onlinepubs/009695399/functions/fork.html.

I once made a list of the functions missing from Microsoft's C library
that are in every BSD and GNU implementation I know of. IIRC it
numbered over 100, some very difficult if not impossible to recreate
without kernel support. I didn't count those, like winsock32, that
exist but with questionable semantics or arbitrary limitations.

The so-called Posix subsystem has no shell, no mail, and no system
management utilities. It is so crippled that cygwin ignored it.

--jkl

Geoff Clare

unread,
Jan 8, 2015, 9:11:07 AM1/8/15
to
James K. Lowden wrote:

> On Tue, 6 Jan 2015 21:07:16 -0800 (PST)
> luser droog <mij...@yahoo.com> wrote:
>
>> Another option UNIX programmers look at is the Windows POSIX
>> subsystem. However, it only supports POSIX 1003.1
>
> FSVO "support". I suggest fork is an important part of of the
> standard,

It had fork. There was no way it could have got FIPS 151-2
certification without it.

--
Geoff Clare <net...@gclare.org.uk>

Geoff Clare

unread,
Jan 8, 2015, 9:11:07 AM1/8/15
to
luser droog wrote:

> Another option UNIX programmers look at is the Windows POSIX
> subsystem.

"Look at", present tense?!

As I understand it, the Windows POSIX subsystem was only included
in NT and 2000 - it was removed in XP.

> However, it only supports POSIX 1003.1, which was the
> only POSIX version standardized when Windows NT was created.

This is a little misleading, since POSIX 1003.2 was merged into 1003.1
in 2001. It would be more accurate to say that the Windows POSIX
subsystem only supported POSIX 1003.1-1990, making it clear that it
didn't support later revisions of 1003.1 (such as the 1996 revision
that brought in threads and realtime APIs) or the shell and utilities
that were originally in the separate 1003.2.

Actually, it was certified to FIPS 151-2 which had a few extra
requirements over 1003.1-1990 (mostly mandating some POSIX options).

--
Geoff Clare <net...@gclare.org.uk>

luser droog

unread,
Jan 9, 2015, 1:11:26 AM1/9/15
to
I was lamenting the fact that my google search for
"porting unix code to windows" turned up this rather
unhelpful bit of hand-waving. My commentary in the
signature "n=", was intended to point out the term
"most applications" and to wonder at what the sample
size had been for that sentence to have ever had
a truthful interpretation.

And also, you know, just feeling a little lonely
in this corner of the world and stabbing in the
dark for contact with people. :)

James K. Lowden

unread,
Jan 14, 2015, 12:17:54 AM1/14/15
to
On Thu, 8 Jan 2015 13:49:21 +0000
Geoff Clare <ge...@clare.See-My-Signature.invalid> wrote:

> > FSVO "support". I suggest fork is an important part of of the
> > standard,
>
> It had fork. There was no way it could have got FIPS 151-2
> certification without it.

http://technet.microsoft.com/en-us/library/cc754234.aspx

Indeed it did, or at any rate gained it at some point. I stand
corrected, thanks.

http://support.microsoft.com/kb/149902/en-us

I'd also forgotten, "POSIX applications do not have access to any
networking APIs such as pipes or sockets." I guess I'll hang my hat on
that one. ;-)

--jkl
0 new messages