Mail Archives: opendos/1997/03/13/21:24:39
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
- Raw text -