Solution Architecture

The .NET Framework is Microsoft’s operating system product that provides prefabricated solutions to these programming problems. The key to the framework is managed code. Managed code runs in an environment, called the common language runtime, that provides a richer and more powerful set of services than the standard Win32 operating system, as shown in Figure 2-1. The common language runtime environment is the higher power that we have to turn our code over to in order to deal with the harsh, savage world that is modern Internet programming.

The solution is managed code, executing in the common language runtime.

Figure 2-1: Managed execution in the common language runtime.

But with that architecture, how can the common language runtime work with any language? Not to sound Clintonesque, but that depends on what your definition of “language” is. Every common language runtime–compliant development tool compiles its own source code into a standard Microsoft Intermediate Language (MSIL, or IL for short), as shown in Figure 2-2. Because all development tools produce the same IL, regardless of the language in which their source code is written, differences in implementation are gone by the time they reach the common language runtime. No matter how it’s presented in the source code programming language itself, every program’s internal implementation of a string is the same as every other program’s because they all use the System.String object within the common language runtime. The same holds true for arrays and classes and everything else.

Figure 2-2: Different source code programming languages are compiled into MSIL.

Any company that wants to can write a common language runtime– compliant language. Microsoft Visual Studio .NET provides common language runtime–compliant versions of Visual Basic, C# (pronounced C sharp), JScript, and C++. Visual Studio 2003 has added support for J#, which compiles Java language source code into .NET IL. Third parties are producing many others, including APL, COBOL, and Perl.

All common language runtime–compliant source code languages compile to the same intermediate language.

The IL code produced by the development tool can’t run directly on any computer. A second step is required, called just-in-time (JIT) compilation, as shown in Figure 2-2. A tool called a just-in-time compiler, or JITter^[1], reads the IL and produces actual machine code that runs on that platform. This provides .NET with a certain amount of platform independence, as each platform can have its own JITter. Microsoft isn’t making a huge deal about just-in-time compiling, as Sun did about Java 5 years or so ago, because this feature is still in its infancy. No common language runtime implementations for platforms other than Windows (98, NT4 SP6, Me, 2000, or XP for clients; 2000 or XP Professional for servers) have currently been announced, although I expect some will be over time. It’s probably more a strategy for covering future versions of Windows, like the forthcoming 64-bit version and now Windows XP, than it is for covering different operating systems, like Linux.

The IL is compiled just-in- time to run on the target machine.

The .NET Framework provides automatic memory management, using a mechanism called garbage collection. A program does not have to explicitly free memory that it has allocated. The common language runtime detects when the program is no longer using the memory and automatically recycles it. Wish I had a maid that did that with my laundry.

The .NET Framework provides automatic memory management via garbage collection.

The .NET Framework finally supports versioning. Microsoft .NET provides a standardized way in which developers of servers can specify the version that resides in a particular EXE or DLL and a standardized mechanism that a client uses to specify which version it needs to run with. The operating system will enforce the version requests of clients, both providing a reasonable default set of versioning behavior and allowing a developer to override it and specify explicit versioning behavior.

The .NET Framework supports explicit standardized version management.

Because each language compiles to the same IL, all languages that support the common language runtime have the potential to support the same set of features. While it is possible to write a common language runtime language that does not expose this or that underlying common language runtime feature to a programmer, I expect the brutal Darwinian jungle that is the modern software marketplace to kill off such an ill-conceived idea very quickly. The common language runtime provides a rich set of object-oriented programming features, such as inheritance and parameterized object construction. Don’t worry if these sound like complicated concepts—they aren’t hard to use; they save you a lot of time and potential errors; and you’ll grow to like both of them.

The .NET Framework extends rich object- oriented programming features to all languages.

The .NET Framework organizes operating system functionality through the System namespace. All operating system objects, interfaces, and functions are now organized in a hierarchical manner, so it’s much easier to find the things you want. It also keeps your object and function names from colliding with those of the operating system and those of other developers.

The.NET Framework organizes system functionality into a hierarchical namespace.

The .NET Framework supports code access security. An administrator can specify that a piece of code is allowed to perform this operation but not that one. For example, you can allow a piece of code to read files but not write them, and the common language runtime will enforce your specifications and block any attempt to go outside them. This means that you can apply different levels of trust to code from different sources, just as you apply different levels of trust to different people that you deal with. This capability lets you run code from the Web without worrying that it’s going to trash your system.

The .NET Framework supports code security.

Finally, the .NET Framework provides seamless interoperability with COM, both as client and as server. The framework puts a wrapper object around a COM object that makes the object look like a native .NET object. This means .NET code doesn’t know or greatly care which kind of object it’s running with. On the flip side, .NET objects know how to register themselves with an abstraction layer so that they appear to COM clients to be COM servers.

The .NET Framework provides seamless interoperability with COM, both as client and as server.

Oh Yeah? What Does It Cost?

But what about Platt’s Second Law? (The amount of crap in the universe is conserved; see Chapter 1.) If I have less crap to deal with—for example, if I no longer have to worry about freeing memory that I’ve allocated—whose head did that crap get dumped on because it didn’t just disappear? In the case of .NET, it got dumped primarily on two sets of heads, namely Microsoft’s and Intel’s. (All of my readers who work for Sun just stood up and cheered. Both of them.) In Microsoft’s case, the operating system itself got harder to write. An automatic garbage collection mechanism like the one in .NET is several orders of magnitude harder to write than a simple in-out heap manager of the type that Windows 2000 contains. Since Microsoft hopes to sell millions of copies of .NET, they can afford to hire lots of smart programmers and engineer the heck out of it. This division of labor—letting Microsoft develop infrastructure while you worry less—makes economic sense.

The operating system got harder to write, but you don’t really care about that.

In the case of Intel, the new .NET Framework will keep them busy producing faster CPUs and more memory chips. Applications built on .NET will run slower in some operations than those that aren’t, but they’ll be easier to write and debug. Sophisticated garbage collection requires more computation than simple heap allocation, just as an automatic seatbelt requires more parts than a manual one. Plus, since garbage collection doesn’t take place as often, your computer probably needs more memory so that your app still has enough while objects are hanging around waiting to be garbage collected. (Remember Grosch’s Law? Go check the end of Chapter 1 if you don’t.) But I don’t think that the additional memory and CPU cycles a .NET program requires are being squandered, as they are on that stupid dancing paper clip in Microsoft Office. I think they’re being wisely invested, saving you time and money by letting you write code faster and with fewer bugs because the operating system is doing more of the scut work for you. An application using a general disk operating system will never run as fast as one that programs absolute sector and track disk head movements. But you can’t afford to do that; it takes too long, it costs too much, and you can’t manage very much data. You’ll spend all your time on the silly disk sectors and never get any paying work done. Once it becomes possible to abstract away these infrastructural problems, doing so becomes an economic necessity. If your own memory management was working well enough, you wouldn’t be spending your debugging time tracking memory leaks.

The computational task also got harder, requiring more computing horsepower.

^[1]Defects in this piece of software are known, of course, as jitterbugs.