I need some help sorting this out. If I have overlooked existing resources, I apologize and would appreciate being re-directed.

A problem has been identified by an Australian company called MFX Research ( http://www.mfxr.com/ ) involving the creeping corruption of application, shared-library and ultimately OS files due to unhandled errors caused by Short Date processing.

A White Paper was submitted by MFX in October 1999 to The Royal Society (not sure which; For Putting Things Upon Other Things?) explaining the issue. On 11/21, Brian was kind enough to post the text of this paper here at TB2K on this thread.

http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=001oxf

and another thread on this topic from 11/12 is at:

http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=001l1C

Brian didn't say where he got it, and I, (not wanting to appear nosy...), didn't ask. I'll repost the text after my comments.

The White Paper alluded to an ongoing study by an independent group: "...The Rotterdam Test Centre, which is owned by 'Year 2000 Consultants BV', has set up a test bed of computers in various configurations to test the impact of computer usage on the operating systems and applications in a post year 2000 environment.

A comparison is being made between systems that have and have not been remediated by MFX2000.

The program is being co-ordinated by the Director Mr Bart Stuut and has been running for many weeks.

Mr Stuut will publish the final results of his investigations. ..."

*big old snip*

"...In-house studies by MFX Research support the proposition but a comprehensive third party study is being conducted in Rotterdam to test the hypothesis. This test has been running for many weeks and is almost complete. Preliminary results are proving our hypothesis. "

Now, oddly enough, MFX sells remediation tools. "Not that there's anything wrong with that." What's interesting about their tool is that it checks and fixes date formatting in places many other tools don't. Think on that for a moment. NATO uses it, BTW. NSTL said it Didn't S***. Four stars from those guys.

They are now offering the "audit" portion of their tool for free at the website mentioned above. (it's about a 7MB download, and took 5 hours to audit my 4GB drive last nite.) No endorsement intended, but it seems like a nicely done app..

When I arrived this AM and began reviewing the results, I, well, suffice to say a change of clothing was required. Reams of files were listed, alleged to contain the dreaded mm/dd/yy date. Not user data files, mind you; compiled application files. From trivial companies like Novell, Sybase, Corel, Netscape, and damn near every MS .dll on the drive.

So what does this all mean?

I honestly don't know. I cant't figure out if this is The Horrible Thing Nobody Thought Of, (Cherri started an interesting thread on that topic last week), or a desperate marketing attempt.

I need to call upon all the Wise Old Geeks (Polly/Gloomer/Doomer) who wander around TB2K, muttering. (Any thoughts, Pere Yourdon?) Read the full text of the White Paper below and tell me if their core argument holds water:

"...Summary

What starts off as a minor misrepresentation by an application/s of a short date transfer, rapidly results in corruption of the application shortly followed by the operating system, assuming that the application is not reinstalled.

The basic problem relates to dates ending in /00 and to a lesser extent /01. These cause data type errors in applications, and because error trapping has not been written to handle these types of errors, due to the sharing of DLLs between applications, as one application is corrupted, it involves other applications and eventually the operating system.

There is an inexorably fatal process:

Errors not trapped

Calls left in limbo

Freezing of calls and returns

Corruption of Applications

Corruption of the O/S..."

Thank you all for assesments. You will be paid your usual rate....

-- Lewis (aslanshow@yahoo.com), November 23, 1999

Answers

Text of White Paper follows. Any wonky formatting is my fault.

Part 1

The Royal Society in England received a report and White Paper on Y2k short date issues for personal computers and desktops on Oct. 5, 1999. The White Paper is attached. An independent testing firm in Rotterdam has confirmed the Royal Society info. NATO has confirmed the Rotterdam Group's finding. You can test your computer for free to see if it has short date problems by downloading an audit at http://www.tir.com/bretzke/free.html

Personal computers will cease to operate during first quarter of 2000. Test your own computer and see where you stand PERSONALLY then go out and prepare for your family like I have. WHITE PAPER

THE YEAR 2000 ERROR

And

CORRUPTION of PC OPERATING SYSTEMS & APPLICATIONS

OBJECT CODE TECHNOLOGY

Copyright

This document and the MFX software described within it are copyrighted with all rights reserved. Under copyright laws, this document may not be copied, photocopied, reproduced, translated or reduced to any electronic medium or machine readable form, in whole or in part, without the prior written consent of MFX Research Pty Ltd. (MFX). Failure to comply with this condition may result in prosecution.

Disclaimer

The information contained in this document is intended to be used as a guide to some of the more complex Year 2000 (Y2K) issues. In no event will MFX be liable for direct, or indirect, special, incidental or consequential damages arising out of the use, or inability to use, the information contained herein. MFX reserves the right to correct update or modify this document without notice and without incurring liability.

Acknowledgments

Throughout this document, references are made to other manufacturers' proprietary products. All Trademarks are acknowledged.

Copyright: ? 1999 MFX Research Pty Ltd.

MFX Research Pty Ltd. Level 1 19 - 23 Bridge Street Pymble NSW 2073 Australia

Telephone: +612 9440 0200 Fax: +612 9440 0033 EMAIL: info@mfxr.com WEBSITE: http://www.mfxr.com

Index

Copyright Notice, Disclaimer & Acknowledgements 2

Index 3

1 Introduction 4

2 Why Will the Impact of Y2K Result in the Corruption of Operating Systems and Applications? 6

3 Testing for Date Usage in Operating Systems and Applications. 13

4 Significance of Short Date Formats in Operating Systems and Applications. 16

5 Evaluation of Object Code Technology (OCT). Functionality and Possible Downstream Impacts 18

6 The Rotterdam Report 19

7 Object Code Technology 20

8 Impacts of MFX2000 on Operating Systems and Applications 22

9 Conclusion 23

1 Introduction

The computer industry only identifies the Y2K problem to reside at two levels in the PC environment:

? Hardware - BIOS / CMOS / RTC ? Data Files

MFX Research completely disagrees and contends that the impact of the "Millennium Bug" problem on Operating Systems and Applications has been completely overlooked.

MFX Research has put forward the following prediction:

"The most serious impacts of the Y2K bug will be the progressive degradation of applications and operating systems. In addition this will prevent access to data files, whether or not they are Y2K compliant.

Any resolution to the Y2K problem should involve a global approach to the PC environment including the Operating System and Applications together with Hardware and Data Files."

Bruce Parker, the MFX Research Director of Research and Development has stated:

"The Y2K dilemma has always been described as a data issue, but this approach is too simple. It is not just a data issue, but how an application and operating system will manage the data, to perform calculations and various date related functions. How can any application passing data with a date ending with 00 or 01 handle such information?

A date function is recognised by its satisfying certain criteria, that is a day, month and year. Dates like 01/01/02 and 01/01/99 fit within these criteria, and are classified as a date structures even though the century component is not defined. There are multiple date separators including "/", "-" and ".". These identify the break between a day, month or year. However, these three particular separators also carry the mathematical functions of divide, subtract and decimal.

As a result, if an application sends a call and expects the date in the return to be in a string format, if the string return is 01/01/00, the data may be accepted as a date or, due to the format and the possible functionality of the file, it may be interpreted as a 1 divided by 1 divided by 0. A major issue occurs with a month year return, a year return or a string based day, month, year return because these will return a non-date format to the relevant application resulting in an error.

Errors may be trapped or ignored. In either case, part of the functionality of the application will be frozen in memory when the application is closed. This frozen component will be released, if the application is closed correctly. Such an error is unlikely to be trapped and the application will not be closed correctly and a stack freeze will occur resulting in a slight corruption of the relevant file. This will be cumulative and will ultimately affect system files, so that not only the application, but also the system will become corrupted and unstable.

Such errors do occur now, but are not usually date based. By introducing dates into the equation, an application using date calculations will experience a significantly increased incidence of such errors, every time a date function is implemented. This will apply at its worst across 2000, as O will return a non-date format, a divide by O error or a O. 2001 will return the original parameter sent as if read, because a mathematical function divided by 1 or multiplied by 1 always returns the same number.

Matters will only return to normal after the year 2002."

2 Why Will the Impact of Y2K result in the Corruption of Operating Systems and Applications?

Y2K will impact on Operating Systems and applications in a number of different ways.

Impact on non-remediated data

If data has not been remediated for Y2K, all the known problems at this level will occur i.e. incorrect billing cycles etc. Excluding BIOS, this is the level of most Y2K awareness.

Impact on remediated data

Data is information, stored in one format or another, which will be ultimately used by an application for a given function. Functions like DateSerial in MS Excel will default to a non-Y2K compliant format as will Today, and Now etc, if the code that is used with them is not compliant, or if the driver files supporting this functionality are not compliant. Put simply, compliant dates may be stored, but if the application reads them as short dates and performs functions on them as if they were short dates, the effort expended in remediating the data is wasted.

Applications and date calculations

Consider an application that calculates the difference between two dates and uses the default short date format. Because in Win '98 and NT4 SP4, the pivot date can be changed, two identical machines could have different pivot dates i.e. 2029 and 2019. Unless the date function of the O/S is permanently fixed to a long date format, the two different machines could conceivably return two totally different answers.

If a date calculation is hard coded into an application and it is short date based then an error will occur with calculations across the year 2000. If an application passes a date function calculation to a DLL in a long format (so the application is compliant) but the DLL only reads a short date, then a similar error is generated.

Unfortunately, today the word application applies only to the immediate functionality of a tool, and not to any bundled third party applications or any other "standard" files, which the application may use.

This is important because Microsoft on its website only vouches for the year 2000 compliance of MS products but not for third party applications.

Consequently it is important to carefully read the Microsoft Year 2000 compliance statement:

" provided all other products (e.g., other software, firmware and hardware) used with it properly exchange date data with the Microsoft product"

Most corporates cannot check the compliance of all "other products", let alone know what the "other products" are.

Operating Systems and date calculations

The Microsoft Year 2000 Compliance Statement is important for another reason:

" The Compliance Statement does not apply to user customisable features or third party add-on features or products, including items such as macros and custom programming and formatting features"

In other words, the compliance statement does not cover changes the user can make to applications like changing the pivot dates or putting in back ground VBA code. All versions of Windows allow the user to customise the Short and Long date settings on their PC. Whilst this may not affect all the Windowing functions used in Windows, it affects all of the Languages shipped by Microsoft, and the languages used by developers for "customisable" features including VB, VBA and C++. Only the most recent releases of these tools actually ignore the short date settings, but they are fully reliant on the Windowing pivot date ranges in Windows '98 and Windows NT 4 SP 4. This raises another set of issues, as these pivot dates are "customisable" on individual PCs and therefore Year 2000 compliance may be lost. For example, one PC may have the pivot date set to 2029 another to 2002, so data entered as say 1/1/10, will appear on one machine as 2010, and on another as 1910.

Windowing at best is a method of delaying remediation of data and applications and at worst an extra "overhead" on an operating system (OLEAUT32.DLL). Windowing is constantly making "decisions" on dates entered, but not on date calculations performed by an Application or the O/S.

With the arrival of Windows 3.0 in 1990, the mass storage of data really began. There are now approximately, 400 million plus PCs in the world, each possibly with an average of 50Mb of data. Utilisation of Windowing to 2019 or 2029, is delaying the impact of a very major problem.

Application errors

Most applications that use date functions are not Y2K compliant, so application errors are to be expected.

Consider the simple example of passing data from a database to a charting tool like Crystal:

Data for sales projections could be represented as 07/1999, 08/1999, , 05/2000 and 06/2000, but read as 07/99, 08/99, , 01/00, 02/00, 03/00, 04/00, 05/00 and 06/00. In this situation, what does 01/00 mean? What has happened to the bytes passed for the century? Does a query go back to the database for 01/00 returning data from 1900, or 2000? The answer is:

? The extra bytes don't just disappear, they are "stuck" in memory. A memory stack freeze will occur, and when the application is closed a slight corruption occurs. ? No application unless specifically programmed can handle a 0 function request. Does the application handle a 01/00 request from the reporting tool as a date or does it actually see it as 1/0 or a divide by zero error? It may be expecting a date format 01/00 as a date format, but it can also be returned as an integer i.e. 1/0. This will not send a return, because it is not the correct data type. The possible errors are: it is the wrong data type or it is a divide by 0 error. There is no error trapping for either of these possibilities, as neither of these errors would be expected when passing date parameters. The net result is file corruption.

Each time there is an error of this type, the application should return an error, to complete the matter until the date issue is resolved, but in reality, applications do not return these errors, as they were never expected to appear at this level. As a result, the application will freeze, crash or continue on, but with a memory stack freeze created around that function. In any of the three cases above, the application has frozen the relevant function, so when it is closed a slight modification or corruption occurs in the relevant files. These errors become cumulative over time, to a point where an application cannot operate properly, if at all.

There is nothing new in this situation as described. This is how file corruption occurs and it is why IT departments reinstall O/S and Applications when a large number of General Protection Faults (GPFs) are being experienced. However, what is new in the scenario is that a period is being entered during which there will be a whole new range of errors, related to 00 and 01, which were never anticipated. The "decay rate" on applications is going to increase exponentially. The problem will be at its worst during 2000, and to a lesser extent in 2001. Sometime in the year 2002, there will be a return to standard errors and their rates.

The situation is complicated by the fact that reports can be embedded in applications, which by themselves do not have date functionality or related errors. By embedding reporting functionality which is obviously date based, the applications are exposed to date errors and their ramifications. This exacerbates the problem because full OLE functionality becomes involved as well as possibly JET or their equivalents, which means that errors are now involving these wrapper applications.

The Operating system is affected in the same way as applications but because the immediate date usage is in the application and support files, the corruption of these files will occur first. As these 'decay', a similar impact will be experienced by the O/S. When the decay of the applications reaches a critical point, the degradation of the O/S, which was initially slow, will increase exponentially.

No software vendors make any reference to these problems in their Y2K testing results or their compliance statements because none is aware of the problem. They are not looking at error trapping or data types. They are simply looking for date structures within their own application that are directly used. Any date structures that are not directly used are classified as non-Y2K volatile and the application is classified as Y2K compliant.

Any short date structure is Y2K volatile, not only for what is commonly known as the Y2K error, but more so for the potential impact that can occur on the applications as previously described.

MFX Research estimates that if a PC is used simply for the typing of letters, and no date calculations are involved, an application will conceivably remain stable for up to 6 months.

Conversely, a commercial PC may reach a state where the application is unusable within 4-5 weeks.

Operating system errors

The decay in an application as described above, will be associated with a decay in the operating system, whether or not the O/S is Y2K compliant.

Every Windows based applications must use Application Programming Interface (API) functions simply to be displayed on a Windows platform. At any given time APIs from the Kernel, User or GDI or other DLLs may be in operation. If the application freezes, there is no way to free the memory. If at the same time the application froze, an API call was being made or received, this will also be frozen resulting in corruption of the files.

As previously stated, corruption of the operating system closely follows corruption of applications.

Summary

What starts off as a minor misrepresentation by an application/s of a short date transfer, rapidly results in corruption of the application shortly followed by the operating system, assuming that the application is not reinstalled.

The basic problem relates to dates ending in /00 and to a lesser extent /01. These cause data type errors in applications, and because error trapping has not been written to handle these types of errors, due to the sharing of DLLs between applications, as one application is corrupted, it involves other applications and eventually the operating system.

There is an inexorably fatal process:

Errors not trapped Calls left in limbo Freezing of calls and returns Corruption of Applications Corruption of the O/S

Two other factors complicate the situation:

a) The Sharing of Application DLLS

The PC environment is significantly different to the mainframe environment in that there is sharing of driver/library files by the operating system and applications. There can be multiple programs sharing the same DLLs. The average PC has more than 25 programs all sharing hundreds of DLLs.

This can result in significant problems when programs are installed onto a PC system.

Whenever a program is installed, if there is commonality of any library files, older library files will be replaced with newer files if they are present in the new program.

If a new program that is not Y2K compliant is loaded onto a system, it may result in the replacement of older compliant DLLs, which are shared by multiple programs, by newer non-Y2K compliant DLLs.

The situation can be exacerbated by two additional possibilities:

i) Some new programs, particularly if downloaded from the Internet, may contain old non-Y2K compliant library files. However, the programmer may have globally restamped the files with a recent date. This will result in these old files with newer file date stamps replacing files that are in fact more recent. Not only will functionality be lost but also non-Y2K compliant files will have been introduced.

