Mail Archives: opendos/1997/03/22/01:25:15
This is all piliminary, there might be a flaw in the reasoning.
The 32 bit BIOS boot process.
After reset, the bios checks the cmos and looks for a new feature flag,
set-32-mode, if on then the bios would configure itself as a 32 bit bios for
the on coming OS, else it would set up a different mode for use in a realmode
environment. (I don't know, I've never written a bios!)
Once it's time to start the hard disk, it should step into realmode for the
MBR to work, THAT would HAVE to remain compatible after all. Once the MBR
loads the bootrecord of the target OS, it would look for a new bios flag in
the bios parameter block, call it the 32 bit check, find something which all
other bios's set to zero I guess. If found then the OS loader would take a
radical departure from 'normal' boots and load the PMOSI, (Protected Mode
Operating System Interface), it's the memory manager for the entire system
hereafter, would have to take the place of DPMI/EMM386, they shouldn't be
needed after this. After initializing the PMOSI, the next step for the boot
loader should take is making a call to allocate memory for the OS proper and
initialize it. The OS would take care of loading the needed drivers and all
the other good stuff which normally happens at boot time.
Probably, one of the features which should be incorporated into the PMOSI is
some form of a taskmanager, that's my logical place for it. Either that, or
have the taskmanager hook into the PMOSI.
Any 'old-dos' program run under this setup should be run in a V86 mode, that
way, it'd see a 630K TPA to work with, and a load of upper memory available
for it to use. If you switched to another task, you'd just swap out the
entire TPA as a unit and load the next task. Probably on certain smaller
memory usage applications, you could get away with just swapping out the
affected areas of memory, or leave the app locked in place and run another in
the free area left by it.
IE's
If the application does not make any memory allocate/modification calls, it's
to be assumed it's using everything, swap all.
If the application shrinks it's memory allocation, and uses memory allocation
to assign blocks of memory, then, depending on the next task's needs:
A) load next task into free memory area,
B) swap out the smaller known size chunks and give the next task a clean
slate to work with.
Under this arrangement, the main OS would always be task 0, and the tasker
could be written to never allow the death of task 0. Command shells would be
something else, you could always swap command shells as you saw the need.
Need a simple shell for this task? Load command.com. Want a powerfull shell?
load 4DOS here.
Now some of the other support the OS needs to do, it allow for them there
games which use an extender as part of the game, the OS has to ensure that
the extender works without corrupting the rest of the virtual machines.
DJGPP programs ought to work real happy in this environment, what with the
DOS/BIOS interface in protected mode, they ought to scream.
Dynamic RunTime Modules would also be a nice fit, you could pop them in
anywhere, and they SHOULD allocate memory for their stack and data spaces,
that way the Tasker could keep a count on how many times they've been
called, and not purge the module until it reaches zero. Each task which
calls upon the module should contain some type of pointer to the module so
when you kill the task, the module's count would be properly updated. The
only bother that worries me would be some <feature> causes the module to
reference itself, and keep calling itself.
The user should be allowed to set up a virtual screen, put the monitor in
a high graphics mode, and slice it up to present frames outlining the
various 'user-interface' tasks which they have running. As an option, a
status bar showing the various submodules a tasks calls and how the
workspace is divided up would be nice, you could spot the memory hogs
right off when PMOSI complains about not having enough free ram to run
something. Then you either pick something less usefull to kill, or blow
the hog out of the water and free up resources.
A dependancy command would be helpfull, something which would some you how
many times each task is using the same module.
(it's 0016cst, GoodNite!)
--
Promise Keepers <a href="http://www.promisekeepers.org/">.</a><br>
DJ Delorie's Home Page <a href="http://www.delorie.com/">.</a><br>
Caldera, Inc. / OpenDOS <a href="http://www.caldera.com/">.</a><br>
- Raw text -