The goal of the FreeDOS Project is to create a free implementation of MS-DOS. DOS is a popular system, and there is plenty of hardware out there that supports DOS. The FreeDOS Project was founded in 1994 by Jim Hall.
FreeDOS is not a derivation of MS-DOS - we are not using or referring to any Microsoft code. We are instead using the description of the MS-DOS program as given in publications (such as the user manual) to create a program of our own that follows that spec.
1.2 Where can I learn about FreeDOS?
The official home of the FreeDOS Project is www.freedos.org. There is also a FreeDOS WebRing
You may also consider joining the FreeDOS mailing list. Or, you can post a message to comp.os.msdos.programmer or comp.os.msdos.misc (whichever seems more appropriate) and ask your questions there. A lot of people in these groups are pretty knowledgeable about FreeDOS. A number of FreeDOS mailing list members are also part of c.o.m.m and c.o.m.p.
1.3 Will FreeDOS run on my PC?
In short, yes, FreeDOS should run on all PC's. That means you can run FreeDOS on your Pentium-Pro 800Mhz. It will just run really fast. You can also run FreeDOS on your 5MHz PC-XT. It will just run a little slow.
FreeDOS will run on all levels of PC's, from as low as an XT with 640k memory. We may one day expand the project to support 32-bit extensions such as protected memory or multi-tasking, but for now we are content with supporting the lower systems.
All of this information, and more, is spelled out in the FreeDOS Manifesto.
1.4 Will FreeDOS work under a PC emulator?
Yes. FreeDOS works well in several PC emulators, including the popular Linux DOSEmu. In fact, FreeDOS is the official DOS of the DOSEmu folks.
FreeDOS is also used in other PC emulators as well, including Mac Bochs, and VMWare (for Linux and Windows NT.)
1.5 Can I use FreeDOS to install my copy of Windows?
FreeDOS will run most MS-DOS programs. However, Windows is a special case. Microsoft Windows does not like to run on any DOS other than MS-DOS. Some people have reported success in running MS Windows on FreeDOS, but I don't recommend it.
Yes, FreeDOS really is free. Most FreeDOS programs are written under the GNU General Public License. This means that the source to all FreeDOS programs (including the kernel and replacement COMMAND.COM shell) is available.
1.7 Can I bundle FreeDOS with my commercial app?
The short answer is: yes, if you pay close attention to the GNU GPL.
Some software in the FreeDOS software distribution is protected under other licenses, so you should be sure to check the licensing of any program that you want to bundle with your app.
1.8 Is FreeDOS the same as OpenDOS?
FreeDOS is not associated in any way with OpenDOS from Caldera.
Actually, Caldera has re-named OpenDOS to DR-DOS, because their DOS was neither really open nor free.
1.9 What programs can I run on FreeDOS?
Refer to the FreeDOS Maintainers Lists for a list of all programs that are currently distributed with FreeDOS.
To see a list of old DOS programs that are currently known to run on FreeDOS, please see the kernel compatibility list.
If you would like to contribute to the FreeDOS Project, you might look at Jim Hall's To-Do List for a place to start. You should also read the Coding HOWTO for guidance on writing your program.
A frequent question on the mailing list is: what programming language should I use? The answer is provided in the FreeDOS Spec, that if you are writing a program that reproduces the functionality of MS-DOS (i.e. a program for the Base list) then you need to use either C or Asm. If you use C, please make sure your program will compile correctly on Borland C 3.1. If you use Asm, your program should assemble properly on MASM.
If you are writing a program that is not for the Base list (i.e. it is some extention third-party software such as a modem dialer) then you can use pretty much any programming language that you prefer.
If you intend to do some serious work for the FreeDOS project, you may also want to join the FreeDOS mailing list.
Submit a maintainers list entry when you have at least a 'beta' available of your program. I am trying to avoid adding any more 'TBD' projects to the maintainers list, as they don't really do me much good, and I have had to take down too many entries because the 'owner' didn't get a chance to finish the program.
You should continue to post updates on your progress to the FreeDOS Mailing List, to (a) let people know where you are, in case they can help or are willing to test, and (b) to continue your 'claim' on the program so no one thinks that you've stopped working on it, and decide to take the project on for themselves.
1.11 What is the difference between the kernel and command.com?
Jan Verhoeven writes:Kernel is the nucleus (kern is germanic for nucleus) of the operating system. Traditionally this is loaded from/by IBMBIO.SYS and IBMDOS.SYS like files. In our case we load one file called Kernel.Sys.
Command.Com is the command interpreter that acts as an intermediary between you, the user, and the computer. It does all the nasty things you COULD do yourself, but which are far better handled by a dedicated program.
They are distinct. Command.Com is in fact mostly user level, whereas Kernel is mainly systems level.
Command.Com, or FreeCom, as we call it, uses the system calls that are needed to control the computer. The Kernel defines the system calls that are needed for the computer.
1.12 I have the source code for MS-DOS! Would you like to see it?
Please do not do this. It is highly inappropriate for any person who is contributing towards the FreeDOS Project to have any "inside" knowledge of the MS-DOS source code. For this reason, you should not have sent this URL to me. I ask you not to do this again.I delete mail that suggests things like this.
The very fact that you have the source code that purports to be MS-DOS is also inappropriate, and possibly exposes you to legal problems from Microsoft. I would urge you to delete all copies that you have of this software.
1.13 How do I use my CD-ROM driver?
The same as you install a CD-ROM driver under MS-DOS:1. In config.sys, you add a DEVICE line to load the driver. For example, if your driver was called IDE_CD.SYS and was in the C:\CDROM directory, you would type:
DEVICE=C:\CDROM\IDE_CD.SYS /D:CD00012. In autoexec.bat, you bind the driver to the CD-ROM extender. For example, if you are using FDCDEX:
FDCDEX /D:CD0001
(I think that is correct usage.) If you were using MSCDEX:MSCDEX /D:CD0001
2.1 Why can't I get the install program to work?
First of all, let's make sure you have the latest copy.
Then, make sure that you have downloaded the FreeDOS Install documentation (usually a README and an INSTALL.TXT) and that you have read them.
Finally, did you check for any errata? Usually these are posted on www.freedos.org/files/
2.2 Why can't the install program find the BASE.1 disk?
I'll assume that after you hit 'y', the floppy disk light will light up for just a second, before you get the next prompt? The install program is looking for a file on the floppy disk named BASE.1. The volume label on the disk means nothing to the install program. However, if BASE.1 is not in the root directory on that floppy, then the install program assumes this is some other disk, and it asks you to load the correct floppy. That's why you keep getting the same message.
All of the install files (the zip files, plus BASE.1 and BASE.TXT) need to be in the root directory of the floppy disk. Do not put them into subdirectories... the install program will not find them there.
2.3 Do I have a broken copy of the distribution?
There shouldn't be any broken copies of the FreeDOS Distribution floating out there. If you're concerned that you have a bad copy, you can download a copy from freedos.org.
Please do not forget to read the Errata!
However, the FreeDOS distribution (at least up to the Beta 3 release) is set up for 1.44MB floppies. If you have 360k or 720k floppies, then you will need to break apart the floppies and create your own distribution. The install program documentation on the install program web site should be able to help you.
2.4 Why didn't the Install program create a config.sys and autoexec.bat?
You need to create these yourself. Perhaps I should add code to do this, or at least provide a sample config.sys and autoexec.bat as an install package in the next distribution to use as a starting point?
However, a good CONFIG.SYS to start with might be:
FILES=20 BUFFERS=20 VERSION=6.22A good AUTOEXEC.BAT might be:
ECHO OFF ALIAS LS=DIR ALIAS COPY=C:\FDOS\BIN\COPY.EXE PATH C:\FDOS\BIN;C:\FDOS\EMACS SET EMACS=C:\FDOS\EMACS\ SET HELPPATH=C:\FDOS\HELP SET PAGER=MORE
2.5 How do I manually install without the install program?
The Install program (until version 4.0) is just a glorified front end to UNZIP, allowing you to select what to install and what to leave alone. If you Unzip every one of the zip files in the distribution, you will just be installing everything, which may be more than you want, but it works.
2.6 How do I make my hard disk bootable with FreeDOS, after installing FreeDOS?
The short answer is to boot from the FreeDOS Install Boot Floppy. When your system comes up, just type:
SYS C:After that's done, remove the floppy from the A: drive, and reboot. Your system is now running FreeDOS.
2.7 Is there a virus on the boot floppy for the FreeDOS distribution?
Some anti-virus software, including Norton's, will report that the install boot floppies contain a virus (usually reported as the 'Bloodhound' virus.) This is a false positive, there is no virus. If your MD5 Sum matches the server, then you should be okay.
Chip Burkitt writes:
Norton AntiVirus 5.0 identifies the FreeDOS boot record as infected with a Bloodhound.Boot virus. It turns out that 'Bloodhound' is actually a heuristic for identifying unknown viruses. Apparently, something in the FreeDOS boot record triggers the heuristic, and Norton reports a viral infection.
2.8 What is the Actual Directory Structure for the install program?
Some of this is explained in: fdinst.htmlBasically, files get installed into: BIN, HELP, SOURCE, and DOC. The path leading up to that is whereever you installed FreeDOS.
For example, if you installed FreeDOS into C:\FDOS\, then your program binaries would go into C:\FDOS\BIN, your FreeDOS help files would go C:\FDOS\HELP. All doc files related to project FOO would go in C:\FDOS\DOC\FOO\ and all source for FOO would go in C:\FDOS\SOURCE\FOO
Some information was lifted from the DOS-C FAQ by Pat Villani. Pat is the original author of the FreeDOS kernel.
DOS-C is the FreeDOS kernel. It was developed by Pat Villani, originally as a DOS kernel for embedded systems (then known as DOS/NT). DOS-C is a highly portable operating system, written mostly in C, that provides systems calls similar to MS-DOS. Refer to the FreeDOS Compatibility List to see what programs are known to work with the FreeDOS kernel.
From Pat Villani:
DOS-C, in its original form was the shareware version of DOS/NT. It was complete as per int 21h specifications supported by DOS/NT, i.e., only what was published in the Tech Ref manual and no FCB code. It was not a 100% MS-DOS compatible OS nor was it meant to be. This is what I originally contributed. I originally was going to contribute the code and walk away from the project. As you can see, I changed my mind.
DOS-C, as it stands right now, is the product of my work over the past few years. It is more than what is in the book because there are significant changes from what is in the book, although the book is still enough to guide you through the code. There is new code for error handling, SDA, break handling, interrupts and system call, etc. This is the FreeDOS kernel I committed to. It is still 85% C and 15% assembler, now over 32000 lines of non-commented source code and growing.
DOS-C in June or July will be a 99% MS-DOS compatible OS. It will still use many of the algorithms but there are significant changes to handle the redirector interface necessary for FreeDOS and dosemu. It will contain a slew of utilities that are MS-DOS work-alikes that will probably not be part of FreeDOS. This is the same as it is today, i.e., the FreeDOS command.com is a totally new work that is different from mine.
3.2 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 Miller Freeman, Inc., 1601 W 23 Street, Suite 200, Lawrence, KS 66046, USA (telephone +1 913 841 1631).
Also available through amazon.com and other booksellers.
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.
3.3 Can I use X compiler to build DOS-C
From Pat Villani:
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.
3.4 Can I use GNU C to build DOS-C
From Pat Villani:
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.
3.5 What is the status of findfirst?
findfirst/findnext is currently broken in the 2017 kernel (yes, including 2017f.)Steffen Kaiser writes:
FreeCom v0.78+ (maybe v0.77, too) does not work on kernel 2017f. Other shells, like Ndos v8.0 (a clone of 4dos v3) and 4dos v6 does not work either! All three shells have problems to find executables (I wasn't even able to execute INT.COM to turn on kernel debugging support). From what I see this applies to all Findfirst-like operations in a more-or-less drastic form.
3.6 Why didn't you use X structure that MS-DOS used?
From Pat Villani:
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.
3.7 Why is floppy disk access is so slow under FreeDOS?
From Pat Villani:
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.
Remember, you're using work in progress.
From Pat Villani:
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. For those who are interested, you can find copies of the shareware version of DOS/NT on ftp.cygnus.com and on Compuserve.
Unfortunately, I am no longer able to supply or support this code for personal reasons.
3.9 Does X program work with FreeDOS?
Please see the FreeDOS Compatibility List.
3.10 Why can't I use my large hard disk with FreeDOS?
The FreeDOS kernel (even as late as build 2017f) still contains the bug for 512MB disks. Do not use this kernel if you plan to access - even read - a disk partition bigger than 512MB. If you do, you will find that your drive is corrupt, and you will need to reformat and re-install your software. This is a well-known bug with large hard disks, advertised on the FreeDOS sites since Aug 12 1998.
From Pat Villani:
The reason for the delay in releasing the new kernel is that I'm trying to track down a serious bug. It seems that any disk over 512 MByte may or will be corrupted if trying to either install the kernel to it or try to use the kernel to write to it. I've just received yet another report of such an occurrence.
Andy Blakely also contributes this:
I wasn't about to reformat my hard drive... so I came up with an alternate plan to save my 6.4GB disk. I borrowed my dad's hard drive running Win95 and installed it in my computer, moving my hard drive to D:. When I got his drive to work, my Nuts&Bolts 98 program immediately caught the error in my boot sector. It prompted me to fix it, risking the loss of all data. It fixed it in the blink of an eye. No problems now, and I've got another hard drive that's 244MB which should be fine for FreeDOS. Thanks for responding to my SOS. And let it be known that it isn't completely necessary to reformat the drive. Even though I used Nuts&Bolts, Microsoft's scandisk also fixes bad boot sectors.
3.11 How do I assign new drive letters?
FreeDOS (like any DOS) will assign a letter at boot-time. Starting at C:, DOS assigns a letter to all the primary DOS partitions on each drive, then to each of the logical DOS partitions for each disk. For example, let's say I have two 300MB hard disks in my computer, and they are partitioned like this:
(1) [primary - 100M] [extended - 200M] [logical - 50M] [logical - 150M] (2) [primary - 200M] [extended - 100M] [logical - 100M]Then letters are assigned like this:
(1) [primary - 100M] C: [extended - 200M] [logical - 50M] E: [logical - 150M] F: (2) [primary - 200M] D: [extended - 100M] [logical - 100M] G:Or, if I combine my two logical disks on disk 1, then letters would be assigned like this:
(1) [primary - 100M] C: [extended - 200M] [logical - 200M] E: (2) [primary - 200M] D: [extended - 100M] [logical - 100M] F:And if I remove disk 2, or at least delete all partitions on drive 2, then letters are now assigned like this:
(1) [primary - 100M] C: [extended - 200M] [logical - 200M] D: (2) [none]
3.12 What happens when FreeDOS boots up?
Mark Aitchison writes:On power up or after the reset line is held low(?) the x86 family of CPUs jumps to a preset memory location, 16 bytes before the end of the first Mb - i.e. FFFF:0 or F000:FFF0), which is in the BIOS ROM, and will be a far jump to something like F000:E056 (that detail depends on the BIOS).
BIOS will carry out Power-On Self Tests (POST routines), and then it will look for adapter cards that have ROM at 2Kb(?) increments from something line C000:0 upwards (somebody corect me if I'm wrong). If the first two bytes of a possible ROM area start with the AA55 signature word it will run the code starting at offset 3(?). This might be for a video card, SCSI card, LAN adapater, etc. The interrupt table will have already been set up (debug the BIOS to find details if you need to). The adapter ROM might add a disk to teh syetm or boot from the network instead of allowing the normal boot from local disk to continue. Warm/cold boots - including whether the standard interrupt table is copied from ROM to RAM depends on a flag in segment 40 hex. Look at Ralph Brown's info, and note how you can modify 40:13 to reduce the effective RAM size then call int 19... so the BIOS startup doesn't have to change everything.
But generally the firmware will load the first sector off the first disk(ette) according to BIOS setup options that might check for C: before A:, etc. In the case of a hard disk this normally contains the MBR with a partition table (doesn't have to though - you can have a hard disk that is all one partition, no partition table, but this only happened in old versions f DOS and is a pain for modern software).
Whether it is diskette of a hard disk, the first sector will be loaded at 0000:7C00. I think the DX register and maybe something else may have important values at this stage (going from memory here though).
Normally DOS boot sectors have a 2 or 3 byte jump instruction at the start so they skip over the OEM name and Bios Parameter Block (that describes the sectors per FAT, etc). Different versions of DOS have had different length BPBs so later ones include a serial number (leaving less bytes for boot code).
Hard disk Master Boot Records (MBRs) don't skip over a BPB, but do leave a table of 4 partition entries towards the end of the sector. (Both DOS boot sectors and MBRs should have an AA55 signature word in the last 2 bytes of the sector to prove it is valid). An MBR will scan the partition table, maybe relocate itself in memory, and load the selected partition's boot sector and carry on like a diskette boot where there wasn't a partition table (or it gives an error message that no valid active partition was set and halts/whatever).
Boot sectors can load the operating system files any way they like; old versions of MSDOS insisted the two invisible files (IO.SYS and MSDOS.SYS) were in the first two boot sector entries (hmm - not sure both needed to be at the start, but I think that was true), but at version 5 (? or 6?) they searched the root directory, to avoid the stupid error from SYS.COM complainuing there was no room on the diskette when there obviously was).
Different versions of DOS pass some important informaton in some register or require a certain byte in the boot sector that remains at 0:7C00 to help the first of the system files loaded. Note that the FreeDOS kernel is a bit different to MSDOS, PCDOS and DRDOS in the boot file - certainly not worse, just different, so beware of generalising too far from observations about how Pat's kernel does it.
Ken Yap adds this information about the BIOS POST:
Yes, that's correct. Here are some more bits:
Offset 0 AA 1 55 2 size / 512 rounded up 3 entry point The blocks of the extension BIOS are then checksummed and must sum to 0. If so the BIOS does a far call to offset 3. The extension BIOS then does any initialisation it wants to and sometimes replaces interrupt vectors, then does a far return. For example a network boot ROM will modify the INT19H entry point. Another entry point sometimes used is INT18H which is activated after disk booting fails, it's the ROM Basic entry point.
Roger C. Pao adds this about the BIOS:
The System BIOS calculates the Extension BIOS checksum using an eight-bit value, ignoring the carry over. Older BIOSes would report a checksum error. My current BIOS silently ignores an Extension BIOS which fails to checksum to zero.
The books I read talk about calculating checksums using a sixteen-bit value. As I see it, the only process which will use a 16-bit checksum is a flash programmer to verify the integrity of the burn. The 16-bit checksum may be written on the sticker of the EPROM covering the erase window.
3.13 Does the FreeDOS kernel support LFN?
Joseph Morris writes:There is an API that lets you make your own programs LFN compliant, it is one of the things Microsoft has documented pretty well (otherwise people wouldn't use it and Win95 would fare badly).
DJGPP's libraries support this automatically, if you compile your program with it and set LFN=Y in your autoexec.bat
The next problem is a program to provide the LFN API. The guys at Caldera UK wrote a TSR to do this, but it was rather buggy, closed-source and is probably unmaintained. It had a nasty problem that it would often pervert directories you created LFNs in, so that it could not be removed anymore.
There is another program, called STAR-LFN. I've only tried an old version so far, but there is a new one dated 19-09-99.
It cannot read LFNs directly from disk in the VFAT extensions, instead it stores them in a file called longname.dat
It contains source code, and appears to be Public Domain. If someone wants to ask this guy, it can probably be GPL'ed and added to the Freedos utility pool.
The URL is: http://c64.rulez.org/~sta
It also points to another, VFAT-capable program at http://members.xoom.com/dosuser
I have not had time to check it out.
4.1 What environment variables should I create?
For Jim Hall's Help program, you need to set the PAGER and HELPPATH environment variables in Autoexec.bat. Reasonable values are:
PAGER=MORE
HELPPATH=C:\DOS\HELP (or wherever you installed FreeDOS)If no values are found in the environment, I think Help uses MORE and C:\FDOS\HELP by default.
Note that Joe Cosentino has written an html Help program, and we will switch to that when we have enough support for it.
For Freemacs, just set the EMACS environment variable. Set it to:
EMACS=C:\FDOS\EMACS\Yes, you need the trailing backslash.
Unless otherwise stated, FD-DOC HOWTO documents are copyrighted by their respective authors. FD-DOC HOWTO documents may be reproduced and distributed in whole or in part, in any medium physical or electronic, as long as this copyright notice is retained on all copies. Commercial redistribution is allowed and encouraged; however, the author would like to be notified of any such distributions.
All translations, derivative works, or aggregate works incorporating any FD-DOC HOWTO documents must be covered under this copyright notice. That is, you may not produce a derivative work from a HOWTO and impose additional restrictions on its distribution. Exceptions to these rules may be granted under certain conditions; please contact the FD-DOC HOWTO coordinator at the address given below.
In short, we wish to promote dissemination of this information through as many channels as possible. However, we do wish to retain copyright on the HOWTO documents, and would like to be notified of any plans to redistribute the HOWTOs.
If you have any questions, please contact the FD-DOC coordinator at jhall1@isd.net.