C is fixed or not ?

[James Kuyper]

On 07/08/2011 08:20 AM, Rui Maciel wrote:
....

pthreads is their unwillingness to do so. Regarding Microsoft, they already
provide suppoprt for pthreads.

According to Larry Jones, they don't provide such support for native
Windows programs, only for programs that run within the restrictions of
their "POSIX subsystem". Do you agree that he's right about that?

 

[Shao Miller]

On 07/08/2011 08:20 AM, Rui Maciel wrote:
...

According to Larry Jones, they don't provide such support for native
Windows programs, only for programs that run within the restrictions of
their "POSIX subsystem". Do you agree that he's right about that?

Even using the term "native" is confusing! You have:

- Kernel-land APIs

- User-land APIs:

- "Native" API (NTDLL.DLL)

- "Windows" API (lots of .DLLs, the "basest" of which use the
"native" API)

- "POSIX" API (PSXDLL.DLL, which itself uses the "native" API)

"Notepad" is _not_ a native Windows program. It is a program that
natively works with Windows. I do believe that Mr. L. Jones meant
this kind of "native." He'd _also_ be correct for the _other_ use of
"native."

But of course your news-reader filtering choices won't allow you to read
this message. Good luck!

 

[jameskuyper]

Le 07/07/11 17:13, Walter Banks a �crit :

I have repeatedly said that I CAN'T go to another continent
(or even within Europe) 3 or 4 times a year paying MYSELF
the plane ticket, the 5 nights at the hotel and all the
associated expenses.

The requirement that you attend meetings applies only to voting
members. I believer that all you need to submit proposals is non-
voting membership. You don't even need membership, if you can convince
someone who is a member that your proposal has sufficient merit to
justify them submitting it on their behalf. The nasty things you've
frequently said about the committee may make that a difficult route to
follow.
The key thing is that a lot of detailed work needs to be done checking
for and dealing with interactions between the proposed change and
other parts of the standard. Your proposals generally tend to be very
weak in that area; too often, you claim incorrectly that there are no
such interactions.

 

[MikeP]

Not quite. The only thing that stops a OS project from adding
support for pthreads is their unwillingness to do so. Regarding
Microsoft, they already provide suppoprt for pthreads. Therefore,
this isn't a matter of "POSIX/Unix crowd" Vs "Windows crowd". This
is a matter of a widely established and adopted international
standard Vs an API taken from some proprietary library. And when
defining an international standard, intentionally neglecting
established international standards in favour of some proprietary
code is not a good thing.

That they didn't choose it does not mean that they didn't consider it.
Why don't you ask them why they chose other than pthreads? I think some
people have already given indications of why, not the least of which is
that just because something has some kind of standardization, that does
not necessarily make it good or appropriate. Your posts on this seem so
whiney instead of factual.

 

[MikeP]

Please demonstrate where exactly the pthreads API is obsolete and how
dinkumware's wrapper is superior to it.

When I receive your check in the mail and it clears, I will do that
analysis for you.

Seriously, anything standardized and 10 years old is surely something
holding back progress. I speak in general, but it is generally true. C,
C++, their libraries: all hindrances to progress. Other examples abound.

 

[MikeP]

I don't believe that the pthreads API is not popular, proven nor
developed by C experts.

I'm not taking sides on a given product, for I don't use either one of
them. I'm just saying about where the products come from and the
surrounding politics.

Adding to this, the pthreads API has been an
international standard for over a decade,

WOOO HOOO! SOOOO WHAT?!!! (You sound like a broken record).

 

[Oliver Jackson]

When I receive your check in the mail and it clears, I will do that
analysis for you.

Seriously, anything standardized and 10 years old is surely something
holding back progress. I speak in general, but it is generally true. C,
C++, their libraries: all hindrances to progress. Other examples abound.

Your mom abounds.

 

[J. J. Farrell]

Oh really?

Pthread Support in Microsoft Windows Services for UNIX Version 3.5
Published: June 15, 2004

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

.... which implements a subset of an old version of POSIX threads which
can only be used in programs running in the POSIX subsystem. Nothing to
do with using POSIX thread interfaces in "normal" Windows programs.

 

[Todd Carnes]

... which implements a subset of an old version of POSIX threads which
can only be used in programs running in the POSIX subsystem. Nothing to
do with using POSIX thread interfaces in "normal" Windows programs.

.... And none of this has anything to do with the OP's original question.

Todd

 

[lawrence.jones]

Where do you base that claim?

On the fact that I've never heard a single person say they use it. On
the other hand, I've heard lots of people say they use cygwin, which is
very similar.

What? Do you even know what you are saying? For example, do you actually
know what the term "unix-like" refers to? Because even windows fits the
description of a "unix-like" system.

Invoking Humpty Dumpty, when I use the phrase it means a system derived
from Unix or specifically designed to emulate it. That would include
all the commercial versions of Unix, the various BSDs, and Linux. It
does not include radically different systems that have emulation
subsystems or libraries that provide a unix-like environment that is not
compatible with the native environment specifically to allow porting
Unix programs with minimal change or being checklist compatible with
requirements to provide POSIX like VMS or Windows.

 

[lawrence.jones]

POSIX threads can be implemented quite comprehensively on Windows:

http://sourceware.org/pthreads-win32/conformance.html

Then why is there a long list of unimplemented functions? Certainly
there are *parts* of pthreads that can be implemented on Windows, but
that's not the same thing as implementing the whole thing.

 

[Ian Collins]

On the fact that I've never heard a single person say they use it. On
the other hand, I've heard lots of people say they use cygwin, which is
very similar.


