The problem with Y2K was that a large number of programs would have a defect (the same defect, or similar defects, as it happened) at the same time. It was the large number of programs affected at the same time that made Y2K the crisis what it was. (That, and our willingness to ignore the problems -- we knew about them since the 1960s -- until we had to address them.)
There are other problems of a similar nature to Y2K.
The year 3000 Most obvious is the "Y3K" problem. We solved the year 2000 problem with a series of patches and temporary fixes. A few programs were fixed with a long-term solution. After January 1, 2000, we all looked back, breathed a sigh of relief, and told ourselves that we would not let that problem happen again. Yet as early as March we dropped the "20" from our years and started using two-digit years in our documents and data. These documents, programs, and datasets will cause problems in the year 3000.
For those of you who are not worried about "Y3K" problems because the date is so far ahead, let me remind you that that thinking is exactly what got us into the Y2K mess.
The year 10000 A more distant and more subtle problem. The programs that were fixed "properly" for Y2K will work in 3000, and int 4000, but may fail in 10000.
The astute reader has realized that the "Y10K" problem is the same as Y2K, but at a larger time scale. The very astute reader has surmised there is no permanent solution for storage of dates, at least not with our current calendar and notations.
The Microsoft COM problem Not related to a specific date (at least not yet), this problem is similar to Y2K in that it will affect a large number of systems at the same time and it is a known problem.
At some point, Microsoft will stop supporting COM. I don't know when that time is, and I don't know that Microsoft has made such an announcement, but I am fairly certain that they will stop supporting COM -- if for no other reason than to get rid of the Windows registry, which COM uses.
COM was a solution to the problem of multiple DLLs, and it worked (clumsily) for a long time. It still works, but the design of .NET makes COM unnecessary. A "modern" Windows application will use .NET, not COM. Well, it might use COM and Microsoft's "Interop" techniques to talk to COM components, but only because those components have not been ported to .NET.
Yet a lot of systems use COM. Adobe products use COM to connect to objects in their scripting language. An unknown number of in-house systems use COM to connect components into systems. Even Microsoft uses COM for some of its products. COM is not dead -- although one can make the argument that it should be.
I'm sure that Microsoft is working to migrate all of its products and applications from COM into .NET. Microsoft has a large product line and a large code base, and such a migration may take years and possibly decades.
But know this: at some point, COM will stop. (It will cease to be. It will depart. It will meet its maker. It will be a dead parrot.) When COM stops, all of the systems that rely on COM will stop, too. Microsoft will have converted their applications to use .NET. Will your systems be ready?
My purpose is not to panic people. I believe that COM will be supported for a long time. You have time to identify your systems, plan for their conversion, and implement the changes long before Microsoft drops support for COM. My purpose is to alert you to this change and get you to make plans.
Eventually, you will have to change your applications. You can change them on your schedule, or on Microsoft's schedule. Which do you prefer?
No comments:
Post a Comment