Previous Table of Contents Next


Whatever level is selected, it is helpful to check whether the organization’s representative systems appear on Microsoft’s Windows NT Hardware Compatibility List. Many major vendor systems intended for business use do appear on the list, although not all. While many systems that have not been certified by Microsoft will run Windows NT successfully, Microsoft will not support these configurations. If a company owns systems that do not appear on the Hardware Compatibility List, IS will have to decide whether to take full responsibility for supporting these workstations running NT. If these systems cannot be replaced, the organization may wish to identify third-party or vendor resources that can assist in maintaining them.

Before beginning testing, make sure the version of Windows NT selected reflects the latest Service Packs introduced by Microsoft. To check for the latest Service Pack — and to download it — visit:

www.microsoft.com/NTServerSupport/Content/ServicePacks/Default.htm.

It is not enough to test Windows NT on stand-alone systems. IS needs to set up a test network that is as representative of the planned network as is practical.

Evaluating and Testing Software

An organization does not need to test software carefully before deploying it widely on Windows NT systems. The following sections describe some of the issues to take into account.

Win16 (Windows 3.x) Applications

Older 16-bit Windows applications will run in the new Windows 4.0 16-bit subsystem, a Windows 3.x emulator sometimes called “Windows on Windows” or WOWEXEC. IS will need to test both the reliability and the performance of applications running on this emulator. IS may also have to determine whether to run these applications in their own memory space (the default setting) or in a shared memory space with other Win16 applications (potentially faster, but one failed Win16 application can crash all Win16 applications running at the same time).

DOS Applications

Many people have discovered that DOS programs will not run in Windows NT because they must address hardware directly. Many other DOS applications will work via Windows NT Workstation’s DOS emulator. If the company still depends on DOS applications, they should be tested carefully. IS may also have to experiment with settings in each DOS application’s Properties dialog box to maximize performance — especially settings in the Memory tab that control the amount of conventional, expanded, extended, and MS-DOS protected mode memory available to an application.

Windows 95 Applications

Even if all the applications are 32-bit Windows applications that utilize the Win32 API, there are a few “gotchas,” including:

  APIs specific to Windows 95 that are not available in Windows NT Workstation 4.0, such as Direct3D, Independent Color Matching, Plug-and-Play, “Flat Thunks,” and the Pen API, as well as these Windows 95 OSR 2-specific APIs: FAT32 File System, DirectX 2, ActiveMovie, and Windows Internet Extensions API.
  APIs that are common to both operating systems but may work differently, including Unicode and some security attributes.

Upgrading Custom Applications

Many companies depend on custom applications originally written for 16-bit Windows 3.x environments. For performance and compatibility reasons, organizations will usually want to port these applications to the Win32 API rather than running them in the “Windows on Windows” emulator.

This is, as programmers say, a nontrivial task. There are significant differences between Win16 and Win32 applications. In the Visual Basic environment, these include differences in naming, treatment of integers, and string routines; deserialized input; changes due to preemptive multitasking; and changes to DLLs. The bottom line: if the company wants to roll out revised Win32 custom applications when it rolls out Windows NT, IS should start updating those programs now.

Identifying, Evaluating and Testing Peripherals

In addition to the PC hardware itself, IS will need to systematically identify all the peripherals and other devices the organization expects to use with NT Workstation or NT Server. Once this is done, IS should review Microsoft’s Hardware Compatibility Web Page for Windows NT (http://www.microsoft.com/ntworkstation/hwtest.htm) to determine whether these devices have NT 4.0 compatible drivers. If in doubt, visit the vendor’s Web site. IS should consider each of the following:

  Video cards
  Video capture cards
  Audio cards
  SCSI host adapters and devices, including CD-rom drives, tape drives, removable media and scanners
  Other (non-SCSI) CD-rom drives and tape drives
  Network interface cards (Ethernet, Fast Ethernet, ATM)
  ISDN adapters
  Modems and multiport serial adapters
  Printers
  PCMCIA (PC Card) devices
  Uninterruptible Power Supplies
  Mice and other pointing devices

If IS is deploying NT throughout the entire organization, then the availability of final-release (not beta) NT drivers should be considered as a prerequisite for future purchases. NT drivers should be tested carefully — especially video drivers that now run in the Windows NT kernel, where they can potentially impact Windows NT’s stability.

Integrating Macintosh Desktops

If an organization has an installed base of Macintoshes that it does not intend to replace with Wintel systems, its testing needs to encompass Windows NT Server Services for Macintosh. Services for Macintosh, a standard component of Windows NT Server, makes it possible to:

  Create Macintosh volumes on an NT Server system
  Support AppleShare, allowing NT disks and folders to appear on Macintosh client desktops
  Support AppleTalk networks, including AppleTalk Internet Routers — eliminating the need to purchase additional routers to support Macintoshes
  Provide file sharing and print services to Macintosh clients


Previous Table of Contents Next

Copyright © CRC Press LLC