.NET Now Positioned to Replace COM

Several years ago when Microsoft introduced its .NET technology, there were many discussions about whether this was a sign of the end of COM. After all, .NET isn't based on COM but instead on a runtime environment and byte code. At the time, most everyone, including Microsoft officials, concluded that .NET isn't the end for COM. But the world of technology keeps changing. As we prepare to take another step forward, so does the likelihood that COM is, in fact, reaching its end of life for most business applications.

Don't get me wrong--I'm not saying that Microsoft's product support for COM or COM's use as a standard (and one used by key Microsoft products) is coming to an end. However, we're fast approaching a point at which most business applications won't be implemented with COM. This distinction is important. Simply put, Microsoft isn't ending its support for COM but rather the market is bringing about the effective end of COM.

In this case, it comes down to the demand for applications that have more memory and faster processors. If you've been developing applications for more than a couple years, you might recall the last big jump: the migration from Windows 3.1 to Windows 95, which is better known in the technical world as the transition from 16-bit to 32-bit OSs. I don't know of a single developer who found this transition to be a pleasant experience. Perhaps it was profitable for some consultants, but nevertheless it wasn't pleasant, even for them.

We're now approaching the next big jump: the migration from 32-bit to 64-bit OSs. When people hear "64-bit," they often think of servers. After all, it was the overburdened database servers of companies' Web-based applications that first showed the strain on 32-bit OSs. However, as we continue to move forward, we're seeing that high-end users (e.g., developers who develop for 64-bit platforms, gamers who want more memory to make games run faster) are eyeing the move to 64 bits. Although 64 bits might not be a priority on the average Web server yet, as more servers are used to host multiple sites, even Web servers will eventually look for 64-bit processing.

The result is a challenge for COM in that COM is a binary protocol. COM-based applications base their communications on data contained and formatted in their compiled state. Thus, when you compile your code to run on a 32-bit OS, the code implements the protocol based on a 32-bit environment. The problem is that an object that worked well in a 32-bit environment might not work as well in a 64-bit world.

Microsoft and many hardware manufacturers are making their 64-bit products compatible with existing 32-bit applications. However, compatibility is a far cry from having a platform that runs 32-bit and 64-bit applications equally well. The Windows .NET Framework is such a platform. More important, Microsoft made the .NET Framework available several years ago, which means that the transition from 32-bit to 64-bit OSs will be far less painful than the transition from 16-bit to 32-bit OSs.

Although there will still be companies that use COM-based interfaces to build applications, these companies will be the exception rather than the rule in the not-too-distant future. Most companies will use .NET 2.0 and the upcoming .NET 3.0 to build code so that their applications can be effortlessly ported to the new 64-bit world.