.NET

To understand the significance of .NET, you have to see the hole Microsoft has been digging itself into OS-wise for the past 10 years. Starting with Windows 3.1, they attempted to maintain API backwards compatibility going to Windows 95 and NT 3.1 and even to Windows 2000. While that was probably necessary to get the market to move to Microsoft's new OS versions (and not defect to something else), it cemented some poor design decisions (i.e. design decisions which nowadays are seen as poor).

The binary interoperability paradigm for Windows has been COM (Common Object Model):

• One or more classes reside in a shared library

• The only way to get an instance of such a class is by looking up a particular interface by an obscure ID in the registry, and having a class factory instantiate an object that implements the particular interface

• Very little type information is maintained with object modules

• There is no inheritance, but an object can implement more than one interface

• The only interface that all COM objects implement is IUnknown with the function QueryInterface. Once you have a reference to one interface of an object, you can call its QueryInterface function to get a reference to another interface of the object.

• Objects are reference counted by the user of an object. If the reference increments are not balanced with reference decrements, you get memory leaks or possibly memory corruption

• There is only one system-wide shared library version for any particular interface

• An executable or shared library is not linked against a particular version of another shared library (as in UNIX) but just against the name of the other shared library.

• DCOM extends the COM paradigm to distributed objects (on multiple machines)

One of the consequences of the design is "DLL Hell" - An application shipping in 2000 needs version 7.34 of a commonly used Microsoft shared library; when the application is installed, it overwrites an existing version of that library and maybe other applications stop working. Windows pretty much forces you to do this, since it always looks first in system32 for a shared library rather than first in the folder of the executable it is launching. So all shared libraries go into system32.

Another consequence is that it is often hard to completely or safely remove an application, because you're not certain what registry settings it may have changed or what shared libraries it has installed or replaced (and what other applications depend on them). There are guidelines from Microsoft on how application installers/uninstallers should behave to minimize problems, but almost everyone has run into major brand programs that exhibit or cause major problems.

Another consequence is that you can't just copy an installation of an application to another computer or move it to another folder on your computer, since you don't know what registry settings may point to the original location. And if you want to have a shared installation on a network, every user must still install the application (but indicate during installation that the app should be installed on the network) to get the right registry settings and the shared libraries that must be in the system32 folder.

It also makes the configuration and management of distributed applications very tedious because of all the registry and shared library infrastructure that must be installed on every client machine.

Finally, there is the fact that Visual Basic has one runtime environment while MFC (for C++) has a different one, and they don't share high-level or even utility-level class definitions. Most users will have a combination of programs written in Visual Basic and in C++ on their machines and so they must have both runtimes. Because they don't share class definitions, COM objects (shared libraries) can't easily be shared by C++ and VB programs - so where's the "common" in the object model?

.NET throws this all away and implicitly admits it was a mess:

• There is now a common class library framework for all languages (right now, at Beta 1, only for C# and VB). The library looks (so far) like a combination of the JDK, MFC, and VB, with support for stream i/o and network operations. Note: in my opinion, the JDK (i.e. the class libraries) is the key to the success of Java in its first two or three years. The network, collection, and other packages have made it much easier and faster to write programs and the programs are more robust because the class libraries are handling some of the hard stuff.

• All languages are compiled into an intermediate language rather than into native x86 code. VB has been enhanced with C++ features like inheritance and namespaces (which are like packages in Java). You can combine modules written in different languages.

• Modules are packaged into assemblies with manifest files, like Java JAR files.

• An assembly is all you need to run an application. You put it in some folder and run it. No registry settings, no dependencies on other shared libraries (unless you choose to). You can have multiple versions in different folders.

• A module knows what version of a shared library it was built with, so you can have multiple versions and it will pick the right one.

• Memory is managed through garbage collection (as in Java) rather than through reference counting.

• Rich meta-information is stored with each object module, allowing applications and tools to discover, present, and use the objects' interfaces automatically and safely (as with Java reflection, and more) rather than being dependent on the meta-information being available in a registry. Objects are instances of classes.

• SOAP (XML over HTTP) rather than DCOM is the way to expose an object's interface to remote clients.

• IIS with ASP.NET can automatically publish and make accessible an object's interface simultaneously with HTTP GET, HTTP POST, SOAP synchronous requests, and SOAP asynchronous requests (a response thread is transparently created to wait for the request to complete). A tool that comes with them also generates a proxy object stub for clients (in any supported language) so that clients are not aware of the protocol used to communicate.

• ASP.NET lets you specify that some or all of the elements of a page live on the server (like LiveWire for JavaScript in Netscape Enterprise Server)

In some respects, Microsoft is tacitly recognizing that UNIX and Java have had better solutions in many areas for many years. But since Microsoft is giving itself a blank check to redo things from scratch this time and to learn/steal from the past five years of Java and Web experience, it is able to go further in using XML throughout, making cross-language rich runtime type information available for all objects, and then utilizing those properties to provide a framework and tools to develop and deploy applications as distributed objects quickly.

[Ed: This article originated as a company memo, which the author kindly allowed me to reprint here.]