Mail Archives: opendos/1997/05/08/16:29:11
On Thu, 8 May 1997, Mark Habersack wrote:
> > 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.
I agree with you for that it could be a problem, but how do you manage the
cases where you don't have "file scan" rights? (i.e. in Unix when you have
X right to a directory so you can go in it and use the files in it, but
not the R right so you cannot do a "ls" in there)
> > 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.
Agreed.
> > 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.
The problem with having a single 32-bit kernel that run 16-bit programs in
V86 mode is that it wouldn't run at all on a 286 or lower. And that
minimal 16-bit kernel could just as well be right that, another kernel.
DOSemu runs a *separate* 16-bit kernel in the emulator and this separate
kernel would run just as fine by itself on a 286. I fear this is the only
way to get a real 32-bit OS.
Pierre Phaneuf
- Raw text -