Microsoft Windows NT Preliminary Device Driver Kit
==================================================

The Windows NT Preliminary Device Driver Kit gives you the tools and information 
you need to develop device drivers that take full advantage of your hardware. 
--------------------------------------------------------------------------------
<< Figure 1: Windows NT device driver architecture  >>

Overview

The Microsoft* Windows* operating system is enjoying phenomenal 
popularity, with well over 15 million users worldwide. The Windows NT* 
operating system is on the same road to success.  Since its preliminary release on 
July 6, we have shipped  over 20,000 Win32* SDKs for Windows NT.

Some of the new features of Windows NT which will contribute to its success 
are the 32-bit device driver model with powerful new functionality, portability 
and symmetric multiprocessing, and the fact that device drivers are easier to 
write.

The 32-bit device driver model does away with the burden of managing 
memory in 64k segments and increases performance. It also allows you to place 
your device I/O anywhere in the 32-bit flat memory model.

Windows NT and its device driver model are portable across different 
hardware platforms and support symmetric multiprocessing. Not only 
will this allow your hardware products to run on PCs-- this will let them run on 
workstations and servers as well,  including the high performance RISC 
processors and multi-processor systems. 

Writing drivers for Windows NT is easier than what you may have 
experienced with other operating systems. Several types of drivers have a 
layered structure, allowing you to concentrate on developing code only for 
those portions of the driver that are specific to your device. Portions of code 
not specific to your device are provided by Microsoft in the Windows NT 
operating system.

This will allow you to market your hardware products to a broader base of 
computer users-- while meeting increasing demands for improved 
performance and varied functionality such as fast, high resolution graphics, 
audio support, and high-capacity storage systems.

The Windows NT DDK is the only development environment for creating 
powerful, portable device drivers for Windows NT. This DDK provides you 
with the sample source code and documentation you need to do the 
following:

o Develop, test, and debug a driver that takes full advantage of all the features 
provided in the Windows NT operating system.
o Develop, test, and debug a driver that runs on all Windows NT platforms 
including Intel* 386/486, MIPS R4000 and DEC* Alpha .

Having your hardware support Windows NT is a huge opportunity-- 
and should be a high priority. Now, you can start developing these device drivers 
today with the Microsoft Windows NT Preliminary DDK.

By purchasing this preliminary version of the Windows NT DDK you will 
receive preliminary and final versions of the included tools, source code, and 
documentation. All updates including the final version will be sent to you 
automatically. (Note that the DDK requires the Microsoft Win32 Preliminary 
SDK for Windows NT, which contains the tools you will need to build your 
driver.)

Device Driver Model

In the Windows NT operating system there are two basic kinds of drivers: user-
mode drivers and kernel-mode drivers. User-mode drivers are specific to the 
subsystem, such as Win32, and include display, printer and virtual device 
drivers. Kernel-mode drivers are for physical devices such as keyboards or 
disks. 

As Figure 1 shows, the Windows NT Executive includes a number of kernel-
mode components with well defined functionality isolated in each component. 
Those of most interest to device driver writers are the Kernel, I/O Manager, 
Hardware Abstraction Layer (HAL), Memory Manager, Executive Support, 
and Process Structure components. Like the Windows NT Executive itself, kernel-
mode drivers are implemented as discrete, modular components with a 
well defined set of required functionality. All kernel-mode drivers have a set of 
system-defined standard  driver routines to get support from these system 
components.

Figure 1 also shows how user-mode drivers fit into the Win32 subsystem, 
which interacts with the Windows NT executive. User-mode drivers include 
display, printer, plotter, multimedia device handlers, as well as virtual device 
drivers (VDDs) to allow MS-DOS*-based and Windows-based applications 
to interact with hardware under Windows NT. User-mode drivers 
generally do not control the hardware device directly- they require a 
complimentary kernel-mode driver to interact with the hardware on their 
behalf.

Other features of the Windows NT device driver model include:

o Portability from one platform to another. In the same way as most of 
the Windows NT system, Windows NT drivers are written in C so that 
they can be recompiled, relinked, and then run on different Windows NT 
platforms without recoding parts of the driver. All Windows NT drivers 
should be tested on the current Windows NT platforms including Intel 
386/486, MIPS R4000 and DEC Alpha.

o Layered Architecture. The layered structure of the device driver model 
lets you write a kernel-mode driver in much less time than what you may 
have experienced with other operating systems. This layered approach allows 
you to concentrate on developing code only for those portions of the driver 
that are specific to your device. Portions of code not specific to the 
device itself are provided by Microsoft in the Windows NT operating system.

