When is C++ not C++? When it's from Microsoft.
The C++ language is defined by the an international committee of technical experts (ISO WG21), composed of representatives from academia, industry, compiler vendors and enterprise.
With the introduction of .NET, Microsoft introduced their own flavour of C++, which they called Managed C++ or C++/CLI, which was derived from the C++ standard and altered to suit the specifics of the .NET environment. (The name "C++/CLI" refers to the Common Language Interpreter, a component of .NET - common at least within the MS "ecosystem").
MS managed to get ECMA, essentially an industry consortium, to bless it as an ECMA standard (ECMA-372). This is much easier to do at ECMA than with most standard bodies such as ANSI or ISO, because of the less stringent requirements and lack of external review and consultation. Since it was not developed in an open, participatory environment but rather within the halls of Redmond, it only bears their needs in mind. Which is, of course, completely their prerogative to do.
But now, on the basis of this ECMA standard, Microsoft are trying to fast-track C++/CLI to become an ISO standard. But we already have an ISO C++ standard (ISO/IEC 14882:2003) - which is cross-platform and not tied to a particular proprietary architecture encumbered by a great number of patents. Even worse, the C++/CLI language specification differs in some significant ways from the ISO C++ standard.
We have had the C++ standard for many years, it is widely implemented in a great variety of compilers, on a great variety of platforms. It is possible to write highly portable C++ code, and support many platforms and environments. This is all possible because of the nature of an open standard. Not so with C++/CLI, which will lock you in to the Microsoft Windows platform.
Many groups are understandably concerned that this move will create a great deal of confusion. A group in the UK have published a list of bjections to the fast-track application, which will hopefully be duly considered by the committee. The objecting group are asking that Microsoft change the name of the language from C++/CLI to avoid confusion from the real ISO C++ standard.
The changes Microsoft have made include adding new keywords, creating context-dependent identifiers and changing semantics of some operations. Also they have made significant changes and additions to the runtime.
Even Microsoft's own documentation creates confusion, by not clearly indicating which keywords or constructs are specific to C++/CLI. This can easily mislead programmers into using these Microsoft-only extensions, thus producing non-portable code and creating a dependence on features only provided by one vendor - Microsoft. (This is of course not the first time this sort of thing has happened, but we won't be distracted just now).
So - the right thing to do is clearly to 1) eliminate the confusion by giving the new proposed language standard a distinct name, and 2) to make it clear in the documentation which features are standard C++ and which are not.
It's deja vu all over again
This may seem all too familiar to those who remember the VisualJ saga. In the early days of Java's ascendence and meteoric rise to fame, Microsoft decided to join the Java revolution and licensed Java from Sun Microsystems (the creator of Java). One of the conditions of the license was that the licensee would maintain API/ABI compatibility of the core language according to the published specification, and not add any extensions to the core. Another condition was that the implementation pass the Java Compatibility Kit (JCK), a suite of compatibility tests designed to ensure the implementation conformed to the specification. In this way, all implementations would remain compatible and Java applications would be portable from one platform to the next.
It started out well, and Microsoft had one of the fastest VMs available. They strategically leveraged their VisualStudio line to produce the VisualJ product (their Java development environment). But after a while, Microsoft started to enhance its JVM (Java Virtual Machine, the runtime platform) beyond the standard. They added Windows-specific features to the Java core, and broke compatibility with the JCK. They claimed it was "innovation" and that it "added value" to the Windows platform. Unfortunately, the changes they made were non-standard, proprietary, incompatible and Windows-specific. Worse, the documentation provided did not always make it clear that certain features were specific to their implementation, and thus not portable.
The result? The Java ideal of "write once, run anywhere" was undermined, as developers using VisualJ were lulled into the trap of writing applications that relied on Windows-specific or MS-specific features. This didn't seem to be much of an issue to Microsoft, of course. But to any vendor attempting to produce cross-platform Java applications (which threatened the Windows hegemony), this created even more roadblocks and difficulties.
This fiasco resulted in Sun suing Microsoft for violation of contract when it couldn't be settled amicably. The case dragged on in the court for so long that by the time a settlement - worth millions of dollars - was finally reached years later, the industry had moved on. Microsoft was sanctioned by the court and forced to remove versions of VisualJ from sale that violated the agreement. But they essentially got away with it, and had another trick up their sleeve.
The Switch
As a result of the VisualJ product being pulled, Microsoft decided to hedge their bets. While the court case was still brewing, and long before it was resolved, MS started a project dubbed "Cool", which was supposed to be their answer to Java, a cleanroom reimplementation that would not have to conform to anyone else's standards or compatability checks. To do it, Microsoft poached key Borland employees to create a "Java killer". Much later, after the dust settled, Microsoft announced C#, which they insisted had nothing to do with Project Cool or Java. Or so they would have us believe.
And thus the ubiquitous .NET was born, out of the ashes of Microsoft's attempts to subvert Java and its promise of platform independence. When the original strategy failed with VisualJ, they simply created a clone of Java, made all the Windows-specific extensions they wanted, and labelled it C#. The JVM was rejigged and extended to support more languages (which is actually a good thing, something I wish Sun would put more effort into). But all the careful security design of the Java Virtual Machine was undermined with the managed code that allowed pointers back in (one of the most common programming mistakes that can create vulnerabilities). And it was further destabilised by the bridging to COM, which is also unrestricted code. Sun's Java sandbox had become Microsoft's playpen, and ActiveX - the source of so many security problems - was a first-class member.
And now CIOs all over the world are being weaned off Visual C++ and onto .NET, which is pitted against Java as a very enterprisey platform. Now the Java environment and .NET have more in common than areas of difference. Except for one key factor: Java won't lock you in to Windows. So why is it that CIOs seem to be lapping it up?
Well this article is already too long, so if you made it this far: well done. I was hoping to illustrate the patterns of behaviour, but I lacked the time to make it shorter.
(Via GrokLaw and Andy Updegrove.)
