Microsoft continues to lose the war for Y2K compliance. There are now 393 Microsoft applications that have had Y2K status changes since December 1. This includes some applications that recently finished testing. Of these 393 applications:

53 are rated compliant, 11 cannot be made compliant, 159 need updates that aren't available yet, 76 need new updates that are available, 4 don't process dates, 4 are considered compliant "with acceptable deviations", and 76 have changed status from compliant to "under revision".

Among the products which require updates that aren't available yet, are Excel 95, Excel 97, Excel 2000, and all versions of Office 2000. Windows Media Player used to be listed as compliant, now it's "under revision". This is a component of all recent versions of Internet Explorer.

There are also new Y2K updates for Windows NT that have been released in the last few days.

This is as of 10:00 am today,12/9/1999. With the recent pace Microsoft products falling off their "compliant" list, you will likely find a different number if you go to http://www.microsoft.com/technet/year2k/product/product.asp and do a search.

There are another 34 products on the "yet to be tested" list, some of which used to listed as Y2K compliant.

Bootom line: if you use Microsoft software on your PC or server, you are probably not Y2K compliant, even if you thought you were and verified that with Microsoft as recently as 10 days ago.

-- Jerry Heidtke (jheidtke@email.com), December 09, 1999

Answers

Gates and his silver bullet, indeed. Definitely distribute this to the faction of DGIs who think MSFT has been holding out with the fix.

Thanks, Jerry.

-- lisa (lisa@work.now), December 09, 1999.

I upgraded to Office 2000 last week after the salesman said Y2K compliance was a major feature. Curiously, nowhere in the external packaging is Y2K even mentioned. I shall run Check 2000 and see what it says about it.

-- Jonathan Chevreau (jchevreau@nationalpost.com), December 09, 1999.

HEY!!

Aren't you concerned that articles like this might confuse the pollies and DGI's?

-- Familyman (prepare@home.com), December 09, 1999.

No, no, no, you're getting it all wrong. The rules have been changed, "compliant" now just means "still expect to get it fixed before 1/1/19002000"

-- Servant (public_service@yahoo.com), December 09, 1999.

Microsoft 2000 products NOT 2000 compliant??? LOL!

In the next week, I have to make compliant Windows 95 Release 1 (16 bit) on my daughter's Acer, and Windows 98 on my Gateway. Microsoft's Website for Y2K is confusing as all heck.

Where does Gates get the Chutzpah to sell Office 2000 that is not Y2K compliant???

