Message-Id: <199705081146.NAA27832@grendel.sylaba.poznan.pl> Comments: Authenticated sender is From: "Mark Habersack" Organization: PPP (Pesticide Powered Pumpkins) To: pierre AT tycho DOT com Date: Thu, 8 May 1997 13:48:38 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: BIG suggestion for Opendos Features Reply-to: grendel AT hoth DOT amu DOT edu DOT pl CC: opendos AT delorie DOT com References: <3 DOT 0 DOT 1 DOT 16 DOT 19970507113652 DOT 35ef03e2 AT pop DOT verisim DOT com> In-reply-to: Precedence: bulk Once upon a time (on 7 May 97 at 14:21) Pierre Phaneuf said: > > On the whole topic of case sensetivity that's been wracking this group, I > > don't think there's any burning need to modify FAT. I think we all agree > > that backward compatibility is vital to OpenDOS. If it can't run legacy > > apps, it may as well be a whole new OS. Therefore, whether we make some > > enhancement to FAT or not, the good old FAT will still have to be around > > for people to use. > > I don't think much will happen to OpenDOS/16, apart maybe VFAT and a few > improvements. OpenDOS/32 though will get a slew of improvement (ext2 is a > memory hog compared to FAT!) and will have its own protected mode API. > Program that calls the kernel through the current 16-bit real mode API will > get an emulation (like complex permissions systems parsed to a simple > "doesn't exist" (for file for which the user has no permissions), It is not the approach we should take. In case when an unpriviledged client tries to access some file and finds out that *it does not* exist, it may try to create the file - that would naturally result in name clash. The client receives a 'cannot create file - access denied' message with no obvious reason. In case of an unauthorized access, the client should receive either old "access denied" error (as you write below), or (if it identifies itself as a 16-bit, but new API aware system) a message telling it about insufficient access rights. > "read-only" and "read/write", depending on the users rights. A bit like OS/2 > native calls and it's INT 21h services... > > > If you want backward compatibility, FAT is there to be used. If you > > want long filenames, VFAT or ext2 is there. If you want to be Win95- > > compatible, use VFAT. If you insist on cast-sensetivity, use ext2. We can > > enhance FAT if we want to, of course, but I don't really see the need. > > OpenDOS/16 will probably get hardcoded FAT and optional VFAT driver (or VFAT should be hardcoded but with a built-in compatibility mode configurable in CONFIG.SYS. > maybe hardcoded too) and nothing else. OpenDOS/32, should get installable > file systems without any problems... Let me get that straight. Are you suggesting that we provide two kernels - one 16 and the other 32 bit? That would make things much easier for programmers, and not so easy for users. Wouldn't the DOSemu approach be a better way? Just to provide a DOS extender working in a VM of the superior, 32-bit kernel. That would allow to create a minimal 16-bit kernel that would pass the 16-bit requests up to the 32-bit OS. Exactly the way it's done with 16-bit thunks on Micro$loth's Win32. If I have missed a part of the discussion and the issue had already been raised, I apologize for returning to the topic. ------------------------------------------------------------------------- Who left the cap off the toothpaste tube, who forgot to flush the loo? Leave your sweaty socks outside the door, don't walk accross my polished floor, oh Judy! - PUNCH A JUDY [...] Propping up a bar, family car, sweating out a mortgage as a balding clerk World war three, suburbanshee, just slip her these pills an I'll be free PUNCH A JUDY. Judy no more! ---------------------------------