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.