Programming Windows: COOL (Premium)

In February 1999, just months after Microsoft shipped a sophisticated new version of its Visual J++ Java development environment, rumors emerged that the firm was developing an in-house replacement for Sun’s programming language.

What Microsoft had accomplished with Java was impressive: The software giant’s Java Virtual Machine (JVM) handily outperformed Sun’s JVM as well as all other third-party JVMs, with JavaWorld noting that “Microsoft … still stands alone as the only fast and scalable Java virtual machine … Customers with the highest website traffic currently have no other viable choice for a JVM.”

But Sun had sued Microsoft, charging the company with “trademark infringement, false advertising, breach of contract, unfair competition, interference with prospective economic advantage, and inducing breach of contract.” Sun’s complaint, put more simply, was that Microsoft’s JVM did not conform to the Java 1.1 standard as required by the contract it had signed, and it did so specifically to harm the Java platform.

“Microsoft embarked on a deliberate course of conduct to fragment Java,” JavaSoft president Alan Baratz said when the suit was filed.

Between that suit and Microsoft’s disastrous showing at its U.S. antitrust hearings in 1998, it became obvious that Microsoft would need to abandon Java. The problem was that in trying to usurp Java, the software giant had in fact created something wonderful: Visual J++ 6.0 built on the clean, object-oriented design of Sun’s programming language and runtime environment and added an exhaustive new framework called the Windows Foundation Classes (WFC), allowing developers to easily create native Windows applications with Java.

This was important because the Windows application developer space in the late 1990s was fragmented into incompatible camps. Microsoft offered developers three main choices, each of which was fraught with compromise. There was the Windows API with its flat collection of C-based functions, which had expanded in recent years to include interface-based COM APIs too. There was Visual Basic, an approachable environment for beginners, enthusiasts, and app prototype makers. And there was Visual C++, a complicated environment for professional developers only; Visual C++ further complicated matters by offering two major frameworks of its own, the Microsoft Foundation Classes (MFC) for traditional application developers and the Active Template Library (ATL) for those focused on COM and Microsoft’s component-based platform.

And let’s not forget the web. In its Blitzkrieg-like embrace of the Internet in the late 1990s, Microsoft had also quickly created scripting languages, web frameworks like Active Server Pages (ASP), and backend component connectivity, management, and scheduling capabilities via its COM, Microsoft Transaction Server, and Microsoft Message Queuing services. And this was all on top of the client-side HTML and DHTML publishing capabilities it had added across a host of developer and productivity applications as well.

WFC was superior to all of the Windows-based options. It provided developers with the same simple Rapid Application Development (RAD) tools as did Visual Basic, but it also delivered a more sophisticated and object-oriented language with a truly well-designed and logical framework that put previous Microsoft frameworks, from the Windows API to MFC and ATL, to shame.

If Microsoft was going to replace Java, it would need to do so on both the client and the server, on both Windows and the web. And to do that, it needed more than a new, object-oriented and C-like programming language. It also needed a new common runtime engine, and new application frameworks for Windows, the web, and perhaps other platforms.

The language came first.

InfoWorld’s Dana Gardner reported on February 13, 1999 that Microsoft was “working on an alternate C++-like object development model tightly aligned with Windows 2000 and the forthcoming Component Object Model+ (COM+) environment.” The inference was that the work was precautionary, in case Microsoft lost the Sun lawsuit.

“Java is under serious constraint and uncertainty over how any vendor can innovate around it, whether it’s our tools or any other,” Visual Studio lead product manager Greg Leake told the publication. “We have to determine if that uncertainty is acceptable. It depends on the lawsuit. I can’t speculate further than that.”

Microsoft’s Java-like programming language was codenamed COOL, for C++ Object-Oriented Language. Leake said that it was “simpler” than C++ and would be “married to an easier model.”

Three days later, Mary Jo Foley wrote in Smart Reseller that the fate of COOL rode as much on internal politics as it did on Microsoft’s legal battles.

“Advocates within Microsoft’s Developer Tools Division are the ones pushing the entirely new language approach, say sources,” Foley wrote. “But other Microsoft developers and executives—primarily those who have been with the company for a number of years—are advocating staying the course and either betting on a COM+-enhanced version of Microsoft C++ and/or Microsoft Visual J++.”

External critics of this plan noted that abandoning Java at a time in which Sun’s environment was experiencing explosive growth was dangerous.

“Creating a pseudo-C++ or an alternatively easy object-oriented language would be a disaster,” Hurwitz analyst Dave Kelly told InfoWorld. “There is just too much support for Java for Microsoft to entice people away from it.”

“Microsoft has to think carefully about what it’s doing,” Giga Information Group analyst Phil Costa concurred. “It could alienate its enterprise customers, who our research indicates are very interested in Java.”

They were right to worry. But Microsoft was caught in a strange trap of its own making. In Java and WFC, It had seen the value of a clean OOP language and a properly-written framework. And it wanted to reverse some of the bad API and framework decisions it had made in the past, undo the inherent complexities of COM, and provide developers with something simple, clean, and consistent that would work across all of the platforms it was now supporting.

If it couldn’t have Java, Microsoft needed to create a new programming language—no, a new platform—of its own. And the results would be very cool indeed.