As we all know, QDOS did not come with the concept of directories and subdirectories. A number of extensions to QDOS are available to help create the working concepts of directories. When using ED drives, I found the Path (PTH) extensions useful because they would search a list of subdirectories looking for a particular executable.
Now, I’ve never used a QL with a hard disk, so I’m not too experienced with using the tools for handling directories, plus my copies of some of the good articles dealing with this subject are not available to me. So, I’ve been doing some thinking on the matter, especially since I have been writing a freeware program and I want to make it as versatile as possible.
The one issue that I’ve been pondering over is telling a program where there data file are at. This is called a Working Directory. It is a directory where the data files are at and any newly created files will also go.
I know that DATA_USE is designed for this purpose, but I do not want to type in a new DATA_USE before each program I execute. I could set up a short little SuperBasic program to set up everything, but I want to EXEC a program not LRUN it. Of course, using a front end like QASCADE, this point is mute, since the user is removed from the details of executing the program. With PTH_ setup, I don’t need to set PROG_USE, because PTH_ finds the executable. I was looking a way of having the executable know where the Working Directory is.
What I came up with is this: Have an item in the Config Block for Working Directory. The contents would be something like this, “WIN1_PROG_DATA_”. This string would be appended to the front of each file name used in the program. This does mean that the user would not be able to type in a new device name, such as “FLP1_FILE_EXT”. Initially, the Config Block entry for Working Directory would be the null string (empty), so that a user would enter “FLP1_FILE_EXT”. Once the user has created a working environment, the Config Block can be changed to what the user wants.
If this feature is linked to Environment Variables, it would become more powerfull. By setting an Environment Variable for the program, the user could temporarily override the Config Block and change the Working Directory. If the Config Block was changed to a Working Directory and the user needed to use the floppy for a few times, the user would set the Environment Variable to “flp1_” or to the null string (“”) and then set DATA_USE to flp1_. If they did not want to change the default Config Block, a BOOT program could set the Environment Variable and it would be active during the whole computing session. If different programs used different Environment Variable names for their Working Directory, then all Working Directories could be set up in the BOOT program. Something that could not be accomplished with just DATA_USE.
Since my experience in this area is kind of light, the more experienced QLers may want to take this all with a grain of salt. I prefer to think of it as a way that I would prefer to organize things and others may have a different way.
The reason I am bringing up this idea is for programmers to consider the concept and add it to their programs. The option is not very difficult to implement, but it would a nice feature to the program. The whole feature would take up no more than 10-20 extra lines of code to a program. By setting the default value of Working Directory to nothing, the feature is essentially turned off and it does not impede the user that does not want use a Working Directory.