C is fixed or not ?

[Rui Maciel]

Windows SFU gets you a pretty good Unix environment, where you can
compile and run your Unix applications. It is largely separate from
the Windows API side of things, and there's little or no ability to
use the Windows APIs in an WSFU application (or vice versa).

So the fact that MS (with some outside help) has implemented WSFU on
top of the NT native API (which is not the Win32 API, but the Win32
API is built on top of the native API too), says nothing about the
practicality of implementing pthreads on top of the Win32 threading
functions.

It was already proven that it is possible to create and provide a standard-
complying pthreads API in Windows. The "practicality" of doing so is
irrelevant, as what counts is that it is there, it is available and users
are able to rely on a standard-compliang C threading API in Windows. And
finally, let's not confuse technical impossibilities with an unwillingness
to provide some features.


Rui Maciel

 

[James Kuyper]

On 07/12/2011 08:35 PM, Rui Maciel wrote:
....

It was already proven that it is possible to create and provide a standard-
complying pthreads API in Windows.

So, you're referring to something other than the implementation
described on <http://sourceware.org/pthreads-win32/conformance.html>.
That implementation fails to fully comply due to the items listed in the
section which says "The following functions are not implemented:". So,
what is this other pthreads API in Windows, the one that does implement
all of those functions, and therefore counts as complying? How may I
clearly distinguish that API from the one described on the web page
referred above?

 

[James Kuyper]

According to Microsoft's site, their pthreads implementation was released in
2004 and it conforms to IEEE 1003.1-2001. As that standard was updated in
2004 to include an errata and after that ony in 2008 then I fail to see your
point.

The point is that the cited web page makes no claim that Microsoft's
pthreads implementation fully complies with any version of POSIX later
than 2001. You'd think that if they did actually go to the effort of
complying with the current POSIX standard, they'd mention that fact.

It appears you are confused. Larry Jones' assertion was that "POSIX threads
cannot be implemented on top of Windows", which was already demonstrated to
be false. I don't know what you mean by "can only be used in programs
running in the POSIX subsystem"

Can you write a program that makes use of arbitrary Windows features,
just like any other ordinary Windows program, AND also makes use of the
Windows version of pthreads? Larry's comments imply that there are
Windows-specific facilities that are not available to programs running
under the POSIX subsystem. I wandered around the Microsoft web site for
a while; I found lots of statements suggesting that the POSIX Subsystem
provides a very Unix-like environment; but I couldn't find anything
which addressed the issue of whether or not Windows-specific features
are available to programs operating in that environment.

 

[Nick Keighley]

James Kuyper wrote:


Let's see.. the POSIX/Unix crowd has their threading API already and the
Windows crowd has theirs, and you are making the assumption that
something that works on both platforms is going to be liked/used by
either of those groups, even knowing that the approaches are different?
What are the chances!

some people write portable code. i find it vaguely irritating that
unix and windows have gratuitious incompatibilities in, say, sockets.
If I could do the thready part of the program in some standard API and
have it Just Work then I'd feel a strong compulsion to use that API. I
could alos avoid learning two presumably subtly different thread
approaches. Seems a win win to me.

 

[lawrence.jones]

It appears you are confused. Larry Jones' assertion was that "POSIX threads
cannot be implemented on top of Windows", which was already demonstrated to
be false.

We have different definitons of what "on top of Windows" means. I mean
"on top of the normal Win32 environment subsystem that essentially all
Windows users and applications use", not "on top of the bare Windows
kernel".

I don't know what you mean by "can only be used in programs
running in the POSIX subsystem"

It means that pthreads are only available in the POSIX environment
subsystem that hardly anyone uses because it provides *only* a Unix-like
environment and not the Win32 environment that most users and
application expect. For example, in the POSIX environment, file names
look like "/bin/ls", not "C:\Program Files\dir.exe". The two
environments are completely separate (although implemented on top of the
same kernel) and you have to pick one or the other; you can't use both
at the same time.

 

[Ersek, Laszlo]

Please note: I've added comp.unix.programmer (for the POSIX aspects)
and comp.programming.threads (for the threading aspect)

