Novell is now a part of Micro Focus

Overview of NetWare Client 32 for Windows 95

Articles and Tips: article

BEN HENDRICK
Consultant
Novell Consulting Services

01 Nov 1996


Describes the networking architecture in Windows 95 and howClient 32 interacts with it.

Introduction

The NetWare Client 32 product family represents the next step in the evolution of Novell's client software. The architecture of this new client has been completely redesigned to take full advantage of the 32-bit capabilities of the 80386 and higher microprocessors. Client 32 combines the best elements of Novell's previous client architectures (the NETX Shell and the NetWare DOS Requester, or "VLM" client) and adds some significant enhancements of its own.

NetWare Client 32 is a two-fold release. One version is NetWare Client 32 for Windows 95, which extends the Windows 95 desktop by fully integrating with NetWare 2.x, 3.x, and 4.x services, including Bindery and Novell Directory Services (NDS). The other version of the 32-bit client is NetWare Client 32 for DOS/Windows 3.x, designed for PCs running DOS, Windows 3.1, or Windows for Workgroups 3.11. While there are many similarities between these two client versions, there are also significant differences. This AppNote covers only NetWare Client 32 for Windows 95. (For more information about NetWare Client 32 for DOS/Windows 3.x, see the May 1996 issue of Novell Application Notes.)

This introductory AppNote provides a general overview of the Windows 95 networking architecture. It covers the following topics:

  • The Windows 95 networking architecture

  • How NetWare Client 32 for Windows 95 interfaces with and enhances that environment

  • The various components that make up the Client 32 software

If you understand the underlying architecture, components, and terminology of Windows 95 and NetWare Client 32, you will be better prepared to install, configure, and troubleshoot Windows 95 workstations.

Windows 95 Networking Architecture

Windows 3.x was not designed with networking in mind. It wasn't until the release of Windows for Workgroups that Microsoft began adding networking features to the Windows platform. With the release of Windows NT, Microsoft introduced a new architecture designed for networking. Windows 95 inherited much of this new networking architecture, giving Windows 95 a consistent network model that is comparable to that of Windows NT.

One of the biggest problems integrators faced in the past was getting two network redirectors from various vendors (Banyan, DEC, IBM, Microsoft and Novell) to coexist. To alleviate this problem, Microsoft designed the networking architecture of Windows 95 to support more than one "network provider" at a time. This architecture allows multiple protected-mode network clients to run at the same time, as long as they are specifically written to the Windows 95 networking interface.

To better understand the networking architecture of Windows 95, it helps to be familiar with the different network components and with the terminology involved. This section:

  • Describes the components of the Windows 95 networking architecture.

  • Identifies the network redirectors and servers that are natively supportedin Windows 95.

  • Compares the different protocol options available in Windows 95 andidentifies the protocol interfaces that are supported.

Components of the Windows 95 Networking Architecture

Windows 3.1 and Windows for Workgroups 3.11 used an Application Program Interface (API) referred to as "WinNet 16" to interface with the network. For Windows NT, Microsoft developed a new 32-bit interface called the "Win32 WinNet" or "WinNet 32" API. In designing the networking architecture of Windows 95, Microsoft had three main design goals:

  1. To support the Win32 WinNet APIs that were defined in Windows NT and apply these APIs in Windows 95. To meet this goal, Microsoft updated all "WNet" commands and function calls (such as WNetGetConnection) to support the same interface that Windows NT provides.

  2. To ensure that Windows 95 is backwards compatible with the networking architecture of Windows for Workgroups 3.11. Besides providing compatibility with WinNet 16 calls, this meant supporting one WinNet16 network driver. (For Novell, this is the NETWARE.DRV driver that comes with theNetWare DOS Requester.)

  3. To provide a generic API interface that allows seamless browsing of network resources. Since multiple networks are supported, application requests to list non-specific resources (such as "all known servers") use the generic WinNet API to query the different providers and redirectors that are enabled to display those resources. This browsing capability appears in Windows 95 programs such as Network Neighborhood, My Computer, andthe Explorer.Figure 1 illustrates the resulting networking architecture of Windows 95.

Figure 1: The Windows 95 networking architecture is modularized and layered.

This diagram shows the different paths that network requests take from applications that make either WinNet 16 or WinNet 32 calls. All of these calls are passed through the Multiple Provider Router (MPR) to the proper network provider. In the case of a WinNet 16 API call, the request goes through USER.EXE and is routed to the WinNet 16 Network Provider, which passes it on to the WinNet 16 network driver to get it out onto the network. Win32 API calls are routed to the appropriate Network Provider, which passes them through the Installable File System Manager (IFSMGR) to the appropriate network File System Driver (FSD). From there, they go to the protocol driver, and onto the network through an NDIS (Network Device Interface Specification) or ODI (Open Data-link Interface) LAN driver.

What Microsoft has basically done is modularized the networking architecture so that requests are routed by several different "managers" through the various layers. The following paragraphs describe the purpose and function of each of these architectural components in more detail.

Multiple Provider Router. Microsoft's Multiple Provider Router, or MPR, is the component that manages the network API calls. It is implemented as a Dynamic Link Library (DLL) running in Windows 95. The MPR is a request manager that collects calls and determines which provider to route the call to.

As a 32-bit example, suppose you are using a Windows 95 application such as the Explorer or Network Neighborhood, and you click on an option that makes a NetWare request. The program issues a call using the Win 32 WinNet API. The call goes to the MPR, which routes it to Novell's Network Provider (DLL).

