Microsoft abandons the C language

[BartC]

It's hard to be enthusiastic about boring old C though. Yeah, it may be
the simplest way to deliver a library of simple functions, but so what? ....
I think of C as a kind of least common denominator.

Using C would be the nearest thing to having a binary (ie. language-neutral)
interface. That's why it's important.

Why bother worrying about the lonely C standard when C++ is almost a
superset of it and you're using a C++ compiler anyway?

Suppose you're developing another language (Pascal for example, or just
ASM); making it talk with foreign functions and interfaces specified in C is
trivial, once you've figured out whether 'long' is 32 bits or 64. Dealing
with a C++ interface (and all that COM and DCOM stuff, whatever the hell
that's all about) isn't.

It's a bit like the difference between using TXT format to create a document
(a human-readable format that can be read and written universally), and
having to use DOCX instead (a format so complex, the specification needs
nearly 5000 pages of documentation -- probably in DOCX format itself!).

 

[Ansel]

If you were doing graphics twenty years or more ago, then this was
quite common!
(I think my first attempts with raster graphics were in
'79...).

I did some graphics programming about 20 years ago (2D charting of realtime
data), *but* I used the Quinn-Curtis Graphics Library with the "Microsoft
Optimizing Compiler", woo hoo!. (Ah yes, Programmer's Workbench, Codeview...
what a waste of time, LOL! Can't forget MS QuickC--lots of fun. I bet I
still have the manuals. I'm sure I have all the TurboC, TASM and Borland C++
stuff. But I digress.)

These days I would prefer to use OpenGL, a rare example of a
well-designed API, and available for many languages! Including C,
which allows bindings to be created for languages not officially
supported (like mine..).
However OpenGL was never popular with MS, and was only grudgingly
supported. Hopefully that will still be available, but probably stuck
at some ancient version.

I've peeked at it awhile ago, but don't remember if I liked it or not. I'll
look at it again for sure when doing any graphics work. Also, though, I've
heard that the latest DirectX APIs are damn nice. Have you looked at them?
Not that you'd want to use them and give up cross-platform capability, but
just to evaluate the API design.

 

[Ansel]

Using C would be the nearest thing to having a binary (ie.
language-neutral) interface. That's why it's important.

That's such a small part though. C can be used as a wrapper around C++ just
for that binary interface. Indeed, it is used like that a lot. DLLs, of
course. You snipped the rest of my post, but alluded to the merits of
"paltry C" being a boon to temper the zeal of programmers who go wild when
they have a bunch of features at their disposal. (But alas, a lot of C
programmers are Unix programmers and we all know what that means--functions
that are 3 pages long and have more branches than you can shake a stick at
and all the obscene things that can only be done "at the hardware level".
(And that's just the "Hello World!" program!)).

That was rhetorical. It was meant as a statement from someone who is already
using C++ but needs only the level of functionality that C provides. Again,
it's stable and old news--nothing to get excited about.

Suppose you're developing another language (Pascal for example, or
just ASM); making it talk with foreign functions and interfaces
specified in C is trivial, once you've figured out whether 'long' is
32 bits or 64. Dealing with a C++ interface (and all that COM and
DCOM stuff, whatever the hell that's all about) isn't.

The reason MS invented the COM stuff was because they *needed*
cross-language interaction--can't let B. Gates' pet VB die, you know. The
low-level interfacing you are talking about was decidedly at too low of a
level to meet the requirements at a more abstract level. Indeed, aren't all
the new languages these days loaded-up with "metadata" and "attributes" and
such so that the all-important "reflection" capabilities can be had? It
depends on what level of cross-language support you need. If all you need is
the capability to call a C function, fine. That's inter-library and
intra-program stuff. C doesn't have a thing to say about a higher level
cross-language capability. I don't think you want to limit yourself to just
that functionality though and thereby limit all the other possibilities. I
still create DLLs that use the C binary interface. They may be passing back
an interface pointer to a C++ object though! Which begs the question, "Is C
the interface, or the C++ object passed to the program the interface?".

It's a bit like the difference between using TXT format to create a
document (a human-readable format that can be read and written
universally), and having to use DOCX instead (a format so complex,
the specification needs nearly 5000 pages of documentation --
probably in DOCX format itself!).

Bad example, for *plain text* is one of those things that have been and are
still wrongly used. If you don't trust your computer software to make a text
document for you, maybe you should go back to pencil and paper.

 

[jacob navia]

Le 26/08/12 13:02, Ansel a écrit :

But alas, a lot of C
programmers are Unix programmers and we all know what that means--functions
that are 3 pages long and have more branches than you can shake a stick at
and all the obscene things that can only be done "at the hardware level"

Ahhh those Unix programmers. Bunch of morons isn't it?

"We all" know what that means.

Just go on trolling dude.

 

[Tim Prince]

Maybe there is no need to because very few develop with C on Windows? Those
who do use the C subset available through C++ and find it adequate? What
features of the C standard are missing and who wants to *use* them? It's
one thing to criticize that the standard is not implemented while there is
great need by developers for the features, but quite another to criticize
just "for standards sake", as if ISO decree were more important than actual
developer needs/desires. Statistics please. What C features are developers
targeting Windows clamouring for and which developers and how many
developers? C standard compliance just for compliance sake is wasted effort?

We have plenty of applications which don't need to be "ported" between
operating systems (or at least the non-portabilities can be localized),
when there are standard-compliant compilers available.
Perhaps you don't consider portable use of C99 features useful in OpenMP
(and in certain other threading models, such as Cilk) to be a suitable
standard C topic.
Fortunately, others on this forum are open to considering Windows as an
eligible platform to support C.

 

[Stephen Sprunk]

I do not see that as a feather in MS's hat. Windows would have been
better if it had come after C++ was invented. Much better.

Judging by the quality of MFC, I doubt it.

C, as a matter of fact, is much of the reason why Windows's
underpinnings are so convoluted. There is no denying that. They did
the best they could> with what they had at the time.

I deny that.

The Windows API is convoluted mostly because it was developed by
hundreds of different groups across three decades, and each group did
things its own way based on what they thought was best at the time,
rather that stick to a consistent model--and they never went back and
"fixed" the imperfect parts because that would have broken backwards
compatibility. If you look at each piece of the API in isolation, as
Microsoft's developers do, they make sense; it's only when you try to
use them _together_ that you realize it's such a mess.

And don't kid yourself; Microsoft knows that having an unchanging (if
imperfect) API is the key to their market success. The day they abandon
Win32 (which, itself, is just an adaptation of Win16) is the day they
hand the desktop market to their competitors.

Also, don't forget that Microsoft only has two profitable products,
Windows and Office, and both are written in C. Every other MS product
exists only to generate more demand for Windows and/or Office.

Microsoft _does_ promote other proprietary languages/environments, but
largely towards its corporate customers and potential competitors, who
they _want_ to see locked into Windows and Microsoft development tools.
Most important, by pushing a succession of new languages and SDKs, and
then deprecating each a few years later, they force potential
competitors to waste time constantly rewriting their code just to stay
in the same place, while Microsoft's own products move ahead.

Most of the "incompetence" people bash Microsoft for is actually very
shrewd marketing. Bad news for customers, good news for Microsoft's
shareholders.

S

 

[Malcolm McLean]

בת×ריך ×™×•× ×¨×שון, 26 ב×וגוסט 2012 07:35:28 UTC+1, מ×ת Ansel:

Keith Thompson wrote:


It's hard to be enthusiastic about boring old C though. Yeah, it may be the
simplest way to deliver a library of simple functions, but so what? Why
bother worrying about the lonely C standard when C++ is almost a supersetof
it and you're using a C++ compiler anyway?

The whole point is that the language is boring. Ultimately programs boil
down to arithmetical operations, reads and writes to and from memory, and
conditional jumps, most of which are loops. C applies a bit of structure,
which is the subroutine call, but no more.

So C is good for simple but processor-intensive functions, like
rasterisation routines, sorts, vector normalizers, hash tables, FFTs and
so on. But it's also good for core logic - the Canny edge detector in my
binary image processing library is written in C, for example. The fact it is
implemented in C gives it maximum performance, excepting only assembly, and
maximum portablity. The interface is very simple, even thought the function
itself is quite complicated.

Basiclaly you do the algorithmically interesting stuff in C, the boring
language. Then you use another language for stuff which is of no algorthmic
interest, but is necessary to glue the program together.

 

[Les Cargill]

Stephen Sprunk wrote:

Most of the "incompetence" people bash Microsoft for is actually very
shrewd marketing. Bad news for customers, good news for Microsoft's
shareholders.

At one point, there was footage of a manic Ballmer screaming
"Developers! Developers! Developers!". VB was (is?) the everyman's
development platform, biased towards domain expertise
and away from the specializations of computer science departments.

And still I use Windows, because there are apps for it
that no other platform quite has. I could hypothetically
switch to some Mac variant, but it would be quite difficult.

Given that the die was cast decades ago with Bill Gates letter,
it's really appropriate that they became a leader.

http://en.wikipedia.org/wiki/Open_Letter_to_Hobbyists

 

[Stephen Sprunk]

What are the applications programs, if any, that are critical to have
on Windows from a party other than from MS that would be significantly
detrimental to sales of Windows?

Games.

If MS dropped support for games, forcing all of those customers to
switch to Linux or Mac, that would be seriously detrimental to the sales
of Windows. In fact, one can look at the Xbox as an attempt to keep
Windows relevant to games developers: they can target two platforms for
only slightly more than the cost of one. After all, there must be a
reason they're willing to pour billions of dollars into that money pit
every year, right? They're not idiots.

Pretty much everything else is either company- or industry-specific,
which would not threaten Windows as a whole; competes with Office or
something included with Windows, which again does not really threaten
Windows as a whole; or is open source.

On my Win 7 + MS Office Pro desktop machine, I can't, off the top of
my head, think of any software on it that I actually paid for (and I
don't have any pirated software) and same for the Win XP setup I had
previously, so that's why I ask.

I've got some non-MS commercial software on my machine, either internal
apps my company wrote or stuff we bought to support specific business
functions. Most of the proprietary "applications" I use today are
web-based, and that's the real threat MS faces because it makes the
desktop OS completely irrelevant. Indeed, many of my coworkers use
Linux or Mac, something that was infeasible just ten years ago.

S

 

[Keith Thompson]

As far as I know, I have made this particular statement (that
Microsoft is planning to support "for (int i;, ...)" in C; jacob
snipped the relevant part) just once, or perhaps twice. I fail to
see how this is "too many times".

As for Microsoft not implementing the (now officially obsolete)
C99 standard 12+ years after its publication, that's absolutely
correct, and I've never stated or implied otherwise.

jacob apparently has decided that he knows what I think, and will
not change his mind in the face of direct evidence that he's wrong.
Which is why I don't respond to him directly in this newsgroup,
but I felt that this particular nonsense called for a correction.

[snip]

We have plenty of applications which don't need to be "ported" between
operating systems (or at least the non-portabilities can be localized),
when there are standard-compliant compilers available.
Perhaps you don't consider portable use of C99 features useful in OpenMP
(and in certain other threading models, such as Cilk) to be a suitable
standard C topic.
Fortunately, others on this forum are open to considering Windows as an
eligible platform to support C.

Exactly. Microsoft's lack of support for C99 and C11 makes it
more difficult (not impossible, just more difficult) to write
portable modern C that will run on a wide variety of systems.
(Yes, there are Windows C compilers other than Microsoft's; not
everyone is willing and/or able to use them.) Thus Microsoft's
decision not to support C past C90 have an impact on the entire C
programming community. Mentioning that does not constitute support
for Microsoft or opposition to C99 or C11.

 

[Adrian Ratnapala]

I do not see that as a feather in MS's hat. Windows would have been better
if it had come after C++ was invented. Much better. C, as a matter of fact,
is much of the reason why Windows's underpinnings are so convoluted. There
is no denying that. They did the best they could with what they had at the
time.

And yet unix APIs fail to suck nearly so hard as Windows ones. Objects or no.

But perhaps it's true the MS sucks harder when it tries to be C compatible.I've recently being using the windows crypto API (http://msdn.microsoft.com/en-us/library/windows/desktop/aa380252.aspx). I challenge you all to figure out how to read a private key from a file (it's possible I assure you)..

 

[ozbear]

Of course some things should (and do) last forever. It's arguably
easier, for example, to get a 6V6 tube than it's ever been.

<snip>
Nonsense.
Oz

 

[Jens Stuckelberger]

This is a long story.

C language: Good riddance, Microsoft.

 

[Ansel]

Exactly. Microsoft's lack of support for C99 and C11 makes it
more difficult (not impossible, just more difficult) to write
portable modern C that will run on a wide variety of systems.
(Yes, there are Windows C compilers other than Microsoft's; not
everyone is willing and/or able to use them.) Thus Microsoft's
decision not to support C past C90 have an impact on the entire C
programming community. Mentioning that does not constitute support
for Microsoft or opposition to C99 or C11.

That is a very weak stance. Maybe *you* know the statistics that I called
for in a prior post, but if you don't give them (a link is adequate), then
you little to squawk about. All I hear is "has to completely support the
standard". Where is the list of functionalities that is so sorely lacking,
along with a quantification and qualification of the need for them? Anything
less is just hot air.

 

[Ansel]

?????? ??? ?????, 26 ??????? 2012 07:35:28 UTC+1, ??? Ansel:
The whole point is that the language is boring. Ultimately programs
boil down to arithmetical operations, reads and writes to and from
memory, and conditional jumps, most of which are loops. C applies a
bit of structure, which is the subroutine call, but no more.

So C is good for simple but processor-intensive functions, like
rasterisation routines, sorts, vector normalizers, hash tables, FFTs
and
so on. But it's also good for core logic - the Canny edge detector in
my binary image processing library is written in C, for example. The
fact it is implemented in C gives it maximum performance, excepting
only assembly, and maximum portablity. The interface is very simple,
even thought the function itself is quite complicated.

Basiclaly you do the algorithmically interesting stuff in C, the
boring language. Then you use another language for stuff which is of
no algorthmic interest, but is necessary to glue the program together.

A little correct. Relegating all "real code" to C functions (skip the "you
can do OO in any language" bit, please) is obviously an extreme position to
be on (unless C is your mightily-constrained scope).

 

[Ansel]

And don't kid yourself; Microsoft knows that having an unchanging (if
imperfect) API is the key to their market success. The day they
abandon Win32 (which, itself, is just an adaptation of Win16) is the
day they hand the desktop market to their competitors.

While it may lead to investigation of other platforms and some may go, it
hardly means, as you said, that everyone would jump ship. Moving to a 100%
new way of developing and delivering software vs. a new way of coding
Windows, is extremely different. Like moving from a US state to another
country vs. moving to another US state.

This is, of course, as obvious as your post was sensationalistic.

Also, don't forget that Microsoft only has two profitable products,
Windows and Office,

Citation needed.

and both are written in C.

100% C? Citation needed.

Every other MS product
exists only to generate more demand for Windows and/or Office.

Citation needed.

Microsoft _does_ promote other proprietary languages/environments, but
largely towards its corporate customers and potential competitors, who
they _want_ to see locked into Windows and Microsoft development
tools. Most important, by pushing a succession of new languages and
SDKs, and then deprecating each a few years later, they force
potential competitors to waste time constantly rewriting their code
just to stay in the same place, while Microsoft's own products move
ahead.

While I don't know if that is their M.O., I do avoid focusing on
Windows-specific technologies because they are all "flash in the pan" and
it's a waste of time renting out my mind for things destined for
obsolescence. That said, those who do focus on them and move with them in a
never-ending procession, can get a job doing that buzzword tech stuff pretty
easily (I assume).

Most of the "incompetence" people bash Microsoft for is actually very
shrewd marketing. Bad news for customers, good news for Microsoft's
shareholders.

Microsoft is "a leader" because people *follow* them. I wonder if that
surprises "them" as much as it surprises me.

 

[Ansel]

Le 26/08/12 13:02, Ansel a écrit :


Ahhh those Unix programmers. Bunch of morons isn't it?

Humor: get yourself a sense of it. (This may help you:
http://www.metamucil.com/).

 

[Ansel]

We have plenty of applications which don't need to be "ported" between
operating systems (or at least the non-portabilities can be
localized), when there are standard-compliant compilers available.
Perhaps you don't consider portable use of C99 features useful in
OpenMP (and in certain other threading models, such as Cilk) to be a
suitable standard C topic.
Fortunately, others on this forum are open to considering Windows as
an eligible platform to support C.

ISO does not control industry. Three or so posts now by three or so
different people have presented nothing but fan-boyism. List the things that
are missing, qualify and quantify the need for them, stick it in MS's face.
By their analysis (I *assume* that they do that), they seem to have decided
they are not important. Just wailing "ISO standard, ISO standard! Hail to
the ISO standard!" lacks substance.

 

[Öö Tiib]

Citation needed.

Is it here Wikipedia or USENET? Sure, Microsoft also sells Tools
(like SQL servers and crap) besides Windows and Office. The MS
revenues split about 30%/30%/30% for Tools/Office/Windows and rest of
the business is below 10%. For citations just google for MS revenues
reports, it is public enterprise.

How lot of code in the things that MS sells is C, does not matter. Some
crucial parts certainly are written in C.

The claim that entertainment and public services are mostly to polarize
sheep around the core Tools/Office/Windows business is just elementary
logic applied. Where one should get citations about their business
strategy? All you see in the open are the tactic they run and that looks
like what Stephen Sprunk said.

 

[Ansel]

Is it here Wikipedia or USENET? Sure, Microsoft also sells Tools
(like SQL servers and crap) besides Windows and Office. The MS
revenues split about 30%/30%/30% for Tools/Office/Windows and rest of
the business is below 10%. For citations just google for MS revenues
reports, it is public enterprise.

Nope. I'm not going to do someone else's research for them. That is hardly a
common household fact, so if someone makes some statement like that, they
need to provide the source of the information. IOW, don't waste the reader's
time, and also don't expect anyone to "just believe" you.

How lot of code in the things that MS sells is C, does not matter.
Some crucial parts certainly are written in C.

That would be, then, a non-substantive claim that Stephen made about MS's
products being written in C (read, a waste of bandwidth to even type in the
first place). But you're not the one who said it, so we'll have to wait for
Stephen's reply.

The claim that entertainment and public services are mostly to
polarize sheep around the core Tools/Office/Windows business is just
elementary logic applied.

He didn't say that, and it's not. Let's wait for him to reply instead of you
doing the talking for him, OK?

Where one should get citations about their
business strategy? All you see in the open are the tactic they run
and that looks like what Stephen Sprunk said.

With all the hot air and sensationalism in this group, it's not worth even
saying vacuous statements like that to begin with (though it does fit right
in!). What Stephen wrote about "Every other MS product" is unsubstantiated
spew, and it's not even remotely plausible.