Abstract

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

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.

Executive overview
"Well-connected" client
Microsoft's 32-bit NetWare client
Network administration
Improved network setup
Improved security features and administration
True 32-bit support
Printing
Backup
Backward and forward compatibility
Automatic reconnect
Underlying technology and architecture of Windows 95
Introduction to Windows 95 APIs
Conclusion
For further information

Executive overview

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:

Windows 3.1	Windows 95
Multiple network support is difficult to impossible, with different interfaces for each	True multiple network support and native support for more network 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 workstation on the network	Remote management of the registry 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 requires use of obscure .INI parameters	System Policy Editor is a GUI tool that lets you restrict certain functions on the desktop by providing a GUI front end to the desktop registries
Windows® for Workgroups had no real security tools	Peer security works with existing LAN 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) drivers	16-bit or 32-bit NIC drivers; 32-bit 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 identified and set consistently for each workstation	Automatic detection of frame type so network administrator does not have to set it for each workstation
Network login must occur before running Windows in order to have login script support and login under Windows supported only through nonnative (NWUSER) utilities	Native support for NetWare login and login scripts
Print to NetWare print queues	Point and Print, Drag and Drop to network printers
Windows for Workgroups provides peer-to-peer networking, but only among Windows for Workgroups–equipped PCs—security is only on a password (share-level) basis	NWServer allows Windows 95–based PCs to appear as NetWare file servers across the network (users can map drives, share files, and print to Windows 95–based PCs as if they were NetWare file servers)
Backup with software from Arcada or Cheyenne requires memory-resident programs to be loaded	Win32® backup agents included inside Windows 95 so memory-resident programs are not needed
When network goes down, workstation goes down	Automatic disconnect and reconnect 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 consume conventional memory and quickly exhaust upper memory	32-bit virtual device driver (VxD) architecture means network drivers and related software run above 1 megabyte (MB), so more than 600 kilobytes (KB) are free for MS-DOS®–based applications
MS-DOS 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 Windows	Supports 32-bit and 16-bit 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.

"Well-connected" client

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.

Similar interface to local and network resources

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

Windows 95–based desktops can appear as NetWare file servers

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:\ >slist
Known NetWare File Servers              Network   Node Address Status
--------------------------              -------   ------------ ------
NETWARE_41                             [     ACE][           1]Default
WIN95PC                                [       1][  20AF41B946]Attached
Total of 2 file servers found

Microsoft's 32-bit NetWare client

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.

Intelligent NetWare support: NetWare login scripts and frame type autodetection

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.

Network tools built into the graphical desktop

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

Heterogeneous network support

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.

Long filename support

A common frustration of MS-DOS 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 MS-DOS DIR command.

Figure 6: Long filenames displayed by the MS-DOS 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.EXE
EGYPTI~1 BMP           630  02-08-95  6:39p Egyptian Stone.bmp
HONEYC~1 BMP           854  02-08-95  6:40p Honeycomb.bmp
THATCHES BMP           598  02-08-95  6:45p Thatches.bmp
FORYOU~1 CPE         4,133  02-08-95  6:40p For your information.cpe
SYSTEM   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.

Network administration

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.

Tools: Net Watcher and System Monitor

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

Registry/RegEdit

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 files	Three files at most: SYSTEM.DAT for 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: [section] name and settings under that section	Hierarchical structure; can be any depth required by applications
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 editors	Registry files may be managed locally or remotely (across the network) using GUI tools
All .INI files placed in \WINDOWS directory	Registry files can be placed in the 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.

Why does the NetWare user care about the registry?

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.

Policies/PolEdit

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:

Policies for settings that already are in the registry (such as for setting the network Preferred Server)
Policies that restrict access to certain parts of the desktop (for example, to disable Control Panel or Start|Run)
Custom desktop settings for users who roam to other workstations

Figure 9: Policy Editor

Figure 10: : Registry Editor

Plugging into HP OpenView, NMS, and Microsoft Systems Management Server via SNMP agent

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.

DMI support

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.

Inventory

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.

Improved network setup

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.

Setup scripts and automated installation

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.

