Networking in Windows 95 Now that Windows 95 is on the loose, it's time to explore its underbelly so that you'll know how to make the most of its connectivity features.

November  1995

Just when you thought you knew everything there was to know about PC networking, Microsoft brings us Windows 95 WinNet. This time Bill Gates's crew has done a brilliant job. Our topic this month (and the next few columns) is WinNet: how it works and how to bend it to your will. (1,800 words)

Mail this article to a friend

Windows 95 brings the networking improvements users across the land clamored for. Microsoft's hot-selling desktop operating system allows administrators to install and use common networks with relative ease. Gone are the days of relying on third-party developers for the essential networking components that Macintosh and Unix users take for granted. TCP/IP and other stacks are built in and supported properly. But Windows 95 is not perfect, and network managers have much to learn.

If you sell or support DOS and Windows 3.1 PC networking software, you'd better study Windows 95, and fast. Windows 95 represents Microsoft's expanding grip far into this market, so much so that most PC software developers and hardware vendors recognize they must adapt their products to complement Windows 95 or fight for crumbs in smaller markets.

For both administrators and vendors, survival in the Windows 95 kingdom requires understanding the many changes the new OS offers -- improvements not only to the visual environment but also to the OS's internal structure and function.

Better doesn't mean perfect
There is much networking technology for users and developers to digest. An improved uniform networking system now integrates telephony and serial connections (e.g., ISDN, modems, voice-mail, etc.), network interface cards and systems (Ethernet, Token Ring, FDDI, wireless, and soon Asynchronous Transfer Mode), multiple co-existing protocol stacks, multiple co-existing network drivers support, and useful protocol stack implementations for TCP/IP, NetBEUI, and IPX/SPX with the base Windows 95 OS.

Yet even with these improvements, unexploited pockets remain. These niches present opportunities to third-parties that take the time to understand Windows 95 and develop products that exploit its strengths and overcome its weaknesses.

The Windows 95 architecture (no more DOS networking API)
The architecture of a networking system provides a general notion of its individual components and how the system works. Today, most networking architectures are based upon a layering idea. Each layer provides a more abstract concept of the services and components of the lower layer. This method allows a greater degree of freedom from the topmost layers while retaining functionality. Application-layer programmers thus only need to know the function calls of the layer that lets their programs use the network; they do not need to involve themselves with details of managing network device drivers, signaling, multi-protocol management, and so on.

The Windows 95 networking architecture completely replaces the Microsoft networking API created originally for DOS 3.0. As shown below in the Win32 networking architecture diagram, the structure is much more complex than the earlier simple interrupt-based link to protocol stacks. The older method sometimes caused interference between processes generating and accepting network traffic (and nothing is worse than losing data because of bad design).

At the lowest layer is an improved Datalink architecture (which Microsoft calls the Device Driver layer) that implements the NDIS 3.1 protocol standard. This provides the management services for multiple network cards, connections, and even drivers.

Above this are the transport protocols such as TCP/IP, NetBEUI, and IPX/SPX. Each transport layer protocol is accessible independently as required and has access to the network drivers layer as needed. There is no longer contention between the transport protocols for these services. The transport programming interface is the next layer. The two current implementations within Windows 95 are the NetBIOS and Windows Sockets systems. A software developer can now write network-aware programs using one application programming interface (API) set for TCP/IP, IPX/SPX, NetBIOS, or even AppleTalk-based communications; previously, each network operating system (NOS) vendor had its own specific APIs and programmers had to learn each separately.

Above this layer is the Network Redirectors layer, which provides NOS-specific service mechanisms; this implementation is similar to NETX for the NetWare environment and the LAN Manager service mechanism for Microsoft Networks.

At the very top is the Multiple Provider Router (MPR), which interfaces between the application and the entire network architecture to control which transport mechanism and subinterfaces will be used for the communications. The MPR also controls system-level functions like access to network disk drives and printers.

The Datalink architecture
At the base Datalink layer (as shown in the Transport layer diagram), Windows 95 supports multiple Network Interface Cards (NICs), each accessible by the different protocols as needed through the Protected Mode (32-bit mode) Network Device Interface Specification (NDIS) version 3.1. Through its NDIS 2.x support layer, Windows 95 also supports numerous drivers written for the Real-mode (16-bit) NDIS 2.0 standard.

In NDIS 3.1, to interface with each card requires a Media Access Control (MAC)-layer driver, which Microsoft has decided to split further to provide more efficient drivers. The MAC layer now can be either a single whole NDIS 3.1-based driver or a mini-driver that interfaces with the NDISWRAP.VXD support layer to make up one whole NDIS 3.1- based driver. For example, the 3Com Etherlink III driver (known as elnk3.vxd) is a single NDIS 3.1 driver. With the initial Windows 95 distribution, there are no mini-drivers available. Above this layer is the NDIS.VXD system, which connects all network drivers with the communication protocols.

