Mail Archives: opendos/1997/03/21/15:59:32
On Fri, 21 Mar 1997, Yeep wrote:
> Some guy posted something about why the bios creators (Award, AMI)
> don't create 32bit bioses.
I cannot remember that thread, but anyway:
Since 286+, (small) parts of the BIOS are written for Protected Mode,
mainly for mode switching... (you meant Protected Mode code by '32bit
BIOS', didn't you?). Modern machines actually have larger parts of
Protected Mode code in their BIOS. Helix and Award made an attempt to
reduce the Real Mode memory footprint of the BIOSes (normally
32KB-64KB for the System BIOS and 32KB for the Video BIOS) using
Helix' CLOAKING technology (which was developed around the same time,
when Novell's DPMS was created). They did this by developing
fully Protected Mode versions of generic System and Video BIOSes,
taking it all over after the old and highly vendor specific build-in
BIOSes have completed the hardware initialization. Since the 386+
CPU is in Virtual-86 Mode after EMM386 was loaded and is doing it's
job to map UMB regions etc., most of the memory areas formerly
occupied by the BIOSes can than be easily assigned to UMBs.
(At the user level this looks somewhat similar to QEMM's Stealth
feature, but on system level it's a completely different approach.)
So, here you have a Protected Mode BIOS. While 'modern' operating
systems are not suffering from limited Real Mode address space,
they also often bypass most of the build-in BIOSes with their own
Protected Mode drivers.
> Well It just occured to me, that that's because the CPU's natural state
> is 16bit.
Yes, an 286+ starts up in Real Mode for compatibility with older
8088/8086/80188/80186 CPUs, which did not knew of a Protected Mode.
The DOS architecture is bound to the segment:offset arithmetics
(at least on the user and standard API levels), so legacy DOS code
runs only in Real Mode or in Virtual-86 Mode (which is a sub-mode of
Protected Mode since 386+).
> So first the CPU should boot up (or start or whatever) in 32bit mode,
> then the bios can be 32bit and we shall all be happy.
The CPU will always come up in Real Mode after a reset. However,
if it would start in Protected Mode, it would break DOS. You won't
get happy this way...
But you could do it vice versa:
After a memory manager is loaded, you can use DPMS or CLOAKING (which
can be called a superset of DPMS, since it actually supports the DPMS
386+ API besides it's own API) to hide away from Real Mode address
space all the DPMS/CLOAKING aware drivers leaving only small stubs in
the 1st Megabyte. You could set up a Cloaked BIOS, which occupies
only ca. 8KB, and in Virtual-86 Mode, you can map memory in these
freed address spaces, that can now be used for old Real Mode DOS
drivers and applications. You could port almost all DOS drivers and
TSRs to use DPMS or CLOAKING and so move the whole system out of the
Real Mode address space, despite some small areas for compatibility
with programs that are hardcoded to expect specific data at fixed
places or at least in specific areas, e.g. FILES, FCBS, BUFFERS, CDS,
etc. structures could not be moved out of the first 1MB+64K.
Using DPMI, DPMS, or whatever, DOS applications can make use
of 32-bit Protected Mode coding and a flat memory model.
The ultimative approach for maximum address space for old Real Mode
only applications and drivers could be to load groups of
Real Mode TSRs/drivers in 'hidden' domains of a multitasking/
multithreading kernel, which we already have available with the
OpenDOS multitasker.
However, there would be a need for some kind of 'bidirectioal
gateway' between these domains, so that only stubs would show up in
all the 'visible' domains that are used to run different applications
under the multitasker. Any service call to a driver in a hidden
domain would go to the stub in the callers domain, tunneling the
request to the driver in a different domain. If the driver itself
would need some other services it would call down to the stubs in its
own domain or pass it back to the original callers domain. While you
can think of such a system to work in theory, there are tons of
dependencies between different drivers in different domains, each in
their own context. I'm not sure, if it was possible to track them
all down, and to provide such a feature: The kernel would have to
build these stubs and gateways by itself on loading a driver by this
'tunnel'-technic (it would need to intercept all interrupts etc. of a
driver to be loaded)... With the help of special configuration files
describing a drivers behaviour, it should be possible to implement
such a DEVICETUNNEL=/INSTALLTUNNEL=/LOADTUNNEL feature, that would
work at least for some device drivers/TSRs that are rather well
known. On the other hand, if the source code was also available,
these drivers could be modified to directly use DPMS/CLOAKING
technics, and there was no need for such a sophisticated technic...
Somewhat related, but more on the user interface level:
Imagine a special utility running in a 'hidden' backround domain
and shelling original PKZIP, ARJ, etc. with different options to
compress/decompress/list files from archives, that are mounted in
the file system in the 'visible' domains. Think of going in a .ZIP
archive using something like UNC-syntax, and also of the usage of
URLs:
An example:
c:\>pkzip test.zip *.* -ex
c:\>CD C:\\TEST.ZIP\ mounting PKZIP in the
c:\\test.zip\>EDIT config.sys background domain
c:\\test.zip\>MD backups
c:\\test.zip\>COPY config.sys .\backups\config.sys
c:\\test.zip\>CD..
c:\>COPY c:\\test.zip\backups\config.sys c:\config.bak
c:\>COPY c:\\test.zip\config.sys ftp://ftp.caldera.com/serv/incoming
running FTP in the
background
Ok, I think, that's enough to have you cracks some nice dreams
over this spring weekend... ;-)
Have fun,
Matthias
------------------------------------------------------------------
Matthias Paul ! My eMail address has changed. For some time !
Ubierstrasse 28 ! mails to former <MPaul AT ibh DOT rwth-aachen DOT de> !
D-50321 BRUEHL ! will be forwarded to the new address. !
eMail: <Matthias DOT Paul AT post DOT rwth-aachen DOT de>
WWW : URL: http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html
------------------------------------------------------------------
- Raw text -