ii) Some set-up routines used when applications are installed globally replace DLLS that are common to other files. The result is exactly the same as above.

b) Non-Y2K Compliant Compilers.

The importance of the use of Y2K compliant compilers for the production of Y2K compliant applications is not widely recognised.

It is not uncommon for software houses to write source code that is Y2K compliant but then to utilize non-Y2K compilers. This will inevitably result in the production of a non-Y2K compliant program.

When Y2K compliant software is created, there are a number of issues that must be considered.

If tools like Visual Basic are being used, date management for functions like NOW, TODAY and DATE etc, are managed by supporting DLLs.

If these DLLs are not Y2K compliant, it will not be possible to compile a compliant file using date structures of this type.

For C and C++ compilers, most programmers will ensure that all of their code is using long dates. However, what are often missed are the date structures within Include files. In addition, if the compiler is not set correctly and / or relies on external files like MSVCRT20.DLL etc, then short dates will be used.

The compiler must be capable of compiling compliant code. The supporting files must also support compliant date structures.

Currently there are very few compilers available that allow the compilation of compliant code without changes being made to the compiler's configuration.

3 Testing for Date Usage in Operating Systems and Applications.

The development of Object Code Technology by MFX Research allowed, for the first time, the evaluation of Operating Systems and Applications. In addition it also allowed the prevalence of short date formats in Operating Systems and Applications to be accurately documented.

