This is from a technical article (for developers) on MSDN titled "Building Year 2000Compliant Applications with Visual Studio 6.0 and Microsoft Windows DNA." Not a bad overview of the problem, considering that it's from MS.

http://msdn.microsoft.com/isapi/msdnlib.idc?theURL=/library/techart/msdn_vs6y2k.htm

I thought the following 2 paragraphs would be appreciated here.

"What exactly is Year 2000 compliance? Microsoft defines a Year 2000compliant product as one that "will not produce errors processing date data in connection with the year change from December 31, 1999, to January 1, 2000, when used with accurate date data, provided all other products (for example, other software, firmware, and hardware) used with it properly exchange date data with the Microsoft product."

Does this mean that if you are using all Microsoft development tools, or all Year 2000compliant development tools, the applications that you develop will automatically be Year 2000compliant? Not at all. In fact, Microsoft issues a disclaimer with their development tools regarding Year 2000 compliance that states "Compliance refers to the Microsoft product as delivered by Microsoft. The Compliance Statement does not apply to user customizable features or third-party add-on features or products, including items such as macros and custom programming and formatting features." What this amounts to is that while the development tool is itself Year 2000compliant, it is still up to the developer to practice development techniques that insure compliance is maintained in their custom applications."

Merry Christmas! Tick... Tock... <:00= ...

-- Sysman (y2kboard@yahoo.com), December 25, 1999

Answers

"What exactly is Year 2000 compliance? Microsoft defines a Year 2000compliant product as one that "will not produce errors processing date data in connection with the year change from December 31, 1999, to January 1, 2000, when used with accurate date data, provided all other products (for example, other software, firmware, and hardware) used with it properly exchange date data with the Microsoft product."

How many Microsoft engineers does it take to replace a lightbulb? None - they just declare darkness a standard!

But seriously, individual Microsoft products are generally Y2K okey- dokey. The problem is, their different products solve the Y2K problem in different ways (windowing in lots of cases). Thus, exchanging data between Microsoft applications can be a problem.

Much like IBM became to slow to lead the market in the past due to 1960s mainframe "compatibility baggage", Microsoft is now having trouble keeping-up. They have too many old, buggy applications that they need to remain compatible with.

-- Anonymous999 (Anonymous999@Anonymous999.xxx), December 26, 1999.