Don't Rush to Climb On Win2k Bandwagon
The Microsoft Windows 2000 operating system brings many incremental improvements to test applications, but you needn''t hurry to buy a copy.
Rick Nelson, Senior Technical Editor -- Test & Measurement World, 4/1/2000
So, if you’re a power user with a 133-MHz or faster Pentium-compatible CPU, at least 64 Mbytes of RAM, a 2-Gbyte or bigger hard disk with at least 650 Mbytes of free space, you can upgrade your Windows 98 OS for $219 or your Windows NT OS for $149. (Those prices are for the single-user client; server upgrades start at $599.) Don’t rush, though. The immediate benefits of Win2k’s incremental improvements will likely pale before the potential problems that could occur as computer vendors, test-and-measurement software publishers, and PC-compatible instrument makers adjust to the transition:
• Win2k lets Windows 98 users upgrade from FAT or FAT32 file systems to NT File System (NTFS), but that process is one way. If you decide to revert to Windows 98 after moving to NTFS, you’ll have to reformat your hard drive and perform a clean installation of your old operating system and all your applications.
• The Win2k upgrade itself is also one way. Unlike with Windows 95 and 98 upgrades, you can’t automatically use a control-panel applet to remove Win2k and revert to your old OS and system settings. If you have sufficient disk space and use FAT32, however, you can maintain your Windows 95/98 system and install Win2k in a separate partition.
• Your 16-bit DOS applications or any applications requiring virtual device drivers (*.vxd and *.386 files) won’t work.
• Your old instrument device drivers won’t work under Win2k. You can expect some vendors to need most of the year 2000 to port all their drivers to the new platform. Even if your instruments all have Win2k drivers, you might find that over the next few months you need to buy a specialized instrument that doesn’t have a Win2k driver.
• If you have a DVD drive, you’ll find that your software decoders don’t work, and you’ll have to hope your DVD vendor has Win2k versions ready.
• Any third-party control-panel applets or disk utilities you’re now using won’t work under Win2k.
The Good News
That’s the bad news; there is good news, as well:
• If you do make the one-way jump from FAT32 to NTFS 5, you gain support of hard drives with capacities of 2 Tbytes, and you’ll escape the inverse relationship between disk size and performance that accompanies FAT32. With FAT32, the bigger the drive, the longer it takes the disk controller to locate and retrieve specific blocks of data.
• Win2k combines Windows 98 features such as Plug and Play, power management, and USB and Firewire support with Windows NT features such as dual-processor support.
• If you are using Win2k servers, you can install Win2k clients over a network.
• Win2k clients support peer-to-peer networking with earlier versions of Windows, so you can access application data and peripherals while migrating to Win2k one PC at a time.
• A Unix-services option provides interoperability with existing Unix-based systems so you could, for instance, link Windows-based test results with legacy Unix-based data-analysis applications.
• Win2k servers support MIT’s Kerberos Version 5 authentication protocol for secure single sign-on to Windows resources. You get a high level of security without having to log on each time you access another directory or launch another program. Smart-card support provides additional security.
• On systems with 64 Mbytes of RAM, Win2k runs applications 25% faster than Windows 95 or 98 and is comparable to Windows NT 4.0, according to an independent test lab under contract to Microsoft.1 This evaluation, however, relied heavily on a benchmark slanted toward business applications like Microsoft Office and Lotus Notes. Performance for data acquisition, analysis, and test management may be significantly different.
• Perhaps the most significant benefit is the promise of improved reliability. Microsoft has been touting Windows as a fully 32-bit operating system since the first release of Windows 95, but this time the company seems to mean it. Although you won’t be able to run 16-bit applications under Windows 2000, you won’t experience the system crashes caused by conflicts between real-mode and protected-mode drivers. (With Windows, every silver lining has a cloud: Microsoft plans to ship 64-bit Windows 2000 by the end of the year, but there’s no prediction on how long we will have to wait for a “fully 64-bit operating system” or how mixing 32- and 64-bit programs will affect reliability.)
Improving DLL Reliability
Of particular significance, if you are putting together a multivendor hardware and software test system, is Win2k’s file-protection scheme, aimed at managing dynamic-link-library files. DLLs are blocks of executable code that applications can share. Back when disk space and memory were dear, DLLs were important in saving system resources. If your 5-Mbyte data-acquisition program and 4-Mbyte data-analysis application share a 2-Mbyte chunk of code, the reasoning went, why not put the shared code in a separate file that both your data-acquisition and data-analysis programs could access—that is, dynamically link to—when they run. Instead of requiring 9 Mbytes of disk space, you would need only 7 Mbytes: 3 Mbytes for the data-acquisition program, 2 Mbytes for your data-analysis program, and 2 Mbytes for the shared code.
It’s a great theory. The Unix community eschewed the DLL shared-code concept. It tended to ship large, expensive, reliable self-contained applications, which required large, expensive mainframes, minis, or high-end RISC workstations to run. The DLL approach that Microsoft incorporated in Windows allowed low-cost hardware to accommodate and run low-cost applications. But you get what you pay for, and the price of DLLs’ economy was system stability.
Ideally, multiple applications should share a single instance of a DLL in global memory, so that DLLs conserve memory as well as disk space. But each of multiple processes in Windows runs within its own 32-bit address space, so Windows must map the global instance of a DLL into the address space of each concurrently running application that requires it. The operating system’s efforts to juggle the memory maps, several DLLs, applications, and associated data structures can cause system crashes. Alternatively, Windows may attempt to reduce the memory-map overhead by loading separate instances of a DLL for each application that needs it, but the additional instances take up the additional memory the DLL approach should be saving.
Two Bugs Make a Feature
But the most intractable problem surrounding DLLs has been version control—maintaining a set of DLLs that are compatible with all your applications. The most common problem has been the replacement in the windowssystem directory of one DLL with another having the same name but different version number.
This overwriting of one DLL with its not quite identical twin occurs when an application’s install program replaces a DLL file in your windowssystem directory with an older version that lacks the functionality required by your other applications. High-quality software should at least alert you that it’s about to overwrite a file with an older version, but exceptions are common. Further, you might be so inured to Windows’ many annoying warning boxes that you automatically type OK whenever one pops up, or you may have installed a program that automatically “hits” OK for you.2
In any event, you can easily end up installing old DLLs that are incompatible with new applications. With luck, you might get an error message that suggests which DLL is at fault, and you might be able to find the correct version on a CD or the Web. Then, you can try copying the newer version back into windowssystem. Your application still might not run, though, because simply copying the DLL won’t update system registry, which your errant install program may have modified after installing the older DLL version. When all else fails, you’ll have to reinstall the affected application, or perhaps even the entire operating system.
Such overwriting of new DLLs with older ones is the easiest of DLL problems to fix. Others—which Windows 2000 addresses—are much more difficult. Suppose you buy data_acq.exe 1.0, which comes with test.DLL 1.0. Your installation program will probably copy test.DLL into the windowssystem directory, where data_acq.exe can find it. By the time you decide to buy the companion program analysis.exe, you find that version 2 is out, and it comes with test.DLL 2.0. Your analysis.exe install program copies test.DLL 2.0 over version 1.0, and now your data-acquisition program no longer works!
Microsoft developer Rick Anderson, who has mapped the seven circles of DLL hell3 (actually he has found only three so far), calls this problem “side-effect DLL hell.” This type occurs when, for example, complementary bugs in data_acq.exe 1.0 and test.DLL 1.0 allow the data-acquisition program to access invalid memory locations. The two bugs add up to a feature, but when you upgrade to a bug-free DLL, you’re left with the application bug.
DLL Nirvana
Win2k aims to address DLL-related problems by regressing toward the Unix model of statically linked libraries. That’s increasingly feasible as disk and memory prices tumble. Win2k preserves the DLL concept but facilitates the simultaneous use of multiple versions of a single DLL.
The first step Win2k takes to address DLL problems is to protect the DLLs that ship with the operating system. The Windows File Protection (WFP) feature prevents any install program from replacing a DLL file in the windowssystem directory. DLLs located there can be updated only by installation of a Microsoft service pack.
To deal with other DLLs—that is, those supplied with applications—Microsoft recommends two approaches: Side-by-Side (SxS) components and DLL/COM redirection. Win2k and Windows 98 Second Edition support these schemes; Windows 95 and NT do not. Both schemes involve private DLLs—ones dedicated to a specific application and that reside in that application’s directory or subdirectory, not in the system directory. Microsoft bills SxS as the ultimate release from DLL hell.
Developers of new Win2k applications who follow Microsoft’s SxS design guidelines4 will create private DLLs locked to those applications. Other versions of those DLLs can reside on the same system in other applications’ directories, as long as those DLLs, too, are SxS-compliant. (Note that SxS DLLs are backward-compatible with Windows 95 and NT—just install them into the windowssystem directory.) When an application invokes a private DLL, the operating system loads that DLL directly into the program’s address space.
DLL/COM redirection is an interim approach aimed at improving DLL management among existing components. It lets you selectively isolate each existing DLL so it is available to one and only one application. To activate DLL/COM redirection, you place an empty file with a .local extension (for example, data_acq.exe.local) in the application directory. On encountering the .local file, Windows will search the application directory for DLLs before looking in windowssystem. It does this regardless of any explicit path specification in the calling application or the Windows registry. If Windows doesn’t find the DLL in the application directory, it proceeds to look in windowssystem, the normal repository of globally shared versions of such files
If you follow this approach, you’ll need to thoroughly test your application, making sure to have other applications that use a different version of your DLL running concurrently. If your DLL alters a global state, such as registry entry, for example, then two different versions running concurrently in different process spaces might crash. Similarly, your private DLL may make inconvenient assumptions about where to find other system resources. For example, the private DLL may expect to find in its new home directory (for example, data_acq) components such as other DLLs that remain in its original directory (windowssystem).
With Win2k, Microsoft has addressed many of the problems of the Windows 95/98 and Windows NT families, not least of which is the merger of those families into a single platform for business and technology applications. If your company is acquiring new computers this year, you might find yourself on the Win2k bandwagon, like it or not. If you are staying with your current systems, however, be very cautious about embarking on the upgrade path. Win2k is no panacea. Its DLL management is nice, but not infallible. As Microsoft itself acknowledges, “You must test all components to ensure side-by-side validity . . . since there is no side-by-side enforcement by current operating systems.” 4 T&MW
FOOTNOTES
1. “Windows 2000 Performance Test,” ZDLABS, Morrisville, NC, microsoft.com/windows2000/guide/platform/performance/reports/zdlabs.asp (downloadable, self-extracting Word file.)
2. RtvReco is one useful program that does this, freeware for download at www.annoyances.org/cgi-bin/ce-showtopic/003_006.
3. Anderson, Rick, “The End of DLL Hell,” Microsoft, January 2000, msdn.microsoft.com/library/techart/dlldanger1.htm.
4. D’Souza, David, B.J. Whalen, and Peter Wilson, “Implementing Side-by-Side Component Sharing in Applications (Expanded),” Microsoft, November 1999. msdn.microsoft.com/library/default.asp?url=/library/en-us/dnw2k/html/sidebyside.asp
You can contact Rick Nelson at rnelson@tmworld.com.