The first documented tests by MFX Research using Object Code Technology on the Windows environment were conducted in mid 1998.

The results are summarized as follows and confirmed the suspicions of MFX Research that short date usage was common throughout the Windows Operating System and in most Applications.

Windows 3.11

A clean formatted box was loaded with only Windows 3.11, Microsoft Office 4.3 Professional and MFX 2000. The results of the scan of the PC were as follows

? Number of files scanned 1408 ? Number of short date formats 578 ? Number of files involved 70

5% of files were affected by short date usage.

Windows '95B

A clean formatted box was loaded with only Windows '95B, Microsoft Office '95 Professional and MFX 2000. The results of the scan of the PC were as follows

? Number of files scanned 2808 ? Number of short date formats 1101 ? Number of files involved 70

2.5% of files were affected by short date usage.

Windows '98

A clean formatted box was loaded with only Windows '98, Microsoft Office '97 Professional and MFX 2000. The results of the scan of the PC were as follows

? Number of files scanned 3873 ? Number of short date formats 1227 ? Number of files involved 214

5.5% of files were affected by short date usage.

Windows '98 SP1

A clean formatted box was loaded with Windows '98 with Service Pack 1, Microsoft Office 97 Professional with SR1 and SR2 and MFX 2000. The results of the scan of the PC were as follows

