Networking with Windows 95 part 2
The upper layers of WinNet 95
December 1995
![[Next story]](/sunworldonline/icons/tb-next.gif){kind=icon}
![[Table of Contents]](/sunworldonline/icons/tb-toc.gif){kind=icon}
![[Search]](/sunworldonline/icons/tb-search.gif){kind=icon}
|
|
Networking with Windows 95 part 2The upper layers of WinNet 95 |
December 1995
|
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.
 Mail this article to a friend |
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
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
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.
|
|
Resources
About the author
Rawn Shah is Vice President of RTD Systems & Networking, Inc., a Tucson, Arizona based network consultancy and integrator.
Reach Rawn at rawn.shah@sunworld.com.
|
|
|
|
![[(c) Copyright Web Publishing Inc., and IDG Communication company]](/sunworldonline/icons/b-copyright95.gif){kind=icon}
If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-12-1995/swol-12-connectivity.html
Last modified: