VBScripting Solutions: A Look at .NET and Its Impact on Scripting

You probably know by now that Microsoft has announced the revolutionary platform called Microsoft .NET. You might not know, however, what .NET is and how it fits in with VBScript, JScript, and Microsoft Visual Basic (VB).

What Is .NET?
Essentially, .NET builds on existing COM-based technologies. You wouldn't be too far from the truth thinking of .NET as COM+ taken to the next level. In COM+, a central design element makes system-provided services available for all registered components. To make those services available, COM+ hosts components in a monitored, controlled, administered container. In other words, COM+ components run in an environment that supports managed capabilities, and .NET goes a step further by making that environment a managed environment.

Managed is a key word in understanding .NET basics. With .NET, you have just one development environment: Visual Studio.NET. This environment assumes that all compliant code runs under the control of its language-independent Virtual Machine (VM) called the Common Language Runtime (CLR). Objects or other software that the code might call within this runtime environment are no longer standalone objects as they were with COM+. In .NET, these objects are part of the managed environment.

The biggest change between .NET and COM+ is the number and quality of the services natively available to components and applications. In COM+, you have services such as eventing, queuing, and pooling natively available. Microsoft merged these COM+ services into the .NET Framework of objects, then added more complex, intrusive services, such as garbage collection, security, and integrated code debugging, profiling, and versioning.

The CLR instantiates components and applications and ensures that they accomplish their tasks under improved conditions by managing them and setting boundaries for their behavior. For example, the CLR sets the boundary that a .NET application can't use raw pointers or interact with preexisting COM and COM+ components. (In CLR 1.0, the .NET programming interface lets you overcome such boundaries. However, Microsoft supports this practice for backward compatibility only because it can result in poor performance.)

Introducing MSIL
In the Windows platform, Microsoft touts as a key feature the ability to use different languages, software development kits (SDKs), and even programming models to create components and applications. In the .NET platform, Microsoft takes the opposite approach: It promotes the use of the same intermediate language—Microsoft intermediate language (MSIL)—as a key feature. This new approach doesn't mean that you must learn MSIL, however. You can use any .NET-compliant language to write components and applications. A .NET-compliant language is a language for which a .NET compiler exists. A .NET compiler is a compiler that transforms your language-specific source code into MSIL. At this time, Microsoft's Visual Studio.NET offers the .NET languages of C#, Visual Basic.NET, JScript.NET, and Managed C++. C# is a new language that's similar to Java in terms of syntax and semantics. JScript.NET and Managed C++ are adaptations of JScript and C++, respectively. Visual Basic.NET is an adaptation of VB and VBScript. In the near future, third-party vendors will likely offer .NET versions of other languages.

After you write a component or application in a .NET-compliant language, you run it through the .NET compiler to produce MSIL code. After the .NET compiler transforms the language-specific source code into MSIL code, the resulting component or application loses all its language-specific characteristics. So, once compiled, a Visual Basic.NET component is indistinguishable from a C# component. This language transparency will make .NET attractive to administrators and developers.

Another feature that will attract administrators and developers is the CLR's true object orientation. In OOP, classes are key. You can think of OOP classes as blueprints for objects because the classes contain data about how the objects appear and act. All OOP classes share three characteristics:

The CLR lets you not only manage objects but also derive new objects from existing objects (implementation inheritance) and adapt the objects' inherited properties and methods (polymorphism). Thanks to the CLR's language transparency, every .NET language in the .NET platform automatically inherits the ability to support implementation inheritance and polymorphism. Implementation inheritance and polymorphism aren't new to C++, so the inclusion of these features in Managed C++ isn't that significant. Nor is their inclusion in C# that significant because you expect this language to take full advantage of the CLR considering that Microsoft created this language just for .NET. However, the inclusion of implementation inheritance and polymorphism in JScript.NET and Visual Basic.NET is a great leap forward for JScript, VBScript, and VB.

JScript and JScript.NET
If you look under JScript.NET's hood, you'll find that Microsoft has completely rewritten JScript's architecture to accommodate JScript.NET's principles. However, from the JScript users' standpoint, JScript.NET looks mainly unchanged, except for a few new keywords. Because JScript.NET is a compiled rather than an interpreted language, it's stronger than JScript in terms of syntax and performance.

Visual Basic.NET, VBScript, and VB
Visual Basic.NET is more like the .NET version of VBScript rather than VB, so upgrading to Visual Basic.NET will be much easier for VBScript users than for VB developers. If you look at Visual Basic.NET closely, you can see that the gap between VB 6.0 and Visual Basic.NET is larger than the gap between VBScript 5.0 and Visual Basic.NET.

Microsoft designed VBScript to be a stripped-down version of VB that uses a dynamic interpreter instead of a compiler. Thus, many of the features that Microsoft built into VB aren't in VBScript. For example, unlike VB, VBScript doesn't support type-manipulation functions, events, pointers, and API calls. For a long time, support for classes was a missing feature in VBScript. Then, in version 5.0, Microsoft included this support. However, VBScript's classes differ significantly from VB's classes—and neither VBScript classes nor VB classes are true OOP classes.

