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.
End of Article
