PART 16: ENVIRONMENTAL CONCERNS
PATH=, and all that garbage
NeoDesk 4 is unusual in offering complete control over the Atari system environment. By "environment" I am referring to an area of memory that the operating system uses as a sort of information pool that all applications can make use of. The concept of a system environment may be familiar to MS-DOS users, who often need to set the DOS environment through such statements in their bootup files as "PATH=;C:\;C:\DOS" and so on. The ability to set environmental variables was built into the Atari operating system from the start, although few users know about it.
The system environment can contain pointers to locations in your file storage where certain support files can be found, and it can tell an application where to create temporary files. It can do a lot of other things too, if the applications that are running support it.
That's the problem. Most applications do not make use of the environment in any creative way, and so the system environment is one of those aspects of NeoDesk that you could safely ignore most of the time. But if you take advantage of it, you may find it surprisingly useful when running some applications.
The most common use is to set a temporary-path variable, available to any application that checks the environment. Archivers that are properly written usually look for a TEMP statement to find the designated location of a temporary storage area to hold scratch files that are deleted after the archive is finished. To enter a variable for a temporary storage area, create a folder on a partition of your hard drive (or on a large-capacity floppy disk) that has 1 megabyte or more of free space. Name the folder TEMP. In the "Edit Environment" menu under the "Options" drop-down menu, type "TEMP=C:\TEMP\" (or whatever the pathname is) in one of the environmental-variable slots, and then save the configuration file. In my own setup, I have a second temporary-path variable named "TMP=C:\TEMP\" because some applications look for a "TMP" variable instead of one named "TEMP."
Another function of the system environment is setting a general PATH variable. This is used by all GEM applications to locate their resource files, and is entered as "PATH=C:\PATHNAME\". If you make use of this variable, you can place all the ".RSC" files of every GEM application in your collection into a single folder (or into a group of folders, if you have more than 100 or so), and of course you can then remove all the ".RSC" files from their scattered locations among dozens or even hundreds of folders. This GEM pipeline for resource files should work properly for all applications that follow standard programming guidelines; I have seen only a few programs that could not find their ".RSC" files this way. If an application complains through an alert box that it cannot find its ".RSC" file, you can move that particular file back into the same folder that the application runs from.
Desk accessories present a difficulty for this method, however. Because DAs run before NeoDesk takes control of the system environment, they will not find their resource files and therefore will refuse to load. STeno and STalker are two common desk accessories that must locate their resource files before NeoDesk loads. (This problem is not solved by installing NeoDesk as an auto-running application under the TOS desktop.)
You can get around this in three ways. The most effective is to purchase Geneva, which provides complete environmental control in addition to its multitasking abilities. The second is to place the resource files for desk accessories in the root directory of your boot drive (or in the folder the accessories are loaded from, if you use ACC.PRG or MultiDesk). The third is to avoid using NeoDesk's environment manager and use Ian Lepore's GEMENV.PRG instead. GEMENV.PRG runs from the AUTO folder, is easily configured, and has the advantage of working with the TOS desktop as well as the NeoDesk desktop.