As a 16-bit example, suppose you are running the NetWare User Tools (NWUSER.EXE) utility, a NetWare DOS Requester application that is supported in the Windows 95 client as well. NWUSER is hooked into Novell's NETWARE.DRV driver, which uses a WinNet 16 call to make network requests. The application calls USER.EXE, and is then passed by the MultipleProvider Router to the supported WinNet 16 Network Provider (NETWARE.DRVin this case).

Network Providers. The MPR interacts with the various Network Providers, such as Microsoft's Network Provider, Novell's NetWare Network Provider, or other third-party 32-bit network providers. For WinNet 16 applications, the MPR interacts with one WinNet 16 Network Provider (see Figure 2).

Figure 2: Windows 95 supports multiple Network Providers.

The Microsoft Network Provider is a 32-bit network-specific driver interface contained in the MSNP32.DLLand MSNET32.DLL files. If an application issues an SMB (Server Message Block) call to a Microsoft network, it uses the WinNet 32 API. The call is passed down through the MPR, which routes the call to the Microsoft Network Provider.

Microsoft has included a 32-bit NetWare-compatible network provider as a standard part of Windows 95. This component is officially called the "Network Provider File for Novell" and is contained in the NWNP32.DLL and NWNET32.DLL files. With this provider loaded, when an application issues a WinNet 32 call for NetWare services, the NetWare Network Provider translates the call into an NCP request. The MPR then routes the call to the appropriate network provider.


Note: Do not confuse the NetWare-compatible provider supplied by Microsoft with the NetWare Provider (NOVELLNP.DLL) that comes with Novell's Client 32 software.Novell's NetWare Provider allows you to perform network functions such as loggingin, authenticating to NDS, and accessing NetWare resources. You perform thesefunctions through the Windows 95 interface available in the Explorer or NetworkNeighborhood programs, which interact through the networking architecture ofWindows 95. (The NetWare Provider is covered in more detail in the AppNote"Accessing Network Resources with the GUI Login Utility and the NetWare Provider"in this issue.)

Typically, the installed Network Providers are sorted by a value in the Windows 95 Registry database. Providers with lower values are called before those with higher values. One of the providers is designated as the Primary provider. Other providers are available, such as the print provider, but they are outside the scope of this AppNote.

Network File System Drivers. Microsoft has written a number of File System Drivers (FSDs), or "redirectors." One example is Microsoft's SMB Redirector, called VREDIR.VXD. Another is the Microsoft-supplied NetWare Redirector, called NWREDIR.VXD. VxDs are "virtual device drivers," which is how Microsoft implements Ring 0 interaction with the Windows 95 operating system kernel and various interfaces for protected-mode clients (see Figure 3).

Figure 3: Network file system drivers (redirectors).

Microsoft also supplies other file system drivers, including the disk drive interface, which handles all disk I/O activity. There is also a CD-ROM file system driver that is implemented as a VxD and interfaces with the IFS Manager.

VCACHE.VXD is a common cache that File System Drivers use. All of the FSDs mentioned above use the memory that has been allocated through VCACHE.VXD.


Note: In NetWare Client 32, the device drivers are written as NetWare Loadable Modules(NLMs) instead of as VxDs. Because of the way NetWare Client 32 is designed, itdoes not use VCACHE.VXD. It uses its own, separate cache mechanism instead.We'll explain more about how Client 32 uses this cache later in this AppNote.

Network (Peer-to-Peer) Servers

Naturally, Windows 95 supports Server Message Block (SMB), which is the protocol Microsoft clients use to talk to their servers or to other SMB clients in a peer-to-peer fashion. SMB server support for SMB clients in Windows 95 is implemented through a virtual device driver called VSERVER.VXD.

NetWare uses a similar protocol for client-server interaction, called NetWare Core Protocol (NCP). Microsoft provides a "clone" NCP server called NWSERVER.VXD with Windows 95. This NCP server claims to be the equivalent of a NetWare 3.1x server, but it is actually more like a NetWare 2.x server because it doesn't understand the "Case 87" NCPs that Novell has used in NetWare since version 3.11. NetWare Client 32 for Windows 95 does not support Microsoft's clone NCP Server and will not communicate with that server.


Note: The SMB server and the clone NCP server cannot both be installed at the same time. If you want to access both SMB and NCP services from a workstation, useVSERVER.VXD. The corresponding client must also be installed.

Protocol Interfaces

Microsoft has included a number of network protocol interfaces in Windows 95. These include:

  • NetBIOS

  • Windows Sockets (WinSock)

  • ECB (Event Control Block)

  • TDI (Transport Driver Interface)

NetBIOS Interface. All of Microsoft's offerings use the NetBIOS interface. NetBIOS provides a protocol-independent way of creating sessions, datagrams, and name resolution management over whatever transport protocol you want to use: NetBEUI, TCP/IP, or IPX/SPX (see Figure 4).

Figure 4: The NetBIOS interface in Windows 95.

The Microsoft implementation of SMB encapsulates requests within the NetBIOS interface. The NetBIOS information is ten wrapped by a transport protocol. This double-wrapping overhead has a performance effect on the client-server request.

The NetBIOS interface supports any kind of application (16-bit, 32-bit, or real-mode) as long as it is written to the standard NetBIOS calls. Microsoft provides a VxD called VNETBIOS.VXD to determine which protocol the NetBIOS application calls are routed to. For example, a Win16 NetBIOS application communicates through NETBIOS.DLL, a DLL provided for the NetBIOS interface.