Invoking Humpty Dumpty, when I use the phrase it means a system derived
from Unix or specifically designed to emulate it. That would include
all the commercial versions of Unix, the various BSDs, and Linux. It
does not include radically different systems that have emulation
subsystems or libraries that provide a unix-like environment that is not
compatible with the native environment specifically to allow porting
Unix programs with minimal change or being checklist compatible with
requirements to provide POSIX like VMS or Windows.

So you exclude the RTOSs with a POSIX layer? That's where just about
all of the C code I write these days lives.

 

[lawrence.jones]

But YOU participated to that discussion and were aware of my
criticism. The message you sent in that discussion
was sent on June 8 2009 at 11:52pm

Your initial criticism was that you couldn't make any sense out of the
proposal because you didn't understand the terminology. Most of those
problems have been addressed (although there's certainly more to do).
My sole participation was to point you to where you could find committee
documents, which you should have already known.

Mr Jones: It is very easy to laugh at me. I have no money to go to your
meetings, and the C group in France has disappeared because the AFNOR
decided so.

I'm not laughing at you. I'm frustrated because you keep complaining
that the committee doesn't pay any attention to you despite having been
told repeatedly that the reason they don't is because you're crying in
the wilderness instead of talking to them. I understand your
frustration at not having a more convenient (for you) mechanism for
communicating with the committee, but what would be more convenient for
you would be much less convenient for the committee. You can't afford
to attend meetings, we can't afford to read news groups.

For what it's worth, *I* pay my own way to the meetings and I'm the
project editor! If you can't go to meetings, you can still communicate
with the committee through the convenor, but there's very little chance
of getting anything adopted without some kind of active participation.

You haven't even read the containers proposals, you have not even
bothered to consider the whole idea. You just spread your arrogance
around as it was the thing to do.

I don't recall make any comment on the containers proposal whatsoever.
My personal experience with such things is that they're always much more
trouble than they're worth, so I have no interest in it one way or the
other. If there were a groundswell of support for it here, I might feel
a responsibility to bring it to the committee's attention, but I haven't
seen any.

 

[James Kuyper]

The list isn't that long. What distinguishes those interfaces is that they
can't be implemented on top of, e.g., the stdio implementation. The original
question, as I understood it, was whether the general architecture of
Windows was a reasonable fit for a POSIX threads implementation. Most of the
library can be implemented without unwarranted chumminess with the
underlying implementation, and the remaining pieces--with signals being the
biggest question mark--would appear to require only minimal cooperation by
the vendor.

Not that I believe C1x should adopt pthreads, mind you. Also, the proposal
was qualified--it suggested adopting a _subset_ of pthreads.

There are two proposals that I'm aware of, neither of which can be
accurately described as a "subset of pthreads". The official proposal is
for changes to the language and a set of new library functions that
could be implemented as thin wrappers for pthreads functions, but are
sufficiently generic in their definitions that they could alternatively
be implemented as thin wrappers for other threading systems.

The second proposal has not been officially made, but has been suggested
in a number of forms in this forum. That proposal is that the entire
pthreads specification from POSIX should be inserted, by reference, into
the C standard. While not explicitly stated, the implications have been
that it would need little or no additional wording would be needed,
beyond the statement that it has been so incorporated.

The list of pthreads features which have not been implemented in Windows
is an argument in favor of the official proposal, over the unofficial
one. In the unlikely event that the second proposal were accepted, a
conforming implementation of C running under Windows would be required
to implement all of the items on that list. How difficult would that be?
If Microsoft has not even attempted to implement them, I imagine it
would be pretty difficult.

The fact that even those features which are available, are available
only in the POSIX Subsystem of Windows, and not for native Windows
programs, is another such argument. If I understand it correctly, the
official proposal defines a system that could be made available even for
native Windows programs.

 

[Ian Collins]

The list of pthreads features which have not been implemented in Windows
is an argument in favor of the official proposal, over the unofficial
one. In the unlikely event that the second proposal were accepted, a
conforming implementation of C running under Windows would be required
to implement all of the items on that list. How difficult would that be?
If Microsoft has not even attempted to implement them, I imagine it
would be pretty difficult.

The fact that even those features which are available, are available
only in the POSIX Subsystem of Windows, and not for native Windows
programs, is another such argument. If I understand it correctly, the
official proposal defines a system that could be made available even for
native Windows programs.

Maybe those features will be implemented when they get around to
implementing C99?

 

[lawrence.jones]

So you exclude the RTOSs with a POSIX layer? That's where just about
all of the C code I write these days lives.

I don't have any experience with them, so I can't say which group they
fall into.

 

[Ian Collins]

I don't have any experience with them, so I can't say which group they
fall into.

Most RTOS were designed with their own process and threading models and
they were not designed to emulate UNIX.

They have adopted a POSIX layer for the reason it was originally
proposed in this sub-thread: portability.

 

[James Kuyper]

Most RTOS were designed with their own process and threading models and
they were not designed to emulate UNIX.

They have adopted a POSIX layer for the reason it was originally
proposed in this sub-thread: portability.

How fully does they implement implement POSIX pthreads? Are their
implementations typically more, or less, complete than the Windows
implementation that has been discussed elsewhere in this thread?

 

[Ian Collins]

How fully does they implement implement POSIX pthreads? Are their
implementations typically more, or less, complete than the Windows
implementation that has been discussed elsewhere in this thread?

It's been a wee while since I went into the details, but the two I'm
familiar with are:

Green Hill Integtity:

http://www.ghs.com/news/20040802_posix.html

and VxWorks:

http://www.windriver.com/products/vxworks/
(certifications bottom left).

 

[Rui Maciel]

... which implements a subset of an old version of POSIX threads

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.

which
can only be used in programs running in the POSIX subsystem. Nothing to
do with using POSIX thread interfaces in "normal" Windows programs.

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


Rui Maciel