? Number of files scanned 4029 ? Number of short date formats 1248 ? Number of files involved 222

5.5% of files were affected by short date usage.

Windows 2000 Beta 3

A clean formatted box was loaded with Windows 2000 Beta 3, Microsoft Office 2000 Premium and MFX 2000. The results of the scan of the PC were as follows

? Number of files scanned 4766 ? Number of short date formats 1183 ? Number of files involved 170

3.5% of files were affected by short date usage.

Windows NT 4 SP3

A clean formatted box was loaded with Windows NT 4 with SP3, Microsoft Office 97 Professional and MFX 2000. The results of the scan of the PC were as follows

? Number of files scanned 2461 ? Number of short date formats 906 ? Number of files involved 138

5.6% of files were affected by short date usage.

Windows NT 4 SP4

A clean formatted box was loaded with Windows NT 4 with SP4, Microsoft Office 97 Professional and MFX 2000. The results of the scan of the PC were as follows

? Number of files scanned 2588 ? Number of short date formats 915 ? Number of files involved 143

5.5% of files were affected by short date usage.

The testing program conducted by MFX Research has demonstrated that there is pervasive use of short date formats in the Windows Operating Systems and in virtually all Applications that have been tested, Microsoft and non-Microsoft.

The testing also demonstrated that even after the installation of Microsoft Patches, there was still significant usage of short date formats. 4 Significance of Short Date Formats in Operating Systems and Applications.