Windows Sockets (WinSock) Interface. The Windows Sockets interface was originally designed to be a vendor-independent method of accessing datagram and session services over TCP/IP. Microsoft has now extended this interface to their 32-bit implementation of IPX/SPX.

With the Windows Sockets Interface, you can have a 32-bit WinSock application, such as the NetScape Web browser, and a 16-bit WinSock application, such as the Trumpet news reader, running at the same time. Each application interfaces into the appropriate DLL depending on the calls they make: WINSOCK.DLL for 16-bit application calls, and WSOCK32.DLLfor 32-bit application calls.

Figure 5 shows how information flows through the different interface layers, with the DLLs interfacing with the VxDs that they support, and the VxDs interfacing with specific transport protocols (TCP/IP or IPX/SPX).

Figure 5: The Windows Sockets (WinSock) interface in Windows 95.

Event Control Block (ECB) Interface. The ECB interface in Windows 95 allows applications to send and receive data over the IPX/SPX protocol. However, this ECB interface is different than the IPX support Novell provides with Client 32. The Windows 95 ECB interface for IPX works through Int 7Ah for 16-bit applications and through a VxD called NWLINK for 32-bit applications. NWLINK.VXD handles Microsoft's implementation of IPX (see Figure 6).

Figure 6: The ECB (Event Control Block) IPX/SPX interface.

You could use this interface if you were using Microsoft's peer-to-peer networking capability through the SMB client and you wanted your information to go over IPX. In this scenerio, your information would be routed through NWLINK, which interfaces with the IPX interface that Microsoft provides.

TDI (Transport Driver Interface). The TDI interface is strictly for TCP/IP, allowing applications to send and receive data over the Microsoft TCP/IP stack. A number of other vendors are coming out with TCP/IP modules that are TDI-compliant. Thus TDI has become a "standard" interface for all TCP/IP stack providers. Developers can write to a single API and their networking components can work with different TCP/IP stacks (see Figure 7).

Figure 7: The TDI (Transport Driver Interface) interface in Windows 95.

Novell uses TDI to provide support for NetWare/IP in Client 32. Instead of providing our own TCP/IP stack, we use Microsoft's TCP/IP stack so that Client 32 can run NetWare/IP client/server access through Microsoft's TDI interface. If you are using a TDI-compliant TCP/IP stack from another vendor, NetWare Client 32 can interface through that stack when accessing NetWare/IP servers.

Transport Protocols

The transport ("network") protocols that Microsoft supports in Windows 95 include:

  • NetBEUI

  • IPX/SPX

  • TCP/IP

  • SDLC

In this discussion of Microsoft's Windows 95 architecture, the examples are NDIS-based. Later in this AppNote we'll look at how ODI drivers are supported in Novell's Client 32 networking architecture.

NetBEUI Protocol. NetBEUI (NetBIOS Extended User Interface) is an implementation and extension of the NetBIOS transport protocol. It is used by Microsoft to communicate with a network through the NDIS interface. In Windows 95, NetBIOS-based applications communicate through the NetBIOS interface. The VNETBIOS.VXD module routes the requests to a specific transport protocol driver-- NETBEUI.VXD in this case--which then interfaces with NDIS.VXD(see Figure 8).

Figure 8: The NetBEUI protocol in Windows 95.

If you are using Novell's Client 32 with a 32-bit ODI driver, Novell provides an ODINSUP module that interfaces with NETBEUI.VXD and emulates the NDIS interface. The NetBIOS application interfaces with NETBEUI.VXD as usual, but the requests are translated by ODINSUP. From here, requests are passed to the ODI driver, rather than going through the NDIS interface, and are then transmitted onto the wire. Novell also provides a VMLID shim which allows ODI protocols and requesters to run over an NDIS driver. This is discussed in more detail later in this AppNote when we talk about NetWare Client 32.

IPX/SPX Compatible Protocol. Microsoft provides an IPX/SPX compatible protocols that not only IPX/SPX-based applications can use, but also Win32 sockets applications and NetBIOS applications (see Figure 9).

Figure 9: The Windows 95 IPX/SPX compatible protocol.

Requests from a Windows Sockets application, for example, flow down through the 32-bit WinSock DLL to WSOCK.VXD. Because we're using IPX, the communications flow goes to WSIPX.VXD, then to the NWLINK interface, and then to the NDIS interface and out onto the network.

TCP/IP Protocol. In Windows 95, TDI-based applications, Windows Sockets applications, and NetBIOS applications can all use TCP/IP as their transport protocol. A TDI application, for example, interfaces with VTDI.386 and then passes on to the VTCP.386 driver, down to the VIP.386 driver, and finally through NDIS.VXD (see Figure 10).

Figure 10: The TCP/IP protocol in Windows 95.

32-bit DLC (Data Link Control) Protocol. Since the initial release of Windows 95, Microsoft has added support for DLC (Data Link Control) drivers for accessing IBM mainframes. A service pack add-on to Windows 95 includes 32-bit DLC software which allows mainframe access to plug into Windows 95's existing networking models. In the past it was an intricate process to integrate LAN-based clients with the DLC protocol. But with 32-bit DLC support integrated into this new architecture, connecting LAN users and mainframes is significantly easier.


Note: The service pack update from Microsoft includes this as well as other patches that arerequired for using NetWare Client 32. You can download the service pack from theWorld Wide Web at http://www.microsoft.com/.

Windows 95 Support for Netcard Drivers

