Windows 95 Network Architecture Overview

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

This chapter presents information about the architecture for the networking components in Windows 95.

Windows 95 provides multiple, simultaneous connections to a variety of networks (Windows NT, Novell® NetWare®, and others) and a variety of resources (files, programs, printers, host systems, and mail systems) over most popular media (Ethernet, token ring, X.25, ISDN) from almost any location.

Windows 95 networking capabilities are implemented using a high-performance, reliable, and open architecture based on the Windows Open Services Architecture (WOSA) specification. This approach provides users with a consistent interface to different services on the front end, while giving system administrators the flexibility to mix and match multiple services on the back end.

OSI Reference Model and Windows 95 Architecture

The modular networking architecture of Windows 95 is based on two industry standard models for a layered networking architecture, namely the International Organization for Standardization (ISO) model for computer networking, called the Open Systems Interconnect (OSI) Reference Model, and the Institute of Electrical and Electronic Engineers (IEEE) 802 model. Windows NT and Windows for Workgroups are also designed according to these standard models. The ISO OSI and IEEE 802 models define a modular approach to networking, with each layer responsible for some discrete aspect of the networking process.

The OSI model describes the flow of data in a network, from the lowest layer (the physical connections) up to the layer containing the user's applications. Data going to and from the network is passed layer to layer. Each layer is able to communicate with the layer immediately above it and the layer immediately below it. This way, each layer is written as an efficient, streamlined software component. When a layer receives a packet of information, it checks the destination address, and if its own address is not there, it passes the packet to the next layer.

When two computers communicate on a network, the software at each layer on one computer assumes it is communicating with the same layer on the other computer. For example, the Transport layer of one computer communicates with the Transport layer on the other computer. The Transport layer on the first computer has no regard for how the communication actually passes through the lower layers of the first computer, across the physical media, and then up through the lower layers of the second computer.

The OSI Reference Model includes seven layers:

rk32_01

The Application layer represents the level at which applications access network services. This layer represents the services that directly support applications such as software for file transfers, database access, and electronic mail.
The Presentation layer translates data from the Application layer into an intermediary format. This layer also manages security issues by providing services such as data encryption, and compresses data so that fewer bits need to be transferred on the network.
The Session layer allows two applications on different computers to establish, use, and end a session. This layer establishes dialog control between the two computers in a session, regulating which side transmits, plus when and how long it transmits.
The Transport layer handles error recognition and recovery. It also repackages long messages when necessary into small packets for transmission and, at the receiving end, rebuilds packets into the original message. The receiving Transport layer also sends receipt acknowledgments.
The Network layer addresses messages and translates logical addresses and names into physical addresses. It also determines the route from the source to the destination computer and manages traffic problems, such as switching, routing, and controlling the congestion of data packets.
The Data Link layer packages raw bits from the Physical layer into frames (logical, structured packets for data). This layer is responsible for transferring frames from one computer to another, without errors. After sending a frame, it waits for an acknowledgment from the receiving computer.
The Physical layer transmits bits from one computer to another and regulates the transmission of a stream of bits over a physical medium. This layer defines how the cable is attached to the network adapter and what transmission technique is used to send data over the cable.

The following diagram shows the layered components that make up the Windows 95 networking model.

Layers in the Windows 95 networking model

The following sections describe these elements of the Windows 95 network architecture, beginning with redirectors. Network providers are described in "Network Providers" later in this chapter.

Redirectors and IFS Manager

A network redirector provides mechanisms to locate, open, read, write, and delete files and submit print jobs. It also makes available application services such as named pipes and mailslots. When an application needs to send or receive data from a remote device, it sends a call to the redirector. The redirector provides the functionality of the Application and Presentation layers of the OSI model.

The redirectors are included in the Windows 95 network client software as the following file system drivers:

In Client for Microsoft Networks (VREDIR.VXD), the redirector supports all networks based on Microsoft networking, which use the Server Message Block (SMB) file sharing protocol.
In Microsoft Client for NetWare Networks (NWREDIR.VXD), the redirector supports NetWare networking products, which use the NetWare Core Protocol (NCP) file sharing protocol.

Windows 95 also supports network redirectors from other network vendors.