-- K. Stevens (kstevens@ It's ALL going away in January.com), December 09, 1999.

Link please.

Thank you!

-- Bayou Boy (BayouBoy@bayou.com), December 09, 1999.

To win a war, one has to take it seriously. Since quality, customer satisfaction, and documentation are last on Microsuck's list of priorities, this is no surprise to me.

Much as I dislike government meddling, I hope gov chops Microsucks into mincemeat.

-- A (A@AisA.com), December 09, 1999.

Is there a link to this somewhere? Not doubting it, just would like to see a link. I've got friends with stock in MS and they would like to see this in black and white, other than here.

Thank you!!

-- Familyman (prepare@home.com), December 09, 1999.

For the people asking if there is a link to the above information:

This isn't a quote from an article somewhere. I wrote it myself. The data that I based the posting on is available on Microsoft's web site at http://www.microsoft.com/technet/year2k/product/product.asp

Anyone willing to make some small effort will be able to confirm everything stated above. If anyone does try to navigate Microsoft's Y2K information and has trouble finding out what they need to know, they can email me or post a message here. I'll try to help, as time permits.

I'm responsible for PC and server remediation for a large mid-western corporation. Microsoft, by it's failure to take Y2K issues seriously a long time ago, by it's failure to actually test it's applications (it waits for customers to report problems instead), and by it's generally lax attitude towards quality control, has made it impossible for any large organization to truthfully claim that their systems have been completely remediated in regards to Y2K.

-- Jerry Heidtke (jheidtke@email.com), December 09, 1999.

Microsoft is SUCH a pain! I've spent countless hours updating my two personal pc's (home business) and am now trying to upgrade my mom's Window's 95 again (thanks for the post about Win95 patch being upgraded - again!!!).

If anyone is doing last-minute patches, you might want to check out http://www.windowsupgrade.microsoft.com which has other critical updates that aren't mentioned with MSN's Product Analyzer compliance list - both lists of patches need to be downloaded and installed in order for "compliance" to be achieved.

If somebody knows a better way to do the patches, please let me know. I'm tired of banging my head against a wall working with MSN's site. Thanks!

-- Deb M. (vmcclell@columbus.rr.com), December 09, 1999.

Sorry, also forgot this link for MSN's Product Analyzer download site:

http://www.microsoft.com/technet/year2k/pca/pca.htm

-- Deb M. (vmcclell@columbus.rr.com), December 09, 1999.

Just a quick update as of noon today (26 hours after the above statistics were gathered).

Number of Microsoft products

with Y2K status changes since 12/1: 495 (up from 393).

which require updates that aren't available yet: 195 (up from 159).

which require updates that are available: 95 (up from 76).

that cannot be made compliant: 19 (up from 11).

considered compliant "with acceptable deviations": 19 (up from 4).

Way to go, Bill....

-- Jerry Heidtke (jheidtke@email.com), December 10, 1999.

Jerry,

Hello. I'm hoping you could clear up some confusion, please. I've a few different versions of Jet database on my computer - don't ask me how I ended up with three versions, I just do... (3.000.2908, 3.51.3328, and 3.52.3328) and all are on my c:\WINDOWS\SYSTEM file. The 3.000 is NOT compliant, but the 3.51 and 3.52 are compliant. Does the 3.000's non-compliance matter in this instance?

When I've tried to download the patch for 3.000 I hit a snag in the installation. The computer asks me which file I want to put the patch in, and I have no idea where it's supposed to go.

Thanks for any advice you can give me!

-- Deb M. (vmcclell@columbus.rr.com), December 11, 1999.

Deb,

Having the 3.0 version of the Jet database engine on your system will probably not affect the compliance of any applications that use the Jet database. Most applications are designed to use the most recent version. It's possible that an application was designed to use a specific version.

In order to find out if this is true in your case, just rename the 3.0 Jet database engine (Msjt3032.dll) to something else, and run all your applications. If they all work fine, you have no problems. If any of them complain about missing dll's, then you'll either have to upgrade the application, or upgrade Jet 3.0 to version 3.000.4513 or later.

Upgrading the application would be a better choice, since any program that old would be likely to have other Y2K issues.

The Microsoft page that has compliance information and remediation steps for all version of Jet is http://www.microsoft.com/technet/year2k/product/user_view69954EN.htm

Hope this helps.

-- Jerry Heidtke (jheidtke@email.com), December 11, 1999.

Jerry,

Thanks! I re-did the download and pointed the file towards the c:\WINDOWS\SYSTEM file (Duh! I shudda thought about that one...) and the patch took...

Next question (please, please) is about Visual C++. I've gone to the site and downloaded the Intel versions - I still can't get the 4.1 to compliance. The 4.2 version is fine though - no problems getting that to compliance. (Also, I'm using Win. 98 on this system. I don't understand why I'm using a file from '95 (Tools_95), do I need to download a Windows 95 O/S patch too?

Here's the print-out. Thanks again!

Visual C++: MFC 4.1 (English) Location: c:\Tools_95 Status: Compliant (prerequisite required) More Info: http://www.microsoft.com/technet/year2k/product/user_view72061EN.htm Action: The product is compliant. User action is recommended, which may include loading a software update or accessing shared technology.

-- Deb M. (vmcclell@columbus.rr.com), December 11, 1999.

Deb,

I guessing that this system was upgrade from Windows 95 to Windows 98, and that the Tools_95 directory contains some older utility programs for Windows 95. Again, you probably don't have to worry about this.

To quote Microsoft: "Version 4.10.6140 of MFC40.dll and MFC40u.dll are needed for applications that use DLLs in operation to properly work past 1999. To update your machine to these versions of the files please go to http://msdn.microsoft.com/visualc/downloads/MFCy2k/default.asp. These versions of MFC40.dll and MFC40u.dll are also included in Windows 98 Service Pack 1, Windows 98 Second Edition, Service Pack 3 for Visual Studio 6.0 and Windows Update. The update at http://msdn.microsoft.com/visualc/downloads/MFCy2k/default.asp can update Windows NT 3.51, Windows NT 4.0, Windows 95 and Windows 98."

What you probably have are multiple copies of these DLL's on your system. Use the "Tools...Find..." feature in Windows Explorer to find all the copies of these two DLL's. Make sure that the ones in C:\Windows\System are the most recent, Y2K-compliant versions, and then delete the rest. Any application that uses these DLL's will find them in C:\Windows\System automatically.

-- Jerry Heidtke (jheidtke@email.com), December 11, 1999.

I jokingly told Ken Decker in the Chat Room once that he will need to download his final patches for MS on Dec. 31, 1999 @ 11:45. Sometimes I hate it when I'm right.

I keep putting off down-loading the "next set" of patches I need, because of the constant updates. I have naively updated everything (only about 50 pcs) twice already once almost a year ago, and once recently. I get antsy when I'm not doing something about a "known" issue, but with MS "DELTA Website", I will probably be forced to wait till the last minute.

Even if Win2000 was completely "compliant" I would not be able to take advantage of it. The interdependencies between my Network SW, our ERP systems and our Misc Desktop Apps, have not been vendor approved for interface with MS 2000 (MS '00);-)

The more complex your systems the more difficult it becomes to upgrade/change any piece in the chain.

-- (karlacalif@aol.com), December 11, 1999.

Jerry,

"What you probably have are multiple copies of these DLL's on your system. Use the "Tools...Find..." feature in Windows Explorer to find all the copies of these two DLL's. Make sure that the ones in C:\Windows\System are the most recent, Y2K-compliant versions, and then delete the rest. Any application that uses these DLL's will find them in C:\Windows\System automatically."

Thanks again for your help. One last question though - if I delete the non-compliant DLL file, will the dependent application be smart enough to switch to the other, different version Y2K compliant, DLL file? I'm concerned that the dependent application might have the DLL's version specified in the code - if I deleted the non-compliant version, the application would crash, not switch to the updated version...

Thanks again, I very much appreciate your help.

-- Deb M. (vmcclell@columbus.rr.com), December 11, 1999.

Deb,

I've never heard of a Windows application looking for a specific version of a DLL in order to run. I have seen applications that make sure that the version of a DLL loaded is at least some minimum version.

If you had a program that depended on a certain down-level version of a DLL, you would already have problems. These are DLL's that many application use. Once a particular version of a DLL is loaded by a program, all other programs that use that DLL will use the same version, until Windows is rebooted. So, you can see that depending on what order you run applications, different versions of a particular DLL might be used in each session.

The order that an application looks for a DLL when it's needed is: 1. A previously loaded instance of that DLL. 2. An explicit path hard coded in the application. 3. The working directory of the application. 4. The location of the executable program that launched the application. 5. The Windows System directory 6. The Windows directory 7. The locations specified in the PATH environment variable.

If an application doesn't find a DLL in one location, it keeps going down the list. So, you can see that by having all your main DLL's in the Windows System directory, and deleting duplicates located elsewhere, you have maximum control and consistancy in your environment.

Again, if you're nervous about deleting a copy of a DLL, try renaming it. For example, rename MFC40.DLL to MFC40.OLD. Then, if your program has a problem, it's easy to change it back to the original name.

-- Jerry Heidtke (jheidtke@email.com), December 11, 1999.