Crossing the chasm

Abstract

For years to come, Windows developers will be straddling the boundary between managed code, which runs in the .Net Common Language Runtime, and unmanaged 32-bit Windows and COM codes, which do not. There are two primary bridges across the managed/unmanaged chasm. COM Interop enables the use of legacy COM software from .Net languages. Platform Invoke (P/Invoke) likewise enables the use of legacy Win32 code from .Net languages. Developers should expect years of mixed-mode operation.

For years to come, Windows developers will be straddling the boundary between managed code, which runs in the .Net Common Language Runtime, and unmanaged 32-bit Windows and COM codes, which do not. Even if all VB (Visual Basic) and C++ applications were magically converted to VB Net and Managed Extensions for C++, there would still be thousands of unmanaged libraries and components with which to contend. A recent search of Component-- Source.com, for example, turned up 670 ActiveX components versus only 84 .Net components -few of which are among the most popular items.

For the component vendors, it's not just translation from C++ to C# that's holding up the show. The new generation of.Net components must be redone to exploit features of the .Net Framework, such as WinForms and ADO.Net. Meanwhile, developers will continue to reach for legacy components and libraries that plug holes in the still-evolving framework.

Microsoft foresaw a lengthy transition to Net and worked hard to make mixed-mode programming easy. There are two primary bridges across the managed/unmanaged chasm. COM Interop enables the use of legacy COM software from .Net languages (VB Net, C#), and vice versa. P/Invoke (Platform Invoke) likewise enables the use of legacy Win32 code from Net languages.

What this means for developers is that things aren't getting simpler anytime soon. All of the old COM and Win32 skills are still needed, and there are new .Net skills to master. Moreover, special complications arise from the union of the two technologies.

For tool vendors, these complications create opportunity. One vendor stepping up to the plate is Compuware, whose DevPartner Studio suite of debugging and analysis tools - formerly the NuMega product line - will, in a forthcoming version, equip developers for the long transition. One key feature is a monitor that watches calls crossing the managed/unmanaged border. These are computationally expensive. Microsoft, acknowledging that, recommends that developers choose "chunky" architectures over "chatty" ones. But Visual Studio .Net offers no further assistance. The Compuware monitor, which counts the boundary crossings and lists called functions, "enables you to make important architectural decisions," according to Peter Varhol, product manager of DevPartner products at Compuware in Nashua, N.H. "Does it make sense to chunk this? Or should I spend effort to wrap it in managed code or rewrite it as managed code?"

Although Net itself has a modern, robust, exception-handling architecture, all bets are off should an unhandled exception in a COM component find its way into managed code. Compuware's new analyzer will catch these exceptions at the boundary and pop up an alert window.

Similarly, although .Net itself will use COM components in an orderly way, those components may invoke others and then fail to release them properly. The analyzer will reveal this elusive flaw as well.

Nobody disputes the virtues of managed code, but the center of gravity of a large installed base moves slowly. Developers should expect years of mixed-mode operation and plan accordingly.