Because each protected-mode redirector is implemented in Windows 95 as a file system driver, the redirector is managed by Installable File System (IFS) Manager. The redirector works with IFS Manager to map local names into network devices and decides whether the application needs access to a local or remote device. IFS Manager controls file I/O transfers for all the installable file systems in Windows 95. For more information about IFS Manager, see Chapter 31, "Windows 95 Architecture."

Client for Microsoft Networks (the redirector for Microsoft networks) formats an application's request into data packet SMBs and submits the packet to the protocol. Microsoft Client for NetWare Networks (the NetWare redirector) formats requests into NCP packets. The data packet is passed by the protocol to the adapter driver.

The Windows 95 server side at this layer of the networking model supports peer resource sharing. Windows 95 provides two server services for peer networking:

File and Printer Sharing for Microsoft Networks (the Windows 95 SMB-based server, VSERVER.VXD), which supports resource sharing among all computers on the network that use the SMB file sharing protocol.
File and Printer Sharing for NetWare Networks (the Windows 95 NCP-based server, NWSERVER.VXD), which supports resource sharing among all computers on the network that use the NCP file sharing protocol.

Multiple Network Support

The Windows 95 modular network provider interface, as described in this section, supports concurrent communication with several different networks. For example, a computer can have connections to computers running Windows 95 peer resource-sharing services, to servers for Windows NT and NetWare networks, and to the Internet, all at the same time.

In addition to the Windows 95 network client and peer sharing components, Windows 95 includes built-in support for the following network clients from other vendors:

Artisoft® LANtastic® version 5.0 and later
Banyan® VINES® version 5.52 and later
DEC™ PATHWORKS™ (installed as a protocol)
Novell® NetWare® version 3.11 and later
SunSoft™ PC-NFS® version 5.0 and later

Most of these network clients can be installed along with protected-mode Windows 95 networking components. Windows 95 does not include the supporting files for these networks; you must obtain them from the network vendor. For information about these network clients, see Chapter 10, "Windows 95 on Other Networks."

Multiple network support in Windows 95 consists of these components, as described in the following sections:

Win32 WinNet API
Multiple provider router and service provider interface
Network providers (including the WinNet16 interface)

Components of multiple network support in Windows 95

Win32 WinNet Interface for Applications

The Win32 WinNet interface in Windows 95 provides an API that software developers can use to create single versions of applications that run unmodified on different networks. The Win32 WinNet interface is the successor to the WinNet16 interface introduced in Windows 3.0 and enhanced in Windows 3.1.

The expanded WinNet API set includes the following:

Support for the Win32 WinNet APIs as defined in Windows NT. This set of functions and the other Win32 APIs provide all the commonly used capabilities required by applications.
Support for the Win32 WinNet APIs for browsing network resources (directories, printers, and other resources). This includes consistent handling of authentication requirements across multiple networks and support for the NetWare server security model.
Backward compatibility with Windows for Workgroups 3.11 and support for networks that use a WinNet16 network driver.

Multiple Provider Router and Service Provider Interface

The multiple provider router in Windows 95 exports the Win32 WinNet APIs to applications. It provides seamless access to network services and resources, and it supports a way to access a single WinNet16 network driver. It routes incoming network requests to the appropriate network provider, using the same interface whether one or more network providers are installed.

Features common to all networks are implemented once in the multiple provider router, which reduces the code base for each network provider and ensures common behavior among networks. For example, network providers do not implement persistent connections — this feature is implemented in the multiple provider router and is entirely transparent to a network provider.

Windows 95 uses an open, modular service provider interface (SPI) to allow multiple 32-bit network providers to be installed in Windows 95 simultaneously. The service provider interface is a single, well-defined set of functions used by Windows 95 to request network services to browse servers, connect to and disconnect from servers, and so on. The multiple provider router communicates with the network providers using the service provider interface.

The service provider interface provides the needed network services to honor a Windows 95 request for network-specific services. This model is similar to the Windows 95 design for various device driver interfaces: a well-defined set of interfaces used by the operating system, with services provided by a device driver (often written by another vendor) to honor requests. These requests are then passed to the network providers.

The service provider interface enables Microsoft or other network providers to integrate varied network services seamlessly into Windows 95. The service provider interface ensures that all supported networks are identically accessed and managed through Network Neighborhood and other user interface components.

