To: opendos AT mail DOT tacoma DOT net
Subject: Re: [opendos] Wishlist v2.0 
Message-ID: <19970313.180558.11959.1.chambersb@juno.com>
References: <15396 DOT 9703132259 AT orkney DOT dcs DOT st-andrews DOT ac DOT uk>
From: chambersb AT juno DOT com (Benjamin D Chambers)
Date: Thu, 13 Mar 1997 21:01:29 EST
Sender: owner-opendos AT mail DOT tacoma DOT net
Precedence: bulk


On Thu, 13 Mar 97 22:59:45 +0000 dg AT dcs DOT st-and DOT ac DOT uk writes:
>>Okay, I've updated the wishlist that I'm keeping.
>>Here it is:
>>
>>1] Direct screen write
>
>No. Direct screen write is totally inappropriate in the kernel. It 
>uses up 
>valuable kernel space (64kB limit, remember?) and reduces flexibility. 
>The 
>kernel should just pass on requests to the BIOS; if you want direct 
>screen 
>writes, then you can load a TSR later that hooks the BIOS interrupt. 
>That's 
>what it's for.
Should have been written: Everything added is OPTIONAL.  Ie, if you don't
want any of the additions on this list, you can turn them off.

>>3] IFS support
>
>What, you mean support for a *different* IFS than the one we've 
>already got? 
>Why?
The whole point of IFS is to have more than you already have.  What if
you have a Linux drive on your system?  Think FAT'll let you use it?

>>4] File Descriptions
>
>Better suited for an external program. If I can get gdbm ported to 
>Borland I 
>might give it a try.
With IFS, It's trivial to write this one in.

>>6] Compile all drivers in the kernel
>
>You're kidding, right?
Again, optional.

>>9] Automount util
>
>The standard DOS IFS already supports invisible automounting. 
>(Floppies, 
>CD's...)
DOS has a standard IFS?  There was a discussion on this a while back, I
don't know what came of it...

>>10] Make the source compilable by one compiler and linker (not our 
>job, but
>>I'm sure a lot  
>>    of people would like this)(DJGPP??????????)
>
>This is definitely needed. But not DJGPP. DJGPP is a 32-bit 
>protected-mode 
>compiler. DOS is a 16-bit real-mode operating system. We can't use 
>DJGPP for 
>*any* of OpenDOS apart from, possibly, external utilities, and even 
>then it 
>would be a Really Bad Idea.
And yet, isn't a 32bit DPMI OS which utilizes V86 consoles _definitely_
what we want?  The only problem is the overhead - for just the kernel,
though, and without any external crap (sound, graphics, et cetera,
they're all drivers) the kernel shouldn't be too bad.

>>12] Make W95 run from OpenDOS
>
>Almost certainly not possible, I'm afraid; MS-DOS 7 was majorly bent 
>to make 
>Win 95 work. You're probably stuck with WfW and Win32s (I don't run 
>Windows).
Doesn't W95 let you keep an older version of DOS if you wish?  Then why
couldn't we make it work like this?

>>13] On the fly DLD's (dual mode) (Dynamically Loaded Driver)
>
>Not possible with block devices and file systems, because of the way 
>drives 
>are allocated. Most other drivers are already dynamic (TSR's).
I would hardly call TSR's dynamic - you load them manually, and then
they're loaded for good.

>>14] Add 4DOS's cool stuff
>
>Mmmm... possibly. 4DOS is very complex. I think that anyone who 
>actually needs 
>the extra features can install 4DOS proper. If a few simple extensions 
>were to 
>be put into the current shell (passing command lines through the % 
>expander, 
>%? which returns the error level, SETVAL which evaluates numeric 
>expressions) 
>that would suffice for most purposes.
Again, optional.

>>21] Coredump!!!
>
>Well, I've been doing Unix programming for some years now and I have 
>*never* 
>found a use for a coredump.
What, you've NEVER made a program that crashed?  Either you're the best
programmer in the world, or you're full of sh*t.  Core dumps tell you
where you're program crashed, making debugging a _lot_ easier.  Hadn't
this ever occured to you?

>>22] FSSTND
>
>It's too late.
Why?  Is there any good reason software can't be written FIRST for OD,
_then_ ported to other OS's?  IMHO, This'll help it more than anything.

...Chambers