Opening the LAN Server domain icon shows all the servers you are connected to. However, you cannot open this folder until you are logged on. If you try to open it before being logged on, you are prompted for a "user ID" and password before this folder will be opened. Each server can then be opened to show the network resources of either disks or printers. The Public Applications folder is provided by the LAN Server and not the shell, hence it is just placed on the desktop.
LAN disks behave just like local drives and the LAN printers behave like local printers. You can drag any network objects onto your desktop to be used later or the next time you start your machine; this saves going back to the network folder. Note that this process creates shadow copies of these objects, not real copies; these will be grayed out until the "login" is completed.
Now you have folders, files and printers that behave just like local objects. All the standard shell operations of drag/drop, move, copy, shadow, opening and settings are available. For example, you can associate a program on the network with a data file on your local disk or network disk. The only restriction is that if you do operations on a network disk that affect the contents of that disk, then you need Read/Write (R/W) permission for that disk.
There is one aspect of the LAN independent shell which may appear as an inconsistency to some users. While you can see any program and data files on remote servers, you cannot see program references or shadow copies within the server. This is due to the design of the Workplace Shell. The WPS only knows about shadows and program reference objects stored in its own OS2.INI file. The WPS on your system cannot read the OS2.INI file on another (remote) system. Therefore any shadows or program references defined within that remote system are rendered invisible to it.
For example, if a user could access the root drive of an OS/2 V2.0 LAN Server, he could use Drives to view the desktop structure on that system. However, the System Setup folder would appear to be empty. This is because the objects stored in that folder are program references, that is, they are pointers to programs in the OS2.INI file on the server.
See Workplace Shell Implementation for a detailed explanation of how Workplace Shell objects are implemented.