Picture
Information
ProWesS
LINEdesign
DATAdesign
PWfile
PFlist
fsearch
fontutils
QL Links
Downloads
[What is ProWesS] [Introduction] [Goals] [Parts] [Documentation] [News] [Future] [Update]
[the ProWesS window manager]
[RLL vs DLL and support of the standard C library]
[installation of applications]
[the new colour screen driver & the future of PROforma]
[the DATAdesign engine]
[device drivers]
[support programs]
[when ???]

device drivers

There has been quite a bit of discussion about this recently, especially in the ql-users mailing list. So I will add my two pennies worth. My ideas are the following :

  • File naming structure should change. I think it would be useful to move to Unix style directory structure. For compatibility sake, it would be best to limit "real" file name length (name including extension, excluding path) to 36 characters. This should be sufficient for all normal use. Longer names would no longer be user friendly anyway (you don't want the filename to contain the entire text of the document - that beats the purpose of naming  files). Filenames should have their extension separated by a dot (yes, this is already supported in ProWesS). The directories should be separated by a  slash (/). There should be one root directory, and all the devices should be  subdirectories of that (e.g. "/win1/" for what is now "win1_"). If you would  ask for a directory of the root (so "dir /"), you would get all the available  devices. This is a big improvement, as there is currently no clean method on  the QL to know which devices are available.
  • All programs need local default search path and destination directory. This  can be provided by using the environment variable system which is part of c68 (and ProWesS's global variables should be replaced by that). The path can contain several directories, separated by semicolons (;) and searched from  left to right.
  • Device driver structure could be made more generic. You can make the distinction between block oriented devices (disks etc.) and serial devices  (serial and parallel port). You can have protocols to run on top of these  devices to provide specific services like talk to another computer, or use  the blocks to provide a directory structure and filing system. This could be a major improvement over current systems. It would make all  disk based systems behave identical, independent of whether they are interfaced by ACSI (ST/TT), SCSI (TT), Qubide, Rebel or Miracle i/f.  It is currently a real problem under Qdos/SMSQ(/E) that you can not rely on a specific error to be reported when a specific problem occurs. This depends on  the producer, type and even version of the device driver.
  • Links should be supported. For example "/prg/" could then be a link to the  "/win1/prg/" directory. Alternatively the file "/win1/prg/LINEdesign" could  be a link to the "/win1/development/applications/LINEdesign/LINEdesign".
  • In the resolution of filenames and paths, it always has to be possible to  use environment variables. They can normally be referenced by including  "$VARNAME". The name can be terminated by a slash or dot or another dollar  sign.
  • I have already mentioned that each program should have a local path and destination. These should be inherited from the calling program, but still be local. When a filename starts with a slash then the filename includes the complete path. If the filename does not start with a slash then the place to search depends on the action. When you open an existing file, it should be  searched on the path. If you open for writing, it should be opened on the  destination.
  • The file system should also support the "." and ".." conventions. Using "..",  you can move a directory up in the path, so "/win1/mine/../" is the same as  "/win1/". The dot is a current directory indicator. When used at the start of  the path (e.g. "./output.txt") it should reference the destination, even when opening for reading. When it occurs in the middle, it should be skipped, so  "try/./this.txt" is the same as "/try/this.txt".
  • It would be useful if the file header includes an extra field which indicates  the producer of the program. This could be used to automatically call the producer program when you execute a file. This is similar to the FileInfo linking of file extensions to programs, but without the problem that an extension could be used by several programs. Of course the handling of  FileInfo would still be useful when the requested program is not available.
[Information] [ProWesS] [LINEdesign] [DATAdesign] [PWfile] [PFlist] [fsearch] [fontutils] [QL Links] [Downloads]

This site is designed and brought to you by PROGS, Professional & Graphical Software.
If you have any comments about this site, ideas for improvements or questions, tell us.
All material is copyrighted, © 1998-2001.,