Since the .NET announcement by Microsoft in June, most of the buzz in the development community has been around the language wars—C++ versus C# versus Java. But arguing about language choice is a colossal waste of time in the context of a Universal Run Time that makes language choice insignificant.
By understanding this and other programming issues the Microsoft.NET initiative was designed to solve, we can begin to refocus our efforts on how to make sure our Microsoft and non-Microsoft applications interoperate with the systems that make up 80 percent of the computing world. In this article, we’ll take a high-level look at the development issues that the .NET initiative focuses on solving.
In the first installment of this series, “The .NET initiative: Microsoft puts the “e” in NT,” Tim Landgrave explained the concepts behind Microsoft.NET and how it is poised to affect the Web. Last week’s article, “Network engineers can prepare for Microsoft .NET,” covered its effect on application deployment and availability.
The compiled application versus run time debate
In the early 90s, Borland International made a big deal over the size of the EXE produced by their Delphi compiler. They compared their EXE to the size of the Visual Basic EXE and its need for an associated VBRUN.DLL with support libraries.
I always found this to be a humorous, marketing-driven ploy. As any developer knows, Windows is itself composed of several support libraries, and each programming language supplements these Windows system libraries with support libraries of their own (including C++). The issue in the Borland versus VB debate was simply that Microsoft shipped the binaries that Borland relied on in the box, whereas the VB run time shipped separately (a problem Microsoft fixed starting with Windows 98).
As more systems and development languages, and the resultant applications and support libraries, have been deployed on the Windows platform, the sheer number, complexity, and interoperability issues have made developing Windows applications more difficult and cumbersome.
From Microsoft alone we have the C run-time library, the standard template library, the Microsoft Foundation Class library, the Active Template library, the VB run-time library, the Java virtual machine, Microsoft Data Access Components, and all the versions of Windows and their service packs (with varying versions).
With the release of the .NET platform, Microsoft will bring all of these run-time engines and libraries together into a single base class library and provide a core set of services that will enable a new era of rapid software development.
The benefits of a turbo-charged, highly functional run-time environment
The most significant benefit of this new environment is the ability to offer all application services via a common object-oriented programming model. This replaces the confusing Win32 model today in which some facilities are DLL calls and others are COM calls.
This will also create a situation under which all languages can easily use all the underlying services, since no services will have been developed to support a single language calling syntax and constructs (e.g., C++ on the Win32 platform). It also means that concepts like the registry, GUIDs, Iunknown, and other COM or Operating System concepts simply cease to exist. The other benefits realized by this common run-time approach include:
- Automatic memory and resource management. The run time automatically tracks all resource usage for the developer. By doing so, it eliminates the possibility that a developer will create a “memory leak” that can negatively impact not only the performance of the application, but also create an unstable environment for other applications running on the same physical box.
- Common data types and type safety. In order to manage all memory efficiently, the run time defines all valid types (e.g., String, Integer, Character, Byte, objects, arrays). Now the run time can automatically trap errors caused when applications pass each other the wrong type for a given function. It also insures that programmers can’t “poke” information into memory and start running malicious code. The other hidden benefit of this approach is that all languages operating within the run time can share all data types, making interoperability natural and simple.
- Language choice and integration. In addition to making it easy for languages to share data through common data types, languages can integrate with each other at the class level. For example, a developer can write a core function in C++, and then that object can be inherited by a Visual Basic object. There are companies working on several other languages for the run time, including COBOL, Python, Java, and Eiffel. Since objects in any language can be subclassed by any other language, this makes code sharing and reuse not only simple but also elegant and effective.
- Debugging and error handling. Having systems written using several different objects using different language engines would not be practical without significant run-time support for debugging and error handling. The run time supports debugging applications that cross language boundaries and allows stack walking through layers of objects to determine where the defective code resides. Unlike Win32 programs where errors can be found in Hresults or Exceptions (depending on the routine), all .NET run-time errors are handled by Exceptions. This allows developers to move error-handling code out of the body of code used to get actual work done. Exceptions can also be raised across module and programming language boundaries.
Using the .NET platform, developers will not only be able to develop systems that can call or be called as global or local services, but the resultant applications will be more reliable, faster, and easier to develop and deploy.
How do you plan to integrate Microsoft.NET into your enterprise? Are you hesitant to incorporate it into your business? Post a comment below or send us an e-mail.