Mail Archives: opendos/1997/05/08/07:49:27
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!
---------------------------------
- Raw text -