Navigation
Highlights

Release 0.0.5

The latest release, alpha testing, unstable. See "downloads".

2005-06-01

Links
Documentation

FreeDOS-32 FAQ

Table of Contents

1) Overview

General information about the project

1.1) What is FreeDOS-32?
1.2) How did FreeDOS-32 get started?
1.3) Where can I get FreeDOS-32?
1.4) Why bother writing yet another DOS?
1.5) What does FreeDOS-32 have to do with FreeDOS?
1.6) What makes FreeDOS-32 different from Linux?

2) Technical

Technical information for developers and testers

2.1) What are the FreeDOS-32 specifications? Where can I find them?
2.2) Can I compile FreeDOS-32 with MinGW or Cygwin?
2.3) Is the FAT driver safe for multithreaded execution?
2.4) I frequently get "Abort 64" on Bochs.
2.5) Why can't I load programs from the command line?

3) Compatibility

How FreeDOS-32 behaves with existing programs

3.1) Can I run real mode programs in FreeDOS-32?
3.2) Can I use my old device drivers in FreeDOS-32?
3.3) Can I run 16-bit protected-mode apps in FreeDOS-32?
3.4) Can I run 32-bit protected-mode apps in FreeDOS-32?
3.5) Will my protected-mode apps run faster under FreeDOS-32?
3.6) Are there any programs known to run under FreeDOS-32?

1) Overview

1.1) What is FreeDOS-32?

FreeDOS-32 (also known as FD32) is an open-source, 32-bit operating system intended as a replacement for MS-DOS and compatible operating systems. It runs in 32-bit protected mode, and as such, requires an 80386 or higher CPU. The software license used is the GNU GPL, thus FreeDOS-32 is free software. [Contents]

1.2) How did FreeDOS-32 get started?

The project started in August 2000 as a DJGPP port of the FreeDOS kernel by Sven Dehmlow. But while the FreeDOS kernel is wonderful in real mode, a simple 32-bit recompile of it (supposing that it was possible) was not the right solution to build a 32-bit DOS kernel. So Sven Dehmlow opened a mailing list to discuss how to modify the FreeDOS kernel in order to port it to 32-bits. It was clear that such a solution wouldn't have been better than the standard DOS+DPMI server approach, so the whole project has been completely redefined. Shortly afterwards Sven left the project, and almost all FD32 code has been written from scratch. [Contents]

1.3) Where can I get FreeDOS-32?

Right now, FreeDOS-32 is still in development. If you want to contribute, or want to test the work done so far, you are welcome to download the latest development sources through CVS, or a public alpha release. Please note that development of FD32 is still in an early stage, so it may contains bugs that could damage your system, especially in respect of disk services and data storage in general. Testing with emulators (such as Bochs) or machines with no valuable data is recommended. [Contents]

1.4) Why bother writing yet another DOS?

DOS is severly limited in many respects due to its real-mode architecture. In order to run most modern applications and games, which are 32-bit protected-mode programs, DOS uses special APIs to switch between real mode and protected mode. This is because despite the fact that the applications are 32-bit, the kernel and device drivers are 16-bit and suffer from the limitations of the 16-bit architecture. FreeDOS-32 is natively 32-bit, so it doesn't suffer from the same restrictions. [Contents]

1.5) What does FreeDOS-32 have to do with FreeDOS?

The main goal of the FreeDOS-32 project is to write an efficient 32-bit DOS-like kernel, and its related modules and drivers. But an operating system is much more than a kernel. In fact you have a shell and several utility programs. For the rest of the operating system, we refer to the standard FreeDOS distribution, recompiled to work in our new 32-bit environment. In this sense, you can think of FreeDOS-32 as an alternative kernel for the FreeDOS operating system. After all, this project started as a 32-bit port of the FreeDOS kernel, even if this choice has proved unsuccessful. [Contents]

1.6) What makes FreeDOS-32 different from Linux?

Linux and FreeDOS-32 are alike in that they are both 32-bit operating system kernels. But that's where the similarity ends. Linux is a multi-user, multi-tasking OS designed to be used as a server, whereas FreeDOS-32 is single-user and single-tasking, designed to be used by the end-user. There is also a difference in protection. Linux always runs applications in a protected environment, where it only has very limited access to RAM and I/O. FreeDOS-32 runs applications without any kind of protection, at least by default, letting the user have total control of the system, just like the real mode DOS does. Of course this doesn't mean that FreeDOS-32 is the best operating system and the others are bad, but just that FreeDOS-32 is designed to be tiny, fast and reliable, so it is well suited to real-time and embedded tasks. [Contents]

2) Technical

2.1) What are the FreeDOS-32 specifications? Where can I find them?