As I mentioned previously, an OOP class supports encapsulation, implementation inheritance, and polymorphism. As Table 1 shows, of these three features, VBScript and VB classes natively support only encapsulation.

A VBScript class is a language construct that you import or define in a script or application. Specifically, you use the Class statement to create classes. An abstract subtype encapsulates the class's implementation details. So, although VBScript supports encapsulation, its minimal class construct and lack of other OOP features put VBScript light-years away from being an object-oriented language. (For information about VBScript classes, see "Creating Classes with VBScript 5.0," December 1999, and "Importing and Porting Classes in VBScript 5.0," January 2000.)

A VB class is an external component that requires a distinct project, ad hoc settings, and a special naming convention. As such, a VB class is merely an instance of a COM automation object. By design, COM objects don't support implementation inheritance and polymorphism, which is why Microsoft never intended for VB to offer these features. Under COM, the only breed of inheritance is interface inheritance—the inheritance that occurs when you write a COM object that implements a certain interface. Although savvy developers have figured out how to simulate implementation inheritance and polymorphism in VB, these simulations are mere tricks.

Microsoft didn't include support for implementation inheritance in COM for several reasons, one of which is the trade-off with code reusability. When Microsoft designed COM, it moved the compiler action from the source code to the binary code to make COM objects highly reusable across many languages. However, a class is a language element, so you need to work with implementation inheritance and polymorphism at the source-code level. To derive one class from another at the source-code level, you must have the code that makes up the base class (i.e., the base-class sources), which isn't always possible. Therein lies OOP's major weakness and the reason for the success of VB's inherently less elegant approach.

Because Microsoft moved the action to the binary-code level and didn't include implementation inheritance or polymorphism in COM, you can create highly reusable but not easily expandable components with VB. In .NET, Microsoft overcomes this limitation by moving the action to a level between the source code and binary code. With this setup, .NET provides the best of both worlds: high reusability and support for implementation inheritance and polymorphism.

The key idea in .NET is the creation of a compiler for a virtual, true OOP language. The compiler is the CLR, and the language is MSIL. The CLR takes in MSIL code and makes sure it can run that code on the selected hardware platform. (At this time, the only platform that the CLR supports is Win32, but don't be surprised to see the CLR support the Linux platform in the future.)

You might conclude that you need to write MSIL code to take advantage of .NET's reusability and true OOP characteristics. However, like assembly language, MSIL isn't designed to be read by a human but rather by the runtime environment. Thus, although you could use MSIL to write a component or application, it would be difficult. Brilliantly, Microsoft solved this problem by adding another level of compilers—the .NET compilers—which transform Visual Basic.NET and the other high-level languages to MSIL. With two sets of compilers, you can use any .NET language to create code that's highly reusable like VB's classes and object oriented like OOP classes—all without the need for the base-class sources.

Unlike a VB class, a Visual Basic.NET class is a language construct that represents data and renders that data in terms of properties, methods, and events. To create a Visual Basic.NET class, you use a syntax that mimics the one that VBScript uses.

Visual Basic.NET differs from VB in other respects besides classes. Visual Basic.NET hides pointers, introduces strong data-typing capabilities, and has a slightly different set of data types. (Incidentally, the data-type changes eliminate some anomalies in VB. For example, in VB 6.0, the Integer data type represents 16-bit values, whereas in Windows, the Integer data type represents 32-bit values.) Table 2 lists the new features in Visual Basic.NET compared with VB.

A Glimpse into the Future
With .NET's arrival, VB, VBScript, and JScript will, for the most part, become obsolete. Although VBScript will work in Windows XP (formerly code-named Whistler), the bitter truth is that VB, VBScript, and JScript will be archaic languages that modern Windows platforms don't support. The new features in the various .NET languages will make backward compatibility with existing VB, VBScript, and JScript applications difficult, so you might do well to learn a .NET language.

Visual Basic.NET provides many of the features that VB developers have longed for. However, getting those features comes at a high price: Developers must learn a new language—and which language might surprise you. As I've shown, the gap between VB 6.0 and Visual Basic.NET is so significant that VB developers might find learning C# easier than learning Visual Basic.NET. I know that this statement is bold, but its psychological background softens it. When developers know that they must learn a new language, they typically open their minds and more readily accept new concepts. Conversely, when developers must adapt to a revised language, their mental inclination is typically less positive because they tend to concentrate on what's different and how they'll have to repair code that currently works fine. So, VB developers learning C# instead of Visual Basic.NET isn't such a daft idea.

What about VBScript and JScript users? Although the .NET documentation doesn't mention VBScript, Visual Basic.NET replaces VBScript, so VBScript users should start learning Visual Basic.NET. Similarly, JScript users should learn JScript.NET. Both VBScript and JScript users should view the transition to their respective .NET languages in a positive light because of the many powerful features the new .NET platform offers.