What is the significance of short date formats in Operating Systems and Applications.

MFX Research classifies short date formats into two categories:

? Non-Volatile ? Volatile.

a) Non-Volatile short date formats are not involved in calculations and are classified as low risk in regards to Y2K. The dates usually reside in the header and footer of a file where they are usually date stamps. They are used for identification or some other purpose. Non-volatile short date may also occur in bitmaps, wave files etc.

b) Volatile dates are any dates sitting within the body of a file, be that a data, executable, library or a driver file. The body of a file is that part of a file where the actual processes occur or the data structuring occurs. In most files, over 90% of dates are held within the body of the file.

A definition, such as a date format, is only incorporated within the operational component of a file i.e. the body of the file, if it is to provide functionality, even when that functionality is not immediately apparent. So, while a file may contain a short date definition for which there is no apparent usage, given the complexity of the current PC environment, with the usage of libraries referencing other libraries, VBXs, OCXs and other driver files, the chance that the date will be referenced is high. It may be an obtuse usage of the file, and not seen at interface level but such a usage is possible.

The file inter-referencing that occurs in a PC is far more complex than the situation in a Mainframe computer.

In a Mainframe environment, there is an Application that runs in tandem with a Data File Data structure. These sit on top of the Operating System. The data file data structure may or may not be in the same directory. All of the functionality for the application is held within the one directory and it would be rare to encounter referencing occurring outside of that directory.

In the PC environment, referencing between files is complex. An application may reference a data file, which references back to the application which may be spread across 30 different directories in a sub-directory tree, which is in turn referencing back out to Windows. In the Windows Directory there are dozens of sub-directories and there could be references going between all of these sites.

The significance of the referencing between files containing different date formats depends on the functionality involved. Whilst two files may be using different date structures, if they are not passing date information between them there will not be a

problem. If a date is involved in the functionality of the files, there is a potential for conflict and this means a potential for corruption and eventual degradation of the operating system as the operating system relies on a lot of the same driver files. The impact will not be evident immediately but will occur over a period of time.