Network Providers

Windows 95 uses an open, modular network provider interface to allow multiple network support simultaneously. Key benefits of the network provider interface architecture are the following:

An open interface allowing any network vendor to supply tightly integrated support for Windows 95.
Identical access to and management of network resources and components through the Windows 95 user interface, including Network Neighborhood and the Network option in Control Panel.

The network provider API calls are used by applications to request network services. Windows 95 passes a network provider call to the appropriate network provider, which then supplies the requested network service.

The network provider is a network-specific driver that implements the service provider interface call from the multiple provider router. The functions provided include authenticating users when they access a network server, managing passwords, adding or removing server connections, and browsing network resources.

Windows 95 includes the following network providers:

MSNP32.DLL for Microsoft networks
NWNP32.DLL for NetWare networks
WINNET16.DLL to support a single 16-bit network provider that uses WinNet16 APIs

Windows 95 also supports any number of other 32-bit network providers. Such network providers must be supplied by other network vendors.

The Windows 95 system logon is an example of a network service provided by the network provider interface. Each network provider can provide a unique logon dialog box to suit the needs of its network server security model. After the logon is validated by the requested server, this is passed back to Windows 95, which can then use this password to unlock any network resource linked to the logon validation. In this way, Windows 95 can accommodate the various ways that network servers provide their services, yet still offer a consistent user interface.

The following summarizes the internal processes when, for example, a user double-clicks the Entire Network icon in Network Neighborhood:

The Windows 95 user interface generates a Win32-based network API call to enumerate servers and resources on the network.
The multiple provider router receives the API call and submits a service provider interface call to all the available network providers.
Each network provider browses its individual networks and returns the list to Windows 95, which displays all the networks and their hierarchies in the Entire Network window.

Because of the network provider support in Windows 95, users can specify server name strings in a drive connection dialog box using the syntax to which they are accustomed. A network provider knows how to correctly interpret the syntax of its own server name strings. The server name string is the syntax used by a particular network operating system to specify a shared disk resource. Microsoft network-compatible networks use the UNC format (\\server_name\share_name).

However, because the network provider knows how to interpret server name strings, users who are accustomed to using the NetWare server syntax (server_name/volume_name:directory_name) can type such server names wherever required in Windows 95 to access NetWare server resources. The Windows 95 user interface and the net command also support UNC names for connecting to NetWare resources.

Network Provider for NetWare Networks

The network provider that supports NetWare networks (NWNP32.DLL and its support library, NWNET32.DLL) provides access to NCP-based NetWare network resources using Windows Explorer, Network Neighborhood, and Control Panel, and other Windows-based applications.

Basic architecture for network provider for the NetWare networks

The network provider supports these functions on NetWare networks:

Browsing NetWare networks. Bindery-based NetWare networks (versions 2.15 and above, 3.x, and 4.x with bindery emulation) use a Server-Volume-Directory hierarchy.
Logging onto and off of a NetWare network, providing dialog boxes for network logon, and performing attachments to bindery-based servers.
Adding and removing connections, allowing remote drive and printer connections using the NetWare format (server/volume:) and the UNC connections to NCP-based network resources (mapped drive or printer port, and \\server\share).

Network Provider for Microsoft Networks

The network provider that supports Microsoft networks (MSNP32.DLL) provides access to SMB-based Microsoft network resources using the Windows 95 user interface, such as Windows Explorer, Network Neighborhood, and Control Panel, and other Windows-based applications.

MSNP32.DLL provides the Microsoft network-specific dialog boxes (such as the Windows NT domain logon dialog box) and code to resolve a service provider interface call from the multiple provider router to a call to Client for Microsoft Networks.

Windows 95 architecture for the network provider for Microsoft networks

Notice that there are two arrows, one going through IFS Manager and one going directly to Client for Microsoft Networks.

When a network request is for a generic function such as adding a connection, the call is submitted to the IFS Interface.
When a network request is specific to a redirector, such as logging on or browsing a server, the call is sent to Client for Microsoft Networks.

The network provider supports these functions in Windows networks:

