http://www.microsoft.com/TechNet/ps/win95/technote/wn95-wp.htm (PC Press Internet CD, 03/1996)
Posted Date: May 24, 1995
by Charles Rose, RoseWare
Charles Rose, RoseWare President, author and consulting software developer and NetWire systop provides here an in-depth look at Windows 95 from the perspective of a Novell NetWare expert. Rose concludes that Windows 95 is a compelling upgrade for customers who connect Windows to NetWare.
Ask network administrators about the client environments they support and the Microsoft® Windows® operating system usually mentioned as the most popular client-and perhaps the most involved to support. Network administrators generally recognize the benefits of a graphical environment, but the installation, configuration, and support aspects of a graphical user interface (GUI) seem to as ease of use increases.
Microsoft Windows version 3.1 brought tremendous flexibility and ease of use to the desktop, but it created extensive work for network administrators. Managing a diverse network with individual Windows-based configurations turned out to be no mean feat.
The Windows 95 operating system promises even more power and flexibility to the user. As a network administrator, you might be excited by the latest technology and the power of the new features, yet worried about how you will handle installation, configuration, and support. But Windows 95 promises more power and flexibility to the network administrator than any previous version of Windows. Your life may become easier-not harder-with the introduction of Windows 95. Microsoft has listened to the requests of network administrators for more performance, better security, easier setup and administration, and smarter network management tools.
It can be difficult to separate marketing promises from the hard realities of network management. The purpose of this paper is to identify these realities and explain how Windows 95 will make your life easier.
What does Windows 95 mean to you?
Windows 95 means different things to different types of people
involved with local area networks (LANs).
For the network administrator, Windows 95 will require a certain time commitment for planning but the deployment will require less time than previous versions of Windows, given the tools provided by Microsoft.
Integrating any new environment involves change. However, if the network administrator takes sufficient time to plan the deployment of Windows 95 and learn the tools provided for network setup, the time spent will be well worth it.
Microsoft has put special emphasis on network setup for its new environment. Batch/ scripted setup and global system policies provide a powerful mix of setup tools. Large corporate sites involved in beta testing of Windows 95 found network setup one of the most valuable aspects of Windows 95-based networking.
The prospect of visiting each personal computer (PC) in a medium to large network can be daunting at best. But with the new network tools, the setup process can be launched from the network login script. Setup can be configured to run entirely hands-free or the administrator can choose those fields that are open to user input.
For the Certified NetWare® Engineer (CNE) or networking consultant, Windows 95 presents new business opportunities and new ways of doing business. Most businesses will likely choose to upgrade to Windows 95 and they will need assistance. Windows 95 is easier to install and configure than previous versions of Windows, but it requires a fair amount of planning to install on existing systems. CNEs and consultants should find more business aiding companies with the planning, installation, integration/configuration, training, and support phases of product deployment. In addition, the remote management capabilities of Windows 95 will allow CNEs and consultants to perform their network management over an asynchronous connection. Finally, after companies have successfully integrated Windows 95 at the software/hardware level, they will need to integrate it at the user level. To take maximum advantage of the new environment, users must be made aware of the new features available to them.
For the network software developer, Windows 95 provides exciting new opportunities. As modern operating environments are becoming 32-bit protected-mode systems, the demand for 32-bit applications is rising dramatically. Thus, application vendors will need to build 32-bit versions of their applications to take advantage of the new resources of Windows 95 (32-bit application programming interface, the registry, and so on). In addition, the fact that Windows 95 supports a wide array of networks means that applications written to the WinNet API (discussed in more detail following) will run on all supported networks. Develop an application for Windows 95 using the WinNet API, and it will run without modification on Windows NT™, NetWare, Banyan® and other networks.
For the user, Windows 95 brings a plethora of new features. Users will notice better performance, both in terms of increased speed and a more stable environment. And they will benefit from a better-looking, more tightly integrated desktop environment. As Windows 3.1 improved the landscape of the desktop, Windows 95 provides similar dramatic improvements. Users will see the network more as a unified collection of resources rather than a random accumulation, each with its own interface and individual quirks.
Why should you care?
What are the specific advantages and improvements to Windows
95? The rest of this paper will examine in detail the feature-level
improvements. But at a higher level, the value of moving to Windows
95 can be expressed in terms of higher productivity, increased
user satisfaction, and improved manageability of the network.
Organizations that move to Windows 95 and take the time to properly
plan should see these improvements from better performance, a
more robust feature set, and enhanced desktop management support.
Because most readers are familiar with Windows 3.1, let's start by examining some of the differences between networking in Windows 3.1 and Windows 95:
Go To TechNet Home Page
Windows 3.1 Windows 95
Multiple network support is difficult True multiple network support and
to impossible, with different native support for more network
interfaces for each environments and consistent interface
for each
No native network management support Plugs into HP® OpenView, NMS, and
Microsoft Systems Management Server;
simple network management protocol
(SNMP) agent over IPX/SPX or TCP/IP;
information pulled from the registry;
Desktop Management Interface support
(cross-platform developing,
registry-based, MIF) (DMI support is
not in the first release of Windows
95)
.INI files managed separately for each Remote management of the registry
workstation on the network allows net administrators to manage
all PC configurations (even on local
hard disks) across the network
Lots of .INI files to manage Windows 95 registry database contains
configuration for PC, Windows, and
other applications, all in one place
Changing security of Program Manager System Policy Editor is a GUI tool
requires use of obscure .INI that lets you restrict certain
parameters functions on the desktop by providing
a GUI front end to the desktop
registries
Windows® for Workgroups had no real Peer security works with existing LAN
security tools administrator tools (Syscon, NWAdmin,
and so on.)
Hardware setup is usually a hassle Plug and Play lets Windows 95 set
hardware configuration
16-bit network interface card (NIC) 16-bit or 32-bit NIC drivers; 32-bit
drivers network driver interface specification
(NDIS) 3 drivers up to 200 percent
faster than 16-bit drivers
Frame type (802.2 vs. 802.3) must be Automatic detection of frame type so
identified and set consistently for network administrator does not have to
each workstation set it for each workstation
Network login must occur before Native support for NetWare login and
running Windows in order to have login login scripts
script support and login under Windows
supported only through nonnative
(NWUSER) utilities
Print to NetWare print queues Point and Print, Drag and Drop to
network printers
Windows for Workgroups provides NWServer allows Windows 95-based PCs
peer-to-peer networking, but only to appear as NetWare file servers
among Windows for Workgroups-equipped across the network (users can map
PCs-security is only on a password drives, share files, and print to
(share-level) basis Windows 95-based PCs as if they were
NetWare file servers)
Backup with software from Arcada or Win32® backup agents included inside
Cheyenne requires memory-resident Windows 95 so memory-resident programs
programs to be loaded are not needed
When network goes down, workstation Automatic disconnect and reconnect
goes down allows local PCs to keep running even
when the "network resource" goes away;
when it's available again, PCs
reconnect.
16-bit, real-mode network drivers 32-bit virtual device driver (VxD)
consume conventional memory and architecture means network drivers and
quickly exhaust upper memory related software run above 1 megabyte
(MB), so more than 600 kilobytes (KB)
are free for MSDOS®-based applications
MSDOS 8.3 filename support Long (up to 255 characters) filename
support on local drives and on network
file servers (including NetWare)
Supports 16-bit applications for Supports 32-bit and 16-bit
Windows applications for Windows and NetWare;
fully forward and backward compatible
16-bit nonpreemptive environment 32-bit preemptive environment provides
performance, protection, and
flexibility
Now let's discuss these issues in more depth. We'll begin with the more apparent networking changes and work our way down into the architecture. We will conclude with a discussion of the Windows 95 networking APIs.
One of the design goals for Windows 95 was to have a "seamless" interface to all of the various networking platforms it supports, such as NetWare; Windows NT; Microsoft LAN Manager; Banyan VINES®; Artisoft® LANtastic®; DEC™ PATHWORKS™; Sun® PC-NFS®; 3Com® 3+Open® and 3+Share®; Beame and Whiteside B&W-NFS; IBM® LAN Server; LAN Program; and PC LAN Program.
This makes life much easier for the user, because the user interface does not change according to the type of network resource. To the user, one vendor's file server volume looks like another network vendor's volume, which relieves the burden of remembering platform-specific details.
There are several areas where this seamless interface manifests itself. The first area is in the My Computer and Network Neighborhood boxes (see Figures 1 and 2). The first provides a folder/document-type interface to the user's local drives and mapped network drives, while the latter provides an identical interface to network resources.
Figure 1: My Computer dialog box
Figure 2: Network Neighborhood
In addition to providing a consistent user interface to dissimilar networks, the peer-to-peer capabilities of Windows 95 behave like a NetWare file server to NetWare clients. You can ATTACH to a Windows 95-based desktop, see it in SLIST (see Figure 3), and use VOLINFO or other NetWare utilities. You can MAP a drive to it, and it will function just like a NetWare file server.
These features can be particularly useful to relatively small workgroups. Administrators of large networks may choose not to allow peer services.
Figure 3: List of NetWare servers, including Windows 95 NetWare
file and print server
F:\ >slistKnown NetWare File Servers
Network Node Address Status--------------------------
------- ------------ ------NETWARE_41
[ ACE][ 1]DefaultWIN95PC
[ 1][ 20AF41B946]AttachedTotal
of 2 file servers found
Microsoft provides a 32-bit client for NetWare with Windows 95. NetWare 2.X, 3.X, and 4.X (Bindery emulation) are supported. Windows 95 also allows for login completely under Windows, including full support for NetWare login scripts.
Microsoft has gone to great lengths to ensure NetWare compatibility. NetWare performance enhancements such as Packet Burst and Large Internet Packet (LIP) are supported. Packet Burst improves the speed of workstation and server communication by reducing the number of packets involved. LIP support means network routers and gateways can send packets at their normal size, rather than breaking them down into smaller parcels.
Windows 95 does not support packet signature, however, nor does it provide a GUI frontend for password changes. (You must execute Novell's SETPASS.EXE to change your NetWare password.)
In addition, Microsoft's 32-bit client provides Plug and Play support (see below under Windows/Network Setup for more information), and client-side caching, both of which provide improved functionality and performance.
The NetWare login script support is one of the key features of Microsoft's 32-bit NetWare client. Windows 95 processes system and personal login scripts, and it supports the commands and variables of NetWare's login scripts. Network administrators should note that TSRs cannot be loaded in the login script, although you can execute programs as long as they don't stay resident.
In addition, Microsoft wrote the client software so that it automatically discovers the network frame type and network number. This can be a time saver for network administrators who would normally have to manually coordinate server and workstation setup of the frame type.
Both of these features result in a desktop that is far more "network-aware" than others.
In addition to the architectural NetWare support that has been built into Windows 95, you will also notice certain GUI enhancements that provide a graphical way of performing tasks once done under MS-DOS, or through a third-party utility. Right-click on the "Network Neighborhood" icon on the Windows 95 desktop and you see options such as "Who Am I," "Map Network Drive...," and "Disconnect Network Drive." These options function like Novell's WHOAMI and MAP commands (or the NWUSER utility).
Also, if you right-click on a NetWare file server under the Network Neighborhood, you will see options such as "Who Am I," "Log Out," "Attach As...," "Map Network Drive," and "Properties." These options function like Novell's WHOAMI, LOGOUT, ATTACH/LOGIN, MAP, and NVER commands.
GUI support for these networking tasks makes using the network more of a natural part of the desktop environment, rather than something external to the user. It will make the user feel and act more as a part of the network.
Figure 4: Network Neighborhood Menu
Figure 5: NetWare File Server Menu
With Windows 95, you can run multiple protocols from the same workstation. The 32-bit versions of IPX, TCP/IP, and NetBEUI are provided.
The Windows Sockets interface allows a common API to these heterogeneous protocols (IPX, TCP/IP) and the DCE remote procedure call (RPC) interface is supported-both of which are useful in client-server applications.
A common frustration of MSDOS users is the 8.3 naming convention. Windows 95 supports long filenames that may be up to 255 characters (the complete file path may be up to 255 characters long, so the actual file name will be less, depending on the length of the path name). Figure 6 shows how long filenames are displayed by the MSDOS DIR command.
Figure 6: Long filenames displayed by the MSDOS DIR command
Volume in drive C is DOSWINFAX Volume Serial Number is 15EC-2251
Directory of C:\TEST. <DIR> 01-17-95
5:38p ... <DIR> 01-17-95 5:38p ..MSD
EXE 166,099 01-30-95 11:31p MSD.EXEEGYPTI~1 BMP
630 02-08-95 6:39p Egyptian Stone.bmpHONEYC~1 BMP
854 02-08-95 6:40p Honeycomb.bmpTHATCHES BMP
598 02-08-95 6:45p Thatches.bmpFORYOU~1 CPE 4,133
02-08-95 6:40p For your information.cpeSYSTEM CB
98 02-13-95 10:37a SYSTEM.CB
Windows 95 can display files on NetWare file servers with long filenames; network administrators simply load the OS/2® name space. This means that not only will NetWare users see long filenames (like those shown in Figure 6) on their local drives, they will see long filenames on NetWare drives as well.
Networks are becoming larger and more complex, which places increasing demands on the network administrator. The administrator needs a set of tools that are powerful enough to monitor, configure, and manage the entire network. Windows 95 goes well beyond Windows 3.1 and Windows for Workgroups in providing tools for network management and support.
NetWatcher is a tool for the peer capabilities of Windows 95. It shows which users are attached to the workstation, the shared local drives, and what files are currently open. System Monitor allows you to view (as a histogram, graphic bar, or numeric value) a vast number of performance statistics. You can choose statistics from the file system, network protocols, the kernel, memory manager, peer server engine, or network client. NetWare users can check Burst Packet statistics, NCP dropped packets, bits per second, local cache statistics, pending requests, and more. It is important to note that both Net Watcher and System Monitor function locally as well as remotely. Figures 7 and 8 show Net Watcher and System Monitor, respectively.
Figure 7: Net Watcher
Figure 8: System Monitor
The Windows 95 registry is a database that contains system and user-specific configuration information, and is an incremental improvement over the .INI files in Windows. Rather than using simple text editors, Microsoft provides a GUI front end to the registry called RegEdit. The registry stores information in a hierarchical order, and the GUI lets you browse and modify this information by expanding levels of information in an outline format. One of the more powerful features of RegEdit is the ability to remotely manage another user's registry. Given the proper security, you can access a remote user's registry and browse or update certain values.
The table below illustrates the differences between the new registry and the old .INI configuration files:
Windows 3.1 .INI files Windows 95 Registry
Many (often well over 100) small .INI Three files at most: SYSTEM.DAT for
files PC-specific information, USER.DAT for
user-specific details, and (optional)
POLICIES.DAT for system-wide items
64K limit on each .INI file No logical limit on registry file size
At most, two levels of information: Hierarchical structure; can be any
[section] name and settings under depth required by applications
that section
Complicated to administer Easier to administer with RegEdit
registry editor and PolEdit policy
editor
No user-specific information Registry separates information specific
to the local PC (SYSTEM.DAT) versus
user configuration (USER.DAT). This
way, multiple users can share the same
workstation and retain individual
settings
.INI files managed locally using text Registry files may be managed locally
editors or remotely (across the network) using
GUI tools
All .INI files placed in \WINDOWS Registry files can be placed in the
directory Windows directory or distributed
according to use. PC-specific
information can be stored on the hard
disk, user info on the login directory,
and system policies in the SYS:PUBLIC
directory.
The registry simplifies the storage and management of configuration information. It works well with the centralized/distributed model. Information that should be distributed (PC-specific data) is stored on the local workstation; information that should be centralized (user-specific and system-wide data) is stored at the file server. In addition, Windows 95 does a good job of coordinating local and remote configurations. For example, the registry is stored locally and is replicated on the network file server. The files are compared and updated during network login/logout operations. Two copies of the file are maintained so that laptop users, for example, can disconnect from the network and still retain a registry database.
The existence of the registry does not free you from .INI files completely. They must exist in order to be compatible with existing applications for Windows. However, more and more applications will be supporting the registry for storage of configuration information, so the burden of managing .INI files should fade over time.
There are several reasons why the registry is important on the network. First, the registry is the central depository for Plug and Play and other hardware configuration information, including the network setup. Network administrators can manage the configuration of each PC on the network remotely using RegEdit. Also, more formal network management software, such as those that use SNMP or DMI, relies on information that is stored in the Registry.
Anyone who has managed a medium to large network with Windows and wanted to update a .INI setting globally knows what a nightmare this can be. Most users will have .INI files stored locally, which either requires special software just for .INI management, or lots of aerobics-visiting each individual workstation to manage these files. The registry (and a system policy) allows the administrator to make one setting that each user reads and incorporates upon login. This can be a tremendous time-saver.
Another important aspect of the registry is the integration with the network and the fact that information can be stored where it makes sense for it to reside. For example, PC-specific information resides at the workstation (SYSTEM.DAT) while user-specific information can be stored in the user's login directory on the file server (as discussed above, the user-specific information is actually stored locally and replicated to the network file server). This allows users to roam the network and log in to different workstations while still preserving their user-specific environment (wallpaper, desktop setup, and so on.). Also, system-wide registry information or "policies," which override PC-specific or user-specific information, are stored in the SYS:PUBLIC directory on the NetWare file server.
Optionally, an administrator may choose to place all three registry files on the server. This would be the only option for workstations that do not have local drives, such as with remote initiation program load (RIPL) or diskless workstations.
Not all information in the registry is stationary. Like the NetWare Bindery, the registry stores some information that is static (configuration information, for example) and other information that is dynamic. Dynamic registry settings include network adapter statistics, which can be useful for network administrators to query.
One useful aspect of the registry for network administrators is its extensibility. The registry is not just for Windows 95: Applications can use the registry to store user configurations as well, which adds to the flexibility of the network.
The registry is a powerful new means of configuration, but something is missing. Even though you can remotely connect to each desktop to make configuration changes, you still manually connect to each desktop. Windows 95 includes "policies" software to handle this dilemma. Policies are one of the more powerful network management features of Windows 95. They allow network administrators to globally control certain registry settings and they map to one or more keys in the registry.
The interface to policies is called PolEdit, a GUI outline-based front end. When you change settings in PolEdit, you are making changes that will affect the registry of certain users.
Network administrators can specify policies globally, per-server, on a group, or even on a single user-basis.
Policies can be used to make registry-based configuration changes for certain groups of users (or for all users). Policies also can help administer security by restricting access to certain system functions, such as the Run system menu option. Additionally, policies help the network administrator to create defaults during network setup. The network administrator can specify default workgroup and organization names, or hardware configurations for network boards, and the like.
The batch setup aspects of policies can be a true lifesaver. Rather than setting defaults in each user's registry, the network administrator can make global defaults (or defaults specific to just a few users) for certain settings, such as the workgroup, company name, network adapter, and so on.
Like the registry, policies are not restricted to managing system settings; network managers can create their own policies, manageable in the GUI-based PolEdit (see Figure 9). This can be useful for creating defaults in certain applications or in grouping settings in ways other than is provided in Windows 95.
There are three types of policies that the network administrator will manage:
Figure 9: Policy Editor
Figure 10: Registry Editor
Windows 95 plugs cleanly into Hewlett-Packard OpenView, Novell Network Management System (NMS), and Microsoft Systems Management Server through the use of its SNMP agent. Built-in support allows for easy management of workstations under these network management platforms.
Simple network management protocol support in Windows 95 includes an SNMP agent, an extensible MIB handler interface, and MIB I and MIB II support. Support of SNMP makes it easy to add workstations into a formally managed network without having to struggle with loading special software on each workstation. In addition, the extensible MIB handler interface allows hardware or software vendors to instrument their components so they can be remotely managed via the SNMP console.
The Windows 95 SNMP support works over TCP/IP and IPX transports.
Desktop Management Interface (DMI) is a specification designed by the Desktop Management Task Force (DMTF). The DMI agent for Windows 95 should be included in the next version of SMS, due for release the same time Windows 95 is released.
Windows 95 makes it easy for ISVs to develop network inventory applications. The registry for each PC stores local hardware information that can be sent to an inventory application across the network. So inventory applications simply gather updated inventories of the network.
One of the most impressive features of Windows 95 is the ease of setup for network administrators, particularly given the size of the new operating system. As the size of network applications and environments have grown, so has the complexity (not to mention drudgery) of installing and configuring for a large network. The larger the network, the more the administrator will appreciate the network installation features of Windows 95. These features include: setup scripts and automated installation, significantly improved client support and full 32-bit network support during setup.
The combination of setup scripts and system policies provides the network administrator with the power to perform batch installations for large networks. Imagine running the setup program from a login script so that users logging in on a given day have their local workstations automatically set up under Windows 95. The time savings for the administrator can be significant.
Windows 95 supports many more clients than were available under previous versions of Windows. Figure 11 shows the clients that are supported under each boot option. Client configurations that were supported under Windows for Workgroups 3.11 are shown with an asterisk (*).
Figure 11: Network Client Support under Windows 95
MS Client MS NetWare NETX VLM Banyan PC-NFS
HD Yes* Yes Yes* Yes* Yes Yes
FD Yes Yes Yes Yes Yes Yes
NT at Yes Yes Yes No No
ship
RIPL
* Windows for Workgroups supported clients/platforms
Windows 95 provides a full 32-bit network client during setup, which provides performance improvements over the older 16-bit network clients, as well as protection during the setup phase.
There are three major configuration possibilities when installing Windows 95 on the network: hard disk installation, floppy boot, or remote initiation program load. The administrator can install Windows 95 to a user's local hard disk, deciding whether to place most of the operating system files and swap file locally or on the network. For workstations without hard disks, the administrator may choose to boot the workstation from a floppy disk and, once connected with the network, boot and run Windows 95 from the file server. For diskless PCs, the RIPL solution is provided, which allows diskless workstations to boot, log in to the network, and load and run Windows 95 from the network.
Administrators will find advantages to each approach. The final decision should be made based on local workstation configuration, disk space and random access memory, number of users, and so on. Configurations that place more files on the local workstation reduce network traffic but decentralize the placement of files. Centralizing files on the network can be convenient, but the price paid is in performance. The system is flexible enough to allow for a number of configuration options, such as keeping most Windows 95 files on the server but using local swap files.
When deciding how to set up and configure local workstation support, a critical consideration is performance. The performance from any of the above configurations will depend heavily on:
The advantage of network swapping is centralized management. Increasing workstation memory reduces the amount of swapping involved, thus reducing network traffic. The network administrator can also disable swapping to disk, if desired.
In addition to the previously mentioned features, there are a few other, less-obvious features that are hidden deeper within Windows 95 to help the network administrator. For example, Microsoft wrote the client software so that it automatically discovers the network frame type and network number. Because NetWare 3.1 (and below) servers default to the Ethernet 802.3 frame type and NetWare 3.12 and 4.X default to Ethernet 802.2, it can be frustrating to coordinate server and workstation setup, particularly in a large environment. The Microsoft feature makes the behavior of Windows 95 on the network more intuitive and allows the network administrator to concentrate on core management issues.
Windows 95 removes more of the hassle and headache of network setup with Plug and Play architecture. For systems with Plug and Play-compatible hardware, Windows 95 configures and assigns resources such as input/output (I/O) ports, interrupts, and direct memory access (DMA). It resolves conflicts that can take hours to troubleshoot through traditional methods.
Plug and Play allows hot docking and configuration for laptop computers. For laptops that support this feature, Windows 95 senses that the computer is docked and makes the new resources (network, CD-ROM, sound, etc.) available without having to reboot the machine.
This "dynamic configuration" works for PCMCIA cards as well. Unplug a network PCMCIA card while logged in and Windows 95 unloads the network drivers and lets the user continue working. Plug the card back in and Windows 95 logs in the background and reconnects to the previous devices (re-map drives, and so on.). This is a refreshing change from dealing with a "frozen" computer.
In addition to performance, network security is one of the top priorities for network administrators. Windows 95 provides a variety of security features and allows the network administrator to choose those that are most appropriate to the network.
If the network administrator decides to use peer services, there are two options available: share-level security and user-level (pass-through) security. The former method controls access to a shared resource (a local hard disk) by using a password. For example, if you want to connect to Bob's hard disk, you would need to use the appropriate password to access his files.
User-level is a more sophisticated method of sharing the resource that involves relying on a NetWare file server for a list of users and groups. Access is granted on a user or group level. Administrators choose between full access, read-only, or custom access (these options function like volume-level NetWare trustee assignments). Users can be granted read, write, create, delete, change attribute, directory search, and access control rights to shared resources.
For example, if Bob wants to share his local disk using user-level security, he specifies to Windows 95 the users and groups that have access and the type of access allowed. When Joe tries to access Bob's hard disk, Joe uses the same user name and password that he uses for his NetWare file server. Bob's computer will then ask the NetWare file server to authenticate Joe, and if the password is valid, Joe will be granted access to Bob's local disk.
To accomplish this, the network administrator must create a user (with no password and no trustee assignments) on a NetWare file server called WINDOWS_PASSTHROUGH. Because most Bindery information is not available without an object logged in, Windows 95 needs this login to scan the NetWare Bindery.
The advantage to the pass-through approach is that administrators have to maintain security and access through only one place: the NetWare utilities such as SYSCON. The range of access privileges allows the network administrator to create a variety of access profiles. For example, the administrator can set up a group for read-only users and another for full-access users. The administrator can use NetWare SYSCON to determine who is in which group.
Some network administrators, particularly those managing large networks, may not want to offer peer services to users. In these environments, peer services can be disabled entirely so that all resource sharing is done at the network file server.
The system policies mentioned previously can be used as a means of controlling how Windows 95 and the network are accessed. Through system policies, administrators can restrict the actions of specific users, groups, or even individual workstations (regardless of who logs in). Policies are stored in SYS:PUBLIC on a NetWare file server.
One of the frustrating aspects of working on a diverse network can be having to remember multiple login names and passwords. This can be frustrating for users, who have to type multiple names and passwords. It also can be frustrating for the network administrator who performs the maintenance. Windows 95 provides a facility called password caching, where passwords are encrypted and stored locally. Users type one password and Windows 95 keeps track of the passwords on other systems (such as for NetWare file servers).
One of the more compelling features of Windows 95 is its 32-bit support. Running in 32-bit mode provides a number of performance improvements, including increases in speed and better protection against system errors. The network is not left out of these performance enhancements from 32-bit support.
First, 32-bit NDIS 3 drivers generally run faster than their 16-bit counterparts. (Microsoft research shows that a twofold speed increase can be realized over 16-bit network card drivers.) Memory protection is also a welcome feature.
Another feature of the memory model is the ability to load drivers (network and other) and other software above conventional MSDOS memory. This leaves more than 600K of free conventional memory.
Many of the software modules in Windows 95 are Windows virtual device drivers and the NDIS 3 drivers are no exception. Network VxDs are fast for a number of reasons:
Network administrators have the freedom of choice between 32-bit NDIS 3 drivers and 16-bit NDIS 2 and ODI drivers.
Printing is one of the core functions of any local area network, and Windows 95 provides a number of interfaces that make network printing easier-for the user as well as the network administrator.
Windows 95 supports a document-oriented view of local and network resources, and printing is one area where this support is fully demonstrated. Point and Print support means a user can click the right mouse button on any file and choose Print from the pop-up menu, and Windows 95 uses the application that is associated with that file to print it. For example, a user may click the file README.TXT with the right mouse button. When the user chooses Print from the pop-up menu, Windows 95 launches the application associated with a .TXT file-in this case, Notepad. After NotePad prints the file, it unloads, returning the user to the previous state.
Printers are represented by icons on the Windows 95 desktop. So, in addition, users may Drag and Drop a file on the printer icon to print.
For network administrators, network printer setup is easy with the Add Printer wizard. Administrators specify a path to the network printer (or browse for it) by using the universal naming convention (UNC) name for the printer (for example, \\SERVER\PRINT_QUEUE). If the administrator selects MSDOS-based printing, Windows 95 redirects local printer ports to the network printer, similar to Novell CAPTURE. In addition, print drivers can be stored on the file server for quick connection and driver configuration. In this scenario, users can browse the network to find a printer. If the administrator has set up things properly, when the user double-clicks on the printer, the proper drivers will be installed automatically. The user doesn't have to know the type of printer he or she are using.
Windows 95 includes a 32-bit NetWare-compatible print server that interacts with NetWare print queues and services the jobs. The 32-bit remote printer is convenient because it consumes no conventional memory, runs faster than real-mode print servers, and is better integrated into the environment.
Print jobs can be deferred to a later date. This is useful for laptop users on the road; when they dock or connect to the network, their jobs print automatically.
Windows 95-based printers can be remotely managed. Jobs can be held, canceled, or restarted remotely. Windows 95 supports enhanced printer ports and can return detailed information about printer status.
Network backup is an important duty of the network administrator, but one that is often avoided because of the perceived hassle involved. Windows 95 provides backup agents for popular network backup utilities. Agents are provided for Cheyenne and Arcada server-based backup solutions. These agents enable the backup server (usually running on the NetWare file server) to archive the Windows 95-based workstations without having to consume any conventional memory on the workstations.
Windows 95 is compatible with 32-bit applications as well as older 16-bit applications. It will run all of the current applications for Windows as well as new 32-bit applications that will be released around the time Windows 95 ships. Microsoft has gone to great lengths to ensure NetWare API compatibility, including inviting top independent software developers (ISVs) to test their NetWare-specific applications on Windows 95 at Microsoft's ISV Testing Laboratory.
The NetWare API support can be broken down into components for MSDOS and Windows. The API support for MSDOS includes the standard Int 21h API, the Int 21h F2h "raw NCP" interface, and the Int 2F interface to the VLMs. IPX programming can be done using Int 7Ah or an Int 2Fh mechanism that is similar to calling the requester for MSDOS.
Windows 95 also supports the Windows-based programming interfaces to NetWare, such as Novell's dynamic-link libraries (DLLs), and NETWARE.DRV. (Novell supplies the DLLs, but Windows 95 provides the NETWARE.DRV).
16-bit versus 32-bit development
NetWare developers undoubtedly will want to exploit the power
of 32-bit applications by writing programs that run under Windows
95. The simplest option is to use the WinNet API, which provides
a 32-bit API plus portability across all network platforms supported
by Windows 95. However, there are certain NetWare-specific APIs
not available using WinNet. For them, several options exist:
Obscure support
Microsoft has gone to some lengths to ensure NetWare compatibility,
including support for undocumented APIs and practices that are
not well known to all developers. For instance, when calling the
API that places a job into a queue, NetWare client software opens
a pseudo-device called NETQ. Data written to this device gets
placed into the queue.
Unsupported APIs
As of this writing, the Novell Directory Services (NDS) APIs
are not supported natively (although you can use Novell's NW*
DLLs to access NDS), but they will be supported in the future.
If you use NWNET.DLL to access Directory Services, you will need
to use Novell's VLM client software. Microsoft is demonstrating
NDS support at network conferences.
Also, MSDOS-based file-control block (FCB) APIs are not supported.
One of the design goals for the networking aspects of Windows 95 is that it react more intuitively to the addition or removal of network connections. When the user is logged into the network and the LAN goes down, the cable is cut, or the network connector is disconnected, the network drivers unload and Windows 95 continues to function without network resources. When the network comes back up or the cable is reconnected, the network drivers will reload and the network connections will be restored.
The Windows 95 network architecture is based on the Windows Open Services Architecture (WOSA) model, comprising an API layer, a routine module, and a service provider interface. Transport and driver layers round out the Windows 95 network architecture.
WOSA is not necessarily specific to networking, although it originated within Microsoft as a means to allow multiple software components (with a similar interface) to coexist. Because part of the design goal of Windows 95 was to encompass a wide range of network platforms, WOSA helps provide a structure for incorporating these platforms using a layered approach.
In the WOSA model, there is an API layer that is independent of the underlying hardware or services. Servicing the API is a routing module which directs the API calls to the appropriate service provider interface. The service provider interface works with the operating system to perform service-specific duties.
Figure 12: Network architecture of Windows 95
The Windows 95 API layer consists primarily of the 32-bit WinNet interface, discussed below in "WinNet APIs." This API layer works with all supported networks of Windows 95, so that you can log in to a Windows 95-based peer server, Windows NT™ Server, a NetWare file server, and a Banyan VINES server with the same API call.
The multiple provider router handles all routing for network operations in Windows 95. It handles all 32-bit WinNet APIs and routes requests to the appropriate service provider. Multiple provider routers are 32-bit DLLs.
Each network platform has its own network provider which implements the platform-specific functionality using the service provider interface. Operations such as login/logout and resource mapping are provided by the service provider interface. Note that only the multiple provider router calls the network provider.
Windows 95 supports installable file systems (IFSs). The IFS manager routes requests to the network-specific file system driver. So, each network platform has its own network provider and file system driver. The advantages of the Windows 95 IFS are: multiple redirector support, increased reliability, and improved performance due to an IFS cache (client-side network redirector caching). Network file system drivers are 32-bit VxDs.
NetBEUI, IPX/SPX, and TCP/IP are examples of transport protocols. Network file system drivers use the network transports to send data to the network. In addition, application programmers can use transport-independent programming interfaces such as Windows Sockets and NetBIOS, or they can program specific transports, such as Novell's IPX/SPX. Network transports are 32-bit VxDs.
Microsoft's network driver interface specification, version 3.1 is a 32-bit, vendor-independent specification for interaction between a network device driver and a network transport. According to Microsoft, 80 percent of existing network interface cards have NDIS 3.1 drivers available. Key features of NDIS 3.1 include Plug and Play enhancements that enable dynamic loading and unloading, and a new NDIS mini-driver model, which dramatically decreases the amount of code a network adapter vendor must write.
If network administrators wish to configure 16-bit ODI or NDIS 2.0 drivers for Windows 95, they may do so, but they all talk to NDIS 3.1. NDIS 2.0 works directly with NDIS 3.1, and ODI talks with NDIS 3.1 by the use of a shim (called ODIHLP.EXE) that gets loaded before the ODI driver (such as IPXODI.EXE).
There are several ways to program Windows 95 for networks, and they generally fall into two discrete groups: APIs that are common to all supported networks and APIs that are specific to a certain platform, such as NetWare.
Microsoft's common network API is called the WinNet API. The WinNet API contains calls that are common to all network platforms, such as "login" or "connect" (to a network resource). Windows 95 also supports calls that are platform-specific, such as Novell's APIs for MSDOS and Windows.
WinNet APIs
Microsoft has had a Windows networking API set since Windows
3.0, which was enhanced in Windows 3.1. The interface provides
network platform-independent APIs. LAN Manager version 2.1 provided
the multinetwork DLL which routed requests from the interface
to NetWare or LAN Manager networks. Windows for Workgroups 3.1
extended the API and incorporated common network dialogs that
used the WinNet interface. Windows NT extended the API further
by formalizing the multi-net layer to be the Multi-Protocol Router
and the API was extended to provide network browsing. Also, the
API was modified to allow for network differences (such as different
naming conventions and the NetWare server's security model).
Windows 95 further expands the API. According to Microsoft, the goals of the Windows 95 WinNet interface are:
WinNet function groups
There are several groups of WinNet API calls, many of which
are called by network providers and are not used by applications.
Most developers will use only the Connection and Enumeration API
groups. The groups of WinNet API calls are as follows:
NetWare API compatibility
The NetWare API has evolved over the years to provide a number
of ways to interact with Novell file servers. The following sections
describe the NetWare API support provided by Windows 95:
MSDOS-based NetWare APIs
There are several MSDOS interfaces, such as the standard Int
21h API and the Int 21h F2h "raw NCP" interface. Under
the standard interrupt 21h interface, the developer creates request
and reply buffers, populates them with certain values, loads certain
registers that point to the buffers, and then calls interrupt
21h. When the application calls interrupt 21h, Novell's client
software (NETX or VLM) creates an NCP packet and sends it to the
file server. Once the reply is received, the client software populates
the reply buffer supplied by the application and returns back
to the application.
Novell documented several calls from the "raw NCP" API. Under this interface, the user builds the actual packet that is sent to the NetWare file server-no translation is involved, hence the "raw" name. To make these calls, developers create request and reply buffers similar to the standard Int 21h interface, load registers pointing to these buffers, and then call Int 21h with F2h in the AH register and the function code in AL.
In addition, you can program NetWare using the Int 2F interface for the VLMs. Under this interface, developers set the AX register to 7A20h, and the BX register to 0, and call interrupt 2Fh. The far "calling address" to the MSDOS requester (VLM) is returned in the ES:BX register pair. Next, developers populate request/reply buffers similar to methods described above and call the requester calling address.
MSDOS-based IPX programming can be done using Int 7Ah or an Int 2Fh mechanism that is similar to calling the MSDOS requester.
Microsoft's NetWare client supports these programming interfaces.
Windows-based NetWare APIs
In addition to supporting the MSDOS-based APIs, Windows 95
must support the Windows-based programming interfaces to NetWare
in order for it to be compatible. Such interfaces include Novell's
DLLs for Windows, and NETWARE.DRV (the NW* DLLs are available
only from Novell, but a special version of NETWARE.DRV is provided
in Windows 95).
Novell distributes the following DLLs (with the NetWare Client SDK) that support the standard NetWare API calls: NWLOCALE.DLL, NWINNET.DLL, NWIPXSPX.DLL, NWCALLS.DLL, and NWPSRV.DLL. In addition, Novell distributes TLI_SPX.DLL, TLI_WIN.DLL, and TLI_TCP.DLL to support the Transport Level Interface (TLI).
For many of the API calls, these DLLs populate request/reply buffers and set registers just like the MS-DOS Int 21h interface described above. Then, instead of calling Int 21h, the DLLs call NetWareRequest() in Novell's NETWARE.DRV (which is itself a DLL). Windows 95 provides a "stub" NETWARE.DRV that passes the call to NWREDIR.VXD, the Windows 95 handler for NetWare Core Protocol calls.
Some applications do not use Novell DLLs; they populate the request/reply buffers, set the appropriate registers, and call NetWareRequest() in NETWARE.DRV directly. Because Windows 95 provides that stub NETWARE.DRV, this method of programming is also supported.
If developers wish to write 16-bit NetWare-compatible applications, they can do so immediately using Novell's NetWare Client SDK and the DLLs described above.
Whatever you have heard about Windows 95 in the press and whatever you think after reading this paper, one thing seems inevitable: Windows 95 is coming to a desktop near you. From what I have seen of Windows 95, Microsoft has fulfilled their promise of a "well-connected client." Windows 95 has many features that, as a desktop environment, make it compelling. When you add the NetWare integration (including network batch setup, network management, NetWare 32-bit client, login scripts, network GUI tools, security, peer services, NetWare print services, remote management, Long Filename support, frame type autodetection, and so on) you have a powerful NetWare platform from which to work.
I think it would be difficult for anyone not to find something to like about Windows 95. Having said that, I'm certain there will be some conflicts between Windows 95 and NetWare. Conflicts and bugs are inevitable in any environment; what makes the difference is how software vendors handle them. While visiting the Redmond campus on several occasions, I met major network software vendors as they were testing their NetWare-compatible software with Windows 95. Microsoft had invited them to make sure Windows 95 completely supported NetWare software. I also find it encouraging that Microsoft chose to make the default network transport IPX.
As someone more deeply rooted in the Novell culture than in Microsoft's (but involved with both), it has been frustrating in the past to see technical progress stifled by politics and competition. The companies may gain by it, but the customer ultimately loses. The networking industry was founded on the concept of integrating different kinds of components. I believe the integration of Windows and NetWare will ultimately prove extremely valuable for companies-from the CEO to the end-user.
If these two companies can work together, each providing what they do best, I feel that the customer will ultimately benefit. Only then will we see computing that is truly "pervasive."
Charles Rose
RoseWare
The following resources are available for further information on Windows 95:
Microsoft Windows 95 Resource Kit
Inside Windows 95 by Adrian/King. Published by Microsoft Press. 476 pages, ISBN 155615-626-X, $24.95. For more information or to order call (800)-MSPRESS (or GO MSP on CompuServe®).
For more information about Microsoft Windows 95, look at the Microsoft WinNews file sections found on most major online services and networks.
To receive regular biweekly updates on the progress of Windows 95, subscribe to Microsoft's WinNews electronic newsletter. These updates are sent by electronic mail directly to you, saving you the time and trouble of checking the WinNews servers for updates. To subscribe to the electronic newsletter, send an Internet message to enews@microsoft.nwnet.com with the words SUBSCRIBE WINNEWS as the only text in your message.
Charles Rose's main areas of expertise include networking (especially
Novell), commercial software development, publishing (newsletters
and CD-ROMs), on-line systems (he runs his own), and operating
environments (MS-DOS, Microsoft Windows, Pick, and Apple).
Charles is the author of NetWare Power Tools for Windows
(Bantam Electronic Publishing) and the Programmer's Guide
to NetWare (McGraw-Hill/LAN Times). In addition, he has served
as contributing editor for the NetWare Advisor and was
the senior technical editor for the NetWare Technical Journal.
He has written for Beyond Computing (an IBM publication),
Windows Magazine, LAN Technology, LAN Times, and PC Tech Journal.
Rose's first book, Programmer's Guide to NetWare (McGraw-Hill)
is considered an industry bible for NetWare development. The book
was the Main Selection for the Byte, Tab, and Newbridge book clubs
and went into its second printing less than three months after
its initial release. Rose's most recent book is NetWare Power
Tools for Windows (originally published by Bantam Electronic
Publishing), which details the complexities of NetWare and Windows
integration.
Charles divides his time between writing books and articles, commercial
software development, consulting, teaching, and running his on-line
system, RoseNet™ Online. He has been developing NetWare applications
since the early '80s and has written for several major network
software vendors. He has taught NetWare programming courses in
Washington, DC and in London. He is a sysop for Novell on their
NetWire service on CompuServe.
One of Charles' most recent projects is a CD-ROM, the Network
Support Library™, which contains network-specific files
from his BBS. RoseWare has their own section on CompuServe in
Novell's NVENA (Novell Vendor) Forum (GO ROSEWARE on CompuServe).
Charles is an instrument-rated private pilot, currently pursuing
his commercial license.
He can be reached on CompuServe at 76711,110 or on the Internet
at 76711.110@compuserve.com.
© 1995 Microsoft Corporation. All rights reserved.
This white paper is for informational purposes only. MICROSOFT
MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.
Microsoft, MS, MSDOS, Win32, and Windows are registered trademarks
and Windows NT is a trademark of Microsoft Corporation. Other
trademarks referenced are the property of their respective owners.
Go To Microsoft Home Page