Mail Archives: opendos/1997/03/14/22:06:21
> >>>1] Direct screen write
> >>No. Direct screen write is totally inappropriate in the kernel. It
> >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.
>
> Optional, sure. I, personally, use direct screen writes on my 486 to
speed
> things up. But the place for this isn't in the kernel, it's in a TSR; I
use
> VANSI.SYS. As a rule, you don't want to put extraneous features in the
kernel.
> There's limited space available and it reduces flexibility. Besides,
> modularisation is Good.
How about in the COMMAND.COM?
> >>>3] IFS support
> >>What, you mean support for a *different* IFS than the one we've
> >>already got?
> >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?
>
> What's needed is not IFS *support* (that's already there) but the IFS
modules
> themselves.
That's basically what I mean, but with a standard.
So you have one program that loads all of the drivers and not have 3,000
drivers and 3,000 programs to load those drivers
> >>>6] Compile all drivers in the kernel
> >>You're kidding, right?
> >Again, optional.
>
> There are *lots* of drivers. There's a kernel limit of 64kB. How would
you
> specify parameters? What would you do if you needed to boot without a
> particular driver? What would you do if you wanted to *replace* a given
> driver? Recompile? Yuck.
>
> *Not* a good idea.
I'm not very informed about the insides of an OS, but my Linux kernel is
bigger than 64k for sure.
So why can't the DOS kernel be (aftre some modification of course).
And recompiling isn't so bad.
And if you do hate the recompiling, IT'S OPTIONAL!!!!
If you don't want to compile your drivers _in_ the kernel, you don't, you
just run them as normal TSR's or drivers.
> >>>10] Make the source compilable by one compiler and linker (not our
> >>This is definitely needed. But not DJGPP. DJGPP is a 32-bit
> >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.
>
> DOS is a 16-bit real-mode operating system. It is *not* a 32-bit
protected
> mode operating system. If you want a 32-bit protected mode operating
system,
> use Linux or Demos or something. If you want to try to convert DOS into a
> 32-bit protected mode operating system then it won't be DOS.
Why not?
Most programs nowadays are in Protected Mode, which is 32-bit.
> >>>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.
>
> If you write the TSR properly you can unload them again. As for automatic
> loading? How is DOS supposed to know what interrupts correspond the old
> devices? The only way I can see of doing it is to load a TSR that watches
> certain interrupts and loads another TSR when they're called. If you're
doing
> that anyway, you may as well load the second TSR and have done with it.
Well, if I load a TSR and another one after that, I can't unload the first
one.
I'll need te remove the last one, before I can remove the first one.
> >>>14] Add 4DOS's cool stuff
> >>Mmmm... possibly. 4DOS is very complex. I think that anyone who
> >>actually needs
> >Again, optional.
>
> This is easy --- anyone who wants 4DOS can *install* 4DOS.
I aggree, but then you'll need to get OpenDOS AND 4DOS, it's much easier if
it's one package (or contains a default shell which is VERY like 4DOS).
> >>>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?
>
> I didn't say that. A lot of my programs crash. I said that I've never
found a
> use for a coredump, which is perfectly true. When I need to debug a
program, I
> don't use a coredump, I use a live copy connected to GDB.
I don't use coredumps myself, but the option should be made available for
those who do.
We just need to make sure you can turn off the coredump procedure.
> >>>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.
>
> Are *you* willing to backport the several million DOS programs that are
> currently in existence?
If we do this correctly we don't need to.
And you can't save all programs from being out dated.
Ever heard of Windows 2000, M$'s new brainchild.
A full 64-bit OS, with NO 16-bit support!!!!!!
Yeep
- Raw text -