Installing programs in OS/2 V2.0 is no more difficult than under OS/2 Version 1.3. The difference only becomes apparent after the program has been installed and the user or administrator is trying execute it. Programs can continue to be run, as in OS/2 Version 1.3, by double-clicking on their program icon. Taking full advantage of the WPS, however, means setting up folders with data files and linking these files to the programs so that they are automatically started when the data file is double clicked on.
There are three main ways of making these links:
All three approaches have advantages and disadvantages, which are briefly outlined in Using the Workplace Shell.
File Type Association
Associating programs with files can be done in the programs Settings view, by filenames, or through setting the file type in the data file settings. OS/2 provides a default table of available file types to which programs written for the Workplace Shell can add their entries.
So far very few programs take advantage of this feature, even though they could very effectively be started by association if they did (that is, they are written to expect a filename as their first command line parameter).
Where such a program is written by the user, it is a very simple matter to add the required ASSOCTABLE to add the new type. See Migrating Existing Applications (Using an ASSOCTABLE to Add New File Types) for details of how to do this. In the case of any other program, however, you may want to add a file type to the system, without having access to the source code of the program concerned. A REXX program to do this can be found in Adding New File Types.
Some users have noted the format in which the table of available types is stored in OS2.INI and have written REXX programs to add new types directly. This approach is not recommended; it is unsupported and is dependent on the way OS/2 stores this data, which may change in some future release.
Filename Association
The answer for programs over which you do not have control is to use association by file extension rather than file type. This is simple and easily understood by administrators but has some serious flaws and is not recommended as the default solution.
Consider the PMSPREAD spreadsheet program that is provided as one of the productivity "applets" with OS/2 Version 2.0. If you invoke this program with the name of one its saved spreadsheets as the first parameter, it will automatically load the data as the program starts.
If you open a Settings view of the program object in the Productivity folder, you will see that no type associations are defined for it. So, if we want to start this program by opening one of its data files, then we will have either to add a new file type to the system and associate the program with that, or else associate the program with a filename and/or extension. This particular program uses the distinctive extension .$$S for its files, so association by file extension is probably the best approach in this case.
The major restriction with using filename association is, as noted above, that HPFS filenames can be changed by editing the icon descriptions. Unless users remember to add the correct file extension when they edit a filename (and this is not a natural way of working with the WPS) then the program associations will be lost. Some measure of protection is afforded by the "Confirm on rename of files with extensions" option in the System Settings folder (it is "on" by default) but this may not always prevent the user from renaming the file.
Adding a Program to a Data File Menu
An alternative approach to linking data files to programs is to add the program name to the data files context menu and make it the default "Open" setting. This is a useful workaround to the problem of losing a linkage when the filename is changed by the user, which is the main drawback to the filename association, but other factors may make even this approach unworkable in practice.
Since most of those programs which don't support file types also don't have any mechanism to accept a filename as a parameter, starting the program from the file is going to provide no extra benefit to the user. If anything, adopting this approach could be counter-productive, since the user would be using the same technique for starting both OS/2 and DOS programs but would get completely different results.