Mail Archives: djgpp/1997/03/15/01:07:59
On Fri, 14 Mar 97 18:38:30 +0000 dg AT dcs DOT st-and DOT ac DOT uk writes:
>>>>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.
>
>I'm afraid I fail to see what the IFS has to do with file
>descriptions.
Um.... gee.... I don't know, where else are you going to store the
descriptions? It just occured to me, that they might actually be _part_
of the FS - OTOH, if this is a radical new concept and I'm not on the
beaten path, let me know.
>>>>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.
If people _want_ to compile certain drivers into the kernel, support
should be there. It might be a low priority, but I don't see how having
support for it could hurt things.
>>>>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.
And who said DOS couldn't evolve? If you don't want 32bit OS, don't use
Windows. Period. If you don't want V86 consoles, don't use Windows.
Period. IMHO, having DOS written to provide these is _much_ better than
loading an external app (ie Windows) to do it for you.
>>>>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.
All I can think of is some kind of hash table...
>>>>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?
Um... Backport? Not unless ID, LucasArts, Interplay, and all the others
are willing to give me their code for free, so I can first do my favorite
games :)
OTOH, why would they even need to be backported? Most of them allow you
to at least choose which directory to install into - if they don't, I
usually just move them afterwards and things work fine (a few exceptions
are CD titles that run off the CD so must have the place to look for info
hardcoded into the program).
You mentioned something about the kernel only having 64k. I would like
to know why this is - does it have to be a small model program? Why?
Forgive my ignorance, I don't know as much about the OS as about other
topics...
...Chambers
- Raw text -