david@doe.utoronto.ca (David Megginson) (03/18/91)
It's time for us to start designing programs and libraries which will run under future versions of MiNT which support bigger and better file systems. A good idea might be to include some dummy system calls which MiNT-aware programs can use to replace Fsfirst(), Fsnext() etc. The new system calls should work the same for now, but require a much larger buffer for the program name. That way, in the future when MiNT supports better file systems, MiNT programs will not have to be recompiled to be able to support names like Nethack.Source.tar.Z. If we just put all of the calls in place now, our work will be easier in a year or two. Comments? Perhaps we should write a spec sheet for what programs/libraries should do to be upwards compatible with future MiNT versions. This is something that we can do together on the net, and all Eric would have to do is approve it and include it in the distribution. -- //////////////////////////////////////////////////////////////////////// / David Megginson david@doe.utoronto.ca / / Centre for Medieval Studies meggin@vm.epas.utoronto.ca / ////////////////////////////////////////////////////////////////////////
hyc@hanauma.jpl.nasa.gov (Howard Chu) (03/19/91)
In article <1991Mar19.150319.25547@qut.edu.au> lunnon@qut.edu.au writes: >Huh, why not use dirent ??? This seems reasonably capable and is portable >to boot ??? I'd agree, we should try to hide the Fsfirst/Fsnext layer completely and use the Unix *dir routines instead. (This seems reasonable, given MiNT's apparent intent to provide as much BSD functionality as possible...) -- -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA Disclaimer: How would I know, I just got here!
david@doe.utoronto.ca (David Megginson) (03/20/91)
In <1991Mar19.105139.28070@jato.jpl.nasa.gov>, Howard Chu writes: > In article <1991Mar19.150319.25547@qut.edu.au> lunnon@qut.edu.au writes: > >Huh, why not use dirent ??? This seems reasonably capable and is portable > >to boot ??? > > I'd agree, we should try to hide the Fsfirst/Fsnext layer completely and > use the Unix *dir routines instead. (This seems reasonable, given MiNT's > apparent intent to provide as much BSD functionality as possible...) > -- Of course, the problem is that MiNT is still stuck with TOS, and TOS does not support device drivers, so the drivers (for TOS and Minix) are hard-coded into MiNT. I don't know a lot about the low-level mechanics of Unix, but I think that directories are special files rather than FAT entries, hence the different way of dealing with them (the library emulates these directory files by caching return values from Fsfirst()/ Fsnext()). I'm sure that others here can add to this... David -- //////////////////////////////////////////////////////////////////////// / David Megginson david@doe.utoronto.ca / / Centre for Medieval Studies meggin@vm.epas.utoronto.ca / ////////////////////////////////////////////////////////////////////////
lunnon@qut.edu.au (03/20/91)
In article <1991Mar18.140901.1919@doe.utoronto.ca>, david@doe.utoronto.ca (David Megginson) writes: > > It's time for us to start designing programs and libraries which will > run under future versions of MiNT which support bigger and better > file systems. A good idea might be to include some dummy system calls > which MiNT-aware programs can use to replace Fsfirst(), Fsnext() etc. > The new system calls should work the same for now, but require a much > larger buffer for the program name. That way, in the future when MiNT > supports better file systems, MiNT programs will not have to be recompiled > to be able to support names like Nethack.Source.tar.Z. If we just put > all of the calls in place now, our work will be easier in a year or two. > > Comments? Perhaps we should write a spec sheet for what programs/libraries > should do to be upwards compatible with future MiNT versions. This is > something that we can do together on the net, and all Eric would have > to do is approve it and include it in the distribution. > Huh, why not use dirent ??? This seems reasonably capable and is portable to boot ??? > > -- > //////////////////////////////////////////////////////////////////////// > / David Megginson david@doe.utoronto.ca / > / Centre for Medieval Studies meggin@vm.epas.utoronto.ca / > ////////////////////////////////////////////////////////////////////////
rosenkra@convex.com (William Rosencranz) (03/20/91)
In article <1991Mar19.105139.28070@jato.jpl.nasa.gov> hyc@hanauma.jpl.nasa.gov (Howard Chu) writes: >In article <1991Mar19.150319.25547@qut.edu.au> lunnon@qut.edu.au writes: >>Huh, why not use dirent ??? This seems reasonably capable and is portable >>to boot ??? > >I'd agree, we should try to hide the Fsfirst/Fsnext layer completely and >use the Unix *dir routines instead. (This seems reasonable, given MiNT's >apparent intent to provide as much BSD functionality as possible...) i agree with howard. only i think we should pick BSD or USG, but *not* both. POSIX would be ideal (does it say anything about opendir/readdir/etc? wait, i just checked... yes it does). i have to carry around ndir.h direct.h dirent.h and all the others from BSD and USG for portability. let's stick to posix, here, and do away with the duplicity. posix synopsi are: #include <sys/types.h> #include <dirent.h> DIR *opendir(dirname) char *dirname; struct dirent *readdir(dirp) DIR *dirp; void rewinddir(dirp) DIR *dirp; int closedir(dirp) DIR *dirp; typical use: DIR *dirp; struct dirent *d; char *name; if ((dirp = opendir(name)) != (DIR *) NULL) { while ((d = readdir(dirp)) != (struct dirent *) NULL) do_something_with_d (d); if (closedir(dirp)) check_errno_right_now (); } else check_errno_right_now (); issues: is int 32-bit or 16-bit (note that DTA uses 16-bit ints in its low-level structure)? will we support errno? zillions of (incompatible) versions (like lharc :-). note that readdir(3) provides space for the dirent so it gets wacked on subsequent calls. i have more or less working (BSD-flavor) versions of these. it made porting BSD ls(1) easy. only trouble is it is slow as molasses for large directories. i think gulam's ls reads the FAT directly. it is great for recursive searches (i think i have a traverse(3), if memory serves). i try to hide Fsfirst/next as much as i can, though they do exist in MSDOS. not that both turbo C and MSC on the PC support the *dir functions (i think) so applications port to dos, too (if that matters). my versions use Fs*. in general, i think sticking to posix as much as possible is what we really want. that's why it was developed, after all: portability. speed is another issue altogether. in fact, with these functions in place, it should be possible to use either GEMDOS Fs* or direct reads of the FAT and still have a portable program. if u want, i can post these... -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com