For NDIS 2.x drivers, there are two support files that emulate the older standard so that the driver will still function without rewriting. The immediate interface to one or several NDIS 2.x MAC-layer drivers is the NDISHLP.SYS layer. Each 2.x MAC has its own NDISHLP.SYS interface. Above this is a single NDIS2SUP.VXD interface between all the MAC drivers and the NDIS 3.1 system. These two layers combine to simulate an NDIS 3.1-conformant driver over an NDIS 2.x MAC driver. Above these layers is the NDIS.VXD layer as mentioned before.

NDIS 3.1 can also support Novell's Open Datalink Interface (ODI). ODI drivers work similarly to the NDIS 2.x system, and were created before substantial improvements to the NDIS system. These have since spread into common use in NetWare-centric PC networks.

When you install Windows 95, the system will attempt to check your hardware to determine the make and model of any network cards that you have and install NDIS 3.1 version drivers for these cards. If the system cannot find the proper drivers, it will prompt you to install them separately through software provided by your manufacturer. Most of the common network cards currently available are supported in the Windows 95 system software itself. If you have an older card with NDIS 2.x, or ODI, the system may recognize it without trouble and install any necessary components.

The Transport Protocol architecture
On top of the NDIS datalink architecture lies the individual "protocol stacks" that provide the network protocol transport mechanisms. The meaning of the phrase "protocol stack" has changed from its definition in the architecture for Windows 3.1, which consisted of the entire stack interfaced directly with the application. In the Win32 network architecture, the Transport Protocol system provides only the mechanisms required for packaging data into network protocol packets. The application's actual use of a stack is handled elsewhere.

Windows 95's core protocols include TCP/IP, NetBEUI, and IPX/SPX. A separated VxD-based stack supports each. All interfaces to the Datalink layer go through the NDIS 3.1 (NDIS.VXD) system. Interfaces to the application layer above go through the Windows Sockets and NetBIOS layers.

TCP/IP

The Microsoft TCP/IP implementation consists of several layers: VIP.386 (IP layer), VTCP.386 (TCP and UDP layer), WSTCP.VXD (interface between VTCP.386 and the Windows sockets implementation), WSOCK.VXD (Windows sockets implementation), VNBT.386 (NetBIOS transport layer), VNETBIOS.386 (Win32 and Win16 NetBIOS application interface), and NETBIOS.DLL (Real-mode NetBIOS application interface). In addition, a layer provides services for the Dynamic Host Configuration Protocol known as DHCP.386, and provides a programming interface to the transport mechanism through the VTCP.VXD interface. The two primary application-layer interfaces available over TCP/IP are the NetBIOS and the Windows Sockets interfaces.

NetBEUI

NetBEUI is the traditional DOS and Windows networking protocol for transport-layer functions. Explicitly created to provide a transport mechanism for the NetBIOS system, today NetBEUI is one of several such mechanisms available. NETBEUI.VXD is the transport mechanism that lies immediately above the NDIS layer. This interacts with VNETBIOS.386 (as described earlier) and with the NETBIOS.DLL above it to provide the call mechanisms for Win32 and Real-mode access, respectively, to this transport system.

IPX/SPX

This is the communications protocol for Novell's NetWare family. The Internetwork Packet eXchange (IPX) provides the actual transport mechanism for the delivery of data. The Sequenced Packet eXchange (SPX) and SPX-II provide reliable transport mechanisms for application internetwork communication.

Immediately above the NDIS.VXD is the NWLINK.VXD (IPX/SPX layer). There are two parallel layers above this. One supports Windows Sockets (WSIPX.VXD) and another supports NetBIOS (NWNBLINK.VXD).

Next month...
We'll stop here before you're overwhelmed. As you can see, the network hardware and driver system has gotten more complex. So far, we have avoided most of the details of how the Microsoft Telephony API (TAPI) works with serial line, modem, and ISDN communications. Let's finish with the core networking system before we explore this other system.

Next month we'll learn more about the transport programming interfaces, redirectors, network providers, and the Win32 WinNet API. These higher layers deal primarily with creating more abstract intermediary layers that allow the variety of network-based applications to function as they would under the older DOS-based networking system as well with WinNet.

Resources

• Microsoft White Paper on Windows 95 & Novell Networking
  http://www.microsoft.com/TechNet/ps/win95/technote/novell.htm
• Microsoft White Paper on Windows 95 Networking
  ftp://ftp.microsoft.com/peropsys/Win_News/Docs/W95NET.ZIP Microsoft Windows 95 Resource Kit (Microsoft Press, 1995; ISBN: 1-55615-678-2)
• Microsoft Windows Networking Newsgroup news:comp.os.ms-windows.networking.windows
  
• MS Windows Networking with TCP/IP Newsgroup news:comp.os.ms-windows.networking.tcp-ip
  

About the author
Rawn Shah is the vice president of RTD Systems & Networking, Inc., a Tucson, AZ-based consultancy and software developer. Reach Rawn at rawn.shah@sunworld.com.

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-11-1995/swol-11-connectivity.html
Last modified: