32-Bit DOS. Where Technology Is Heading.

Mike Podanoffsky
mike.podanoffsky@mindspring.com

You may know me as the author of RxDOS. You can download the sources to RxDOS from http://www.freedos.org/files/distributions/rxdos/

From time to time there has been some considerable interest in moving DOS from 16-bits to a 32-bit environment. The motivation is simple: 16-bits limit the address space to 1MB, your PC has a great deal more memory available, and some problems require a greater address space.

A very powerful system can be created in a 32-bit environment. That system could host DOS and DOS applications. I want to walk you through all of the real-world problems and issues and in the end describe an architecture for a 32-bit Operating System that would address all of these issues.

Hardware Modes

The Intel x386 architecture expects to run in one of three modes: Real, Protected, and Virtual modes. In Real mode, the processor is essentially locked into a 16-bit mode which can address approximately 1MB of memory. This is 'DOS mode' as you and I have come to know. The memory addressing scheme relies on 16-bit segment registers CS, DS, ES, and SS, for code, data, extra, and stack segments, respectively. There are no restrictions on the values that can be put into any of these registers.

In Protected mode, the processor allows an operating system to map the memory that an application can access. This protects applications from corrupting each other. It also part of the solution that allows terminating one application without affecting the others. This is, of course, a good thing. But it does mean that applications are now restricted in the value that they can place in segment registers. Even within the valid address space for an application, only the base value for a segment is mapped. All other values are illegal.

To understand this better, consider what is valid in 16-bit real mode versus what is illegal in protected mode. Using segment arithmetic (the segment value is always shifted left by 4 bits), the following will work in real mode, but will generate an exception in protected mode.

To address memory location 04030, you can use DS=0400 and BX=0030. The DS value is shifted left by 4 bits to produce 04000. The BX value of 0030 is added to produce 04030. Values are in hex.

That same memory location can also be addressed in real mode by DS=0402 and BX=0010. (04020 + 0010).

In protected mode, things can work considerable different. 0400 and 0402 can point to totally different memory locations (and often do) because there is no rule that says two different segment addresses have to point to contiguous memory locations. In the x386 architecture, which includes the Pentium, mapping segments registers contiguous to emulate real mode would require mapping 65,536 segment registers. Each mapping takes several bytes, eating approx 512k of memory!

One solution is to create Virtual sessions. Within a 16-bit virtual mode session, the processor emulates a real mode session. Windows 95/98/NT use this mode to run one or more DOS boxes within their visual environments. DOS is still 16-bits, but now at least you can create and run multiple DOS applications.

For each DOS box, the OS can map some 32-bit memory to the process. It could wrap that memory through DOS extenders API, which can support contending allocation and free requests, say from different TSRs.

Cool, Now What

Once you have multiple sessions running, you need to add substantially more features to your operating system. For performance reasons, you'll want a better way to handle the disk. You could use the BIOS, but you'll have to switch in and out of real mode. That's not so bad, after all, Windows 3.1 did it, but that was a long time ago and we know better. You'll need protected mode drivers, at least for the disk, keyboard, and video.

You'll want to map memory to disk as well. It is impossible to achieve any kind of optimal performance if every time someone wanted to access the FAT table or the root directory you actually had to physically read the disk.

You'll need some form of concurrency control. Not everyone can be accessing the same part of the FAT at the same time. Processes need to lock sections of the disk while they perform disk allocations or updates to directories, otherwise they may get interrupted and find that their data updates have been trampled upon.

Finally, of course, you'll need a scheduler that allocates time between different DOS sessions.

Still Only 16-Bits

You may not have noticed, but none of the above actually gave you 32-bit functionality. It was the same great DOS functionality in a DOS compatible box. All existing DOS applications can still run, but with the existing limitations.

We can define a pure 32-bit environment. That environment would be incompatible with existing DSO applications, but it would allow the creation of a new set of applications that could take advantage of a 32-bit address space (4 GB). A 32-bit API could be defined that was largely compatible with the int 21 API. We could also provide POSIX compliant functions to access the disk, set up threads, and handle concurrency control.

Operating systems like Windows 98, WinNT and Linux provide these and many more services. And because they do, and have such a great lead time over anything we can do, one has to question what value-added can be provided in a 32-bit DOS. Windows provides int 21 functions to 32-bit programs that are emulated over low level functionality, as shown in the figure below.

Host DOS

My answer to those who ask is that DOS should exist in its present form. It should be hosted in other more powerful operating system. This is a win/win environment where compatibility is maintained, multiple DOS sessions are possible, and any new development is performed on true 32-bit functionality.

You may disagree. We can exchange ideas.