Networking with Windows 95 part 2
The upper layers of WinNet 95
The Windows NT and Windows 95 networking architectures play a prominent role in the future of desktop computers. Already these systems are gaining a hold in offices as substitutes for low-end workstations. With this in mind we continue our series on the Windows 95 networking by examining the upper layers that provide operating-system and user programming interfaces to networked Windows applications.
Last month we examined the new NDIS 3.x Datalink architecture and the Transport Protocol layer. These two layers provide the interface to the networking hardware system and the network transport mechanisms, respectively. In this issue, we delve deeper into the strange new wonders of Win32 networking, starting with a more proper description of the Transport Programming Interface and then going into the details of Redirectors and Network Providers.
The Transport Programming Interface
The Win32 networking architecture standardizes on two major Transport Programming Interfaces, the Windows Sockets system and the NetBIOS system. We have talked about Windows sockets in previous columns (see " Windows Sockets: The Next Generation"), but I think we should discuss recent developments that will affect the future of the standard. NetBIOS, as many may know, is the older programming interface created for PC networking used in most of Microsoft's early networks: MS-Net, LAN Manager, and even Windows NT.
Windows Sockets (Winsock) is a multi-vendor standard that creates a Unix socket-like application programming interface (API) over a variety of different network topologies and protocols. This unified API was originally created to provide TCP/IP services for network applications over LANs or even WANs like the Internet. It began as a slight modification of the Berkeley sockets system that has been present in the Unix family for almost two decades. However, other vendors soon saw the popularity of this API and decided to add their own protocols into the set.
A new version of the API has been in the works for 18 months and is scheduled to be released with Microsoft operating environments by the turn of the year. Winsock 2.0's goal is to provide one distinct, easy-to-use set of function calls for establishing network connections over TCP/IP, IPX/SPX, OSI, and DECnet; other protocols have been put on the back-burner for a short while until further acceptance of Winsock 2.0 can be proven. The progress of the standard has been hampered by a long creation process compounded by the difficulty of not just multiple protocols but multi-vendor participation -- a difficult endeavor. Nevertheless, with one API set for all these protocols, the future of Windows network application programmers looks bright.
This effort is one of the first few to tackle a practical implementation of the new Internet Protocol standard. Although still not set in stone, the implementation of quality of service, flow control elements, and other behaviors affecting the transportation and use of the network promises the stricter control needed for the vast future Internet with a greater application of commercial common sense.
Microsoft has decided not to retrofit Winsock 2.0 into Windows 3.1 and 3.11, since it would take a serious investment in an operating environments it is trying to abandon. Instead, Microsoft, in a joint development agreement with Intel, will create Winsock 2.0 interfaces and software development kits (SDKs) for the Windows 95 and Windows NT by the end of 1995. (In other words, there is some truth to the prediction that Windows 95 won't be ready until at least 1996.)
NetBIOS is a strange animal in the networking world. It doesn't describe how the data is transmitted, nor does it define who can use it. It almost seems like the layer was created first and then had other layers fitted around it. It is one of the first true network-independent programming systems for the personal computer networking world. After its introduction, IBM soon followed up with the NetBIOS Extended Universal Interface (NetBEUI), which provides low-level transmission of data across network topologies and systems. However, NetBIOS is not limited to the NetBEUI transport protocol. In fact, the Internet Requests For Comments (RFC) 1002 and 1003 specify that NetBIOS can also be carried within IP packets and use IP as a transport protocol. Going one step further, another, albeit non-standard, implementation created by Microsoft even lets you transmit NetBIOS information over the Novell IPX mechanism. These implementations and standards allow NetBIOS to communicate using popular protocols that may be prevalent on your LAN and thus reduce the headache of maintaining a separate network protocol architecture to support a handful of PCs. With the built-in NetBIOS system in Windows 95, it is thus possible to communicate efficiently in small workgroups and LANs from the point of view of both the software and the network managers.
Although NetBIOS provides an easy-to-understand implementation of distributed computing, it is not well suited nor efficient for a large-scale or wide-area network. To overcome this weakness, Microsoft is trudging forth in its plans for a higher abstraction level replacement with its distributed Object Linking and Embedding (OLE) project. OLE already lets applications within a single computer communicate by sharing data and functional segments with one another. Distributed OLE promises to provide a method for uniquely referencing information across the network in an efficient manner. Distributed OLE will move data between applications either as the information is actually being generated or through the access of stored information.
The Redirector layer
Redirectors primarily provide authentication and logical name service translation for applications. By default, a networked Windows 95 system uses the Microsoft Client component, which provides support for all Microsoft networking products including LAN Manager, Windows for Workgroups, Workgroup Add-on for MS-DOS, Windows 95, and Windows NT. When a networked Windows 95 system has completed the boot process, you are asked to log into the network. This is where the Redirector plays its most obvious role.
Once associated with a client component (such as the default Microsoft Client, the NetWare Client, or the (PC)NFS client), you have been identified on the network as a unique individual associated with that system. This is important. Unlike previous releases of Windows, Windows 95 no longer assumes a single user; independent user profiles can be saved for each Windows 95 system.
Each user can create a independent profile describing how his or her desktop is set up, which network drives are mounted, which applications are available, and even how the personal task bar is set up. This lets each user customize the desktop according to their needs and preferences.
If you are on a Microsoft-based network, you can set up a series of profiles on your NT or LAN Manager server that will serve as the startup point for you no matter which Windows 95 PC you use in the office; thus, your profile can travel with you from desktop to desktop. With an NT server, you can also control the level of access per profile, constrain a user to specific programs or applications, and even prevent them from modifying their own system. This is not just a safety precaution to prevent users from tampering with their system set-ups (and possibly reconfiguring their system software or hardware into a dead end), it also provides control mechanisms so that the user need learn only a few applications and not worry about nonessential or irrelevant applications. While power users no doubt shun such safety devices, office clerks requiring only a word processor or spreadsheet -- and their system administrators -- may benefit from this control mechanism.
The NetWare Core Protocols also are implemented at this level. This provides all the services for logging onto a NetWare server for 3.1x or to the network for NetWare 4.x. It also provides the NetWare Directory Services assistance for programs attempting to locate other service units or resources on the network.
The Network Provider layer
The Network Provider layer is used mostly for emulation of the different older network APIs such as the NetWare API, the older Microsoft Windows 3.x network API, the 16-bit Windows networking API, and so on. It is a minimalist layer that attempts to maintain compatibility with the large volume of networking software out there.
A secondary but lower-level component of this layer is the Installable File System (IFS) manager, which provides separation between API-level file and print services and the actual device level. For example, a disk drive can exist on the local IDE drive system (a DOS File Access Table (FAT) file system, a foreign file system (a High-Sierra/ISO 9660 CD-ROM system, a SCSI hard disk), or on a number of different network systems (a NetWare volume, an NFS drive, etc.). The IFS manager layer makes sure applications can rely on the same (single) API for all of these different systems. Each of the file and print services can also be handled by other components external to this layer. For example, (PC)NFS also employs components at the Transport and Redirector layers.
The application interface
The topmost layer of the networking architecture, the application interface consists mostly of the function calls that programmers invoke. The WinNet programming API provides interfaces to a high-level resource management system that can communicate between applications across the network. Through the use of named pipes, mailslots, and remote procedure calls, applications can share data with each other directly across the network. If tied into a workgroup domain through a Windows NT server, the Windows 95 WinNet API also lets users examine the available resources within their domain on the network. Currently, Windows 95 resides as a client in the network domain and can only provide some basic resources that can be shared with others on the network. These include drives and printers. The more powerful Windows NT system can act as a proper application server and provide the required management facilities as well.
The API also supports both 16-bit and 32-bit function calls to provide for real-mode and protected-mode applications. The 16-bit support handles older Windows 3.1 and 3.11 networking software, but not the DOS network functions that work through software interrupts rather than true function calls. The DOS network functions actually are provided by VxD-based drivers and DOS 7.0 emulation mode, which support software interrupts.
The sum of the parts
The Windows 95 networking architecture differs quite a bit from the Windows 3.1, sporting significant improvements throughout. It is modeled after Windows NT, yet maintains some compatibility with the DOS world as well. New abstraction levels provide simpler and more unified systems to the programmer, which reduces the burden of learning multiple APIs for a range of networking systems or uses. The truth is that the old networking architecture became a complete hack as the years progressed and people tried to add more and more functionality to an inflexible networking system. Although there is no simple way to predict all future networking trends, the new architecture provides enough flexibility to allow much enhancement and modification if needed.
We have covered the general networking system available in this new operating system. However, each layer of the architecture is made of numerous components, some of which we left out of this article for simplicity's sake. We will discuss these related elements (such as the Remote Application Services (RAS), the Telephony API (TAPI), and the serial communications system) in future columns.
About the author
Rawn Shah is Vice President of RTD Systems & Networking, Inc., a Tucson, Arizona based network consultancy and integrator. Reach Rawn at firstname.lastname@example.org.
If you have technical problems with this magazine, contact email@example.com