Technology Insight - Using a VxD Architecture

The Advantages of Using a Virtual Device Driver (VxD) Architecture for Networking in Microsoft Windows

Companies using networks face new challenges in the future, in part because future versions of Microsoft Windows will be based on 32-bit architecture. This paper discusses the features and benefits of using a Virtual Device Driver (VxD) architecture for a network protocol stack, to accomplish networking in the Microsoft Windows environment.

Version 3.1 of Microsoft Windows is based on the foundation of a real mode DOS operating system. Future versions of Windows will migrate from real mode to protected mode, which will alter the approach and implementation of Windows network protocol stacks. Traditionally, the protocol stack's architecture has been implemented either as a Terminate and Stay Resident (TSR) program or as a Windows Dynamic Link Library (DLL). As Windows moves toward its future 32-bit version, a 32-bit VxD-based architecture will emerge as the preferred method for implementing network protocol stacks.

A Windows Virtual Device Driver, or VxD, is a multiplexing device driver that manages data exchanges between Windows applications and system services. For example, a VxD allows a user to access a Windows word processing application while simultaneously running other network applications. A VxD architecture for network stacks essentially means three important things to end users: superior performance for applications, reduced conventional memory use, and technology that is aligned with future 32-bit versions of Windows. To further understand the importance of VxD technology, we need to look at the previous two methods of network protocol stack implementation: TSR and DLL.

TSR Implementation

A Terminate and Stay Resident, or TSR, program is one that loads into memory upon execution and then returns a DOS prompt, allowing the user to perform other tasks. The TSR remains active and occupies a portion of memory until it is either manually unloaded or removed by another action, such as rebooting the PC. For example, a user activates a TSR program from the DOS prompt (or through a batch program) and then starts Microsoft Windows and accesses a spreadsheet application. The DOS TSR is still active in memory and running, even though the user is in a Windows application.

A TSR resides in real mode addressable DOS memory. Real mode addressable memory is the memory between 0K and 1024K (or 1MB) that is typically used for loading device drivers and applications. This memory is comprised of the conventional memory area (0K to 640K) and the upper memory area (640K to 1024K). The upper memory area can consist of expanded memory (EMS) and upper memory (UMB) blocks.

The main concern with a Windows network protocol stack implemented as a TSR is that it uses a portion of real mode memory. Depending on the size and complexity of the program, little or no memory may be available for other applications. A TSR is a good implementation for DOS-based protocols and a reliable, proven architecture for users who prefer to network primarily through DOS.

DLL Implementation

A Windows Dynamic Link Library, or DLL, is only active when Windows is running. A DLL loads into memory only when an application needs the services the DLL provides. DLLs are "dynamically" loaded and unloaded as needed by Windows. When the application no longer needs the DLL's services, it gets unloaded automatically by Windows. For example, a user starts Windows and starts a remote login application - since that application requires the services of the DLL, the DLL gets dynamically loaded by the Windows Scheduler. When the user finishes the remote login session and closes that application, Windows automatically unloads the DLL. A DLL implementation enables good use of system resources since it has the ability to dynamically load and unload when its services are needed.

However, a DLL is not free from the constraints of operating in real mode memory addressing. Windows "fixes" interrupt-driven DLL network protocol stacks into low memory (conventional memory). This Windows-controlled memory is used to buffer (store) data and execute network code when interrupts occur. Implementing a network protocol stack as a DLL is a short term solution for a Windows 3.0 or 3.1 environment. But what about those companies that want to network in both DOS and Windows, and take advantage of future 32-bit Windows releases?

The VxD Alternative

A VxD architecture is Microsoft's recommended method for implementing network protocol stacks. VxD technology provides the overall best way to implement network protocol stacks within Windows: it takes full advantage of 386/486 architecture, it is written as a 32-bit module, and because it operates at the same level of priority as the operating system, it provides superior performance and faster response time to applications. Applications written as 32-bit implementations can talk through a 32-bit API directly to the VxD, without needing to go through a 32-bit to 16-bit conversion, which reduces performance.

There are several performance advantages that a Windows VxD protocol stack has in comparison to a TSR and DLL. Within Windows, a VxD provides simultaneous network support to Windows applications as well as network applications initiated from within a Windows DOS box. A TSR also offers this capability but, as previously mentioned, it lacks the ability to dynamically load or unload. In addition, a TSR can occupy a significant portion of memory depending on the size of the program. The VxD itself requires a very small portion of conventional memory for buffering information received from the network; however, the amount of conventional memory the VxD occupies is significantly less than its TSR or DLL counterparts, since it is only a buffer for network packets without any actual code.

A VxD also has some significant advantages over a DLL. First, a DLL implementation is limited because it does not support network applications initiated from a Windows DOS box. Also, a VxD has improved performance over a DLL because it operates at the same level of priority as the operating system. The operating system and 32-bit VxD both operate from priority level Ring 0, whereas the DLL operates from Ring 3. When a network protocol stack handles packets, a VxD implementation will provide faster response time than a DLL due to less interrupt latency (delay). For end users, this means faster performance for both network applications and Windows.

DLLs also have to contend, due to operating at a Ring 3 priority level, with applications that have an equal or higher priority. This means that a DLL-based protocol stack may come to a complete stop if it encounters a Windows application that refuses to yield control. For example, a user is running a Windows file transfer application while simultaneously working in a Windows word processing application. The DLL protocol stack is in the middle of transferring data, when suddenly the user performs a repagination in the word processing application. Because the word processing application has control, it causes the network application to temporarily stop transferring information over the network protocol stack. Until the word processing application finishes its repagination and yields control, no network traffic moves over the DLL protocol stack.

Microsoft's Recommendation for the Future: VxD

A VxD architecture is Microsoft's recommendation for implementing network protocol stacks in Windows 3.1 and future versions.

Microsoft also highly recommends a protected mode device driver. The NDIS v3.0 specification defines a method by which netwoork implementations builit inprotected mode can interface to protected mode drivers. Microsoft, through Windows for Workgroups v3.11, has released the protected mode device drivers defined in the NDIS v3.0 specification.

The combination of an NDIS v3.0 device driver and a VxD gives the user a complete protected mode network stack. This protected mode stack solves most of the traditional memory consumption issues that TSRs and DLLs present us with, and makes the amount of conventional memory that a network stack occupies almost non-existent.

Summary

A VxD is clearly the way that future Windows network protocol stacks will be implemented. VxD technology provides users with the ability to implement tomorrow's technology today, and be aligned for future 32-bit versions.

The advantages a VxD brings to users include:

32-bit technology that operates at the same priority level as the operating system and makes full use of a PC's 386/486 architecture
Superior performance for network applications
The fastest network protocol stack implementation in the marketplace
The smallest possible conventional memory use
No need for a memory manager
State-of-the-art technology that is well aligned for future operating systems and Microsoft Windows releases

A VxD implementation will help meet some of the future challenges that companies using networks face. For those companies who want to migrate to future versions of Windows and keep up with networking technology, a VxD will soon become the preferred method for protocol stack implementation.

FTP Software, Inc.