Road to managed code

ON JUNE 6, Microsoft posted security bulletin MS02-026, titled “Unchecked Buffer in ASP .Net Worker Process.” Tongues immediately began to wag. Wasn’t .Net supposed to prevent this sort of thing? It’s true that managed code avoids the buffer overflows that trigger so many security snafus. But the ASP .Net engine, a .Net component, is not itself written wholly in managed code, and the security flaw was in an unmanaged function. Work was “currently under way,” the bulletin said, “to migrate all functions over to the .Net Framework.”

That migration is an epic journey that makes the trip from 16-bit to 32-bit code look like a weekend jaunt. Each of the server products will travel at its own pace. The forthcoming Yukon version of SQL Server, for example, will not be written on the .Net Framework, according to John Montgomery, group product manager for the .Net development platform. “There is too much code running too near the kernel for that,” he says. “But Yukon will expose its entire programming model as managed code.”

When teams write new code, the assumption is that they will do so in a managed space “unless there’s a compelling reason not to,” Montgomery says. Here, by the way, managed C++ will play a special role. For example, a C# version of DirectX achieved only 60 percent of native performance, according to Montgomery, whereas a managed C++ version nearly equalled it. All .Net languages are created equal, but some are more equal than others.

This eclecticism should surprise no one. Even if .Net technology could be fully deployed across the server family tomorrow, it would not be a security panacea. The security bible read at Microsoft nowadays, Michael Howard’s and David LeBlanc’s Writing Secure Code, acknowledges the complexity of the problem and prescribes a holistic approach that encompasses legacy, new, and mixed environments.”

What .Net will do for the server family, sooner rather than later, is present a consistent set of interfaces to programmers. These interfaces will live in managed space as part of the .Net Framework and will enable any .Net language to control the servers.

Perhaps the most dramatic illustration of this idea is Yukon’s stored procedures. Written in .Net languages such as C#, they will be able to converse intimately with the rest of the .Net Framework. The planned ability to write BizTalk’s XLANG schedules in C# is another example of the same idea. Broadly speaking, the server products will become a set of components that can be scripted using .Net languages. This arrangement will enable developers to extend individual servers more productively, and it will be a huge win when — as is typical — they yoke different servers together in complex solutions.

One fly in the ointment is the slow progress made to date in adapting the CLR (Common Language Runtime) to the needs of dynamic scripting languages such as Perl and Python. In the open-source world, these languages own the niche that Microsoft is carving out for .Net languages in its server product line. Ideally, the flexibility of dynamic scripting would enable Microsoft developers to be maximally productive using the new .Net interfaces. Early efforts to support such languages on the CLR stalled. Let’s hope a future version of the CLR will revive them.

Is the “.Net everywhere” campaign a Microsoft lock-in? Not necessarily. Covalent has announced ASP .Net support for Apache on Windows. OpenLink Software will soon demonstrate a version of its Virtuoso database/app server/Web services engine that will also host ASP .Net pages and, like Yukon, will support stored procedures written in .Net languages. OpenLink CEO Kingsley Idehen says that Mono, an open-source implementation of the .Net CLR and Framework, will enable the Linux version of Virtuoso to offer the same features.

When and how Microsoft will assert control over alternative .Net implementations is the subject of much debate and speculation. But Web services support alone does not trump Java in the standards game. Microsoft needs to have the premiere .Net interfaces but not the only ones.

Although managed interfaces to the servers are Microsoft’s major focus in the next round, the components that make up those servers will increasingly be built with .Net technology. In this realm, where Java is today the de facto standard, .Net looks like a better Java, offering the same benefits (managed memory, robust exception handling) with closer-to-the-metal performance, deeper Web services hooks, and superior componentization. Whereas .Net servers operate at a high level and in loosely coupled ways, they can rely on Moore’s law for performance (as do Java servers), and can scale by clustering.

Mixing managed and unmanaged code is easier said than done, though. Despite excellent COM support in .Net, for example, there remains an impedance mismatch between the two styles. “COM is about managing object lifetimes very explicitly,” says Jack Ozzie, Groove’s vice president of development. “And when you mix that with the .Net world of garbage collection and nondeterministic lifetimes, you start getting sparks.”

The devil is always in the details, many of which the next generation of Microsoft servers will sweep under the carpet of the .Net Framework. It’s a pragmatic strategy that will deliver much-needed API consolidation while buying time for the migration to managed code.