The programmed logic of Object code technology as used in MFX 2000 excludes file types with no date functionality i.e. wave files, help files and images. Otherwise, all short date formats are identified as being of potential significance. So for operating systems and applications to be Year2000 compliant, all date referencing should be of long format i.e. the century year component defined as 'yyyy'

5 Evaluation of Object Code Technology (OCT) - Functionality and Possible Downstream Impacts.

MFX Research has had the functionality of Object Code Technology as used in MFX2000 evaluated and accredited by third party testing.

The following institutions have evaluated and confirmed the functionality of the technology as used in the MFX2000 software:

NSTL National Software Testing Laboratories (U.S.A.) NATO North Atlantic Treaty Organisation

CSTC China Software Testing Centre BSI British Standards Institution (U.K.)

NSTL and CSTC have provided written accreditations for MFX2000.

BSI provides the definition for 'Year 2000 compliance' utilised worldwide and by the U.S.A. and U.K. Governments. BSI has purchased MFX2000 to evaluate and fix their own computer systems.

Veritest in the U.S.A. is currently evaluating the technology.

In addition, there have been numerous successful case studies conducted on the technology in Europe, UK, Australia and Japan.

No significant negative downstream impacts from the usage of OCT (MFX2000) have been identified by the above testing. Minor impracticality of the interface has been described but there has been no defect identified in the software's functionality.

Written reports prepared by NSTL and CSTC, and comments from NATO are available.

MFX Research has arranged for further and more comprehensive testing of MFX2000 and for specific testing of the hypothesis proposed earlier in this document, relating to corruption of O/S and Applications by short date format usage. In addition, the testing, which is running over several months, is to further evaluate for possible downstream impacts of the usage of MFX 2000.

6 The "Rotterdam Report"

The Rotterdam Test Centre, which is owned by 'Year 2000 Consultants BV', has set up a test bed of computers in various configurations to test the impact of computer usage on the operating systems and applications in a post year 2000 environment.

A comparison is being made between systems that have and have not been remediated by MFX2000.

The program is being co-ordinated by the Director Mr Bart Stuut and has been running for many weeks.

Mr Stuut will publish the final results of his investigations.

7 Object Code Technology.

The concept for the development of Object Code Technology originated from the consideration of the functionality of early compiler programs. Essentially, most compilers are derived in one way or another from Eniac, which was the original computer. Eniac basically had the functions: add, subtract, multiply, divide, and time and date. Research by MFX Research showed that it did not matter what compiler was involved, whether COBOL, FORTRAN, C++ or even VB, compilers all had common characteristics.

This finding was the critical breakthrough in the development of the functionality of Object Code Technology.

Obviously the best area to attack the Y2K problem was the one site that was common to all computers, - the object or machine code level. It did not matter what language a program was written in or whether it was single or double byte, after compilation all programs existed as a universal mathematical function.

By attacking the Y2K problem at the machine code level, operating systems and applications could be evaluated in a clinical and objective manner. There would be no need for reliance on software vendors' opinions.

The new methodology had to provide an objective and reliable evaluation of Y2K vulnerability and to deliver a solution.

-- Lewis (aslanshow@yahoo.com), November 23, 1999.

Part 2

The new methodology had to provide an objective and reliable evaluation of Y2K vulnerability and to deliver a solution.

The following criteria had to be satisfied:

? Universal in Application ? No requirement for source code ? Identify all short date formats ? Be able to distinguish Y2K volatile from non-volatile dates ? Fast ? Change short date formats in O/S, Applications as well as data files ? Cause no change in the file check sum ? Cause no change in file functionality ? Not precipitate legal problems relating to Copyright and Warranty

It was appreciated that existing tools could not evaluate operating systems and could only 'test' applications by scanning the computer registry to identify Applications on the system by their EXE files. These identified files were referenced to a database that contained the Software Vendor's assessment of the compliance of the application. These opinions have been shown to be unreliable.

In addition, some conventional Y2K tools included cell-scanners, which assessed dates (as text) within cells in a database or spreadsheet. Some do evaluate the application. Most however, ignore the fact that dates may also be held by:

? References to files in the Application i.e. RI files, MDB files and DLL files. ? References to the System Settings. ? References to background VBA code.

Six months of R & D resulted in the development of a series of algorithms called DaM (Detect and Modify), which are the basis of Object code technology. DaM was further refined resulting in MFX 2000, an automated Y2K tool that was language and source code independent.

Object Code Technology introduced, for the first time, a clearer definition of Y2K Compliance: "The global use of 'yyyy' to define all year definitions in operating systems, applications and data".

MFX Research has been able to identify 40,000+ basic short date structures at the object code level. The overall number of formats is significantly greater when all possible variations are considered.