We've been discussing the next revision of the C standard (C1X)
http://en.wikipedia.org/wiki/C1X
Specifically, the inclusion of multi-threading support.

Apparently, Dinkumware's library is being considered, and some
are wondering why the committee did not consider adopting the
POSIX API itself, or a subset thereof.

Would enlightened people in either comp.unix.programmer or
comp.programming.threads comment on these aspects?

Perhaps relevant, from 2010-Jul:

"harmonization(?) of threading interfaces between POSIX/SUS and C1X"

- POSIX discussion:
http://comments.gmane.org/gmane.comp.standards.posix.austin.general/2640

- comp.std.c discussion:
http://groups.google.com/group/comp.std.c/browse_frm/thread/61d6ab42db75f19a/fe2b250e2864d136

lacos

 

[MikeP]

some people write portable code. i find it vaguely irritating that
unix and windows have gratuitious incompatibilities in, say, sockets.
If I could do the thready part of the program in some standard API and
have it Just Work then I'd feel a strong compulsion to use that API. I
could alos avoid learning two presumably subtly different thread
approaches. Seems a win win to me.

Well that's the THEORY behind programming language standard libraries,
anyway. All it really is though, is yet another wrench in the machine.
Better to program to the specific platform than some concoction that is
half-way here and half-way there, IMO. The "portable code" mantra is more
trouble than it is worth (again, IMO. Been there, done that). I think
languages should strive to enable library development, but I don't think
they should specify any libraries at all, as that is for ancillaries
(groups, companies) to do. Standard libraries hinder progress rather than
advance the state of the art.

IMO.

(Aside: The C std library is, of course, the Unix API, so why someone
would want to use it on Windows escapes me. One could further on that
track by asking why anyone would want to use C (the Unix PL) on
Windows!).

 

[Ian Collins]