The FreeDOS-32 specifications are evolving specifications for the way that FreeDOS-32 works. They describe the technical details of how FreeDOS-32 works. Our aim is to provide FreeDOS-32 with a rich documentation. In the "documents" section of the FD32 web site you can find the FD32 specifications as well as documentation for kernel, drivers and how-to's. [Contents]

2.2) Can I compile FreeDOS-32 with MinGW or Cygwin?

Yes. Hanzac has provided support for using MinGW to compile the FD32 kernel and drivers under a Windows platform. Although it should work, we have not tried to compile FreeDOS-32 with Cygwin: please let us know if Cygwin is working for you. [Contents]

2.3) Is the FAT driver safe for multithreaded execution?

No, it isn't by design. There are no locks for internal structures, so concurrent execution of the services of the FAT driver is likely to lead to data and status corruption. This has been done in order to keep the driver simple. If you need to run the FAT driver in a multithreaded environment, you can create a "server" thread, which issues calls to the FAT driver request function, one at a time. [Contents]

2.4) I frequently get "Abort 64" on Bochs.

Workaround: append --tick 10000 to the kernel /bin/fd32.bin line in the menu.lst GRUB menu file.

Explaination: Abort 64 means that a timer interrupt fired before the kernel finished to serve the previous one. This basically means that the computer is too slow to serve timer interrupts at the frequency used by FD32 (1000 interrupts per second). It should never happen on real hardware, but frequently happens on virtual machines such as Bochs.
If you get an Abort 64 on real hardware, then there is a bug in the kernel. Please report it on the developers' mailing list or using the bug tracker. If you are using a virtual machine, the Abort 64 is expected, and the only way to work around it is to decrease the timer's interrupts frequency. This can be done by using the --tick kernel option (--tick 10000 means "a timer interrupt every 10000 us", that is 100 interrupts per second. Emulators are often fast enough for this). [Contents]

2.5) Why can't I load programs from the command line?

The kernel is able to execute natively only programs compiled with DJGPP, and linked at a free physical memory address, because the kernel has native support for a flat address space only (no segments). Luca is working on a wrapper to provide linear address spaces (segmented memory) to cope with this issue. [Contents]

3) Compatibility

3.1) Can I run real mode programs in FreeDOS-32?

We plan to support real mode programs through the use of a wrapper program that sets up a Virtual-8086 environment. Inside this environment, FreeDOS-32 will simulate legacy DOS, just like Windows 9x does. However this is not a priority right now. Anyway, you can already start FD32 from the real mode DOS (like FreeDOS), using a special loader called eXtender (see the downloads page). This allows you to shut FreeDOS-32 down at any time to return to the real mode environment you were in before. [Contents]

3.2) Can I use my old device drivers in FreeDOS-32?

At this time we think not, because the 16-bit format used by DOS device drivers is not compatible with the memory model used by FreeDOS-32, so you will likely need to use FreeDOS-32 device drivers in FreeDOS-32. We are thinking about possible solutions for that. Our aim is to exploit the modular architecture of FD32 to support several type of drivers, like UDI, Linux drivers, Windows drivers, as well as native drivers. [Contents]

3.3) Can I run 16-bit protected-mode apps in FreeDOS-32?

The 16-bit protected mode of the 80286 processor, used, for example, by applications created by some older Borland compiler, has not been considered yet. Our first goal is to provide an efficient 32-bit environment instead. However, it seems reasonable to run 16-bit protected mode applications using an appropriate wrapper program like for real mode applications. [Contents]

3.4) Can I run 32-bit protected-mode apps in FreeDOS-32?

Absolutely. FreeDOS-32's API will provide DPMI (the DOS Protected Mode Interface) for 32-bit protected-mode applications, besides the usual DOS application interface (Int 21h and similar). Your applications will just run in a truly native 32-bit protected mode environment. Our first goal is to support applications compiled with DJGPP, that is our reference compiler, but, for example, there is already some support for Windows console executables. [Contents]

3.5) Will my protected-mode apps run faster under FreeDOS-32?

Probably. We don't know for sure yet, but theoretically your program will run faster because in FreeDOS-32 you don't have the overhead of switching between real mode (actually, VM86 tasks) and protected mode, and you don't have to copy buffers between real mode memory and your program's memory (although some legacy protected-mode applications may do this anyway). However please note that, at present, FreeDOS-32 is absolutely not optimized for speed. [Contents]

3.6) Are there any programs known to run under FreeDOS-32?

Only test ones. The FD32 development is still at a very early stage, so several system calls are not implemented. See also question 2.5. Most notably, we have managed to run a command.com replacement, Python, SMEdit and Bash, although with limitations. [Contents]