o Always preemptible and always interruptable. The executive Kernel 
component assigning priorities for thread to determine when a particular 
sequence of code is run. This means most kernel-mode drivers have a 
higher scheduling priority than all threads in the system. Every routine in 
a device driver is interruptable: a driver's interrupt service routine 
retains control of the processor only if no interrupt with a higher priority 
value occurs while that routine is running.

o Multiprocessor safe. Windows NT is designed to run unchanged on 
uniprocessor and symmetric multiprocessor platform. Kernel-mode 
drivers are designed to run the same way. 

o Object-based. The Windows NT Executive is an object-based system. 
For device drivers this means that kernel resources are objects and the 
interface drivers use to request resources is straightforward and 
consistent. Kernel-mode drivers and their devices are also object-based. To 
all other components in the system, including user-mode code, a device is 
represented as one of the I/O Manager's file objects. Within the I/O 
system, each driver's logical, virtual, and/or physical devices are 
represented as device objects. Within the I/O manager, each kernel-mode 
driver's load image is represented as a driver object. The I/O Manager defines 
the object types for file objects, device objects, and driver objects, as well as 
adapter objects to represent system DMA controllers or busmaster 
adapters and controller objects to represent a controller card for similar 
devices.

o Packet-driven I/O with reusable I/O request packets (IRPs). The I/O 
Manager's main job is to accept I/O requests (usually from user-mode 
applications), create IRPs to represent them, route the IRPs to the appropriate 
kernel-mode drivers, track them until they are completed., and return status 
to the original caller. The I/O Manager uses IRPs to communicate with kernel-
mode drivers and to allow drivers to communicate with each other.

o Supporting asynchronous I/O.  Providing asynchronous I/O support 
improves overall system I/O throughput, as well as the 
performance of any code that makes an I/O request. The I/O Manager 
provides asynchronous I/O support so that the originator of an I/O request 
(usually a user-mode application, but sometimes another driver or the 
Executive) can continue executing, rather than waiting for its I/O request 
to complete.

o Powerful Win32 graphics engine- The Win32 graphics engine provides more 
built-in functionality and rendering support than ever before. Features 
including half-toning, Bzier curves, and fractional coordinate give you the 
flexibility to offload complex graphics operations to the Win32 graphics 
engine and reduces the amount of code required to develop a functional 
driver. It is also possible to bypass most of this engine functionality and 
perform these operations in your driver or in your specialized hardware.

How long will it take to write a device driver??

The development cycle depends on a number of factors, including the 
complexity of the interface to the hardware, and your familiarity with the 
Windows NT architecture and its new driver model. Once you've learned this 
new architecture and driver model, the time required to write a driver will 
probably depend on how similar your driver is to one of the supplied driver 
sources.

If your device driver is similar to one of the supplied miniport drivers, your 
driver may require only minor changes that could be done in a a short amount of 
time. If your driver is complex and is not similar to one of the Microsoft-supplied 
drivers, this effort could take significantly longer.

Device Driver Types 

<< Figure 2: List of sources to be included in the first release of the Preliminary 
DDK  (textual information  entered below) >>

Pointing Device: 
  Microsoft InPort Mouse
Keyboard: 
  AT(R) style keyboard driver
Multimedia: 
  Soundblaster Audio board
Communication: 
  Serial; 
  Parallel
Printer: 
  PostScript driver
Display: 
  VGA 640x480x16; 
  SVGA (Video Seven & Tseng) 800x600x256, 1024x768x256;
  Frame buffer (Dell DGX) 1280x1024x256;
  Fixed function accelerator (S3) 1024x768x256
UPD Mini-Drivers:
  Epson(R) 9 pin
  Epson(R) 24 pin
  HPPCL 5
  HP(R) Paintjet
  IBM(R) Proprinter 24 pin
Disk:
  Floppy
  Standard wd-1003 Compatible MFM, IDE, ESDI
NDIS:
  Sonic driver
  (National Semi DP83932)
SCSI Miniport
  Adaptec 154X
  NCR 53C94
SCSI Class 
  Tape
  CD-ROM

* This list is subject to change.  Additional sources my be included in 
  subsequent releases of the Preliminary DDK
  
While there are hundreds of types of drivers, this section outlines the most 
common driver types, including printer, video, SCSI adapter, network adapter 
(NDIS 3.0), and virtual device drivers.

