Mail Archives: opendos/1997/05/08/03:06:52
Just in case anybody is confused by the "case sensitivity" issue...
Most people talking about "case sensitivity" (including me) really mean
storing the actual case (and perhaps spaces, long filenames, etc -
stuff you wouldn't see in FAT directories), and OPTIONALLY taking
notice of the stored case - e.g. just for directory listings, or "try
exact case first, then any case next" strategies in file opens.
It doesn't have to make things more complicated for Grandma. See what
other systems do with mixed case. You don't have to think "Unix".
But it (and long filenames equally so) does present a problem for old
programs - even if we assume that any "legacy" program will be
accessing the files via "legacy" findfirst/find next and open calls:
what happens if your program tries to see if a particular file is
present? If you are testing for "LongFilename1" but "Longfilename2"
exists, should the program see that instead? Under the old system, the
answer is always YES. If you are unzipping files from another system,
or the user simply wasn't aware there was an 8 character limit, then
the wrong file might be over-written.
I guess all that means is that whatever is chosen, the user should have
the option of strategies (and, for newbies, the default should be
reasonably idiot-proof).
The fact that some files might come from Unix systems isn't going to
thrill many existing DOS users (although compatibility with Linux might
appeal to Caldera simply to make life easier).
But most people are aware that MS have already "got" long filenames and
case-sensitive file systems. Suddenly it is worth having.
Purely from my own point of view, I dislike some of the mistakes MS
made in their designs, including VFAT, so I consider it worthwhile
putting time into alternatives. So I hope OpenDOS will...
(a) Remain compatible & unbloated (acid test: run on a 256Kb original
IBM PC, or a Data General DG One with a 204Kb 4MHz 8086!)
(b) Have better security than MS products (you may or may not be aware
of the hideous security problems with MS products, but for Joe
Average, the ability to lock important files away from kids on
the home computer and the prevention of viruses is probably
a good starting point).
(c) Have a better filesystem (VFAT is very, very badly designed. So is
FAT32. But ext2fs *might* have overheads that are excessive on
some systems. No matter what, the system should be *flexible* so
that future good ideas don't break everything (hence the IFS
discussion, and FS notions in general).
I also dislike the MS monopoly, plus I need some decent system to do my
work from day to day. So you can see where I'm coming from. Others
might argue for or against particular features based on what the market
seems to want, but my priority list, biased as it is, probably
coincides with at least a reasonable number of others.
So I am interested in the following projects for OpenDOS, and hope
we'll split into special interest groups with people responsible for
particular aspects, a bit like Linux and Freedos developers...
1. Fix all bugs up to latest Novell DOS 7 patch, tidy source, and organise
people/distribution/ftp sites so we can make a start on the rest.
2. Detect VFAT and DRDOS-style uses of those previously-unused bits in
the FAT directory entries, to at least stop OpenDOS thinking LFN
files are protected, and preferrably giving us long filenames as
well as those user-group-world permissions (as DR MultiDOS actually
had before bits of code were taken out).
3. Provide a flexible file system interface level, to make future
work (object oriented, or whatever) easier. This should become an
attractive standard, e.g. for commercial developers wanting to
write drivers for DOS and (urk!) W95. It should let source code
from Linux drivers port without huge headaches (quite easily done,
I think). And it should be optional, like DRIVER.SYS is.
4. Create Ext2fs and HPFS drivers (both have some important features)
and possibly some others (so we can read Mac diskettes, etc). Not
everyone will appreciate the need for these, until we run some
benchmark tests against (V)FAT. I have the details of my own file
system sitting in the wings waiting for a standard interface, so
there might be a lot of choice!
5. OpenDOS should work really well with Linux. Not everybody needs to
be a Unix fan, but there are projects like SMP support that are so
far ahead of anything we could hope for, the best first step to a
decent 32-bit DOS is to provide seemless integration with Linux;
allow 32-bit apps to run from conventional DOS interfaces, while
fussy legacy 16-bit apps carry on running!
6. Better utilities. I've already done SORT, MOVE and ATTRIB, and have
betas for FDISK and CHKDSK, and SETUP/INSTALL is coming. There are
many more to do (I have a huge wishlist for command.com alone), and
then there are possibilities like an OpenDOS-aware version of ZIP.
And those who like Guis will have their own list, those with web and
net access in general in mind will have others. But it would be nice
to standardise, e.g. on some free compiler/assembler. Not much luck
there with existing products... I wonder if I can add a 7th item...
7. I personally want to see a darn good (okay, reasonably good) set of
development tools (including a MASM, C and Java compilers) that are
easy to use yet the programs are reusable on lots of other systems.
The trouble getting OpenDOS to compile should be enough to convince
us we need a program development environment where we only need to
write the code once, and reuse it for a good many years. "C" (Ansi
or K&R) seemed to promise that, but nowadays most programs are less
portable than Turbo Pascal 5.5! Of course, this isn't just about
finding some free compiler and assembler, but issues like Java and
MS changes to APIs when it suits them, etc.
Ooops! Rant_Mode=OFF;
Bye,
-------------------------------------------------------------------------------
Mark Aitchison, Physics & Astronomy \_ Phone : +64 3 3642-947 a.h. 3371-225
University of Canterbury, </ Fax : +64 3 3642-469 or 3642-999
Christchurch, New Zealand. /) E-mail: phys169 AT csc DOT canterbury DOT ac DOT nz
#include <disclaimer.std> (/'
-------------------------------------------------------------------------------
- Raw text -