A very good solution. I wonder if this new device could work on a
directory path with shortened directory names to maintain more backward
computability. For example if one was at root (win1_) and created a new
directory called 'ThisisaVeryLongDirectoryName' then the new system
device path would be 'win1/ThisisaVeryLongDirectoryName/' but the legacy
directory path could be something like 'win1_This01_'. This would be
something along the lines that Microsoft took when moving from DOS, only
their problem was filename length not path length. All the old
directory commands would work on the abbreviated path and a new set of
traps and directory navigation commands could be designed to use the new
long path such CD and LS.
Cheer
Malcolm
P Witte wrote:
On the problem of compatibilty with old programs, a workaround is to
use some scheme like DEV (or DOS for that matter): You set the dev
root to some "real" directory
DEV_SET 1, win72/dir1/dir2/..dirn/
then Load (in Quill or whatever) dev1_mydoc.doc
BTW that method, given the appropriate underlying mechanisms, would
permit a radical revision of the file and directory system without
braking too many programs. File manager-type programs would be hit.
What a pity that wrappers of the file system are so basic! It makes it
so awkward to upgrade. Getting directory information should have been
done via procedure calls rather than reading those rigid data
structures directly. Any new file system (miracles mat happen!) should
get that right (even if it expects to be the last!)
Per
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