Object Code Technology searches and enters all electronic files at the machine code level, to identify any short date formats, calls or references. There are eight levels of data filtration. Any file, be it data, text, source or complied, may be entered, as long as there is an ability to read the relevant file. The program is looking at ".exe", ".dll", ".com" or ".pif" files or wherever an application is compiled. Any short date formats identified can be subsequently changed to long date formats. MFX 2000 will scan through source code but is not designed as a source code scanner.

The MFX2000 Program excludes those files used in the Windows environment, which hold date formats that are never actually referenced. These files include Help files, animation files, AVI files, wave files (sound files) and the various picture formats bmp, .tif, .gif, .jpg and .ico etc. MFX 2000 Audit will not scan .cab or .zip files, as these are compressed files that are usually put onto drives to install an application or a platform.

8 Impacts of MFX 2000 on O/S, Applications and Data Files

Positive Impacts.

MFX 2000 will supply a comprehensive list of files using short date formats, identifying the individual formats. Vendors of identified files can be questioned on the Y2K compliance of their files.

MFX 2000 will remove any non-string based short date usage from a system and ensure that long dates are consistently used.

This has a number of benefits:

? Corruption of O/S and Applications is prevented ? Data will use long dates ? Date calculations will be accurate

In addition:

? Windowing will not be required ? Application date based errors will be removed ? Operating system date based errors will be removed ? Default settings can be over ridden ? User control over date management of a system

Negative impacts.

No detrimental effects of the implementation of MFX 2000 have been identified in testing and consumer feedback during the last twelve months.

Any negative aspects to the technology are not related to the underlying effectiveness of the software but rather limitations of the user interface. These are issues of nuisance and not of limitation of the basic technology and are fully documented in the products FAQs.

9 Conclusion

This paper has been written to discuss two questions:

i) The functionality of Object Code Technology (OCT).

It has been demonstrated that OCT can correct short date formats in computer operating systems, applications and data files.

The functionality and stability of OCT has been proven by tests conducted by a number of third party institutions and no negative impacts of the technology on operating systems and applications have been identified. These findings have been supported by tests and case studies conducted by numerous customers of the MFX2000 product.

ii) Will short date format usage lead to the corruption of operating systems and applications post the Year 2000?

MFX Research has put forward the hypothesis that the usage of short date formats in applications and operating systems will lead to the corruption of applications and subsequently of operating systems.

The bases for the proposition have been discussed.

MFX Research has demonstrated that there is pervasive usage of short date formats in Microsoft Windows and applications despite the usage of Microsoft patches.

In-house studies by MFX Research support the proposition but a comprehensive third party study is being conducted in Rotterdam to test the hypothesis. This test has been running for many weeks and is almost complete. Preliminary results are proving our hypothesis.

MFX Research October 1999

-- Lewis (aslanshow@yahoo.com), November 23, 1999.

Here is a hot link to the original post

posted by

-- Brian Bretzke (bretzke@tir.com), November 21, 1999.

 Seeking testing conclusions, Programmers/Engineers

I was looking for this sucker to but couldn't find it.

Good work BB

-- Brian (imager@home.com), November 23, 1999.

Should have an 8 page executive summary from Rotterdam by the end of the week. Entire report will be available for a substantial fee. I'm stuck in a non-disclosure agreement with our Y2k Think Tank, but can say the results aren't very encouraging for anyone who depends on a PC or desktop. Will post the Rotterdam exec summary here if it doesn't have a non-disclosure. How many short dates did you find on the free audit Lewis?

-- Brian Bretzke (bretzke@tir.com), November 23, 1999.

I have been following the MFX2000 program and i too have experenced problems with my windows system. I have been looking for the Rotterdam report for a Month ever since Brian and a few others posted the thread. Can anyone locate the Rotterdam Report?? I went to NATO site and mfx2000 was listed as approved for level 4 problems. I'm getting really worried that all of the doomers might be half right :(

BLUE

-- blue (bluefish@thepond.com), November 23, 1999.

Ok, MAYBE that could happen. But we've been running a Y2k test lab dated 2000 for about a year, now, and everything is ticking along just fine. There must be about a thousand forward-dated PCs per each forward-dated mainframe; wouldn't we have heard SOMETHING by now about corrupting OSs?

I don't have time to peruse this report, but my salesman-alert is going off big-time. The fact that I can scan for and find a bunch of nn/nn/nn format strings inside an executable is no evidence, all by itself, that anything is going to go wrong in there. Many compilers embed COMMENTS, for cripes sake, inside executables, and you can find them with a text scan. The Univac linker (@Map) used to show the mm/dd/yy assembly dates of linked modules, not that the executing code gave a rip, and you could find it in a dump if I recall right.

