Shared Source CLI Essentials

Preface

Version 1.0 of the Microsoft Shared Source CLI (still affectionately referred to by many as “Rotor,” its code name) was released to the programming community at large in November of 2002. It is a portable implementation of the programming tools and libraries that make up the ECMA-335 CLI standard, distributed as source code.

The fascination that source code holds for programmers has long been known at Microsoft, yet it remains an unusual way for Redmond to distribute its software. In the case of Rotor, however, the choice was obvious: for experimentation, learning, and as a teaching vehicle, source code has no peer. There is no finer way to learn about any computer standard than to browse and tinker with an implementation directly.

This book is a companion to Rotor’s code. It illustrates the design principles used in the CLI standard, using Rotor’s own implementation of that standard. More broadly, this book is about virtual machines, and the illusions, trapdoors, invisible linkages, and hidden levers from which they are built. Complex software systems, and the ways in which they bridge the abstract world of the programmer with the physical world of a computational model frozen in silicon, are invariably a fascinating topic.

The Rotor Distribution

Over five years ago, I wrote a memo outlining how and why Microsoft should invest in building a companion runtime to its then current Component Object Model (COM). This idea was not new, either inside or outside of Microsoft; products were already shipping for this purpose in the form of C++ frameworks and integrated development tools, such as Delphi and Visual Basic. The popularity of these language-specific approaches made it clear that the technical community was ready to accept features in their everyday tools and APIs that had once served to distinguish programming languages from one another, such as direct support for thread-based concurrency, structured exception handling, garbage collection, and the runtime enforcement of typesafety.

The technologies that made up the list of features in the original proposal had been waiting in the wings (for decades, in some cases), and some were already available to programmers as Windows APIs. Augmenting these APIs with a library implementation that could be shared in place of a growing number of subtly incompatible and overlapping component runtimes made obvious sense. A small team was empaneled by David Vaskevitch to flesh out the details and to make an initial technical proposal, which was run through Microsoft’s somewhat harrowing consensus-building process. Having been deemed a Good Idea, the proposal became the initial strawman for the product now called the Microsoft .NET Framework.

Very early in the development of the .NET Framework, there was discussion of creating a source-code distribution of the technology for researchers, academics, and experimenters. This discussion was spurred by Microsoft’s desire to attract a critical mass of developers, toolmakers, and innovative software products to the new platform. Realizing that having a portable implementation of the CLI was important for both standardization purposes and for the research community, Paul Maritz sponsored the formation of a small team under Geoff Shilling to explore the idea and begin implementation plans. With help from many individuals, both inside Microsoft and out, Geoff’s small team developed and built the Shared Source CLI.

In the interim between memo and product, a wonderful thing happened. While the original goal had been to provide a core set of modern services for COM programmers, what emerged five years later was far more useful. The original runtime library, in the hands of Brian Harry, Mike Toutonghi, and a talented cast of thousands, had become a complete, general-purpose virtual execution model. Even better, this model had been carefully refined as it was shepherded through the ECMA specification and standardization process by Jim Miller. The CLI standard had been born.

The CLI, at its heart, is an approach to building software that enables code from many independent sources to coexist and interoperate safely. The intent of its design is not simply to sweep gnarly hardware and device-driver details under the rug in the form of a “universal virtual machine,” but rather to build a virtual computational model that can be brought up safely within existing host environments and can expose the native capabilities of these environments directly. The design implications that come along for the ride are profound, and they are explored at length within this book.

To use any or all of Rotor’s rich codebase for your own noncommercial purposes, read and abide by the simple, one page shared license that accompanies the code. The code can be found on the CD that accompanies this book, along with additional documentation and related materials. As with any collaborative effort, this CD is only a snapshot in time; go to Rotor’s homepage on MSDN (http://msdn.microsoft.com/net/sscli) or to http://www.sscli.net for details about current versions or other late-breaking information.

Rotor is now in your hands. It is no longer a Microsoft-only endeavor, but rather an ongoing collaboration with all of you who wish to enhance and extend the CLI standard. Because Rotor takes the form of source code, it is easy for interested individuals to offer suggestions, upgrade or patch the implementation, and offer support. This book will help you participate by furnishing context; I hope that you enjoy discovering the fine points of the CLI as much as we have enjoyed writing about them!

Redmond, Washington

November 24, 2002

—David Stutz