Browsing Microsoft networks.
Logging onto and off of a Windows NT or LAN Manager domain. The Microsoft network provider provides authentication services for validation by a domain controller, plus the ability to change the domain password using the Passwords option in the Windows 95 Control Panel.
Adding or removing connections. The Microsoft network provider allows mapped drive and printer connections plus UNC connections to SMB-based network resources.

WinNet16 Interface

The WinNet16 interface is the earlier set of network-independent APIs introduced with Windows 3.0 and enhanced in Windows 3.1. WinNet16 provides simple functionality such as connecting to a drive letter or redirecting a printer port to a network printer. Windows 95 provides support for using a single WinNet16 driver.

If a network vendor provides a WinNet16 network driver developed for Windows 3.1 and has not written a 32-bit network provider and file system driver for Windows 95, using the WinNet16 interface and WINNET16.DLL is the only way to support that network in Windows 95. The WinNet16 driver that currently works with Windows 3.1 can be used without modification under Windows 95, using the WINNET16.DLL.

If Windows 95 Setup detects a Windows 3.x installation that uses a WinNet16 network driver and there is no 32-bit network provider available, Windows 95 Setup keeps the 16-bit network driver in place and provides network functionality with the 16-bit network driver installed as the primary network.

Multiple Network Example

In the following example, the user has installed two Windows 95 network clients (Client for Microsoft Networks and Client for NetWare Networks) and also has installed Banyan VINES support using a WinNet16 driver.

Banyan VINES uses the StreetTalk™ syntax (file service@group@organization) to specify server names. In trying to resolve the request to connect to Docs@Marketing@Corp from a network drive connection dialog box in Windows 95, the multiple provider router submits the request to all installed network providers. WINNET16.DLL receives the call and passes it on to VINES.DRV, which submits the drive connection request to the Banyan real-mode networking software through VVINESD.386.

This example shows a network drive connection request with multiple networks installed.

NDIS Overview

Windows 95 supports the Network Device Interface Specification (NDIS) 2.x and NDIS 3.1 protocol drivers. This section provides some technical background information about NDIS support in Windows 95.

Support for NDIS 2 Protocols

An NDIS 2.x protocol driver must use an NDIS 2.x network adapter driver. Both protocol drivers and network adapter drivers must load and bind in real mode before launching Windows 95.

Windows 95 architecture for NDIS 2 protocols

rk32_16

Support for NDIS Network Adapters

For NDIS 3.1 adapter mini-drivers, the mini-driver divides the existing NDIS media access control (MAC) layer into two halves and implements only the half specific to the network adapter. These include specific details such as establishing communications with the adapter, turning on and off electrical isolation for Plug and Play, providing media detection, and enabling any value-added features the adapter may contain. The mini-driver wrapper implements the other half of the MAC functionality that remains common to all NDIS drivers. In earlier releases of NDIS, each adapter driver carried all this redundant code, so mini-drivers are faster and are roughly 40 percent smaller than existing NDIS 3.x network adapter drivers.

Windows 95 architecture for NDIS 3.1 protocols

rk32_17

Architecture for Network Protocols

Windows 95 includes support for IPX/SPX-compatible protocols and NetBEUI and TCP/IP. The following sections describe how support for each type of protocol is implemented in Windows 95.

Architecture for IPX/SPX-Compatible Protocol

The Microsoft IPX/SPX-compatible protocol uses the NWNBLINK.VXD module to support NetBIOS over IPX and to support the NetBIOS programming interface.

Windows 95 architecture for IPX/SPX-compatible protocol

The Microsoft IPX/SPX-compatible protocol is NDIS 3.1-compliant, allowing computers running Windows 95 to communicate over a routable IPX-compatible protocol. This protocol can use Novell NetWare servers configured as routers (and other IPX routers) to transfer its packets across LANs to access resources on other computers running Windows 95.

Architecture for NetBEUI Protocol

The NetBEUI module, NETBEUI.VXD, implements the NetBIOS framing protocol.

Windows 95 architecture for NetBEUI protocol

Architecture for Microsoft TCP/IP Protocol

TCP/IP is a popular routable protocol for wide-area networks. The TCP/IP module, VTCP.VXD, is accessible through the Windows Sockets interface or through the NetBIOS interface. For information about Windows Sockets and interprocess communication mechanisms, see "NetBIOS" later in this chapter.