Significantly improved client support

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
FD	Yes	Yes	Yes	Yes	Yes
RIPL	NT at ship	Yes	Yes	Yes	No

* Windows for Workgroups supported clients/platforms

32-bit network during setup

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.

Setup options

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.

Performance considerations

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 type of applications running on the clients
How paging is set up (server-based swap files consume more bandwidth than local swap files)
Memory in the workstations (floppy/RIPL clients may require more memory)

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.

Plug and Play

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.

Improved security features and administration

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).

True 32-bit support

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 MS-DOS 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:

There is no real-mode context switch overhead. For network drivers, this eliminates the need to switch back to real mode, populate real mode buffers, exchange packets with the file server, and copy the real-mode buffers back into protected memory.
The software performs client-side caching. Network requests are cached at the workstation, which not only increases speed locally but reduces traffic on the wire which improves performance for everyone on the network.
The peer server (the network software component that shares local resources with the rest of the network) is fast because it is implemented as a VxD. Its threaded 32-bit architecture provides improved performance over 16-bit peer services, such as in Windows for Workgroups.

Network administrators have the freedom of choice between 32-bit NDIS 3 drivers and 16-bit NDIS 2 and ODI drivers.

Printing

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 MS-DOS–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.

Backup

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.

Backward and forward compatibility

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 MS-DOS and Windows. The API support for MS-DOS 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 MS-DOS.

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:

Use the existing 16-bit NetWare DLLs and "thunk" the headers for the calls you need. The thunking process, described in the Windows 95 Software Development Kit (SDK), translates between 32-bit calls to 16-bit calls.
Populate your own request/reply buffers and registers, and then call NetWareRequest() in NETWARE.DRV.
Use Novell's 32-bit DLLs once they become available. Novell is expected to make an announcement soon concerning the availability of a 32-bit NetWare Client SDK.

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, MS-DOS–based file-control block (FCB) APIs are not supported.

Automatic reconnect

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.

Underlying technology and architecture of Windows 95

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.

Windows Open Services Architecture (WOSA)

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 APIlayer that is independent of the underlying hardware or services. Servicing the API is a routingmodule 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

Application Programming Interface (API)

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.

Multiple provider router (MPR)

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.

Service provider interface (SPI)

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.

IFS manager

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.

Network transport

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.

NDIS 3.1

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).

Introduction to Windows 95 APIs

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 MS-DOS 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:

Support for the Win32 WinNet APIs as defined in Windows NT.
An interface that allows seamless browsing of network resources (network directories and printers, for example). This includes consistent handling of authentication requirements across multiple networks.
Backward compatibility with Windows for Workgroups 3.11.

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:

Connection API—Allows applications to create, manage, and destroy connections to specific network resources.
Enumeration API—Allows the application to browse and examine the details of available network resources. Programs can build a list of available resources and retrieve relevant details.
Error Reporting API—Allow for getting and setting error codes. These APIs are to be used by network providers and are not general APIs.
Local Device Name API—Another network provider interface, these calls help standardize device naming.
UNC API—A network provider interface that helps treat UNC paths consistently.
Password Cache API—Lets a network provider use (or prevent use of) the Windows 95 password cache.
Authentication Dialog API—Used by a network provider to provide a consistent login/authentication interface.

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:

MS-DOS–based NetWare APIs

There are several MS-DOS 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 MS-DOS 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.

MS-DOS–based IPX programming can be done using Int 7Ah or an Int 2Fh mechanism that is similar to calling the MS-DOS requester.

Microsoft's NetWare client supports these programming interfaces.

Windows-based NetWare APIs

In addition to supporting the MS-DOS–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.

Conclusion

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

For further information

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 1-55615-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.

On the Internet, use FTP (ftp://ftp.microsoft.com/PerOpSys/Win\_News) or World Wide Web (https://www.microsoft.com).
On The Microsoft Network, open Computers and Software\Software Companies\Microsoft\Windows 95\WinNews.
On CompuServe, type GO WINNEWS.
On Prodigy™, JUMP WINNEWS.
On America Online®, use keyword WINNEWS.
On GEnie™, download files from the WinNews area under the Windows RTC.

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.