From: "Matthias Paul" Organization: IBH, RWTH-Aachen To: opendos AT mail DOT tacoma DOT net Date: Fri, 21 Mar 1997 21:41:28 GMT+0100 Subject: Re: 32bit BIOS Reply-to: Matthias DOT Paul AT post DOT rwth-aachen DOT de Message-ID: <43E9F32776F@ibh.rwth-aachen.de> 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 ! D-50321 BRUEHL ! will be forwarded to the new address. ! eMail: WWW : URL: http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html ------------------------------------------------------------------