Date: Sat, 22 Mar 1997 00:17:42 -0600 (CST) From: "Colin W. Glenn" To: opendos-developer AT mail DOT tacoma DOT net Subject: 32 bit OS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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 .
DJ Delorie's Home Page .
Caldera, Inc. / OpenDOS .