Windows 95 architecture for Microsoft TCP/IP

Architecture for Clients, Peer Servers, and IPC

You can install either or both of the 32-bit, protected-mode networking clients, Client for NetWare Networks and Client for Microsoft Networks. The following sections describe the architecture for these two clients and the related peer servers, plus information about the support for interprocess communications.

Architecture for Client for NetWare Networks with Client for Microsoft Networks

Client for Microsoft Networks Architecture

Windows 95 provides a 32-bit protected mode file system driver to support all Microsoft networking products that use the SMB file sharing protocol. This includes LAN Manager, Windows NT, Windows for Workgroups 3.x, Workgroup Add-on for MS-DOS, and Windows 95. Network products from other vendors using the Microsoft network standard are also supported, such as LAN Manager, IBM® LAN Server, and 3Com® 3+Open®.

Windows 95 architecture for Windows networking

Client for Microsoft Networks supports connectivity over any NDIS protocol that supports a NetBIOS interface and is accessible through VNETBIOS.386. The protected-mode protocols shipped with Windows 95 that support a NetBIOS interface are the following:

NetBEUI using NETBEUI.VXD
NetBIOS over TCP/IP using VNBT.VXD and the TCP/IP components, VTCP.VXD and VIP.VXD
NetBIOS over IPX/SPX using NWNBLINK.VXD and NWLINK3VXD

Client for Microsoft Networks also supports connectivity over IPX/SPX using NWLINK.VXD without the NetBIOS interface.

Client for NetWare Networks Architecture

You can use Client for NetWare Networks in an environment where all that is needed is a 32-bit client to connect to existing NetWare servers (for example, if there is no need for SMB-based peer resource sharing services).

Architecture for Client for NetWare Networks as the sole client

rk32_13

For details about the architecture for Windows 95 with Novell-supplied network clients, see Chapter 9, "Windows 95 on NetWare Networks."

Windows 95 includes components to support file and printer sharing on Microsoft networks and NetWare networks.

When File and Printer Sharing for Microsoft Networks is installed, the Windows 95 SMB server (VSERVER.VXD) is added to the computer's configuration. This component supports all Microsoft networking products that use the SMB file-sharing protocol. The following illustration shows the basic supporting files for File and Printer Sharing for Microsoft Networks in the Windows 95 networking architecture.

Architecture for File and Printer Sharing for Microsoft Networks

When File and Printer Sharing for NetWare Networks is installed, the Windows 95 NCP server (NWSERVER.VXD) is added to the computer's configuration. Client for NetWare Networks is used to get NetWare server connection information and to enable user-level security based on a NetWare server's user accounts. The following illustration shows the supporting files for File and Printer Sharing for NetWare Networks in the Windows 95 networking architecture.

Architecture for File and Printer Sharing for NetWare Networks

For File and Printer Sharing services with user-level security, the security provider (MSSP.VXD or NWSP.VXD) assists in validating user access when sharing a resource and in retrieving a user list when administrating the server. The network address book (MSAB32.DLL or NWAB32.DLL) translates the account lists from the server and provides the Add Users dialog box for selecting which users get access rights. The file security component (FILESEC.VXD) provides access control based on information in the Registry. Notice that these same security components support features such as remote Registry access even when File and Printer Sharing services are not present.

IPC and Windows 95

Windows 95 includes several mechanisms that support distributed computing. Typically, distributed computing means that a computing task is divided into two parts. The first part runs on the client computer and requires minimal resources. The other part of the process runs on the server and requires large amounts of data, number crunching, or specialized hardware.

Another type of distributed computing spreads the work among multiple computers. For example, one computer can work on a complex math problem that would take a month to solve. But with distributed computing, 50 computers could work on the same math problem simultaneously and solve it in less than a day.

In both cases, a connection between computers at a process-to-process level allows data to flow in both directions. Windows 95 includes the following interprocess communication (IPC) mechanisms to support distributed computing: Windows Sockets, Remote Procedure Calls (RPC), NetBIOS, named pipes, and mailslots. The following sections provide details about these IPC implementations in Windows 95.

Windows Sockets

