While looking at the Windows 95 disk subsystem, something seemed oddly familiar. The nagging feeling was confirmed by the Windows 95 DDK documentation (a file called BLOCK.DOC). The new Windows 95 layered block device driver model called “Dragon” wasn’t all that new—it was a modified implementation of Microsoft’s older LADDR (pronounced “ladder”), or Layered Adapter Device DRiver model which first appeared in MS OS/2 in 1990. The LADDR subsystem could be retrofitted to OS/2 1.2 (producing “LADDRized OS/2”) and came standard with MS OS/2 1.3 (i.e. LAN Manager 2.1).
The structure of LADDR and Dragon was obviously quite similar, although there were just as importantly significant differences. The fact that LADDR was 16-bit and Dragon 32-bit was not necessarily a great difference. But for instance SCSI adapter support was noticeably different. Windows 95 could use NT miniport drivers (.MPD), which weren’t at all relevant with LADDR. Dragon also included special support for real-mode DOS drivers, which was likewise a non-issue with OS/2.
LADDR
Microsoft announced LADDR in June 1990 as a significant aid in developing storage drivers for OS/2. When OS/2 1.0 was announced in 1987, it was designed to run primarily on AT-class systems with standard AT-compatible storage controllers (some form of WD 1003 style controller). Microsoft did not provide any other drivers and OEMs had to develop a monolithic block device driver which supported hard disks and floppy drives. Developing a SCSI driver for OS/2 1.0 or 1.1 was doable (and had been done) but it was a significant undertaking.
IBM had a completely different strategy, with all higher-end system being PS/2 machines with ABIOS. There was compatibility on the firmware level and in fact IBM offered both ESDI and SCSI drives in their systems (in addition to AT compatibles), all supported by IBM’s OS/2.
When Microsoft started focusing more on the LAN Manager business around 1990, server systems suitable for running MS OS/2 already used advanced (typically SCSI-based) storage controllers. To support this market, Microsoft needed to make it much easier to develop storage drivers, and LADDR was the answer. The LADDR architecture was developed together with several OEMs, including Adaptec, Compaq, NCR, and Western Digital (i.e. both systems and storage vendors).
It’s worth mentioning that although LADDR wasn’t directly related to the IFS (Installable File System) support introduced in OS/2 1.2, LADDR worked well with IFS and enabled for example CD-ROM support—with a LADDR-based CD-ROM device driver and a Microsoft-provided High Sierra/ISO 9660 IFS.
Another new feature directly enabled by LADDR was fault tolerance. By slicing up the storage driver stack into several layers, it became easy to insert vendor-specific drivers (roughly equivalent to NT filter drivers) between the hardware-specific driver and the logical device layer. It was also possible to implement more generic and effective caching that way.
At the top of the ladder was IOS, or I/O Supervisor, implemented in IOS1X.SYS. The name suggests that a version of IOS for OS/2 2.0 also existed. Just below were TSDs, or Type-Specific Drivers. MS OS/2 1.3 shipped with DISK.TSD, CDROM.TSD, and TAPE.TSD, each with obvious purpose.
At the bottom were BIDs or Bus Interface Drivers; this was the component that OEMs might need to supply. Among the standard drivers was ESDI-506.BID, AHA154X.BID, AHA1574X.BID CPQARRAY.BID, DPT201X.BID, WD7000EX.BID.
The middle part of the driver stack was where the Vendor-Supplied Drivers (or VSDs) lived and where the added value was. For example. FT.VSD provided fault tolerance, FATCACHE.VSD enhanced caching.
One of the VSD layers was reserved for the so-called SCSI’izer (technically not vendor-supplied since it came with the OS). This was a module which translated logical operations such as reads and writes to SCSI Command Descriptor Blocks (CDBs). Hardware drivers thus dealt directly with SCSI commands which could usually be sent directly to (SCSI) hardware with a minimum of processing.
IBM did not use LADDR for OS/2 2.0, although its storage subsystem used a similar layering approach. However, at least one vendor (NCR) used LADDR even with IBM’s OS/2 2.x, presumably in order to leverage existing support written for OS/2 1.x.
Dragon
According to Inside Windows 95 (page 277), the development of Dragon started in early 1991, which would have been right after LAN Manager 2.1 and MS OS/2 1.3 were more or less completed. It’s highly likely that at least some LADDR developers ended up working on Dragon.
Windows 95 in a way faced the same problem as OS/2 1.x, although from a different angle. Windows 3.x did not require any device-specific disk drivers at all and even Windows 95 could use a real-mode fallback. But in the Windows 95 era, real-mode disk access hurt performance too much and Windows 95 needed native storage drivers in order for the OS to be taken seriously. Dragon was the answer.
The Dragon storage subsystem was officially documented in the Windows 95 DDK. It was also described in reasonable detail in chapter 7 of Inside Windows 95.
While the overall architecture of Dragon was very similar to LADDR, there were two aspects unique to Windows 95. The first was real-mode fallback support—something that didn’t make much sense on OS/2 or NT (although it should be noted that IBM did provide similar fallback since OS/2 2.0, in a driver called IBMINT13.I13). Microsoft provided a “protect to real mode mapper” as part of Dragon; this module then interfaced either with the BIOS or an OEM-provided DOS device driver.
The other difference was support for NT SCSI miniport drivers. The NT SCSI miniport driver model was already highly abstracted and suitable for porting to the Windows 95 environment (something that Microsoft had done a number of times with various components). To this end, Microsoft provided the SCSI port driver as part of Dragon. The SCSI port driver interfaced with an OEM-provided NT SCSI miniport driver which handled the hardware-specific details.
For non-SCSI devices, full-blown port drivers could be used. That included standard IDE devices as well as floppy drives.
Once again, at the top of the Dragon driver stack was the I/O Supervisor (IOS), this time delivered as IOS.VXD. Below were Type-Specific Drivers (TSDs): DISKTSD.VXD and CDTSD.VXD.
There weren’t any Vendor-Supplied Drivers (VSDs) worth mentioning shipped with Windows 95, but the concept did exist in Dragon. The SCSI’izer was again a special VSD provided by the OS.
The SCSI port driver was delivered as SCSIPORT.PDR. Some of the hardware-specific SCSI miniport drivers shipped with Windows 95 were AHA154X.MPD, AHA174X.MPD, DPTSCSI.MPD, or WD7000EX.MPD (note the similarities with the drivers shipped with LADDR).
IDE disks were handled by ESDI_506.PDR (the equivalent of SCSIPORT.PDR plus a miniport driver). The naming is rather similar to what OS/2 LADDR used (ESDI-506.BID) and hints at a close relationship, especially because the driver name is a bit of a misnomer: ST-506 and ESDI are physical drive interfaces, not disk controller interfaces.
It should be noted that Dragon first appeared in Windows for Workgroups 3.11 (Nov 1993), albeit in a very incomplete form.
In the late 1990s, Dragon became infamous for causing Windows 95 to crash on faster systems, although few users realized that it was Dragon specifically that was responsible. IOS.VXD, SCSIPORT.PDR, and ESDI_506.PDR all contained CPU speed calibration code that caused division overflows on faster processors.
Dragon = LADDR?
Was there more than superficial similarity between LADDR and Dragon? Component names aside (IOS, TSD, VSD), the layered architecture seems obvious and Windows 95 was nothing like MS OS/2… was it?
Answering this question is tricky, but doable. All one needs is the Windows 95 DDK and the LADDR development kit. Comparing the Windows 95 DDK (files dated 7/11/1995) with the LADDR kit (files dated August-November 1991), the conclusion is that yes, Dragon was unquestionably derived from LADDR, but there were so many minor and major changes that the two subsystems ended up being substantially different.
The similarities in header files clearly indicate that Microsoft directly reused the LADDR source code for Windows 95. However, Dragon evolved significantly further, both in order to fit the different OS architecture and to support new features in Windows 95, such as Plug and Play (not a concern for file servers).
As an example, here are two excerpts from the ISP.H header file. First the LADDR version:
/*
** define the ios service packet for the insert calldown entry function
*/
typedef struct ISP_calldown_insert { /* */
USHORT ISP_filler_29; /* "ISP_INSERT_CALLDOWN" */
ULONG ISP_filler_30; /* cs:ip of caller */
USHORT ISP_filler_31; /* result: zero = no error */
ULONG ISP_i_cd_dcb; /* 32-bit offset to dcb */
PVOID ISP_i_cd_req; /* 16:16 pointer to request routine */
PVOID ISP_i_cd_aer; /* 16:16 pointer to aer */
ULONG ISP_i_cd_ddb; /* 32-bit offset to ddb */
USHORT ISP_i_cd_pv_sel; /* 16-bit selector of perfview data */
ULONG ISP_i_cd_pv_str; /* 32-bit offset to pvw strings */
ULONG ISP_i_cd_pv_ptr; /* 32-bit offset to perfview hdr - */
/* zero if none. */
USHORT ISP_i_cd_pv_len; /* length of perfview data - zero */
/* if none. */
USHORT ISP_i_cd_flags; /* demand flag bits */
} ISP_calldown_insert, far *pISP_calldown_insert;
And now the same structure from the Windows 95 DDK:
/*
** ISP_INSERT_CALLDOWN:
**
** This service is called by a layer driver if it needs to insert its
** request entry point into the DCB call down list. This ensures that the
** driver will see all i/o requests to that device. The driver can also
** allocate a per i/o request packet area called expansion area. This becomes
** part of the IOP and can be accessed when the request is being processed
** by each layer.
*/
typedef struct ISP_calldown_insert { /* */
ISP ISP_i_cd_hdr; /* Standard header */
ULONG ISP_i_cd_dcb; /* 32-bit offset to dcb */
PVOID ISP_i_cd_req; /* 32-bit pointer to request routine*/
ULONG ISP_i_cd_ddb; /* 32-bit offset to ddb */
/* zero if none. */
USHORT ISP_i_cd_expan_len; /* size of IOP expansion length */
/* zero if none. */
ULONG ISP_i_cd_flags; /* demand flag bits */
UCHAR ISP_i_cd_lgn; /* load group number */
UCHAR ISP_pad4[1]; /* Pad to DWORD boundary */
} ISP_calldown_insert, *PISP_calldown_insert;
The structure was substantially modified in Dragon, but at the same time there can be no question that it was modified from the LADDR original, especially given that LADDR/Dragon used a naming convention that was not standard in either OS/2 or Windows 95. This data structure nicely represents the LADDR/Dragon relationship: Dragon was clearly derived from LADDR and kept the general architecture, but it was changed almost beyond recognition.
Dragon was also modified to align better with the NT storage architecture. Overall Dragon was much closer to LADDR than it was to the NT I/O subsystem, but various details (for example the SCSI Request Block, or SRB, data structure) were adapted to match NT rather than the LADDR originals. This was driven by the SCSI miniport compatibility requirement.
In general, Microsoft could not re-use OS/2 components since the code was co-owned by IBM. Being purely Microsoft owned, LADDR was an exception; it was a technology that IBM had no need for (again, the PS/2 Advanced BIOS, or ABIOS, took care of the hardware specifics on the firmware level for IBM systems). It may be the only piece of OS/2 that was more or less directly adopted for use in Windows 95.
References
- Laddr May Be Standard For OS/2 SCSI Peripherals, InfoWorld, Jun 18, 1990, page 8
- First LADDR-Compatible SCSI Software Debuts, InfoWorld, Aug 13, 1990, page 24
- Inside Windows 95, Adrian King, Microsoft Press, 1994
- Layered Block Device Drivers, BLOCK.DOC, Windows 95 DDK, 1995