If error traps aren't written to handle a date-specific exception, the general error handler will get it, and he'll abort the job and hand it back to the OS, right? Or is a date-related error going to somehow skirt the exception handling logic in general?

So, MAYBE there's something here, but I don't buy it.

-- bw (home@puget.sound), November 23, 1999.

bw,

@MAP, that brings back some memories. I worked for Univac back in the old days as an OS 1100 Internalist (catchy title, had to wear a 3 piece all the time)

-- BH (bh_silentvoice@hotmail.com), November 23, 1999.

Looks like there's a lot of BS is this white paper. It sounds like they are suggesting that applications and operating systems are slowly re-writing themselves over time. Ridiculous. An application or operating system might become unstable as errors are encountered, but rebooting will fix that. The errors will not permanently infect the application and operating system.

Also, just because data (or an application) contains 2-digit years, that does not mean it will automatically fail. Furthermore, executable files (or DLLs) may contain two-digit years for reasons that have nothing to do with functionality - ie, no reason to assume it's a problem.

I couldn't read through this whole thing because of all the BS, but I sure wouldn't buy anything from these guys.

-- Another Programmer (notmy@address.com), November 23, 1999.

Hi BH, yeah, Coarse Scheduler and all that. We had an OS with a million lines of code, and now Bill uses what, 50M for windows?

ECL, by golly, @ADMLP, @ACOB, @MAP and go. Wheeee! And if you want file space, you just @ASG, you don't hafta say how long the records are, or what cylinder to put them on, or the middle name of your firstborn or anything. What a honkin' OS, and then you come down to IBM with a JCL that hasn't moved noticeably since my 360/20 in 1974.

-- bw (home@puget.sound), November 23, 1999.

I downloaded the MFX200 Audit Program last night and after several hours I found out that 3.6% of my 11,641 files have the short date.

This is after I just bought Win 98-2nd Edition, Microsoft Word 2000, the Quiken2000 upgrade, a new motherboard, and several Y2K fix programs. I received the Microsoft 2000 Analyser disk and found only a few files that need patches. I thought that I was basically done!

Now I have to buy the MFX2000 fix program? WRONG.

My new plan is to copy all the financial files that I might need, print out the documents I might need, and do no more. I've had it.

I read somewhere that Alan Dershowitz has never used a computer and he writes thousands of pages daily by hand!

If at some point in time, this PC shuts down, I will give it a decent burial and change my handle to CantSayDershowitz!

...buying lots of pencils with erasers.

-- Cant Say (Chicken@NoWay.Com), November 23, 1999.

An interesting snippet from the MXF website. Apparently MS thinks

it works, although the concept of errors accumulating with every

date transaction isn't referred to in this piece from about a year ago.

My audit found 6.5%. Gotta run, more tommorow...

[Snip HTML mess--per poster request--Lewis will post correction tomorrow--Sysop]

-- Lewis (aslanshow@yahoo.com), November 23, 1999.

bw,

thought about this last night, I see from your @ADMLP that you used that good ole' DMS1100. My forte was more along the lines of @MASM @PLUS and the all time favorite from that box, '$!' (if not familiar with the 'dollar bang' it was the big box equivilent of Ctl- Alt-Del...

Thanks for the trip down memory lane.... (@ASG,A @ASG,T @CAT, and the ever favorite @ED !!!!!)

-- BH (bh_silentvoice@hotmail.com), November 24, 1999.

I am not a programmer and am wondering where these errors accumulate and where they are stored when the computer is shut down (data files, DLL's, program files)? Does anyone know?

-- Danny (dcox@ix.netcom.com), November 24, 1999.

The First Public Summary of the Rotterdam report is now available for downlandingfrom www.y2000c.com It is very preliminary, dealing only with the standard,sequential sysmark automated tests, and it is extremely difficult to decipher. More testresults with a more complex use patern are promised by the middle of December. Test results comparing the performance of standard systems that have all manufacturers patches with patched systems that have also been remediated with MFX2000 indicate:

1. Average Sysmark speed ratings were essentially the same for remediated and unremediated systems; 2. The performance of both systems (in terms of application runs that could be made) dropped percipitiously over an eight week period, but the drop was much faster with the unremediated system through week 8 of the tests for the 32 bit system; 3. The reason for the lower number of runs appears to have been that the number of fatal errors in the unremediated system were 50% greater than those in the unremediated system.

-- Richard (richard@y2ksolutionsltd.com), December 01, 1999.