Take another look at our free press... it has an abysmal track record at correcting misinformation, because no one in the news industry wants to appear "biased" or act as a "filter", even if it's just filtering fact from bullshit.
The best we'd get is something like:
Some scientists and doctors have expressed skepticism that the pamphlets contain any biological agents. According to John Smith of the Mayo Institute, "We tested two of the samples and found no traces of any spores or bacteria. Paper is a poor breeding ground for Ebola anyway."
But officials are still urging caution. "Our enemies will stop at nothing," said Bill Jones, Director of Homeland Security. "One or two negative test results doesn't mean anything. If your hands rot off, that's a pretty strong positive, don't you think? The safest thing to do is just not to touch these pamphlets. Or read them. Or think about what they might say."
You can open MS Office apps with Open Office, so MS Office isn't anticompetetive. This certainly is.
No, it isn't. You can open Silverlight applications with Moonlight. It still has a lot of catching up to do, but you'll find the same is true of OpenOffice and Microsoft Office: OpenOffice supports a subset of MS Office's functionality, and you won't get exactly the same experience opening a document in OO as you would with MSO.
If Microsoft tries to prevent the Moonlight team from implementing Silverlight 3, then you'll have a case that it's anticompetitive. Maybe. But right now, the only reason Silverlight code isn't as usable on Linux as it could be is that the Moonlight team hasn't gotten it there yet.
But that doesn't follow from step 2. Microsoft releasing a new version of.NET does not directly lead to anyone being forced to stop using Mono or switch to Microsoft software.
After all, Microsoft is already up to.NET 3.5. People are still using Mono, and software written for.NET 2.0 still runs fine on Mono. Developers who target Mono simply ignore the features that Mono doesn't support.
So, how exactly is the "extend and extinguish" part of this scheme supposed to work? There's still a big question mark in the middle.
You were saying that before the "Community Promise". Funny, right?
It was true then, too.
And yes, the "community promise" doesn't make your statement true. The "Promise" only covers ECMA 334 and 335 (C# language and CLI), as you're well aware. [...] Indeed, Mono is officially being split in half. But you already knew that.
Indeed. So if you stick to the C# language and core framework, and avoid proprietary libraries (the ones being split off), there is no patent mess, like I said.
I can easily imagine MS Embracing, Extending, and Extinguishing Mono and.net on Linux.
Well, "embrace" is irrelevant since.NET came from Microsoft in the first place.
As for "extend and extinguish", doesn't that rely on the assumption that developers don't test their software on Linux? I don't see how that's supposed to work.
1. Linux developers write software using Mono. 2. Microsoft releases a new version of.NET for Windows containing features Mono doesn't support. 3. ??? 4. Linux developers are forced to switch to Microsoft software or stop using Mono.
I can run Eclipse on my Mac to program software in Java that will run on Linux, OS X, and Windows.
I can run Visual Studio on my Windows box to program software in C# that will run on Linux, OS X, and Windows.
GTK#: works on all three. Windows Forms: works on Windows (obviously), largely works on Linux, not sure about OS X. Silverlight: works on Windows and OS X, Linux is still catching up. CocoaSharp: works on OS X.
["I have to admit, however, that I admire Jo's sincerity when he makes this point: it's not the users who want it, it's the developers. It can't be denied that.NET was indeed instrumental in the development of Gnote"] But who cares about the users nowadays?
Er... since when is any project's choice of language driven by user demand?
Is the Linux kernel written in C because users demanded a kernel written in C, or because the developers thought it was a good choice for an OS kernel? Do you choose a web browser, music player, or note-taking tool based on the language it was written in?
I choose to develop in C# because it makes my job easier (although the Visual Studio IDE deserves credit for much of that). When my job is easier, my clients are happier because they get more reliable code and they get it sooner. They don't care whether I'm using C#, C++, Java, COBOL, or manually flipping bits on the hard drive with a tiny magnet and very steady hands. All they care about is how long it takes to turn their requests into a working program that runs on the systems they need it to run on.
From what I gathered they pretty work like type erasure in Java, ie. there's no genericity at all for reference types, it's the same code with implicit casts for all instantiations. (Value types are different naturally.)
Not quite. There are no "implicit casts" with.NET generics.
You're probably thinking of the fact that all instantiations of a generic method with different reference type parameters share the same native code. But when you call a generic method, the VM's static type checker knows the actual parameter/return types, so there's no need for any type casting at runtime: sharing the native code is just an optimization since the native code would be identical anyway.
The difference means that.NET generics can have better performance than Java generics, even when the type parameters are reference types, because no runtime casting is needed. The.NET VM can verify that the method call is type-safe because it has access to the type parameters that Java throws away.
Excuse me. Java pre-dates VB by a considerable amount.
Visual Basic 1.0 was released in 1991. Java was released in 1995. So, no.
Java does predate VB.NET, however. VB.NET is not compatible with VB versions 1-6 and changes some fundamental concepts (like the object model), though the syntax is mostly the same. Rather than "C# is VB with C syntax", it's more accurate to say "VB.NET is C# with VB6 syntax".
ECMAs standards mean nothing, when MS decides to take the standard in a new direction, it will go there.
What the hell does that even mean?
If you develop a program for.NET 2.0, it'll run on Mono today, and it'll still run on Mono next year. If Microsoft publishes a new specification for C# 5.0, your program won't suddenly stop working. No one will force you to adopt language features that haven't been standardized yet.
If you decide to adopt "C# 5.0" features before they're standardized, then you're voluntarily giving up cross-platform compatibility, and you have only yourself to blame. Just like if you decide to use vendor-specific extensions or platform-specific libraries for C/C++ or any other language.
It helps spread adoption of Microsoft's proprietary standards
Actually, this announcement is another nail in the coffin of the theory that C# or CLI are in any way "proprietary standards" (which, if you think about it, is a term that doesn't make much sense to begin with).
It sets anyone (Mono) reimplementing these standards up for the future rug-pull when they change and/or extend the standard in the future, which will be done according to the needs of Microsofts business model.
They can't "change" a standard that's already been submitted and published. That would be like changing the King James Version of the Bible: the KJV is a known quantity and anything different is not the KJV. Whatever they published in its place would be a new standard: the existing C# standard won't just disappear, and they can't stop anyone from using it.
As for extending it (publishing a new standard)... no one's forcing you to adopt the future changes at all, and certainly not at the expense of compatibility. If you want cross-platform compatibility, stick to the existing standard. This should be obvious. It's what developers in most other languages already do: if you want to write a cross-platform C application, you don't use features that are only supported by one compiler, and you don't use features proposed for the next version of C until they've been standardized and supported by multiple vendors.
Having to scrunch different languages in to a Java-tailored bytecode is annoying, but the gymnastics required by MSIL are worse.
Can you clarify this? I've written several programs that generate IL (including one full-blown compiler for a JavaScript-like language) and I don't recall having to do any gymnastics.
If it has platform specific libraries which many people use and are encouraged to use, then the end result is anything but cross platform... It's just another form of lock-in.
By that logic, C/C++ programmers are all the victims of "lock-in" too, and to a much greater extent than C# programmers. Care to rethink this argument?
To them, the entire selling point of C# is.Net, and.Net's entire selling point is that it's from Microsoft.
I'm sure some people do think this way, but in reality both C# and.NET have other selling points.
Other than programmers scratching their personal itch developing in C# on non-Windows, how likely do you think it is that an employer of any size will opt to use Mono or any other non-MS C# for putting product out the door or implementing in-house systems?
A company I'm currently contracting for is doing exactly that: putting a product out the door with fancy versions for Silverlight (Windows and OS X) and eventually Moonlight (Linux) along with console and simple GUI versions that run in Mono.
In all my encounters with others using C# and.Net, they are Microsoft all the way, down to the stereotype of being unaware that non-Microsoft solutions for anything IT (databases, programming languages, IDEs, etc) even exist.
Well, let me expand your horizons. I was recompiling Linux kernels at age 13. I've developed on Linux, OS X, and Windows, in C/C++, C#, Perl, Java, Delphi, VB, and more. I've administered both Windows and Linux servers, and there was a long time when Linux was my primary OS at home; I also own a Mac. I tried SQL Server but was quickly scared back to MySQL and SQLite. And as for IDEs, I've tried others, but so far I haven't seen anything that I believe stacks up to Visual Studio (don't say Eclipse), although of course on Unix I just use joe and make.
I started using C# because it was essentially a successor to Delphi (the language was designed by the same guy, Windows Forms is analogous to Delphi's VCL, and Delphi had just added a.NET compiler), and I wanted to keep my skills up to date with a language people would be using: I figured C# would gain momentum no matter what simply because Microsoft was pushing it, and that seems to be the case, but it's also been a joy to work with. I was also enticed by the prospect of writing once and running on any OS (having previously tried Kylix, the Linux version of Delphi), and although it took longer than I expected to get here, I'm fairly satisfied with the state of cross-platform.NET development.
This is a real issue because if I know anything about Microsoft, it is that they like to keep targets moving. This means dot-net will evolve so quickly that there will only be one complete implementation: Microsofts own one.
Er... developers choose which version they want to target. Not Microsoft.
No one's forcing you to target a newer version of the framework, and if you're writing a cross-platform app, you'd be wise not to migrate to newer versions until they're standardized and fully supported in Mono anyway.
I work on a commercial application that targets.NET 2.0, and I've felt no pressure to upgrade it: I believe that with VS 2008 you can even upgrade your IDE while still targeting the old framework, although I'm still using VS 2005 for this project.
(Oddly enough, I'm also working on a free application that targets.NET 3.5, and it works just fine under Mono.)
With C++, there is no vendor with this amount of power, and that's the way I like it.
You're mistaken about the "amount of power" Microsoft has here: the situations of C++ and C# are more analogous than you think.
If you write a C++ app that uses a proprietary library, you're subject to the vendor's terms. Likewise, if you write a C# app that uses proprietary libraries like ADO.NET, you're subject to Microsoft's terms. Solution: use an open source data/GUI/whatever layer instead.
If you're unable to resist shiny, nonstandard features that a certain vendor makes available (say, a C++ language extension), that vendor has power over you. Likewise, if you're unable to resist features of Microsoft's C# 4.0 before they're standardized and implemented by other vendors, Microsoft has power over you. Solution: stick to features that have been standardized and implemented by Mono.
Sometimes I miss the days of terminal emulators and 1200bps modems. Then I remember how long it took to download pr0n, and I don't anymore.
Don't forget that once you downloaded a picture, it'd take seconds, if not minutes, to decode the thing! Nowadays, decoding JPEGs is trivial... on a 286, not so much.
Don't knock your rudimentary instincts, they got our species to where it is today.
Rudimentary instincts got our species to where it was several thousand years ago: living in small tribes, hunting and gathering, dying at 30. The ability of our higher cognitive functions to override those instincts got our species to where it is today.
C# is a useless, extraneous, Microsoft-owned (don't kid yourself about the paper standards body) standard, intended only for addicting more people to Microsoft.
You keep making this claim. I keep asking for evidence, or even a solid idea of how C# possibly could lead to the situation you fear. And you keep trying to avoid admitting that you have neither.
A mailing list post. Right. And that is a patent license in your eyes?
It's exactly what it appears to be: a statement from a Microsoft employee that in the event any patents are necessary to implement the standard, they will be available royalty-free.
You're claiming that the statement is untrue. You have no evidence for that claim; all you have is FUD.
And don't forget, the existence of those patents is still essentially a myth. The boilerplate notice you cited doesn't mention any specific patents, or even indicate how many there might be.
Go pull the other one, it's got bells on.
OK, you have FUD and snarky remarks. Unfortunately, all the FUD and snark in the world still doesn't add up to one shred of evidence.
You've been dodging long enough. Please don't waste my time with another reply unless it cites positive evidence that (1) Microsoft actually has patents necessary for the implementation of C# or CLI, or (2) the statement from a Microsoft employee regarding royalty-free licensing of any such patents is untrue.
You're going to tell me that Microsoft developed C# out of the goodness of their hearts, because Java is so limited, and that it has nothing at all to do with Microsoft responding to Sun's insistence that Microsoft refrain from embracing and extending Java?
That's not at all what I said. It's going to be very hard to continue this discussion if you can't parse simple English statements.
What I said is: we know how Microsoft abused the standardization process with OOXML. They submitted a "standard" that's too poorly documented/defined for others to implement it completely, because it defines features in terms of the (undocumented) behavior of MS Office.
That did not happen with C#. The standards for C# and the CLI are complete enough that multiple independent groups have implemented them.
So, once again, I'm still waiting to hear what form you think this "abuse" could possibly take.
As for Microsoft's motivation in creating C#, I have no doubt that it had something to do with spiting Sun. They want to take market share away from Java. But in order for.NET to be a real competitor to Java, Microsoft needs it to be cross-platform. Their interests are aligned with yours here, unless you work for Sun.
Slashdot Mirror
Wouldn't work with a free press.
Take another look at our free press... it has an abysmal track record at correcting misinformation, because no one in the news industry wants to appear "biased" or act as a "filter", even if it's just filtering fact from bullshit.
The best we'd get is something like:
You can open MS Office apps with Open Office, so MS Office isn't anticompetetive. This certainly is.
No, it isn't. You can open Silverlight applications with Moonlight. It still has a lot of catching up to do, but you'll find the same is true of OpenOffice and Microsoft Office: OpenOffice supports a subset of MS Office's functionality, and you won't get exactly the same experience opening a document in OO as you would with MSO.
If Microsoft tries to prevent the Moonlight team from implementing Silverlight 3, then you'll have a case that it's anticompetitive. Maybe. But right now, the only reason Silverlight code isn't as usable on Linux as it could be is that the Moonlight team hasn't gotten it there yet.
A bust:waist:hip ratio of 3 to 2 to 3 (in humans, 36-24-36)
Heh. Maybe if she's 5'3".
But that doesn't follow from step 2. Microsoft releasing a new version of .NET does not directly lead to anyone being forced to stop using Mono or switch to Microsoft software.
After all, Microsoft is already up to .NET 3.5. People are still using Mono, and software written for .NET 2.0 still runs fine on Mono. Developers who target Mono simply ignore the features that Mono doesn't support.
So, how exactly is the "extend and extinguish" part of this scheme supposed to work? There's still a big question mark in the middle.
GTK# works only on mono.
Not true.
On other operating systems I'd use MonoDevelop, or Mono's CLI tools together with joe and make.
You were saying that before the "Community Promise". Funny, right?
It was true then, too.
And yes, the "community promise" doesn't make your statement true. The "Promise" only covers ECMA 334 and 335 (C# language and CLI), as you're well aware. [...] Indeed, Mono is officially being split in half. But you already knew that.
Indeed. So if you stick to the C# language and core framework, and avoid proprietary libraries (the ones being split off), there is no patent mess, like I said.
But you knew that, right?
I can easily imagine MS Embracing, Extending, and Extinguishing Mono and .net on Linux.
Well, "embrace" is irrelevant since .NET came from Microsoft in the first place.
As for "extend and extinguish", doesn't that rely on the assumption that developers don't test their software on Linux? I don't see how that's supposed to work.
1. Linux developers write software using Mono. .NET for Windows containing features Mono doesn't support.
2. Microsoft releases a new version of
3. ???
4. Linux developers are forced to switch to Microsoft software or stop using Mono.
Could you fill in step 3, please?
I can run Eclipse on my Mac to program software in Java that will run on Linux, OS X, and Windows.
I can run Visual Studio on my Windows box to program software in C# that will run on Linux, OS X, and Windows.
GTK#: works on all three.
Windows Forms: works on Windows (obviously), largely works on Linux, not sure about OS X.
Silverlight: works on Windows and OS X, Linux is still catching up.
CocoaSharp: works on OS X.
And now the Linux community is actually starting to willingly include a Microsoft patent mess right into the heart of distributions
False. There is no patent mess. But I guess even the legally binding "community promise" isn't enough evidence for the determined haters, eh?
["I have to admit, however, that I admire Jo's sincerity when he makes this point: it's not the users who want it, it's the developers. It can't be denied that .NET was indeed instrumental in the development of Gnote"]
But who cares about the users nowadays?
Er... since when is any project's choice of language driven by user demand?
Is the Linux kernel written in C because users demanded a kernel written in C, or because the developers thought it was a good choice for an OS kernel? Do you choose a web browser, music player, or note-taking tool based on the language it was written in?
I choose to develop in C# because it makes my job easier (although the Visual Studio IDE deserves credit for much of that). When my job is easier, my clients are happier because they get more reliable code and they get it sooner. They don't care whether I'm using C#, C++, Java, COBOL, or manually flipping bits on the hard drive with a tiny magnet and very steady hands. All they care about is how long it takes to turn their requests into a working program that runs on the systems they need it to run on.
From what I gathered they pretty work like type erasure in Java, ie. there's no genericity at all for reference types, it's the same code with implicit casts for all instantiations. (Value types are different naturally.)
Not quite. There are no "implicit casts" with .NET generics.
You're probably thinking of the fact that all instantiations of a generic method with different reference type parameters share the same native code. But when you call a generic method, the VM's static type checker knows the actual parameter/return types, so there's no need for any type casting at runtime: sharing the native code is just an optimization since the native code would be identical anyway.
The difference means that .NET generics can have better performance than Java generics, even when the type parameters are reference types, because no runtime casting is needed. The .NET VM can verify that the method call is type-safe because it has access to the type parameters that Java throws away.
Excuse me. Java pre-dates VB by a considerable amount.
Visual Basic 1.0 was released in 1991. Java was released in 1995. So, no.
Java does predate VB.NET, however. VB.NET is not compatible with VB versions 1-6 and changes some fundamental concepts (like the object model), though the syntax is mostly the same. Rather than "C# is VB with C syntax", it's more accurate to say "VB.NET is C# with VB6 syntax".
Isn't that what "Post Anonymously" is for?
ECMAs standards mean nothing, when MS decides to take the standard in a new direction, it will go there.
What the hell does that even mean?
If you develop a program for .NET 2.0, it'll run on Mono today, and it'll still run on Mono next year. If Microsoft publishes a new specification for C# 5.0, your program won't suddenly stop working. No one will force you to adopt language features that haven't been standardized yet.
If you decide to adopt "C# 5.0" features before they're standardized, then you're voluntarily giving up cross-platform compatibility, and you have only yourself to blame. Just like if you decide to use vendor-specific extensions or platform-specific libraries for C/C++ or any other language.
It helps spread adoption of Microsoft's proprietary standards
Actually, this announcement is another nail in the coffin of the theory that C# or CLI are in any way "proprietary standards" (which, if you think about it, is a term that doesn't make much sense to begin with).
It sets anyone (Mono) reimplementing these standards up for the future rug-pull when they change and/or extend the standard in the future, which will be done according to the needs of Microsofts business model.
They can't "change" a standard that's already been submitted and published. That would be like changing the King James Version of the Bible: the KJV is a known quantity and anything different is not the KJV. Whatever they published in its place would be a new standard: the existing C# standard won't just disappear, and they can't stop anyone from using it.
As for extending it (publishing a new standard)... no one's forcing you to adopt the future changes at all, and certainly not at the expense of compatibility. If you want cross-platform compatibility, stick to the existing standard. This should be obvious. It's what developers in most other languages already do: if you want to write a cross-platform C application, you don't use features that are only supported by one compiler, and you don't use features proposed for the next version of C until they've been standardized and supported by multiple vendors.
Having to scrunch different languages in to a Java-tailored bytecode is annoying, but the gymnastics required by MSIL are worse.
Can you clarify this? I've written several programs that generate IL (including one full-blown compiler for a JavaScript-like language) and I don't recall having to do any gymnastics.
If it has platform specific libraries which many people use and are encouraged to use, then the end result is anything but cross platform... It's just another form of lock-in.
By that logic, C/C++ programmers are all the victims of "lock-in" too, and to a much greater extent than C# programmers. Care to rethink this argument?
To them, the entire selling point of C# is .Net, and .Net's entire selling point is that it's from Microsoft.
I'm sure some people do think this way, but in reality both C# and .NET have other selling points.
Other than programmers scratching their personal itch developing in C# on non-Windows, how likely do you think it is that an employer of any size will opt to use Mono or any other non-MS C# for putting product out the door or implementing in-house systems?
A company I'm currently contracting for is doing exactly that: putting a product out the door with fancy versions for Silverlight (Windows and OS X) and eventually Moonlight (Linux) along with console and simple GUI versions that run in Mono.
In all my encounters with others using C# and .Net, they are Microsoft all the way, down to the stereotype of being unaware that non-Microsoft solutions for anything IT (databases, programming languages, IDEs, etc) even exist.
Well, let me expand your horizons. I was recompiling Linux kernels at age 13. I've developed on Linux, OS X, and Windows, in C/C++, C#, Perl, Java, Delphi, VB, and more. I've administered both Windows and Linux servers, and there was a long time when Linux was my primary OS at home; I also own a Mac. I tried SQL Server but was quickly scared back to MySQL and SQLite. And as for IDEs, I've tried others, but so far I haven't seen anything that I believe stacks up to Visual Studio (don't say Eclipse), although of course on Unix I just use joe and make.
I started using C# because it was essentially a successor to Delphi (the language was designed by the same guy, Windows Forms is analogous to Delphi's VCL, and Delphi had just added a .NET compiler), and I wanted to keep my skills up to date with a language people would be using: I figured C# would gain momentum no matter what simply because Microsoft was pushing it, and that seems to be the case, but it's also been a joy to work with. I was also enticed by the prospect of writing once and running on any OS (having previously tried Kylix, the Linux version of Delphi), and although it took longer than I expected to get here, I'm fairly satisfied with the state of cross-platform .NET development.
This is a real issue because if I know anything about Microsoft, it is that they like to keep targets moving. This means dot-net will evolve so quickly that there will only be one complete implementation: Microsofts own one.
Er... developers choose which version they want to target. Not Microsoft.
No one's forcing you to target a newer version of the framework, and if you're writing a cross-platform app, you'd be wise not to migrate to newer versions until they're standardized and fully supported in Mono anyway.
I work on a commercial application that targets .NET 2.0, and I've felt no pressure to upgrade it: I believe that with VS 2008 you can even upgrade your IDE while still targeting the old framework, although I'm still using VS 2005 for this project.
(Oddly enough, I'm also working on a free application that targets .NET 3.5, and it works just fine under Mono.)
With C++, there is no vendor with this amount of power, and that's the way I like it.
You're mistaken about the "amount of power" Microsoft has here: the situations of C++ and C# are more analogous than you think.
If you write a C++ app that uses a proprietary library, you're subject to the vendor's terms. Likewise, if you write a C# app that uses proprietary libraries like ADO.NET, you're subject to Microsoft's terms. Solution: use an open source data/GUI/whatever layer instead.
If you're unable to resist shiny, nonstandard features that a certain vendor makes available (say, a C++ language extension), that vendor has power over you. Likewise, if you're unable to resist features of Microsoft's C# 4.0 before they're standardized and implemented by other vendors, Microsoft has power over you. Solution: stick to features that have been standardized and implemented by Mono.
70564,2740 here.
Sometimes I miss the days of terminal emulators and 1200bps modems. Then I remember how long it took to download pr0n, and I don't anymore.
Don't forget that once you downloaded a picture, it'd take seconds, if not minutes, to decode the thing! Nowadays, decoding JPEGs is trivial... on a 286, not so much.
Don't knock your rudimentary instincts, they got our species to where it is today.
Rudimentary instincts got our species to where it was several thousand years ago: living in small tribes, hunting and gathering, dying at 30. The ability of our higher cognitive functions to override those instincts got our species to where it is today.
C# is a useless, extraneous, Microsoft-owned (don't kid yourself about the paper standards body) standard, intended only for addicting more people to Microsoft.
You keep making this claim. I keep asking for evidence, or even a solid idea of how C# possibly could lead to the situation you fear. And you keep trying to avoid admitting that you have neither.
Good day, sir.
A mailing list post. Right. And that is a patent license in your eyes?
It's exactly what it appears to be: a statement from a Microsoft employee that in the event any patents are necessary to implement the standard, they will be available royalty-free.
You're claiming that the statement is untrue. You have no evidence for that claim; all you have is FUD.
And don't forget, the existence of those patents is still essentially a myth. The boilerplate notice you cited doesn't mention any specific patents, or even indicate how many there might be.
Go pull the other one, it's got bells on.
OK, you have FUD and snarky remarks. Unfortunately, all the FUD and snark in the world still doesn't add up to one shred of evidence.
You've been dodging long enough. Please don't waste my time with another reply unless it cites positive evidence that (1) Microsoft actually has patents necessary for the implementation of C# or CLI, or (2) the statement from a Microsoft employee regarding royalty-free licensing of any such patents is untrue.
You're going to tell me that Microsoft developed C# out of the goodness of their hearts, because Java is so limited, and that it has nothing at all to do with Microsoft responding to Sun's insistence that Microsoft refrain from embracing and extending Java?
That's not at all what I said. It's going to be very hard to continue this discussion if you can't parse simple English statements.
What I said is: we know how Microsoft abused the standardization process with OOXML. They submitted a "standard" that's too poorly documented/defined for others to implement it completely, because it defines features in terms of the (undocumented) behavior of MS Office.
That did not happen with C#. The standards for C# and the CLI are complete enough that multiple independent groups have implemented them.
So, once again, I'm still waiting to hear what form you think this "abuse" could possibly take.
As for Microsoft's motivation in creating C#, I have no doubt that it had something to do with spiting Sun. They want to take market share away from Java. But in order for .NET to be a real competitor to Java, Microsoft needs it to be cross-platform. Their interests are aligned with yours here, unless you work for Sun.