When you upgrade your network to Windows 2000, your hardware's compatibility with the OS isn't your only concern. You also need to thoroughly test the software that you've deployed throughout your enterprise. Many systems administrators request that their company dedicate one or more of its most experienced users to work with the software in the test lab. Never assume that if the software launches properly, everything is operating correctly. Instead, take each feature of each application through its paces.
One problem you'll probably encounter is that some software applications have features that don't work when the software runs on Win2K (e.g., specialized accounting software, which is a vertical package designed for specific industries). Even Microsoft applications experience this problem, and typically the cause is the Win2K registry's stricter permission levels (i.e., software that runs on Windows NT might not be able to access the Win2K registry when the application calls specific features). For example, the Microsoft Office 97 spell checker doesn't work on a Win2K desktop because the feature can't access the necessary registry subkey. In this case, use regedt32.exe to go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Proofing Tools\Spelling, and edit Users permissions to permit Set Value and Create subkeys. Check with Microsoft (or visit the Microsoft Knowledge Base at http://search .support.microsoft.com/kb/c.asp) for other application problems of this nature.
Resolving Incompatibility Problems
If some of your applications don't run well (or at all) under Win2K, you can easily fix the problem in many cases. The solution is to trick the software into believing that it isn't running on a new and different OS.
Win2K's Application Compatibility (apcompat.exe) tool helps you perform this sleight of hand. Microsoft designed apcompat.exe to convince software programs that perform compliance checking that they're really running on an earlier OS. This trick works more often than it fails. For example, I used apcompat.exe for two programs that originally failed. The error messages explained that the programs wouldn't run because they were designed to run under NT Service Pack 3 (SP3). After I used apcompat.exe, I got both programs to run in less than 2 minutes.
Installing Apcompat.exe
To install apcompat.exe, open the Win2K CD-ROM and go to the \support\tools folder. Double-click the support.cab file object, and drag apcompat.exe onto the desktop. (You can also complete Win2K's tools installation procedure, but the first method is quicker.) Drag w2rksupp.chm, which is the Help file for all the tools in the \support\tools folder, onto the desktop. You'll need this file when you click Help in the apcompat.exe dialog box.
Using Apcompat.exe's GUI
Apcompat.exe is available with both a GUI and a command-line interface. To use apcompat.exe's GUI version, open apcompat.exe to display the dialog box that Figure 1, page 164, shows. Enter the path to the program you want to test for compatibility, or click Browse to find the executable file object. Click OK. If the program runs and all the features work, you don't need to use apcompat.exe. To test your installation, use the Setup.exe program in apcompat.exe.
If the program doesn't work, enter its path again in the Application Compatibility dialog box and select the appropriate options to resolve the problem. Sometimes an application's error message helps you decide which option to try first. For example, a common error message tells you that the program requires an earlier Windows version to run. This error occurs because the programmers hard-coded that information into the executable file when a particular OS was the current version. Another common error message is that not enough disk space is available to run the program, even though you know you have gigabytes of free space. You might receive this message when Win2K doesn't support the data type that an application uses to read available free disk space.
Solving OS-version incompatibility. Use the Application Compatibility dialog box's Operating system selections to resolve an application query for an OS version that fails when the response is Win2K. The query and resulting failure typically occur during installation but also can occur when you launch the executable file if the program exists on a computer you upgraded to Win2K from an earlier OS.
The query for OS version doesn't necessarily mean that the application won't install or run on Win2K. Rather, the query might mean that the application isn't programmed to accept the response to the query. Your solution in that case is to convince the software that it's running on an OS other than Win2K. To do so, select the OS on which the application ran previously, then click OK. When the program checks the OS version, the system returns that OS. To perform this operation, Win2K creates registry entries that provide the data that the program wants to see when the executable checks the registry during the launch.
Solving memory-management problems. Microsoft made some changes to how Win2K manages memory as compared with earlier Windows versions. If errors occur when you run a program on Win2K but didn't occur when you ran the program on your earlier OS, try disabling the heap manager to free the memory that the program reserves. To do so, open apcompat.exe, enter the path to the program, and select the Disable Heap Manager on Windows 2000 check box.
Win2K's heap manager allocates memory to the subsystem APIs, executive components, and device drivers and automatically expands and decreases amounts of memory for programs as needed. Disabling the heap manager lets you avoid memory conflicts with the affected program, although you'll lose some of the efficiency that Microsoft built into Win2K because the feature is part of Win2K's improved memory management.
When programs use the heap manager, the OS runs internal validation checks that either keep processes running smoothly or produce error notifications. If a program doesn't use calls to the heap manager, you won't have a problem. Problems occur when the program makes calls to memory functions that conflict with the heap manager.
Changing the temp path. Some programs limit the number of characters that they use to store the path and name of the temp folder. However, the number of characters that identifies Win2K's Temp folder might exceed that limit (e.g., \documents and settings\usernamelocal settings\temp). If so, select the Use pre-Windows 2000 Temp path check box from the Application Compatibility window's dialog box to specify a temp folder that is different from the default Win2K Temp folder (and that has a shorter path, such as C:\temp). The application will use the new temp folder, which apcompat.exe creates if the folder doesn't exist.
Adjusting disk-space detection. An application might use a data type that Win2K doesn't support to query and read the amount of free disk space available on your computer. Data types vary by programming language, but the process for detecting available disk space is the same. The application sends a query and uses (and expects) a particular data type for storing the response. For example, data types in Visual Basic (VB) and C could include Real, Float, Integer (Int), or Double Integer. Even Microsoft SQL Server-based applications use specific data types, such as Tiny, Integer, or Bigint.
If an application uses an incompatible data type, the application might receive a response that says 1.4GB of free space exists but misinterpret the response as another number. When the Win2K data type doesn't match the data type that the application supports, the application might incorrectly determine that sufficient disk space to install, run, or perform a specific operation isn't available. (Remember that before Win2K, support for extremely large drives was sparse.) You can select the Correct disk space detection for 2-GB+ drives check box in the Application Compatibility dialog box to resolve this problem.
Making successful resolutions permanent. If any of the above methods work for your application, select the Make the above check box settings permanent check box in the Application Compatibility dialog box. This selection writes the settings to the registry so that they're available whenever you run the application. If none of the solutions work, you'll need to update the application for Win2K.
Using Apcompat.exe's Command-Line Version
If error messages provide a clue as to why an application won't run on Win2K, using apcompat.exe's command-line version to resolve compatibility problems is faster than using the feature's GUI version. To use the command-line version, open a command prompt and enter
apcompat \[-v <version name>\] \[-x <program path>\] \[-d\] \[-t\] \[-g\] \[-k\]
The parameter -v version name specifies the name of the OS you want to return to the program. You enter the following numbers to indicate version name: 1 returns NT 4.0 with SP3, 2 returns NT 4.0 with SP4, 3 returns NT 4.0 with SP5, 4 returns Windows 98, and 5 returns Win95.
The parameter -x program path specifies the path and name of the executable file for the program you want to test, and -d disables the heap manager. The parameter -t assigns C:\temp as the program's temporary folder. The parameter -g corrects disk space detection, and -k permanently stores the settings.
For example, when I first launched a program named MedAccnt (a medical accounts-receivable package) after I upgraded to Win2K from NT 4.0 with SP3, I received the error message This program requires Windows NT. I entered the command
apcompat -v 1 -x c:\medaccntmedaccnt.exe
and the program ran without error. I reentered the command and added -k to write the settings to the registry to make them permanent. I then called the software company and suggested that it stop hard-coding OS versions in its program.
When you use apcompat.exe's command-line version, I suggest using one parameter at a time because using two parameters can involve a lot of permutations and combinations. However, if you do need to use two parameters, apcompat.exe's GUI version is easier to use than the command-line version and is probably a better choice.
Testing 1, 2, 3
Whether you use apcompat.exe's GUI or command-line version, spend the necessary time to test every inhouse, proprietary, or legacy application you have. As you run your software compatibility tests, follow these guidelines:
- Test the highest-priority software in your network. Users and management are probably more concerned about whether the company's accounting program works on every machine than about whether a favorite Help desk utility performs well.
- Besides testing clean Win2K installations, test client-based software on client computers that you upgraded from NT and Win9x.
- Test server-based software on servers that you upgraded from NT as well as on servers with new Win2K installations. Also test server-based software from clients that represent all the platforms you'll have in the enterprise while your Win2K rollout proceeds.
- Test databases for multiple simultaneous access, including access from mixed-client platforms.
- Test printing from mixed-client platforms.
- If you have crucial software applications that are older, highly customized, or were built inhouse, design tests that are as grueling as possible.
Although the permutations you need to experiment with might seem endless, your time investment is minor compared with the consequences you might endure if your CEO can't get today's balance sheet. Apcompat.exe is a systems administrator's first line of defense in a Win2K deployment.