(Aside: The C std library is, of course, the Unix API

No, it isn't.

 

[MikeP]

No, it isn't.

Well it started out being that and still has that same flavor, that is
the point: they belong together, a match made in... he

That it is now a subset of POSIX is really unimportant.

 

[Nick Keighley]

Well that's the THEORY behind programming language standard libraries,

there is nothing as practical as a good theory. A theory isn't a half
assed idea someone dreamed up in the shower.

Standard cross platform libraries are incredibly useful.

anyway. All it really is though, is yet another wrench in the machine.
Better to program to the specific platform than some concoction that is
half-way here and half-way there, IMO.

and I beg to differ. *Some* things are goign to be platform specific
but huge chunks of many applications are plaform agnostic.

The "portable code" mantra is more
trouble than it is worth (again, IMO. Been there, done that).

so have I, and the conclusions we've drawn seem to differ

I think
languages should strive to enable library development, but I don't think
they should specify any libraries at all, as that is for ancillaries
(groups, companies) to do. Standard libraries hinder progress rather than
advance the state of the art.

the Python people would disagree (plus pretty much any other language
designed in the last 20 years)

IMO.

(Aside: The C std library is, of course, the Unix API, so why someone
would want to use it on Windows escapes me. One could further on that
track by asking why anyone would want to use C (the Unix PL) on
Windows!).

what do you thing Windows was programmed in? Take a look at the Win32
API. It's C.

 

[Malcolm McLean]

Well that's the THEORY behind programming language standard libraries,
anyway. All it really is though, is yet another wrench in the machine.
Better to program to the specific platform than some concoction that is
half-way here and half-way there, IMO. The "portable code" mantra is more
trouble than it is worth (again, IMO. Been there, done that).

It depends how you work.
If the programs have trivial logic but complex user interface, e.g.
drawing programs, typical business applications, arcade-style games
then it's probaly more trouble that it's worth to port them.

However if you've just coded an intricate natural language parser for
an adventure-style game, it's a thundering nuisance to have to go
through all the code and fork development, just because someone's
decided that strcpy() is dangerous and therefore no longer supported.

 

[Ben Bacarisse]

Well it started out being that

I don't think so. Had you said "is influenced by" or "was developed to
work closely with" or some such phrase I doubt there would be much
objection, but "is" on its own suggests they are the same (or
substantially the same) and they're not. The only part of the Unix API
(the system call interface) that I can spot that went into the C
standard library was signal(2). That's a tiny part of the library.

Your argument is, presumably, that tighter system integration is more
important than portability. There will be times when that's true and
times when it won't be. As a general claim I think it's almost
impossible to judge, but it dose not fly as a criticism of the C library
because the presence of some standard functions does not force you to
use them when there are more appropriate system-specific ones.

<snip>

 

[J. J. Farrell]

According to Microsoft's site, their pthreads implementation was released in
2004 and it conforms to IEEE 1003.1-2001. As that standard was updated in
2004 to include an errata and after that ony in 2008 then I fail to see your
point.

You emphasise my point while failing to see it, which is curious.
Windows Services for UNIX 3.5 implements a subset of pthreads as defined
by POSIX 2001. The current definition of pthreads is provided by POSIX
2008, two generations of POSIX later. The version of POSIX threads
implemented for the POSIX subsystem of Windows is a subset of POSIX
threads as it was defined seven years and two generations before the
current POSIX Standard.

It appears you are confused.

I don't believe so.

Larry Jones' assertion was that "POSIX threads
cannot be implemented on top of Windows", which was already demonstrated to
be false.

I've not seen any such demonstration. An implementation of a subset of
an old version of pthreads for an isolated subsystem which is rarely if
ever used but happens to run on Windows' NT kernel is hardly relevant.

I don't know what you mean by "can only be used in programs
running in the POSIX subsystem"

I mean exactly what I say. Almost everyone, in almost every
circumstance, when talking about writing user-level software for
"Windows", is talking about writing software for "the Win32 subsystem on
Windows". I don't know Larry, but I'll happily bet that's what he meant
since that is what almost everyone almost always means by that
shorthand. Most people who write user-mode software for Windows aren't
even aware that other subsystems can run on the NT kernel. Even if there
were a conforming implementation of pthreads which could run in the
POSIX subsystem on top of NT, what possible relevance is that to the
99.99999% of Windows user mode software which runs in the Win32
subsystem? That software can't make any use the pthreads implementation,
it can't use it instead of the Win32 threading primitives, it can't
interact with it.

but independent of what you meant, but that
doesn't contradict the fact that it is quite possible to provide a standard-
conforming pthreads interface to windows.

Even the implementation which runs in the POSIX subsystem doesn't
conform to POSIX; what evidence do you have for this claim that it is
possible to provide a conforming implementation for use by Windows
programmers, which means one that runs in the Win32 subsystem?

And if it is possible to provide
an API in an OS then the only thing that stops you from using it is your
will to use it.

If it is possible, and if someone reliable chooses to implement and
supply such an implementation for the Win32 subsystem at no additional
cost, then you are obviously quite right and there wouldn't be this
discussion. In this world though, no such implementation exists and
there are doubts that one is even possible.

 

[MikeP]

I don't think so. Had you said "is influenced by" or "was developed
to work closely with" or some such phrase I doubt there would be much
objection, but "is" on its own suggests they are the same (or
substantially the same) and they're not. The only part of the Unix
API (the system call interface) that I can spot that went into the C
standard library was signal(2). That's a tiny part of the library.

E.g. (what I was getting at): Unix has 'fopen', Windows has 'CreateFile'.

Your argument is, presumably, that tighter system integration is more
important than portability.

Not really (not that I don't or do agree with that). Standard libraries
of programming languages notoriously suck. One is faced with that "holy
portability" (and "performance trumps elegance") thing even when one need
not be. That's fine if you need it, but if you don't, you don't. Not that
platform-provided libraries are a panacea, but that I'd rather build
something on top of that than on top of language-provided libraries
because I feel that language-provided libraries are not adequate as the
top-level of abstraction and if I have to build something on top of
something anyway, I prefer to build on top of the platform API. YMMV: I'm
not trying to persuade anyone to use my methods.

There will be times when that's true and
times when it won't be. As a general claim I think it's almost
impossible to judge, but it dose not fly as a criticism of the C
library because the presence of some standard functions does not
force you to use them when there are more appropriate system-specific
ones.

I think the library committee and the language proper committee should
not be one in the same (even if they have largely the same membership).

 

[Ian Collins]

E.g. (what I was getting at): Unix has 'fopen', Windows has 'CreateFile'.

Really? The Unix native functions are open() and creat().

Not really (not that I don't or do agree with that). Standard libraries
of programming languages notoriously suck.

Have you ever tried to use say PHP, Python or Java without using their
standard libraries? have you never used printf?

One is faced with that "holy
portability" (and "performance trumps elegance") thing even when one need
not be. That's fine if you need it, but if you don't, you don't. Not that
platform-provided libraries are a panacea, but that I'd rather build
something on top of that than on top of language-provided libraries
because I feel that language-provided libraries are not adequate as the
top-level of abstraction and if I have to build something on top of
something anyway, I prefer to build on top of the platform API. YMMV: I'm
not trying to persuade anyone to use my methods.

Have you ever used platform-provided libraries in PHP, Python or Java?

I think the library committee and the language proper committee should
not be one in the same (even if they have largely the same membership).

The language committees have separate working groups for the core
language and the libraries (at least that's the case with C++). The two
can not work in isolation, some library components require language
enhancements.

 

[MikeP]

there is nothing as practical as a good theory.

LOL. You surely meant to say: there's nothing practical about theory!

A theory isn't a half
assed idea someone dreamed up in the shower.

Standard cross platform libraries are incredibly useful.

To some of the people, some of the time.

and I beg to differ.
*Some* things are goign to be platform specific
but huge chunks of many applications are plaform agnostic.



so have I, and the conclusions we've drawn seem to differ

I'm not much of a follower, so people and me usually differ. No problemo.

the Python people would disagree (plus pretty much any other language
designed in the last 20 years)

20 years wasted, why waste 20 more?

what do you thing Windows was programmed in? Take a look at the Win32
API. It's C.

That was a loooong time ago. It's changing. It doesn't take much
imagination to see the trends.

 

[Keith Thompson]

LOL. You surely meant to say: there's nothing practical about theory!

Right, because if anyone states an opinion contrary to yours, it could
only have been a typo.

[...]

 

[MikeP]

Really? The Unix native functions are open() and creat().

And the C std library is probably adequate for abstracting them, for
those who like that Unixy taste. We can go round and round for years but
won't get anywhere because you think the std library is the best thing
since apple pie and I think it sucks. If I was programming for Unix, I
would surely build something on top of open and create just as I have
built on top of CreateFile and friends.

Have you ever tried to use say PHP, Python or Java without using their
standard libraries?
No.

have you never used printf?
Yes.


Have you ever used platform-provided libraries in PHP, Python or Java?

I don't use those.

The language committees have separate working groups for the core
language and the libraries (at least that's the case with C++).

Well that is good news. Completely separate would be (would have been?)
better, but maybe not for the boys club that those languages are. I'm not
knocking it.

The
two can not work in isolation, some library components require
language enhancements.

Well see. Why have only one group influencing the direction of the
language proper? (rhetorical, as it is too late for C and it's processes
to change).

 

[MikeP]

LOL. You surely meant to say: there's nothing practical about theory!

Right, because if anyone states an opinion contrary to yours, it could
only have been a typo.

[...]

Lighten up dude, I was making a joke!

 

[Ian Collins]

And the C std library is probably adequate for abstracting them, for
those who like that Unixy taste. We can go round and round for years but
won't get anywhere because you think the std library is the best thing
since apple pie and I think it sucks. If I was programming for Unix, I
would surely build something on top of open and create just as I have
built on top of CreateFile and friends.

I hold no such opinion. The C standard library simply is.

No.

Well you wouldn't get very far if you did. Part of the attraction of
scripting languages and that abomination called Java is their
continuously evolving, often huge, cross-platform libraries.

Yes.

Ah, so you don't always roll your own?

I don't use those.

Hint: you probably won't find one.