A language divided

Through the years, Microsoft Corp. has constantly upgraded the features of VB (Visual Basic) to keep them in sync with Windows' capabilities. Yet even as VB took on new features, Windows business software got easier to write with each new release of the IDE (integrated development environment). With VB .Net, Microsoft took the risky leap of tightening up the language to make it compatible with the .Net Common Language Runtime. Ironically, by making VB .Net a more respectable language in terms of its structure and its object-oriented features, Microsoft has alienated some of its most loyal developers.

Microsoft has pushed hard to get developers to move to .Net in time for its grand debut in the .Net Server OSes later this year. For example, the latest quarterly refreshing of MSDN (Microsoft Developers Network) Library -- the collection of online documentation for Windows programmers -- can no longer be viewed or searched using Visual Studio 6. Purveyors of VB-oriented Web forums, training classes, books, and conferences got the message and are uniformly obsessed with .Net. Anyone learning VB now is under enormous pressure to learn VB .Net.

Historically, the core programming skills that are prerequisite for languages such as C and Java have been unnecessary for VB beginners. VB's no-frills syntax allows you to express business processes and logic without having the language get in the way. Vast, murky facilities such as COM+ and the 32-bit Windows API are encapsulated by the language and in components you just drop into your project. You don't need to understand how message queues or pull-down menus work to be able to use them in VB.

Some developers are excited about Microsoft's changes to VB .Net. Object-oriented developers see VB .Net as a long-overdue renovation of an infamously sloppy language.

VB .Net's predecessor, VB 6 is a compiled language that started out as an interpreter, so it forgives certain indiscretions that other compilers forbid. Developers are allowed to use a variable without first declaring its data type. VB's implicit type conversion silently coerces mismatched variables to the same data type so that an operation -- adding a string to a number, for example -- won't cause an error.

The common action taken when an error does occur in VB is to ignore the error and keep running. VB's technical sins are many and well-known, but they have survived because imposing stricter rules on programmers would make the language less accessible and arguably less productive. VB .Net is a cleaner, more buttoned-down language that passes the language snobs' sniff test. But it doesn't make everybody happy.

Justifiable inertia

There is a large contingency of VB coders who picked up the language purely to get work done -- or to get work -- and not because they're turned on by writing software. This is a special class of corporate developer. These developers are not casual because they're doing real work, yet they're not full-fledged geeks because they don't hack code for fun. They pick up the minimum technical skills required for each project. To move to VB .Net, they'll have to go back and learn data structures, object-oriented design, and other deep concepts that they don't yet grasp because that knowledge was not required by VB. Developers in this category will want to stick with VB 6 because VB .Net sets the bar higher than they're interested in jumping.

Another group that won't hurry toward VB .Net is the hard-core crowd. They hang out on forums, attend every conference, enjoy writing smart software, and swap snippets of code with one another. When they look at VB .Net, they see a comparatively restrictive language and a development environment that can't handle things they've been doing for years. You can't easily draw lines and shapes on forms, and form design in general is limited compared to what VB 6 has provided.

In VB .Net, you can't use DHTML or WebClasses, appealing Web-oriented features recently added to VB. You can't define an OLE container or attach property pages to customized objects. The Visual Studio .Net debugger won't allow you to edit your application while it's running, which you can do with VB 6. Hard-core developers complain of the slowness of the Visual Studio .Net IDE and of the performance hit their VB 6 applications take when they use the Migration Wizard to translate them to VB .Net.

Rays of hope

The .Net editions of Visual C++ and JScript allow developers to mix the old with the new. Developers can still generate unmanaged (non-.Net) executables with Visual C++; the JScript .Net compiler will relax its new .Net rules so that developers can run existing JScript programs with little modification.

Nevertheless, moving to VB .Net is a jarring experience. Suddenly, constructs that a developer has always taken for granted are illegal or are unsupported; familiar tasks once built into the language must be tackled in strange, Javalike ways. Programs that VB developers used to write off the top of their heads now require extra time for design and lots of spelunking in the .Net Framework documentation.

To its credit, Microsoft understands VB developers' frustration. An enterprise programming contest timed to coincide with its recent Fusion reseller conference was loaded with entries written in VB 6. Microsoft staff responses in the company's managed newsgroups have softened from "You can't do that in VB .Net -- and why would you want to?" to "I'll pass your concerns along to our developers." VB developers expect that several of the features and foibles removed from the first version of VB .Net will be restored in a later release. Until then, companies that rely on VB will have to keep using VB 6.

Crossing the chasm

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 ComponentSource.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.

-- Jon Udell

Join the newsletter!

Error: Please check your email address.

More about ComponentSourceCompuwareInteropMicrosoft

Show Comments

Market Place