How NT 4.0 Merges Win APIs...Right!

Robert L. Hummel

When Windows 95 made its debut, Microsoft told programmers the new OS was the path to NT. But developers have learned that various incompatibilities between the two have rendered twists in the road to NT, which may force developers with limited resources to choose between one OS and the other.

Early in the Windows 95 production cycle, Microsoft told developers--in no uncertain terms--that for an application to qualify for a Windows 95 logo, the program also had to run under NT. Microsoft quickly modifie d its position when it became clear that developers would have to eschew all Win 95-specific functionality.

"It's fair to say that the Windows 95 logo requirements have resulted in some confusion," said Phil Holden, Windows NT Workstation product manager at Microsoft. "We're in the process of updating the logo program now to clarify a lot of these issues."

Currently, to garner a Windows 95 logo, an application must be tested on NT. However, a handful of important Win 95 APIs are not supported under current versions of NT. For example, utilities using the Telephony API (TAPI) will not run under NT 3.51.

In theory at least, a Windows 95- or NT-specific program should degrade gracefully under the other system. But Microsoft provides an out when architectural differences prevent it.

Microsoft's effort to establish congruity between Windows 95 and NT was an attempt to mediate its 32-bit OSes' perceived schizophrenia. Although Microsoft claims that both 95 and NT are 32-bit OSes, the products differ considerably in architecture, performance, and user perception. One example of architectural differences is in NT's and Win 95's driver architectures. "When you build a protocol stack in Win 95, you write to the VxD ar chitecture, whereas if you were to write a stack for NT, you would have to write to NT's driver architecture," says Ted Hess, technical director at FTP Software (Andover, MA), which develops TCP/IP networking applications for intranets. "The differences between the two are nontrivial."

"The current thinking is there will be three Win32 products," Holden said. "For high-power installations, we'll have NT Server and NT Workstation. We'll also provide a smaller, more general-purpose desktop such as Windows 95 for the average user."

The grafting of a Windows 95-style shell onto the upcoming NT 4.0 release will reduce perceived differences among end users. But for developers attempting to target both environments, the differences between the two systems make the goal of one 32-bit world seem elusive. In fact, the changes are significant enough that developers are in some cases targeting only one platform.

Kip McClanahan, a programmer at BMC Software (Houston, TX), favors NT. "Windows NT is muc h more robust," he says. "And all the features that might make me want to develop exclusively for Windows 95 are right around the corner in the next release of NT."

Charles Petzold, author and Windows developer, disagrees. "Windows 95 has more market share and more interest among end users," he says.

But Petzold and McClanahan agree that although programming for both environments may require additional effort, it should not require parallel development or a two-team approach. "I would focus my efforts on Win 95, then test under NT," Petzold says. "Then, if something doesn't work, just add a work-around to the NT version."

NT 4.0 will support many of the APIs introduced in Windows 95, one notable exception being dynamic Plug and Play support. But Holden maintains that the situation will quickly begin to resolve itself for developers. "Our Windows 95 development team is now working directly with our NT team. Our goal is simultaneous shipment on both platforms."

---

W in32 APIs: Slowly Converging

Product
                            
Windows
         
NT


Feature
                            
95
              
Workstation


System resource capacity           Greatly         Unlimited
                                   expanded
Runs MS-DOS applications           Yes             Most
Runs IBM Presentation
  Manager (through 1.3)            No              Yes
  and POSIX 1003.1 applications
Multimedia APIs (1)                Yes             Planned for version 4
OpenGL graphics libraries          Future          Yes
  for 3-D graphics                 release
Win 95 user interface              Yes             Planned for version 4
Plug and Play                      Yes             Static in version 4;
                                                   yes in future release
System Policies  (2)               Yes             Planned for version 4
Built-in Uni
versal Inbox
  providing e-mail and fax         Yes             Planned for version 4
Built-in Microsoft Network
  client software                  Yes             Future release
Preemptive multitasking for
  Win16 applications               No              Yes
System completely protected
  from errant                      No              Yes
Win16 and Win32 applications
  NTFS (3)                         No              Yes
Automatic recovery from
  system failure                   No              Yes
Runs MS-DOS device drivers         Yes             No
Runs Win16 device drivers          Yes             No
Minimum recommended RAM            8 MB            12 MB
Typical disk-space requirement     40 MB           90 MB
Runs on PowerPC, Mips,
  Alpha RISC systems               No              Yes


(1) DibEngine, Direct Draw, DirectSound, Direct Input, Reality Lab
     graphics libraries
(2) To provide centralized control over desktop configuration
(3) File system provides complete prot
ection of files on stand-alone
     system (files, folders, and applications can be made invisible to
     specific users).