OLE in NT 4.0 takes full advantage of NT's built-in security and cleans up
a problem that was frequently associated with OLE applications trying to run as
services under NT: NT's built-in security did not let OLE services communicate
between applications because most applications are launched from a desktop
running in a different security context or winstation from the services. Using
Network OLE, NT 4.0 now allows communication between security contexts.
Kernel Mode User and GDI
Another feature that's way under the hood in NT 4.0 is the
incorporation of the Win32 subsystem into the Kernel. In the past, most of
Windows' core functionality was implemented in three DLLs comprising a library
of callable routines that, in greatly simplified terms, provided the following:
- User: keyboard and mouse input, user interface output (windows, icons,
menus, and so on), and messaging
- Kernel: I/O services, virtual memory management, and task scheduling
- Graphics Device Interface (GDI): bitmaps, fonts, colors, and so on
In the 16-bit versions of Windows, all applications share the same address
space. When Microsoft (actually, Dave Cutler) designed Windows NT, the decision
was to put each process in a separate address space, isolate the Kernel from the
rest of the operating system and create a separate Win32 process for managing
User and GDI objects. Under this design, each application is isolated not only
from the operating system, but also from all its windows, menus, and so on.
Unfortunately, most calls to a User or GDI routine involve a trip through a
client-server runtime subsystem in the Kernel executive. This trip entails a
substantial number of thread transitions and noticeably affects performance. The
NT developers did as much as possible to improve performance and ended up
implementing a couple of optimization techniques: First, they implemented
batching of User and GDI calls, which helps amortize the overhead of the thread
transitions, and second, they implemented caching values on the client side to
potentially short circuit some calls. Figure 1 shows an architectural diagram of
the typical path that a call to NT's User32.DLL takes.
With NT 4.0, Microsoft wanted to add the new shell and user interface
without taking a noticeable performance hit, so the developers decided to move
the Win32 subsystem into the Kernel. The idea was to save some overhead and
eliminate a large number of (expensive) thread transitions. Microsoft then
figured that performance would increase so much that batching and caching would
no longer be required. Unfortunately, tests showed improved performance for User
routines, but GDI routines were slower. The developers put batching and caching
back in and brought overall performance into line with what they were initially
trying to achieve.
Microsoft claims that these changes do not affect system stability, but
many users undoubtedly will adopt a wait-and-see attitude. Figure 2 is the
revised architectural diagram showing the relocated Win32 subsystem. Note that
the client/server runtime subsystem is still present in NT 4.0--a small
CSRSS.EXE still loads CSRSRV.DLL, which is primarily for console applications.
Hardware Profile Support
Another top customer-requested feature of NT is built-in support for
multiple hardware configurations. Although NT didn't get Windows 95's handy
plug-and-play support--it has been deferred back into Cairo--NT 4.0 adds support
for multiple hardware profiles. You can select a hardware profile at boot time,
usually to handle docking stations, external peripherals, and even PC Card
devices (PCMCIA cards with a marketing makeover). PC Cards work fine in NT 4.0
and even have a new Control Panel configuration applet--you just can't hot swap
them. NT 4.0 also doesn't support Advanced Power Management (APM), although it
will obviously respect any hardware settings you have enabled.
Other Features
Now that we've reviewed the most prominent features of NT 4.0, we can turn
to the less earth-shattering ones. Here are a few interesting ones.
- DirectX: The Windows 95 Game Software Developer's Kit (SDK) introduced the
DirectX family of application programming interfaces (APIs) to give Windows game
developers better performance by letting them program closer to the hardware.
Specific DirectX API sets include DirectDraw for high-speed graphics and
animation, DirectPlay for multiplayer communications, DirectInput for handling
game input devices, and DirectSound for advanced audio capabilities such as low
latency and mixing. Although support for the DirectX APIs isn't in the first
beta-release of NT 4.0, the plan is to include these APIs in beta 2.
Unfortunately, the entire spectrum of DirectX APIs may not end up fully
implemented. DirectSound, for instance, runs in emulation mode and uses the
existing NT sound drivers.
- RAS: NT 4.0 also includes revamped RAS support. Changes include shell
integration similar to Windows 95 (where the Dial-Up Networking folder appears
off the My Computer root), AutoDial, the new RAS APIs added to Windows 95 to
support Microsoft Network (MSN) and the Internet Explorer, and new phonebook
APIs that display built-in dialogs for adding and editing phonebook entries. You
can trigger RAS AutoDial by referring to an Internet host name, an Internet
Protocol (IP) address, or a NetBIOS server name that RAS AutoDial has previously
learned.
- Telephony API: TAPI is available in Windows NT 3.51, but only as a limited
subset supporting the functions necessary to make data calls and interface with
RAS. NT 4.0 gains full TAPI support, so NT will now be able to run such
applications as MSN, the Exchange Client, the Internet Explorer, and various fax
applications. Unfortunately, both MSN and Microsoft Fax--including the fax
printer driver, shared fax modem, viewer, send fax wizard, and exchange
extensions--are not shipping with NT 4.0. Also, some telephony applications such
as Microsoft Phone, need additional support for Unimodem/V, which is not yet
ported to NT.
- 486 Emulation: Previous versions of NT running on RISC platforms perform
only 286 emulation. NT 4.0 runs 386-enhanced 16-bit applications.
- CD File System (CDFS): NT 4.0 CDFS now supports autoplay CDs and CD-XA
formats.
- Messaging Subsystem (NT-WMS): The NT-WMS includes the Exchange client, Mail
API (MAPI), migration Microsoft Mail service, and Internet mail service. The
Exchange group delivers it, and it is equivalent to the components that shipped
with Windows 95.
- NetWare 4 client/login script support: The NetWare Directory Service (NDS)
client for Windows NT Workstation provides NetWare login script support and
file/print capabilities.
- Windows Internet Name Service (WINS) and Domain Name System (DNS): NT 4.0
includes DNS (equivalent to the Berkeley Internet Naming Daemon--BIND--in BSD
UNIX). DNS returns IP addresses for named clients. DNS integration with the
dynamic WINS database for mapping computer names to IP addresses is improved.
A Desktop Winner
NT 4.0 has a lot to offer: a great and extensible user interface, a robust
architecture, as much security as you feel like administering, and a bunch of
new services for developers to play with. It's too early to know for sure, but a
memory requirement of 12MB will likely make NT Workstation 4.0 more competitive
on the business desktop. And on the server side, IIS and other new features in
NT Server 4.0 go a long way to strengthen NT server's competitive position and
strategic importance in the corporate market. Of course, you still might want to
run Windows 95 on systems where you play DOS-based games on laptops with
frequent PCMCIA card hot swaps, or on systems that don't support NT's minimum
memory requirements (probably 12MB for NT Workstation). If, however, you are
looking for an industrial-strength solution for corporate desktops, NT 4.0
offers an impressive set of features and functions. Don't be surprised to see NT
4.0 blanket the landscape like a sudden snowstorm.
See Sidebar "NT 4.0 For Developers"