Windows Sockets is a Windows implementation of the widely used U.C. Berkeley Sockets API, the de facto standard for accessing datagram and session services over TCP/IP. Non-NetBIOS applications must be written to the Sockets interface to access Microsoft TCP/IP protocols. Applications written to the Sockets interface include FTP and SNMP. In Windows 95, sockets support is also extended to IPX/SPX.

Windows Sockets in Windows 95 is a protocol-independent networking API tailored for use by programmers using the Windows family of products. Windows Sockets is a public specification that aims to do the following:

Provide a familiar networking API to programmers using Windows or UNIX
Offer binary compatibility between heterogeneous Windows-based TCP/IP stack and utility vendors
Support both connection-oriented and connectionless protocols

Sockets provide reduced overhead when compared with a NetBIOS protocol. Non-NetBIOS native protocols such as TCP/IP and IPX/SPX require a NetBIOS interface and mapping layer. This extra NetBIOS software adds processing time and also adds a header to the data frame sent on the wire. For example, when the NetBIOS interface is used over TCP/IP, a NetBIOS header is added to the frame before the TCP and IP headers. Workstations running only TCP/IP cannot see this frame. However, when sockets are used, the frame is sent using TCP/IP without the addition of a NetBIOS header.

In TCP/IP, the internetwork address is the IP address of the workstation and the software process address is the port number. Source and destination IP address and port numbers are fields in the TCP/IP packet structure. In IPX/SPX, the internetwork address is the combination of the IPX network ID and the media access control (MAC) address of the network adapter, and the software process address is the IPX Socket number. Source network, destination network, node, and socket numbers are fields in the IPX/SPX packet structure.

Note: IPX Sockets are not the same as Windows Sockets.

For a bidirectional path, a Windows Sockets application specifies the following, depending on the protocol.

Protocol	Source and destination socket identifiers
TCP/IP bidirectional path	IP address and port number of the source
IPX/SPX bidirectional path	Network ID, MAC address of the network adapter, IPX socket number

The following table describes the supporting files for 16-bit and 32-bit Windows Sockets over TCP/IP and 32-bit Windows Sockets over IPX/SPX.

File	Description	Comments
WINSOCK.DLL	16-bit Windows Sockets	Provides backward compatibility with existing 16-bit TCP/IP Windows Sockets applications such as ping
WSOCK.VXD	Virtualized Windows Sockets	Supports 16-bit Windows Sockets and 32-bit TCP/IP and IPX/SPX Windows Sockets
WSTCP.VXD	Windows Sockets over TCP/IP1	Supports 16-bit Windows Sockets and 32-bit TCP/IP Windows Sockets
WSOCK32.DLL	32-bit Windows Socket	Supports 32-bit TCP/IP Windows Socket applications such as telnet and 32-bit IPX/SPX Windows Socket applications
WSIPX.VXD	Windows Sockets over IPX/SPX2	Supports 32-bit IPX/SPX Windows Sockets

1 Windows Sockets over TCP/IP are STREAMS-based over TCP and datagram-based over UDP.

2 Windows Sockets over IPX/SPX are STREAMS-based over SPX and datagram-based over IPX.

Popular programs such as ftp or telnet use Windows Sockets. If you are interested in developing a Windows Sockets 1.1 application, specifications for Windows Sockets are available on the Internet from ftp.microsoft.com, on CompuServe® in the MSL library, and in the Microsoft Win32 Software Development Kit.

RPC