Printer Drivers

The Windows Universal Printer Driver (introduced in version 3.1 of the 
Windows operating system) makes it easier for you to create and maintain 
raster printer drivers for all versions of the Windows operating system. The 
underlying principle of the Universal Printer Driver (UPD) is to separate 
printer-specific information from Windows-specific information. Each 
printer has a separate file containing information on its capabilities, and all 
executable driver code resides in a separate common code library. Microsoft 
Windows NT expands on this design while maintaining compatibility with 
Windows 3.x.

To support a printer using the UPD architecture, you must create a 
minidriver- a binary file created with the Windows-based UniTool. This 
minidriver file contains all the printer specific data as well as information on 
supported paper sizes, available font cartridges, page area, cursor movement 
commands, and so forth. It can also create code that addresses features 
and/or problems of a specific printer. However, the minidriver contains no 
Windows-specific information.

The UPD for Windows NT contains all the traditional code for translating output 
from the Win32 GDI imaging model to the printer's specific text/graphics 
functions. The UPD relies on the information within the printer's 
minidriver to determine the basic technology and specific capabilities of 
each printer.

The UniTool application and several minidriver sample sources are included 
in the DDK. The DDK also includes sample sources and information to allow 
you to write drivers that don't fit the UPD model, such as PostScript* drivers.

PostScript support under Windows NT includes the ability to read .PPD files. If 
you supply your postscript printer with .PPD files, your printer will 
automatically be supported under Windows NT. 

The Windows NT DDK also provides information that allows you to write a 
printer driver for a more sophisticated device by allowing you to implement or 
hook Win32 GDI functions directly in your driver.
 
<< Figure 3: Video miniport architecture  >>

Video Drivers

Under Windows NT there is a user-mode display driver that communicates with a 
kernel-mode miniport driver through a system supplied video port driver (see 
Figure 3.) The miniport driver contains the adapter-dependent code while the 
user-mode display driver interacts with the graphics engine. If your video board 
is related to one of the sample display drivers included in the DDK, you 
probably will only need to modify the miniport driver to support the unique 
characteristics of your board. The DDK contains several mini-port/display driver 
samples including VGA/SVGA, framebuffers (Dell DGX), and 
accelerators (S3).
 
<< Figure 4: SCSI adapter miniport architecture  >>

SCSI Adapter Drivers

Windows NT uses an internal SCSI port interface that separates the SCSI-adapter-
dependent part of the driver from the OS-dependent parts. This separation not 
only makes SCSI adapter drivers easy to write, but also allows to SCSI host bus 
adapter (HBA) miniport driver to move across different platforms without 
modification.

The HBA miniport driver is responsible for such tasks as managing 
the SCSI bus protocol steps, interfacing with the SCSI host bus adapter, and 
detecting or distinguishing SCSI bus protocol errors, and performing error 
recovery as required. The port driver is supplied with Windows NT and is 
responsible for interfacing to higher level drivers and system software, providing 
support functions to the HBA miniport driver, timing SCSI bus requests, and 
managing SCSI bus request queues for logical units on the SCSI bus. 

Most HBA miniport drivers are very straightforward. They are written in C 
and do not have to handle multiprocessor issues, data queuing, or 
operating system specific interfaces. The DDK contains HBA miniport and class 
driver samples and several chapters of documentation on SCSI driver issues.

NDIS 3.0 Drivers

The Windows NT DDK contains everything you need to design, write, 
and implement a network device driver that uses the Network Driver Interface 
Specification (NDIS) 3.0 to communicate in a local area network. Drivers written 
to this specification will work with any operating system supporting a NDIS 3.0 
interface. The DDK contains source code for a sample NDIS 3.0-based media 
access control (MAC) device driver, building and performance testing tools, 
and documentation. 

Virtual Device Drivers

