The next '2K' problem

It's been over thirteen years since the much-hyped 'Y2K' problem. We prepared for the great problem of two-digit dates and the rollover effect of the year 2000.

Now, another problem faces us. A "2K" problem, although different from the Y2K problem of thirteen years ago.

That problem is the "Windows 2000" problem.

While most folks have replaced their PCs and upgraded their operating systems, there are quite a few computers running Windows 2000 and Windows XP. I call these the "W2K" and "WXP" PCs. But these are not the typical office PCs -- these are hidden, or at least disguised.

Some of these "disguised" W2K and WXP PCs exist as:

• Automatic teller machines
• Ticket vending kiosks
• Information kiosks
• Restaurant management systems
• Patient scheduling and billing systems for doctors and dentists

The problem is compounded by the owners of these systems. The owners (banks, transit agencies, restaurateurs, and doctors) do not think of these systems as PCs that need to be upgraded. They think of them as appliances, akin to a microwave oven or a refrigerator. Expensive appliances, perhaps, but appliances. Most owners don't see them as needing to be upgraded.

Many of these systems are sold as turnkey systems. Instead of purchasing the software and installing it on separately purchased PCs, the hardware and software are sold as a package. This reinforces the notion of appliance.

The owners of these systems have forgotten (if they ever knew) that these "appliance" systems are PCs running Windows. They will be in for a rude surprise when they find out.

When will they learn that their reliable, use-it-every-day, system must be replaced?

For some, the notice will come early. Some vendors will actively approach their customers and recommend new versions (complete with a newer version of Windows and the hardware to support it). Such an upgrade is not cheap, however, and many customers may balk.

Other users will learn when their system fails. The failure may be caused by hardware (a drive stops working) or software (their new printer doesn't have a driver for Windows 2000) or by a virus (Microsoft will stop sending out security updates next year).

This W2K/WXP problem is unlike the Y2K problem in that failures will happen over time, not all at once. But it is worse than the Y2K problem because people are not expecting it, and are not prepared.

The lesson here is that businesses are built on many services, and a well-run business must be aware of them, and aware of the costs and the reliability. We have stable and regulated services for electricity, water, telephone, and internet services.

Automated systems are another form of service. Less regulated, and perhaps less stable. An upgrade to a new PC running Windows 7 may cost too much for the corner restaurant. That is an ugly way to lose a business.

Windows 8 is like Y2K, sort of

When an author compares an event to Y2K, the reader is prudent to attend with some degree of skepticism. The Y2K problem was large and affected multiple platforms across all industries. The threat of mobile/cloud computing (if it can even be considered a threat) must be large and wide-spread to stand against Y2K.

I will say up front that the mobile/cloud platform is not a threat. If anything, it is an expansion of technical options for systems, a liberalization of solution sets.

Nor does the mobile/cloud platform have a specific implementation date. With Y2K, we had a very hard deadline for changes. (Deadlines varied across systems, with some earlier than others. For example, bank systems that calculated thirty-year mortgages were corrected in 1970.)

But the change from traditional web architectures to mobile/cloud is significant, and the transition from desktop applications to mobile/cloud is greater. The change from desktop to mobile/cloud requires nothing less than a complete re-build of the application: new UI, new data storage, new system architecture.

And it is these desktop applications (which invariably run under Microsoft Windows) that have an impending crisis. These desktop applications run on "classic" Windows, the Windows of Win32 and MFC and even .NET. These desktop applications have user interfaces that require keyboards and mice. These desktop applications assume constant and fast access to network resources.

One may wonder how these desktop applications, while they may be considered "old-fashioned" and "not of the current tech", can be a problem. After all, as long as we have Windows, we can run them, right?

Well, not quite. As long as we have Windows with Win32 and MFC and .NET (and ODBC and COM and ADO) then we can run them. But there is nothing that says Microsoft will continue to include these packages in Windows. In fact, the new WinRT offering does not include them.

Windows 8, on a desktop PC, runs in two modes: Windows 8 mode and "classic" mode. The former runs apps built for the mobile/loud platform. The latter is much like the old DOS compatibility box, included in Windows to allow us to run old, command-line programs. The "classic" Windows mode is present in Windows 8 as a measure to allow us (the customers and users of Windows) to transition our applications to the new UI.

Microsoft will continue to release new versions of Windows. I am reasonably sure that Microsoft is working on "Windows 9" even with the roll-out of Windows 8 under way. New versions of Windows will come out with new features.

At some point, the "classic Windows compatibility box" will go away. Microsoft may remove it in stages, perhaps making it a plug-in that can be added to the base Windows package. Or perhaps it will be available in only the premium versions of Windows. It is possible that, like the DOS command prompt that yet remains in Windows, the "classic Windows compatibility box" will remain in Windows -- but I doubt it. Microsoft likes the new revenue model of mobile/cloud.

And this is how I see mobile/cloud as a Y2K-like challenge. When the "classic Windows compatibility box" goes away, all of the old-style applications must go away too. You will have to either migrate to the new Windows 8 UI (and the architecture that such a change entails) or you will have to go without.

Web applications are less threatened by mobile/cloud. They run in browsers; the threat to them will be the loss of the browser. That is another topic.

If I were running a company (large or small) I would plan to move to the new world of mobile/cloud. I would start by inventorying all of my current desktop applications and forming plans to move them to mobile/cloud. That process is also another topic.

Comparing mobile/cloud to Y2K is perhaps a bit alarmist. Yet action must be taken, either now or later. My advice: start planning now.

Y2K is not dead

The problem with Y2K was not that programs were going to calculate dates incorrectly. The miscalculation of a date is a program defect, a "bug", and all sorts of programs have all sorts of defects.

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?