The explorer views networks hierarchically. There is a logical root of the network, and networks are located under this root. Details of each network are presented as a hierarchy. As a user "explores" down the network hierarchy, a connection to a network resource may be required to view further (for example, to view files). This connection may in turn require authentication.
Browsing APIs are provided to support exploring networks hierarchically. These APIs provide the ability to enumerate the network as a hierarchical set of objects, called net resources. Each net resource has a name that, together with its parent object names, uniquely identifies the resource on that network. Resources are given types that indicate the nature of the resource (e.g., server, file share point, directory). The APIs indicate whether or not access to a resource requires a network connection or authentication to be made. Access to directory resources is made in such a manner that the explorer can use FindFirst/FindNext calls to present file information for network files in the same fashion as for local files. The explorer does not, by default, use multiple windows for each network's connections but presents a single hierarchical view of the entire network.
From the explorer's standpoint, nodes that are returned by the enumeration are either containers or objects, which may or may not be connectable. If they are containers, they may be enumerated further; if they are connectable, the network name returned may then be used in WNetAddConnection() to make a connection. The explorer does not need to have any knowledge of servers vs. shares.
In order to present information to the user in a form that is natural to the network (rather than representing everything in UNC format), services are provided to provide display names for resources in edit controls, drop down lists, and hierarchical views.
The following is an extract from an example network hierarchy:
NETWORK_ROOT
NT_NETWORK
DOMAIN_00
SERVER_000
SHARE_A
SHARE_B
SERVER_001
SHARE_A
SHARE_B
DOMAIN_01
SERVER_010
SHARE_A
SHARE_B
SERVER_011
SHARE_A
SHARE_B
NETWARE_NETWORK
SERVER_1
VOLUME_A
DIRECTORY A
VOLUME_B
DIRECTORY A
SERVER 2
VOLUME A
DIRECTORY A
The names displayed are the network names returned by the NPs. The browsing UI does not initially expand the entire tree, it just shows one level. As the user opens more branches, each node is enumerated. At the top level of the hierarchy, the names are returned by the MPR, which knows what NPs are available. At lower levels, each NP is responsible for its own subtree. Each NP returns unique names for each resource within its tree. Each resource may be a container, which indicates that the browsing API can be used to enumerate further network resources contained within the resource.
In the above example, there are some interesting network specific behaviors:
Firstly, the LAN Manager NP returns domains at the top level, servers at the next level, and shares last. The first two are non-connectable containers, whereas shares are connectable objects. When connecting to a resource, the domain is not specified, and is not part of the fully qualified resource name for a share.
Secondly, a NetWare 3.11 network has servers at the top level, volumes at the next level and directories at all lower levels. An 'attach' (in NetWare terminology) to a server must be made before the volumes can be enumerated. To enumerate the directories in a volume, the user must authenticate himself to the server.
These are performed in a similar fashion to enumerating network resources, i.e., by an Open/Enum/Close model. However, this enumeration results in a flat list of connected resources, and not a hierarchy.
Persistent connections are the same as in Windows 3.1. Instead of each network maintaining its own list, the MPR does it all. Deviceless connections may be persistent to enable authentication at logon time.
One goal of browsing in the Explorer is to be able to browse individual directories and files on the network, and reach a desired file or directory before having to make a connection. The main problem in accomplishing this is that of authentication: you cannot browse the directories on a share, for example, if you don't supply the password for the share.
This is solved by having a new WNet API for authentication. When an application attempts to enumerate the contents of a container, or access an object of some type on the network, it may receive a "not authenticated" error code. The application can then call the WNetAddConnection3 or WNetUseConnection API to gain appropriate access. WNetAddConnection3 sets up a connection to the resource, obtaining security information from the password caching subsystem or from the user using a standard dialog. Once this connection is established, the application can continue normally with its operation. Similarly, WNetUseConnection can provide a counted connection (if supported by the network), so that when the operation is finished, the application can advise the NP that it no longer is using that connection by calling WNetCancelConnection2. The underlying network can also do expiration of idle connections by itself.
In order to present a uniform system access model to the user when multiple networks are present, and to control access to certain generic system resources such as the password caching subsystem, a system logon facility is implemented in Windows 95. This has a dialog similar to the logon in Windows for Workgroups. Individual NPs have entrypoints which are called for logon and logoff, which can perform network-specific operations, optionally using the same information (username and password) provided for the system logon or providing additional UI. Since logging off may imply unloading the user's profile (user-specific registry keys), applications are shut down at logoff exactly as if the user had chosen to exit Windows. System components and service applications can detect logon and logoff by listening for the WM_USERCHANGED message to be broadcast.
Because a logon can fail, the user may be logged on to some networks but not others. If the user subsequently tries to use a resource on a network where logon was unsuccessful, the logon is handled as part of the authentication process for that resource.
The user may also have a User Profile (per-user portion of the registry) stored on a network server. Since logon to that network is probably required before the profile can be accessed, one NP can be designated the Primary Logon Provider. That NP is responsible for displaying the logon UI (a service is provided to display a standard dialog) and returning the username and password to MPR. The user is logged on to that network, the profile is loaded, and then logon occurs for other networks.
Logon can also occur when a new network card or other transmission medium is made available to the system (for example, hot-docking a portable, inserting a PCMCIA card, or establishing a dial-up connection). All network providers are called to perform additional logon in these scenarios.