.NET Framework Gossip


Why did Microsoft develop the .NET Framework? There are many theories . Here I present two of them.

The first theory is that Microsoft's .NET predecessor, the Component Object Model (COM), had a number of flaws, and that .NET was introduced to fix those flaws.

COM was introduced around 1992. One of the goals of COM was to simplify C++ development. In those days C++ developers would write programs for Windows using several kinds of C++ compilers. The compilers would take the C++ source code and turn it into an executable (an EXE file). If a programmer constantly had to write the same code for different executables, the compilers had an option to create a dynamic link library (a DLL file). The DLL would contain a group of the most commonly used functions that all the programs could share. The problem was that the formats for C++ DLLs were different depending on which compiler you used. One of the goals of COM was to provide a technology by which you could create C++ DLLs that worked with programs produced from any C++ compiler.

Around the same time a language called Visual Basic started gaining momentum. C++ programming for Windows was often difficult. The Windows operating system (OS) offers a set of functions that developers can use to develop applications. These functions are called the Windows 32-bit Application Programming Interface (Win32 API). Unless they used a predefined library of functions, C++ developers would often code to use the Win32 API directly, but this was too time-consuming . For example, creating a single form with the APIs alone requires you to declare many variables and structures and monitor messages from the OS such as Paint, MouseDown, MouseUp, etc. There were a lot of functions to remember and a lot of work to be done just to display the smallest thing. People who programmed exclusively in the Win32 APIs tended to suffer from severe vitamin C deficiency and carpal tunnel syndrome.

Visual Basic programming was simpler. With Visual Basic you don't work with structures and messages to create a form. You simply draw it, and the VB compiler changes the "drawing" into calls to the Win32 API. Because of the popularity of VB, the language was changed to produce and use COM components easily. That served as a bridge between C++ code and Visual Basic code.

Life was good for the most part, except that COM had some "flaws." For one thing, if you wrote COM code in C++ it wasn't guaranteed to be compatible with Visual Basic, and if you wrote it in Visual Basic it wasn't guaranteed to be easy to use in C++. In addition COM DLLs suffered from lack of information. A developer could include with their DLL a file called a type library that described the contents of the DLL, but this was optional, and even if the type library was supplied the information in it was limited. But perhaps the worst part of COM was the phrase "DLL hell." COM relied heavily on the registry, and what was worse , there could only be one version of each COM class registered in the machine. So if someone replaced a new version of a COM component for an older version (or many times even a newer version) chances were that all the applications that needed that COM component would break. Another problem with COM was that it only worked under Windows. This is fine for a lot of desktop developers, but what about the Web developers who used UNIX or Linux, and what about those Mac developers (the few, the proud)?

In this theory, the .NET Framework was introduced to eliminate problems with COM, and in fact, the .NET Framework provides mechanisms to solve a number of these problems.

But here is another theory of why we have the .NET Framework, and this one falls more on the category of gossip than the first.

One of Microsoft's competitors , Sun, developed a language called Java. Java lets you write code once and then deploy it in any operating system because Java programs aren't compiled to machine code directly. Instead they are compiled to Java byte code, and a piece of software called the Java Virtual Machine (JVM) converts the Java byte code to machine code at the time the program is run. Vendors of the OS can provide virtual machines for their operating system, so in theory the same Java program can run in any operating system that has a virtual machine.

Java programs don't depend on the Win32 API. Programmers code to the Java Class Library (JCL). If the program is running under Windows, the JCL calls are then translated into Win32 APIs but if the program runs under another OS, the same calls would be translated to the functions native to that OS.

Companies like IBM, for whom I was working, began to ask themselves , "Why would we want to write new applications using C++ for Windows and be shackled to the Windows OS, and then have to rewrite the application for Linux or Mac later? Why not code once in Java and use the same code in every OS?"

At the beginning Microsoft was interested in the Java language, and they developed their own JVM and their own Java compiler. However, one of the biggest problems Microsoft had with Java was that Java programs did not have the look and feel of traditional Windows programs. Also they felt that the language could use some extensions. Some of those extensions facilitated COM interactions. When Microsoft attempted to extend the Java language, with the idea of making it work better under Windows (which some people argued was just a pretense to try to force people to use Microsoft's extensions for the language), Sun sued to keep Microsoft from adding the enhancements.

The legend goes that at that point, even if Microsoft had not been serious before about writing their own version of the .NET Framework, not being able to extend the JVM surely put them over the edge. It could have been that Microsoft said, "Fine, we'll just do our own virtual machine, and our own language for the virtual machine."

This has become a theory because the .NET Framework shares similar programming paradigms to the Java virtual machine, and the C# language shares many similarities to the Java language. In fact as an instructor whenever I teach C# programming, and I have Java developers in the room, I usually hear during the week, "ah, that is just like Java."

So the truth is out there and probably somewhere in between those two theories, but regardless of why we have the .NET Framework today, the .NET Framework is a great programming platform. It does a good job at solving the problems of its predecessors while at the same time providing a language that is as easy to use and as powerful as Java and provides a mechanism by which we can write code once and deploy it in multiple operating systems.



C#
C# & VB.NET Conversion Pocket Reference
ISBN: 0596003196
EAN: 2147483647
Year: 2003
Pages: 198
Authors: Jose Mojica

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net