The last part of the Windows 95 networking architecture we need to look at is the support for various types of network interface card drivers. Out of the box, Windows 95 supports four basic groups of drivers:

  • NDIS 3.1 drivers

  • NDIS 3.0 "mini-port" drivers

  • NDIS 2.x drivers

  • 16-bit ODI "MLID" drivers

Figure 11 summarizes the components that provide support for these drivers in Windows 95.

Figure 11: Windows 95 support for netcard drivers.


Note: Both NDIS 3.1 and 3.0 drivers interface directly with the network interface board.NDIS 2.x drivers must go through a real-mode interface, as do 16-bit ODI drivers.

NDIS 3.1 Drivers. The main differences between NDIS 3.1 and 3.0 drivers are that the 3.1 drivers are more modularized and they support Plug-and-Play in addition to the "mini-port" model (explained below). NDIS 3.1 drivers can also be used with NetWare Client 32, as we'll discuss later in this AppNote.

NDIS 3.0 Mini-Port Drivers. With NDIS 3.0, Microsoft introduced the "mini-port" model for NDIS drivers. This model splits out the functionality so that NDIS can support multiple LAN drivers, similar to what Novell's ODI technology provides. The NDIS.VXD is analagous to Novell's Link Support Layer, and functions as an interface that communicates down to hardware-specific modules: either a VXD netcard driver or a mini-port *.SYS file.

Windows for Workgroups shipped with NDIS 3.0 mini-port drivers, which are compatible with Windows 95. You can use these drivers if you don't have any NDIS 3.1 drivers for your network adapter.

