Date: Thu, 08 May 1997 19:03:56 +1200 From: physmsa AT cantua DOT canterbury DOT ac DOT nz (Mr M S Aitchison) Subject: Just in cAsE ! (A cunningly-disguised wishlist) To: opendos AT delorie DOT com Message-id: <199705080703.TAA07744@cantua.canterbury.ac.nz> Precedence: bulk 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, (/' -------------------------------------------------------------------------------