The security and robustness of Windows NT preclude direct access to the 
hardware by applications.  Instead, applications must use Windows NT 
Device Drivers.  An existing MS-DOS-based or Windows based application 
must use a virtual device driver (VDD's), which communicates with a Windows 
NT device driver, to access the system.

In addition to enabling you to write Windows NT device drivers, the DDK 
allows you to write the VDD's required to support these existing applications 
and thus preserve your installed base of customers.

Windows NT DDK Specifications

The Windows NT DDK contains a complete set of powerful tools-- 
everything you need to start developing Windows NT device drivers now. 


As part of the Windows NT Preliminary DDK you will receive the 
following DDK tools and documentation in preliminary and final form. A CD only 
version of the DDK is also available without printed documentation and also 
includes preliminary and final versions of the same DDK software.

DDK tools
o UniTool for creating printer mini-drivers
o Testing tools for most device driver types
o Performance tools for device drivers tuning 
o Kernel debugger
o Debug version of the Windows NT operating system

DDK Documentation 
o Driver Programmer's Guide
o Kernel-mode Driver Design Guide
o Kernel-mode Driver Reference
o NDIS 3.0 Network Driver Design Guide
o Win32 User-mode Driver Design Guide
o Win32 User-mode Driver Reference
o Windows NT DDK Sample Driver Commentaries

As a special bonus, by purchasing the hard-copy documentation you will 
receive the new book from Microsoft Press* , Inside Windows NT.

System Requirements

In order to write device drivers with the Windows NT DDK, you must have the 
Win32 Preliminary SDK. See the "How to Order"  section below for information on 
ordering the SDK and DDK.

The DDK and SDK system requirements are identical. An Intel 
80386 system or higher, or ACE/ARC compatible R4000 systems with at least 
12MB of RAM and 100MB available hard disk space (includes 20MB for a swap 
file) are required (16MB of RAM is recommended). In addition, the DDK 
requires a second machine running Windows NT to allow for driver 
debugging via the kernel debugger. Debugging drivers via a second monitor 
or dumb terminal is not supported. The Windows NT DDK is only available on 
CD-ROM and requires CD-ROM drive and SCSI adapter. For a list of computer 
systems, CD-ROM drives, SCSI cards and other peripherals on which 
preliminary testing has been done, see the Hardware Compatibility List. The 
most recent hardware compatibility list is in the MSWIN32 forum on 
CompuServe(c).

Product Support

Twenty-four hour online technical information about Microsoft products is 
available through CompuServe. Here, you can exchange messages with 
Microsoft support engineers and experienced users of Microsoft products, 
and download free software (such as drivers, sample code, utilities, and add-
ons) provided by Microsoft and CompuServe members. Through the 
Microsoft Connection, users can now access the Microsoft Developer Services 
area. This area offers:

o Developer Forums. These forums cover information on the Windows operating 
system, languages, tools, and utilities from a developer's perspective. For 
example, a special section of the MSWIN32 forum has been set up to 
support this preliminary version of the Windows NT DDK. Support for 
installation and usage questions for the Windows NT operating system is 
provided in the WINNT forum.

o Developer Knowledge Base. This up-to-date reference tool, compiled by 
Microsoft Product Support engineers, contains developer-specific technical 
information about Microsoft products.

o Software Library. This collection of text and graphics files, sample code and 
utilities is keyword searchable, and these files can be downloaded for local 
use.

To connect to the Microsoft Connection, type GO MICROSOFT at the 
CompuServe "!" prompt. For more information about signing up for a 
CompuServe account, call (800) 848-8199, 8:00 A.M. to 10:00 P.M. eastern time, and 
ask for operator 230 to receive a $15 connect time usage credit.

How to Order

To order the Windows NT Preliminary DDK and/or the Win32 Preliminary SDK 
for Windows NT call Microsoft Developer Services at (800) 227-4679. In 
Canada, call the Microsoft Canada Customer Support Centre at (800) 563-
9048. Outside the 50 United States and Canada, please contact your local 
Microsoft representative.

------------------------------------------------
1992 Microsoft Corporation. All rights reserved. Printed in the United States 
of America. This document is for informational purposes only. MICROSOFT MAKES NO 
WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT. Microsoft,MS-DOS, and Microsoft 
Press are registered trademarks and Windows, Windows NT, Win32, and the Windows 
NT logo are trademarks of Microsoft Corporation. PostScript is a registered 
trademark of Adobe Systems, Inc. OS/2 is a registered trademark licensed to 
Microsoft Corporation. Intel is a registered trademark of Intel Corporation. DEC 
is a registered trademark of Digital Equipment Corp. TrueType is a registered 
trademark of Apple Computer Inc. CompuServe is a registered trademark of 
Compuserve Corporation. IBM and AT are registered trademarks of International 
Business Machines Corporation. Epson is a registered trademark of Seiko Epson 
Corporation, HP is a registered trademark of Hewlett Packard Company. SCSI is a 
registered trademark of Security Control Systems, Inc.

Part Number 098-37859.
