Relationship of the Shell to the File System

The WPS represents program and data files with icons and allows you to move and copy them around the system in a similar way to the OS/2 Version 1.3 File Manager. There are also new functions like "shadow copy" and new objects like the system clock which have behaviors completely unlike those previously seen in the File Manager.

The implementation of the Workplace Shell in OS/2 Version 2.0 is not inherently file-oriented but the current implementation only supports files, not data records or transactions. Data file and program icons may represent files on a disk. A folder is represented by a real directory under its name. Figure "Data Structure Supporting the Workplace Shell" shows the approximate disk structure which supports the WPS.

As you can see, all folders are contained within the desktop and the directories of each folder on the desktop are subdirectories of the "OS!2 2.0 DESKTOP" directory. From the directory structure we can see that the screen will display a Documents folder on the desktop and it, in turn, will contain three other folders; SCRIPTFILES, PERSONAL and 1992PLAN.

Icons in any folder can be dragged (moved) into another folder or onto the desktop. When this happens, the file system will handle it in two different ways. If it is a data file it will be physically moved to the new directory. If it is a program reference or a shadow copy of a data file, then a pointer to the original object and its working directory is passed from one folder to the other.

The relationship of the desktop to the file system is shown in Figure "Drag/Drop - Physical Implementation"

Both the folder and the abstract objects in it are stored as pointers (called HOBJECTs) in the OS2.INI file (see Running Programs (Folder Contents) for more details). When a program is copied to another folder, the HOBJECT of the program is placed in that folders area within the OS2.INI file. The HOBJECT is also placed in the EAs of the directory which corresponds to the folder, along with its position within the folder.

Handling programs in this manner makes sense because, if the programs' main executable modules were to be moved, the executable files could become separated from their DLLs. This approach allows a program to be copied and moved around the desktop without having to be physically moved.

"Shadows" of file objects are handled in a similar way to programs; the original file is left in the source folder but a pointer to it is created in the target folder. HOBJECTs are discussed further in Folders.

There are some problems associated with the Workplace Shell implementation. These are outlined below and discussed in more detail in the rest of the chapter:

  • The system is critically dependent on a single file, OS2.INI, for much of the information. Damage to this file can have a disastrous effect on the user's working environment.
  • The WPS uses EAs to store settings for files. However, EAs are not recognized by all file systems, nor by any DOS or Windows programs. This can cause problems when setting up the working environment for a user who needs both OS/2 and DOS programs.
  • With a FAT file system, moving files can lengthen disk access times as files become fragmented and the tables become cluttered. This would impact users who want to migrate their systems from DOS to OS/2 V2.0.
  • A program file is treated by the WPS as either a program reference object or a data file object, depending on the view used. Once registered as a program reference object and placed in a folder, the WPS restricts the actions which can be performed on it. For example, copying or moving the object moves the program reference, not the underlying file. Viewing the object from the Drives folder, however, allows the user to work with the physical file. Thus direct manipulation in the WPS means that sometimes the program file can be moved and sometimes it cannot.
  • While data files and programs are handled by the shell, there is no base class for record structures and transactions. To be able to create a persistent "transaction" object capable of interacting fully with the other WPS objects might require us to derive a new base class from WPObject. See OS/2 Version 2.0 - Volume 4: Application Development for a more detailed discussion of this issue.

    [Back: Workplace Shell Object Types]
    [Next: Workplace Shell Objects]