The Microsoft RPC facility is compatible with the Open Software Foundation (OSF) Data Communication Exchange (DCE) specification for remote procedure calls and is completely interoperable with other DCE-based RPC systems such as those for HP and IBM AIX® systems. (The RPC facility is not compliant with the OSF specification — that is, it doesn't start with the OSF source code and build on it.)

RPC uses other IPC mechanisms, such as named pipes, NetBIOS, or Windows Sockets, to establish communications between the client and the server. With the RPC facility, essential program logic and related procedure code can exist on different computers, which is important for distributed applications.

As shown in the following diagram, Windows 95 provides RPC client support over the NetBIOS, named pipes, and Windows Sockets interfaces.

RPC client support in Windows 95

The following diagram shows how Windows 95 provides RPC server support over NetBIOS and Windows Sockets. There is no server support for RPC over named pipes. With a named-pipes RPC application, the named-pipes client can be run on the computer running Windows 95 but the named-pipes server must be set up on a LAN Manager server or Windows NT computer.

RPC server support in Windows 95

NetBIOS

NetBIOS can be used in Windows 95 for communication between protocols and upper-level software such as the redirector and server service. NetBIOS provides backward compatibility for existing NetBIOS applications. NetBIOS provides a protocol-independent way of creating sessions and datagrams, and supporting name resolution over multiple protocols. NetBIOS is supported by the Microsoft TCP/IP, NetBEUI, and IPX/SPX-compatible protocols in Windows 95. The additional NetBIOS driver and DLL enable Windows 95 to be compatible with NetBIOS applications and to run software that specifically requires NetBIOS. The NetBIOS software is used only for these situations.

NetBIOS defines the interface between the redirector and the protocol layers. The NetBIOS interface is a set of function calls that allow an application (such as the redirector in the Windows 95 protected-mode network client) to use the services of a Transport-layer service provider such as the NetBEUI protocol driver.

Many network applications use NetBIOS to send commands to the protocol driver. As long as a protocol driver recognizes NetBIOS commands issued by an application, that protocol driver can be used with any NetBIOS application. The NetBIOS interface in Windows 95 (NETBIOS.DLL and VNETBIOS.386) is supported by all three protocols shipped with Windows 95.

The architecture for NetBIOS over the various protocols is described with the respective protocols earlier in this chapter.

Client-Side Named Pipes

Named pipes provides backward compatibility with existing LAN Manager installations and applications. Windows 95 supports client-side named pipes for Microsoft networks. Server-side named pipes are not supported.

Client for Microsoft Networks makes the Named Pipes API available for applications that use named pipes for IPC. However, Client for Microsoft Networks does not provide named pipes support for other networks such as Novell NetWare and Banyan VINES. A user who needs Novell NetWare or Banyan VINES named-pipes support must use the real-mode TSRs and network components provided by Novell or Banyan.

Named pipes provide an easy-to-access conduit for a one-to-one, reliable, connection-oriented data transfer between two processes. These two processes are normally differentiated as a client process and a server process. The term "server" as applied to the server process in a named-pipe application does not refer to the "server service" that is a component of the network operating system, although the server service may be (but is not necessarily) involved in making the pipe available to other workstations.

The named-pipe server process creates the pipe and manages access to it. The resources that make up the pipe are owned by the server process and physically exist on the workstation where the server process is running.
The named-pipe client process uses the services of the underlying network protocols to access the remote pipe resources.

Although named pipes are usually used bidirectionally, the pipe can be configured to allow communication in only one direction, such as from server to client.

A common use for named pipes is in client-server applications based on SQL. The SQL client application can be run on a computer running Client for Microsoft Networks. The Microsoft SQL Server application, however, must be set up on a LAN Manager, Windows NT, or other named-pipes server.

Mailslots

Mailslots provide backward compatibility with existing LAN Manager installations and applications. Mailslot APIs in Windows 95 and Windows NT are a subset of the APIs in Microsoft OS/2 LAN Manager. Client for Microsoft Networks makes the Mailslots API available for applications that use mailslots for interprocess communication.

Mailslots can be used for one-to-one or one-to-many communication. A mailslot can be created on any network workstation. When a message is sent to a mailslot, the sending application specifies in the mailslot message structure whether the message is to be sent using first-class or second-class delivery.

First-class delivery is a session-oriented, guaranteed data transfer for one-to-one or one-to-many communication. Messages designated as first-class delivery can only be sent to a mailslot that was created on a server. (Notice that Windows 95 does not use first-class messaging.)

Second-class delivery is a datagram-based, unguaranteed data transfer for one-to-one and many-to-one communication. Messages designated as second-class delivery can be sent to a mailslot that was created on any workstation, or even on multiple workstations, if the message size is 400 bytes or less.

Windows 95 and Windows NT implement only second-class mailslots, which are most useful for identifying other computers or services on a network and for wide-scale identification of a service. Windows 95 uses second-class mailslots for WinPopup messages and browsing.

Windows 95 Network Architecture Overview

On This Page