NDIS 2.x Drivers. Windows 95 will work with NDIS 2.x drivers. However, NDIS 2.x drivers are 16-bit, real-mode drivers, so they are not as easy to set up and use. They require an NDIS2SUP.VXD module and an NDISHLP.SYS shim in addition to the *.DOS driver file itself. (From the Novell client perspective, Client 32 doesn't support NDIS 2.x real-mode drivers, only protected-mode drivers.)


Note: Up until recently, DLC was the only protocol that still required 16-bit, real-mode drivers in Windows 95. The 32-bit version of DLC, included in the Windows 95 Service Pack 1, eliminates the need to run NDIS 2.x drivers.

ODI Drivers (MLIDs). Windows 95 also works with 16-bit ODI drivers, sometimes referred to as MLIDs (Multiple Link Interface Drivers). This support is similar to what is offered in Windows for Workgroups in the form of an ODI Help shim. ODIHLP.EXE registers itself at the LSL level as a pre-scan module and as the default protocol stack. Microsoft's 32-bit protocol stacks communicate through NDIS.VXD. NDIS talks to a module called MSODISUP.VXD, which translates between NDIS and ODI. The ODIHLP shim knows how to talk to both MSODISUP and LSL.COM. From the LSL, requests go out onto the network through a 16-bit MLID ODI driver.

NetWare Client 32 Architectural Overview

Up until now we have been discussing the Windows 95 networking architecture from Microsoft's perspective. We now turn our attention to NetWare Client 32 and how it hooks into the model that Microsoft has provided. This section provides an overview of the NetWare Client 32 architecture and describes the various components included in the software.

Client 32 Design Goals

Novell programmers designed the underlying architecture of the 32-bit clients to be dynamic, modular, and portable. Their main goal was to create a consistent, cross-platform architecture that could be integrated as tighly as possible to the native DOS, Windows 3.1x, and Windows 95 environments. Even though each of these desktop operating environments is unique, Novell hoped to supply similar features for 32-bit access, as well as client utilities that have a consistent look-and-feel across platforms.

Another design goal was to ensure that Client 32 is backwards compatible with Novell's previous client software--the NetWare Shell (NETX) and the NetWare DOS Requester (VLMs). Client 32 emulates and supports the existing 16-bit client interfaces, so applications that worked with the VLMs or NETX will continue to work under Client 32.

The 32-bit client code is written entirely in ANSI C, and it makes no calls to a specific operating system or networking protocol. This portable design allows the underlying architecture to be independent of client operating system, name services, and authentication methods, as well as session and transport layer protocols.


Note: Client 32 is based on NCP (NetWare Core Protocol), not on Microsoft's SMB (Server Message Block) protocol. Therefore, Client 32 cannot talk to Windows NT servers or to peer-to-peer servers in Windows 95, unless you also load an SMB Redirector. (The procedure for doing this is given in the AppNote entitled "Installing NetWare Client 32 for Windows 95" later in this issue.)

Architectural Highlights

NetWare Client 32 for Windows 95 offers full 32-bit access to NetWare services, including Novell Directory Services (NDS). Build on the same code-base as NetWare Client 32 for DOS/ Windows, the NetWare Client 32 for Windows 95 software provides advanced features such as full automatic reconnection to all network files and resources, simultaneous access to multiple NDS trees, and local file caching routines. (See Appendix A of this issue for a full listing of NetWare Client 32 features.)

NetWare Client 32 for Windows 95 is designed for workstations running Microsoft Windows 95. It supports bindery connections to NetWare 2.2 and 3.1x servers, as well as NDS connections in NetWare 4.x networks. Although Client 32 is not exclusively for NetWare 4, it does take advantage of some of NetWare 4's extended capabilities, such as extended NCPs (NetWare Core Protocols).


Note: At this time, Client 32 does not support peer-to-peer connections via PersonalNetWare.

Windows 95 users can maintain peer-to-peer connectivity with other Windows 95 machines on the network while running NetWare Client 32.

NetWare Client 32 is designed to take full advantage of the 32-bit capabilities of Intel's 386, 486, and Pentium microprocessors. Unlike the 286 microprocessor, which addresses memory in 16-bit chunks, these newer microprocessors address memory in 32-bit chunks and can therefore run 32-bit programs. Because 32-bit processors can move data in bigger chunks, a program that is optimized for 32-bit processors can be smaller and execute much faster than the same program written to run on 16-bit computers.

Based on NetWare Server Technology. If you are familiar with the NetWare 3 and 4 server architecture, you will recognize many of the same architectural elements implemented in Client 32 for Windows 95. These elements include protected-mode execution, a flat memory model, advanced memory management, and even client NetWare Loadable Modules (NLMs) and 32-bit ODI LAN drivers. We'll discuss these elements in more detail as we go along.

Protected-Mode Operation. Novell's previous clients--NETX and the VLMs--operate in 16-bit real mode, which requires conventional memory. By contrast, NetWare Client 32 for Windows 95 operates in protected mode. When the CPU is running in protected mode, memory is addressable as one continuous range of addresses. This flat memory model makes memory allocation and management much more efficient and flexible. By using protected-mode services, Client 32 loads exclusively in extended memory, with only a 3-4KB footprint in conventional memory for backwards compatibility.

NLM Components. Novell's NetWare Client 32 is different from its Microsoft counterparts because the device drivers are written as NetWare Loadable Modules (NLMs). NLMs are similar to VxDs in nature, and they work similarly as far as functionality in the calls and interfaces to the resources available to them. The exception is that VXDs must be written in Assembly language, while client NLMs are written in C code. The set of 32-bit NLMs that come with NetWare Client 32 are similar to (but not interchangeable with) those that are loaded on NetWare servers. These client-based NLMs can be loaded and unloaded in extended memory as needed. They no longer have to rely on terminate-and-stay-resident (TSR) programming with its inherent quirks.

"Shell" Design. Another difference between Microsoft's network components and Novell's Client 32 is that Client 32 is not a File System Device or Redirector. Instead, Novell implemented Client 32 as an Interrupt 21 "shell," similar to the technology we used with the NETX Shell client software. Client 32 hooks in above the IFS Manager, and therefore it receives all application calls before the IFS Manager does. Client 32 looks at the information and passes all NetWare requests to the Client 32 Requester NLM. Any request that is not destined for a NetWare network is passed on to the IFS Manager to interact with the other FSDs that are installed (see Figure 12).

Novell chose the shell technology for Client 32 to avoid some of the problems that the NetWare DOS Requester experienced initially when certain network requests were not sent through the Int 2Fh interface. As an Int 21h shell, Client 32 is able to catch all requests before they go to the Windows 95 IFS Manager. Client 32 can then process NetWare requests as needed, and pass the others to the IFS Manager to be routed to the appropriate FSDs.

In addition, an Int 21 shell is not limited to the rules of DOS like DOS Requesters are. Thus Client 32 does not require the LASTDRIVE=Z parameter in the CONFIG.SYS file, as is the case with the NetWare DOS Requester. Another problem solved by implementing Client 32 as a shell has to do with accessing the SYS:LOGIN directory to run the LOGIN.EXE program. Due to a quirk of DOS, workstations running the VLMs would see a mapping to the root directory (F:\) rather than to the SYS:LOGIN subdirectory (F:\LOGIN) after the client software loaded. This isn't as much of an issue now that Novell is providing a graphical login utility for Windows and Windows 95 workstations with Client 32. But on DOS workstations running Client 32, users will see the desired mapping to F:\LOGIN so they can run the LOGIN.EXE text utility if needed.

Figure 12: Client 32 is implemented as an Int 21 shell that hooks in above the Windows 95 IFS Manager.

Client 32 Components

The Client 32 architecture is comprised of three main components that make up the 32-bit client environment:

  • The NetWare I/O Subsystem (NIOS.NLM)

  • LAN drivers and communications protocols (LSLC32.NLM, CMSM.NLM,CNE2000.LAN, IPX.NLM, TCPIP.NLM, SNMP.NLM, and so on)

  • The NetWare Client 32 Requester (CLIENT32.NLM)

In addition, NetWare Client 32 for Windows 95 comes with a number of client utilities, including the GUI Login utility, the NetWare Provider, and the NetWare Application Manager. The following sections describe the Client 32 architectural components listed above. The client utilities are discussed in other AppNotes in this issue.

The NetWare I/O Subsystem (NIOS)

The NetWare I/O Subsystem (NIOS.NLM) is the main component around which all the others revolve. In fact, Client 32 is sometimes referred to as the "NIOS" client. NIOS serves as the interface layer between the client operating system and the 32-bit client services provided by NetWare (see Figure 13).

Figure 13: Architecture of the NetWare I/O Subsystem (NIOS).

NIOS is the lowest layer in the NetWare client architecture. It is implemented as a VxD to provide Ring 0 protected-mode access to the computer's resources (Ring 0 is the "privileged" level of access on Intel processors). Since the Client 32 code is specific to Intel-based computers, NIOS requires a 386 processor or better. Of course, Windows 95 won't run on a 286-based machine, so this isn't much of an issue. But from an architectural standpoint, NIOS requires the services of an Intel 80386 or better processor.

Based on NetWare Server Technology

To better understand the role of NIOS, we can compare it to the SERVER.EXE module in Novell's server technology. SERVER.EXE is really two components in one: a DOS-based loader mechanism (LOADER.EXE) that auto-loads the NetWare operating system (SERVER.NLM), and a module handler which allows you to load and unload server-based NLMs. A list of NLMs to load is typically contained in the server's AUTOEXEC.NCF file.

With NIOS, Novell uses the same technology. Think of NIOS as a mini-operating system that is abstracted from the desktop environment. Different loader mechanisms are used, based on the desktop operating system that is running (either DOS/Windows or Windows 95). In Windows 95, NIOS is implemented as a virtual device driver (VxD). It provides the loader mechanism (LOADER.VXD) from which you load the NIOS.NLM engine. Once NIOS.NLM is loaded, you can load other client-based NLMs and drivers. Instead of using an AUTOEXEC.NCF file, Client 32 loads its modules through the Registry database in Windows 95.


Note: Architecturally, Client 32 has the capability to load and unload NLMs "on the fly."This feature will be exposed in a future release of Client 32 for Windows 95.

Because NIOS provides a flexible and dynamic environment, it can dynamically allocate and deallocate memory for various Client 32 settings. Thus many of the settings can be changed without having to reboot the machine for the changes to take effect.

Client-Based NLM Architecture

Client-based NLMs can be classified as portable modules or as OS-specific modules. Portable modules work across either Windows 95 or DOS/Windows. Modules that are OS- or platform-specific only work in the environment they are designed for. The Client 32 Requester Libraries sit on top of these modules. Applications interface with the client via the API calls provided by these new 32-bit NetWare libraries (see Figure 14).

Figure 14: Relationship between NIOS and client-based NLMs.

With the exception of the 32-bit ODI binary-compatible *.LAN drivers, you cannot load NetWare server NLMs on a NIOS-based client workstation. Although much of the code is similar, the two types of NLMs are compiled as different binaries. You cannot simply take an NLM for a NetWare server and load it on a NIOS-based client workstation. NIOS gives you an error message and won't allow it to happen. The same is true if you try to load client NLMs on the server.

How NIOS Allocates Memory

Another important function of NIOS is managing memory allocation for Client 32 modules. NIOS allocates memory through Microsoft's Virtual Memory Manager (VMM) in Windows 95. Because NIOS is loaded as a VxD, it has hooks to the VxD callback interface. This allows client NLMs and Windows 95 VxDs to interface with each other in extended memory. VXDs can call NLMs, and vice versa.

Working from the flat memory model, NIOS uses the Windows 95 VMM to allocate memory for each of the Client 32 modules as they load. It takes approximately 800KB to 1.3 MB of extended memory to load the base Client 32 software, which includes NIOS, the LSL, the 32-bit ODI driver, IPX, and the Client 32 Requester/NCP Redirector. File caching takes additional extended memory resources. By default, roughly 25 percent of the available extended memory is allocated to Client 32's file caching and other internal tasks upon initialization.


Note: This default allocation can be overwritten by changing the Max Cache Sizeparameter in the Client 32 Advanced Settings. This parameter allows you todecrease the amount of memory allocated to Client 32's cache. (See Appendix B fora complete listing of Client 32 Advanced Settings.)

Almost all of the Client 32 software loads in extended memory (above 1MB), rather than in conventional memory. Client 32 uses about 2KB to 4KB of Upper Memory Block (UMB) or conventional memory for a "workplace pointer." This pointer ensures backwards compatibility for applications that make calls to a real mode address to see if the Novell NCP Redirector is loaded. By default, the pointer loads in UMB memory. If NIOS can't find at least 4KB of UMBs available, the pointer is loaded in conventional memory (see Figure 15).

Figure 15: Memory usage in Client 32 for Windows 95.

Because NIOS allocates memory through the VxD callback interface in Windows 95, if you go to a DOS Box and type MEM <Enter<, you'll see that WIN386, not Client 32, is actually taking that memory.

On workstations with a limited amount of memory installed, the amount of extended memory taken by Client 32 can become an issue. However, Novell chose this architecture because you can always add more extended memory to a machine by adding RAM. Client 32 requires at least 6MB of workstation memory to install properly on a Windows 95 machine; 8MB is the recommended minimum. This is not much of an issue since Windows 95 workstations typically require at least 16MB to run efficiently. The more memory you have, the better Windows 95 and NetWare Client 32 for Windows 95 will run together.


Note: If you have a Windows 95 workstation with very limited memory (4MB or less), youare probably better off using Novell's 16-bit VLM client rather than trying to runClient 32 without sufficient memory resources. For information on configuring theVLM client for Windows 95, see "Integrating the NetWare Client for DOS/MSWindows (VLMs) with Windows 95" in the October 1995 issue of NovellApplication Notes.

LAN Drivers and Communications Protocols

The next category of Client 32 components includes the communications protocols and LAN drivers, along with their supporting modules. NetWare Client 32 uses the ODI (Open Data-link Interface) architecture to communicate to the network (see Figure 16). Client 32's Link Support Layer, IPX, and TCP/IP components are similar to their NetWare DOS Requester counterparts. However, the Client 32 components have been rewritten as NLMs rather than as DOS executables. This way, the NetWare Client 32 components can take advantage of the flat memory model that NIOS provides.

Figure 16: Client 32 is based on the 32-bit ODI LAN driver architecture used for the NetWare operating system.

This architecture is similar to that shown in the previous section on Windows 95 networking architecture, but with ODI instead of NDIS. Novell's LSL is similar to the NDIS.VXD interface that Microsoft provides, while the ODI LAN drivers are similar to the NDIS 3.1 VxD drivers. Using ODI allows us to run the Client 32 Requester and Novell protocols (such as IPX/SPX) on top of the NDIS layers, if necessary.


Note: Since the Client 32 components are ODI-compliant requesters and ODI-compliantprotocols, they need to talk to ODI interfaces.

LSLC32.NLM is the Client 32 version of the Link Support Layer (LSL). It is a ported version of the LSL for the NetWare OS LAN architecture that has been rewritten in ANSI C code. LSLC32.NLM is not platform specific, so it can be used on other platforms supported by NIOS. The LSL module is loaded first and interfaces with the 32-bit ODI LAN driver, which communicates with the network interface board.

CMSM.NLM is a C-based version of the Media Support Module in the ODI architecture. Client 32 also uses Topology Support Modules, or TSMs, which are components of the NetWare OS LAN driver architecture. TSMs provide an intermediate layer between the actual LAN driver and the LSL. TSMs are topology-dependent-- if you have an Ethernet topology, you load the ETHERTSM.NLM; if you have Token-Ring, you load the TOKENTSM.NLM file; if you have an FDDI topology, you load the FDDITSM.NLM file. (There are no 32-bit support modules available for ARCnet.)

The TSMs are customized to each individual desktop operating system. Instead of using the traditional LSL buffer pool approach that the NetWare OS TSMs use, the Client 32 TSMs use NIOS's Receive Look-Ahead method. Receive Look-Ahead allows protocols to preview packet header information, and then allocate buffers directly to incoming packets.

LAN Drivers for Client 32

Unlike NetWare Client 32 for DOS/Windows 3.1, in which LAN drivers are loaded via the LOAD command in the STARTNET.BAT file, with NetWare Client 32 for Windows 95 drivers are loaded from the Registry database. Client 32 for Windows 95 supports 32-bit LAN drivers as well as the older 16-bit ODI LAN drivers. You can thus choose from four basic sets of available LAN drivers:

  • 32-bit ODI LAN drivers included with NetWare Client 32

  • Many of the 32-bit ODI Server LAN drivers included with NetWare 4.1 and above

  • NDIS 3.1 drivers that come with Windows 95

  • 16-bit ODI LAN drivers from previous NetWare client software


Note: For best results, you should use 32-bit LAN drivers whenever possible with NetWareClient 32. See the AppNote entitled "Installing NetWare Client 32 for Windows 95"for more information on selecting a LAN driver.

32-bit ODI LAN Drivers Included with Client 32. The 32-bit ODI LAN drivers provided with the NetWare Client 32 for Windows 95 software have been rewritten in C especially for Client 32. They are based on version 1.1 of Novell's 32-bit ODI driver specification. (Future versions of these drivers will contain additional functionality to provide the most benefit from using the NetWare Client 32 for Windows 95, especially if you have 32-bit network interface boards.)

32-bit Server LAN Drivers Included with NetWare 4.1. You can also use many of the 32-bit *.LAN drivers included with the NetWare 4.1 operating system, provided they are binary-compatible with the 32-bit C-based drivers. (NetWare 3.x server drivers are not compatible with NIOS.) These LAN drivers are based on version 3.2 of Novell's assembly-based driver specification. NIOS will work with these drivers in a compatibility mode. However, to take advantage of future client enhancements, you should eventually move to the C-based ODI drivers as they become available from third-party vendors.

The binary *.LAN files developed for NetWare 4.11 ("Green River") are written to version 3.3 of Novell's assembly driver specification. They are designed to work with Client 32 as 32-bit LAN drivers. Over time, Novell plans to move away from assembly-based ODI drivers toward C-based ODI LAN drivers.


Note: NetWare Client 32 for DOS/Windows is also based on NIOS and thus supports 32-bit ODI LAN drivers. The currently-shipping NetWare Client for Windows NT is not based on the NIOS architecture (nor will it be in the future). However, the implementation allows the same 32-bit ODI drivers to be used.

NDIS 3.1 Drivers. With NetWare Client 32 for Windows 95, you can use an NDIS 3.1 driver with Client 32's protected-mode redirector, protocol stacks, and LSL. Instead of loading a 32-bit ODI LAN Driver, you load a Virtual MLID shim (VMLID.NLM) in its place. This VMLID interface or translator knows how to communicate with the ODI layers (LSLC32, IPX protocol stack, and Client 32 Requester). It also provides an NDIS interface to communicate with the network adapter. Figure 17 shows where the VMLID sits between the ODI and NDIS layers.

Figure 17: The VMLID interface translates between the ODI and NDIS layers.

Note that the use of VMLID involves an additional step for translating NDIS protocols, which in some cases can cause a performance degradation.

16-bit ODI LAN Drivers. Client 32 also includes a 32-bit ODI to 16-bit ODI shim, called PC32MLID.NLM, which allows protected-mode protocols and requesters to run over Novell's real-mode ODI layers. This module allows Client 32 to run with 16-bit ODI LAN drivers. To implement this configuration, you load PC32MLID.NLM in place of the 32-bit ODI LAN driver. LSLC32 still thinks it is talking to a 32-bit ODI driver, but PC32MLID handles the translation down into the real-mode ODI interface.

PC32MLID.NLM provides support that is similar to Microsoft's ODIHLP.EXE module. However, ODIHLP is a 16-bit real-mode TSR that loads at DOS and talks to the MSODISUP.VXD. This transition causes a performance degradation. By contrast, Novell's PC32MLID shim is a client NLM and can therefore talk to the 16-bit ODI driver as a protected-mode NLM. Consequently, the Client 32 implementation with PC32MLID is faster than using ODIHLP.

ODINSUP. If you are using a 32-bit ODI server driver and you need to install TCP/IP (Microsoft's TCP/IP or their 32-bit DLC driver) or some other NDIS-based protocol, an additional interface is required. Client 32's ODINSUP module provides this interface by registering itself with ODI and providing an NDIS interface to these additional protocols. Thus ODINSUP performs the translation from the NDIS protocols and requesters to the 32-bit ODI driver that actually places the packet onto the wire.

Communications Protocols

NetWare Client 32 for Windows 95 supports both IPX/SPX and TCP/IP protocols equally. The Novell IPX and NetWare/IP protocol stacks have been ported to NLM format (IPX.NLM and NWIP.NLM) for use with Client 32. Some optional modules, such as SNMP.NLM, are implemented as NLMs as well. Others, such as NetBIOS, 3270 emulation, and Btrieve support, remain in their current terminate-and-stay-resident (TSR) implementation for the initial release of Client 32.


Note: Novell does not ship a TCPIP.NLM protocol stack with Client 32 for Windows 95.Client 32 is compatible with and can be configured to use Microsoft's TCP/IP stack.

The Client 32 protocols contain built-in support for Packet Burst and Large Internet Packets (LIP) for optimized performance on both local and wide area networks. They also support binding to multiple network adapters and auto-binding to dynamically loaded LAN drivers.

The Client 32 Requester

In Novell's 32-bit client architecture, the NetWare Client 32 Requester (CLIENT32.NLM) takes the place of the NETX shell or the NetWare DOS Requester (VLMs). The Client 32 Requester provides the internal tables and services necessary to track network resources, file caching, and automatic reconnection levels.

As with the DOS Requester, the NetWare Client 32 Requester is a set of modules, or subcomponents. However, the modules are all contained within the CLIENT32.NLM file instead of as separate files. Thus with Client 32 there is no way to selectively choose which subcomponents you want to load, as was possible with the VLM client. Following is a list of the subcomponents contained within CLIENT32.NLM:


Module
Name
Description

CONNMAN

Connection Manager

Used by Client 32 to keep track of the connection tables, and to store other connection information.

TASKMAN

Task Manager

Keeps track of each task in the system, whether these are WINDOS, WIN16, or WIN32 applications or activities.

FILEDIR

File and Directory

Handles all file system functions.

PRINT

Printing

Set up network printing capabilities for Client 32.

SESSMUX

Session Multiplexor

Currently supports only NCP (NetWare Core Protocol) sessions attaching and accessing NetWare servers. However, future releases of Client 32 may include support for Microsoft's SMB (Server Message Block) sessions.

NCP

NetWare Core Protocol

A child module that ties to the Session Multiplexor.

NSMUX

Name Services Multiplexor

Coordinates activities between the child modules, or processes, that you load.

NDS

Novell Directory Services

A child module to the Name Service Multiplexor module. Provides the name resolution and authentication processes for Directory Services connectivity.

BINDERY

Bindery Services

Also a child module to the Name Service Multiplexor. It provides the name resolution and authentication processes for Bindery connectivity.

MOCKNW

Mock NetWare

Catches raw NCPs sent from applications and redirects them to Client 32 functions in order to take advantage of Client 32'scaching and automatic reconnection settings.

POLYPROC

Poly-procedure

Contains a set of generic miscellaneous routines that didn't specifically fit in any of the other CLIENT32.NLM modules.

NETX

DOS Interrupt 21h redirector

Used to redirect all Interrupt 21h (NETX) function calls to Client 32 functions.

VLMMAP

VLM Mapper

Used to redirect all DOS Requester (VLM) function calls to Client 32 functions. The VLMMAP module is used to support applications and utilities that are written to NETX and DOS Requester APIs.

The NetWare Client 32 Requester is fully backward-compatible with the NETX shell and the NetWare DOS Requester, so NetWare-aware applications taking advantage of the earlier client APIs should run with no modification under NetWare Client 32. This compatibility is accomplished through the NETX and VLMMAP modules that are a part of CLIENT32.NLM.

Documentation and Technical Support

The help files included with NetWare Client 32 for Windows 95 are the primary documentation for the product. These files contain information on understanding, installing, configuring, using, and troubleshooting Client 32. To view the Client 32 help, select Start | Help | NetWare Client 32 after NetWare Client 32 for Windows 95 is installed. This opens the SETUPNW.HLP file. All of the other Client 32 help files are accessible from the SETUPNW.HLP file. Technical support for NetWare Client 32 for Windows 95 is provided by all the usual Novell channels. You can submit enhancement requests for NetWare client software by sending an e-mail message to: enhclient@novell.com

Evolution of NetWare Clients

Novell is no longer developing or maintaining the NetWare Shell (NETX) client software. The NetWare DOS Requester (VLMs) remains Novell's 16-bit client solution. If you are in a situation where you have 386-based workstations that don't have enough memory or other resources necessary to run Client 32, you should use the DOS Requester. Novell will continue to maintain the NetWare DOS Requester, and there will be future releases based on critical issues that are discovered. With all of the advantages that NetWare Client 32 has to offer, Novell hopes to see most of its customers migrating toward 32-bit client solutions. In the next release of IntranetWare (scheduled for early 1997), the name of NetWare Client 32 for Windows 95 will change to IntranetWare Client for Windows 95.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates