Last week's Windows 2000 Pro UPDATE carried instructions on how to check the product version on ntoskrnl.exe to determine whether you have Windows 2000 (Win2K) preview code or a full production copy. Those instructions were incorrect. To determine which version you have, run winver.exe and look for an expiration date below the copyright notice. You can also check the license agreement file (eula.txt), which has different language for the preview and full production copies.
It turns out that the information on decimal numbers (build 2195.1, .2 or .3) denoting different versions was wrong. Here's an official comment on the topic from a Microsoft product manager: "The version number field \[has\] four groups of digits. We use the first three for major version, minor version, and build number. At various times, we've used the fourth field for 'incremental updates'... I think we did this for Beta 2 for Windows 2000, for a few last-minute changes. Windows 9x also uses the fourth field in this way for its beta and final releases. However, for Windows 2000 final builds, we did not use the fourth version number field for incremental builds, we changed the whole build number. The default in the build version numbers just set this to 1. It could have just as easily been set to 0, or for that matter, any random number. The bottom line is that the .1 you see is the final code—but has nothing to do with the time bomb."
Given this information, it's easy to see how the story spread about different decimal versions—people observed that Microsoft had used different decimal versions in other OS releases (and probably Win2K Beta 2), checked the product version property of ntoskrnl.exe, and jumped to conclusions. In fact, if you check the version codes for all your system files (Explore My Computer, drill down to C:\winnt\system32, select View, choose Columns, and check Product Version, then scroll as necessary to display the version codes), you'll find that the codes vary widely.
The information about different decimal versions seemed to make perfect sense given the earlier use of the version codes—and it also seemed to fill a real need. It's one thing for me as an individual end-user to check whether I'm running preview code with winver.exe; it's quite another thing for an administrator to check every workstation on the LAN. We really ought to be able to check versions—if not with the version codes, then with a Registry setting or some other system property. That's no excuse, though, for getting the story wrong—and I apologize!
Ready for Windows 2000 Certification
Yesterday, I spoke with Marc Zasada of Veritest, the company that Microsoft has contracted with for Windows 2000 (Win2K) application certification testing. Interestingly, the actual certification is "Certified for Windows," without specifying a version number; however, Microsoft requires only certification for Win2K (additional options are available to certify products on Windows NT and Windows 9x).
Zasada shared the top reasons developers have trouble certifying their applications: failure to test the Advertised Installation option and associated Microsoft Installer (MSI) files; improper version checking that doesn't handle future OS versions; inadequate long printer name support; applications failing with the high-contrast accessibility option; inadequate long path and filename support; and applications not handling standby and suspend modes properly.
Zasada added that the certification program isn't just for commercial applications: "\[The certification specifications\] are good rules to follow, even for internal line-of-business applications. Using the windows installer properly can have a big payoff for large-scale enterprise applications by resolving DLL Hell issues, alone!" For more information, click here.
I recently solved a recurring problem with my otherwise reliable Hewlett-Packard Laserjet IIP Plus. The printer has only 1MB of memory and has a nasty tendency to lock up with Error 20 if I send pages containing complex graphics at Win2K's default printer resolution of 300 dpi. Setting the graphics resolution to 150 dpi solves the problem, but I had to remember to set the resolution before printing each document. I've now changed the default to 150 dpi. To change the resolution default (or any other default printer property), click Start, Settings, Printers. Right-click the printer you want to use and select Properties, Printing Preferences, Advanced. Set your default resolution setting, and the next time you print a document, your new defaults will be in place.