Date: Thu, 8 May 1997 16:28:36 -0400 (EDT) From: Pierre Phaneuf Reply-To: pierre AT tycho DOT com To: OpenDOS Mailing List Subject: Re: BIG suggestion for Opendos Features In-Reply-To: <199705081146.NAA27832@grendel.sylaba.poznan.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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