Home page:
Download: SourceForge DOS-C Page
Author: Pat Villani (

DOS-C is distributed in source code form and is a fully functional MS-DOS compatible operating system by Pat
Villani. The kernel is also the FreeDOS kernel and may be redistributed under the provisions of GNU GPL. Updates to the source files are available by ftp. It is also the subject of a  book, FreeDOS Kernel (ISBN 0-87930-436-7).  You can also purchase this book from Elsevier CMP Books


DOS-C started in 1988 as an experiment in writing device drivers in C for Microsoft's MS-DOS. Both block and character device drivers were written, along with special C data structures to match the MS-DOS request packet. It was then recognized that using the same techniques, an operating system could be written that would take advantage of the C language features and would require much less time to develop than the traditional assembly language techniques. Although UNIX had proven this earlier, it was not tried with a traditional PC operating system.

At this time, a minimal operating system using the device drivers written earlier along with a new 8086 interrupt API was developed. It was called XDOS and proved to be a functional operating system. This new operating system was used to develop booting techniques and a C library SDK was developed for it.

XDOS enhancements were started in 1989 and MS-DOS was chosen as the new API. A more advanced architecture was also developed. This included the use of an IPL (intermediate program loader) to set up the operating environment prior to loading the operating system itself and reentrant system calls facilitating real-time applications. This version, know as NSS-DOS, was completed and demonstrated in 1991. As a result of these demonstrations, NSS was approached to supply source license for this operating system by a major defense contractor. The only new requirement - it had to run on 68K processors.

This presented a new challenge. Due to the MS-DOS model used for the API, NSS-DOS relied heavily on a segmented architecture. To meet this challenge, a major redesign of NSS-DOS was undertaken. New proprietary techniques were developed that allowed the same source to be compiled on a variety of hosts and with a wide range of compilers. This new version, DOS/NT, was the result of this new project. The kernel was redesigned as a micro kernel along with logical separation of the file system, memory and task managers. A new DOS API was designed along with a new DOS SDK to guarantee portability. Additionally, all processor unique code was separated from the core functions. The result is the highly portable operating system that DOS/NT represents.

After a number of successful commercial applications, DOS/NT became part of both dosemu and FreeDOS.  This version, DOS-C, is the subject of a book and is intended for binary redistribution, free of any royalty. See the accompanying license.txt file for details. If you have not received this file, contact me at the address below and I will send a copy to you.

The DOS-C kernel is also the FreeDOS kernel. FreeDOS is a project designed to provide an alternative to MS-DOS, PC-DOS and DR-DOS that is freely available. See the FreeDOS manifesto for details.


Where can I get more information about DOS-C's design?

Design information about the kernel is in the book, "The FreeDOS Kernel," available from CMP Books, 1601 W 23 Street, Suite 200, Lawrence, KS 66046, USA (telephone +1 913 841 1631). You may purchase it directly from CMP Books

The book covers the design of the kernel and uses example system calls as a guided tour through the kernel. If you plan to hack the kernel, this book is a must for you.

I thought the book was about DOS-C

It is. DOS-C shares the kernel with FreeDOS, an effort to replace MS-DOS for older PCs. But before I start a flame war, the effort was undertaken because Microsoft no longer supports any processor older than an 80386 starting with Windows95 and FreeDOS picks up where Microsoft left off.

Can I use XYZ C to build DOS-C

Yes, but be careful of it's output. Basically, I use Borland C++ v3.1 because it was the last version to output 8088 compatible object code. However, I use Microsoft C v6.0 whenever I debug using the remote debugger because that's what the remote debugger accepts.

I advise you to use whatever compiler you have available and work with it by examining the output. If it's acceptable, that is it will work with your intended target, take an approach similar to what I did. First compile each file individually. Review the warnings and make certain that they don't flag a potential problem. Next link DOS-C, but omit LIBM.LIB. The link will fail, but you will get a set of error messages that indicate what object modules you'll need

With this information in hand, invoke your library utility and use it to examine the libraries distributed with your compiler. Find the object modules you need, extract them and place them into LIBM.LIB. After you've done this for the first time, I suggest you build a MAKELIBM.BAT file similar to mine. You never know when a change or a new feature will invoke a new compiler library module.

Can I use gnu C to build DOS-C

No. The GNU C compiler currently don't support real mode (16-bit) X86 code generation. In addition, it will not run on a PC using MS-DOS in real mode. This defeats the purpose of FreeDOS, so there are no plans to port the compiler at this time. If you'd like to volunteer to write a new gcc back end, send me email.

I can't compile IPL.SYS under BC++ v5.02

I received the following question that I'd like to share here. Please note that you need to add /Tde to create dos executables.

I can compile everything under BC5.02 except the IPL. I get all the object file and everything, but when I go to link it I get this:

TLINK /v/m/Tde/c/l/P-/LC:\BC5\LIB @MAKE0000.@@@
Turbo Link Version Copyright (c) 1987, 1996 Borland International
Fatal: No program entry point

** error 2 ** deleting ipl.exe

I added the /Tde to generate a dos exe file, but I don't know where the @MAKE0000.@@@ came from, do you have any suggestions? I looked in your book, but it doesn't say much about linking.

The entry point for ipl should be defined in ipl.asm by adding the label of the entry point to the end statement. On versions of DOS-C prior to v0.92.1, it looks like I've forgotten to do that. I guess earlier versions of tlink and link simply ignored the entry point or defaulted to some predefined entry point (0 or 100h). In any event, change the 'end' to 'end entry' and the problem should go away.

The @MAKE0000.@@@ file is generated by make itself as part of the build process. Originally, the files I used to build ipl.sys was small, so my rule for linking was simple. Eventually, the list of files that I needed to pass to link was too large to fit on a single line. This broke make so I needed to pass the file list some other way.

If you look at ipl.mak, you'll see that I choose to use make's &@@ that takes the list of files delimited by '|' and creates a temporary file. The way I've written the rule, make uses this temporary file as a response file for tlink and deletes it when done. This eliminates the need to create a response file, say ipl.lnk, and allows me to manage a single file that I place under source control. So, @MAKE0000.@@@ is the file created by make and carries the list of files to link, the names of the exe and map files and the libraries to link to.

Why didn't you use the "foobar" structure that MS-DOS used?

The answer to this is quite simple: DOS-C was not designed as a copy of MS-DOS. I designed the family of DOS compatible operating systems that DOS-C is a part of by using the published programmer's references and a few reference articles. There were no "Undocumented DOS" books or articles when I started, so I was unaware of the extent of dependence upon DOS internals. I chose my own data structures and designed the operating system around them.

With the later releases of DOS-C, I've begun implementing the important data structures as the need arises, so future releases will allow more programs to run on DOS-C that cannot at this time (typically network redirectors, programs that use the redirector facilities to trick the file system code in MS-DOS and TSRs that attempt to multitask MS-DOS).

A little editorializing: there is constant debate over Microsoft's use of undocumented features in MS-DOS, Windows and now Windows95. In all fairness to Microsoft, I've seen other operating systems that also have undocumented interfaces. My opinion is that programmers should avoid these whenever possible. However, Microsoft did go to extremes to hide key features and I fault them for this. You don't go out of your way to hide these key features unless you are actively trying to lock out competition.

DOS-C is open and will remain open. The source code is available to all under GNU GPL and I will continue to make it available in the future. Please do not make changes and fail to publish the source. This violates the purpose of DOS-C.

DOS-C is not part of the FSF software collection, but I do use their GPL to protect my copyright and your right to redistribution.

Why is floppy disk access is so slow under DOS-C?

It's actually very simple. I originally wrote the code as part of a real-time os. That os had disk drivers that worked with dma and were multitasking. So, I took advantage of it and only did all my reads and writes out of the disk buffers. The next sector was always set for read-ahead so that while I was reading or writing the current sector, the next one was filling the buffer.

For the bios drivers, I need to specifically fetch each sector and wait until it finishes. This is too slow to read the next sequential sector so each sector read waits for another revolution of the disk. Since this is tens of millisconds, it is very slow.

In beta 4, I optimize the code and rewrite the code that does the disk accesses. This code will only read into the buffers fragments from the first and last sectors of the read and everything else in-between will go directly to user space. That will speed things up considerably.

Remember, you're using work in progress.

What is DOS/NT?

DOS/NT is the commercial predecessor to DOS-C. I designed DOS/NT for embedded systems and there are now quite a few mission critical systems that use it as the basis of their applications. DOS/NT is portable and there are 68K, real mode 8086 and protected mode 80386 versions.

The DOS/NT kernel is made up of four components: the microkernel, the file manager, task manager and the memory manager. The microkernel supports multi-tasking threads and messaging. The task manager uses an extended PSP and supports threads at the user level. It also has the ability to load ROM code so that the code executes in place. The file manager implements multiple file system types including a memory file system. Finally, the memory manager handles all memory allocation and data transfer to and from user memory.

There were three versions available. The first version is a shareware version that just implemented DOS compatibility. It is this version that DOS-C is derived from. There was a registered version that included some handy utilities but did not implement the full features of DOS/NT. Finally, the developer's version implemented all the features and could be built as either a stand-alone system or as an integrated part of an embedded application..

Unfortunately, I am no longer able to supply or support this code.

Does the "ABC" program work with DOS-C?

Thanks to the FreeDOS testing effort, I have the following list of programs that work with the current version. This list updated periodically, so check back occasionally to look for updates.
Works                           Partially works          Doesn't work
-----                           --------------          ------------
WordPerfect v5.1       0.70        *Norton utilities(1)
*qbasic                                                 *BC 3.1
doom                                                    *DeSmet C
*galaxy word processor                                  *Windows 3.1(2)
*logitech mouse driver
*logitech pt editor
*Turbo debugger (BC3.1)
Turbo C++ 3.0
*browse file browser
*overview file manager

* - verified
1 - missing direct disk support cause failure
2 - complains that HIMEM.SYS is not loaded (we don't have one).
If you want e-mail sent directly to you whenever there is a new feature or the known application list is updated, send email to with the subject subscribe and I will add you to my mailing list.