# The FreeDOS kernel keeps the 0xFD DOS core compatible and buildable > FDOS/kernel is the C implementation of the FreeDOS MS-DOS and PC-DOS compatible core, derived from Pat Villani's DOS-C kernel and released under the GPL v2. It suits anyone who needs a DOS-compatible kernel source they can read, fork and build, and it targets 8086 and later IBM compatible hardware. **FDOS/kernel** — FreeDOS kernel - implements the core MS-DOS/PC-DOS (R) compatible operating system. It is derived from Pat Villani's DOS-C kernel and released under the GPL v2 or later. Please see http://www.freedos.org/ for more details about the FreeDOS (TM) Project. - Repository: https://github.com/FDOS/kernel - Website: http://kernel.fdos.org/ - Stars: 1,059 · Forks: 180 - Language: C - License: GPL-2.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/fdos-kernel ## The kernel is one piece of a larger FreeDOS tree FDOS/kernel is the kernel half of the FreeDOS Project, and the README points to freedos.org for the wider picture. The kernel implements the core MS-DOS and PC-DOS compatible functions, and it is derived from Pat Villani's DOS-C kernel, released under the GPL v2. The repository is the kernel only, but the directory layout shows how much surrounds it. There is a kernel/ directory for the core, a drivers/ directory, a lib/ directory, a sys/ directory, a boot/ directory, a hdr/ directory for headers, and a utils/ directory. There is also a set of top level files that act as the build's input data: config.m, config.b, filelist, country, and a share/ directory. That layout is the shape of a DOS source tree, and it explains what kind of project this is. This is not an application you install and configure. It is the lowest layer of a DOS system, the part that owns the file system primitives, the memory map and the interrupt vectors, and the rest of the tree exists to give that layer something to talk to. The README describes the project history in a way that is unusual to encounter in a repository README. It was originally a branch based on the 2042 SVN 0xFD kernel, and the full SVN history has since been added to git, visible in the other branches. So the git history is not the whole story of the code, and a reader tracing a change back to its origin may need to look at the imported SVN history as well. The homepage is kernel.fdos.org, and the maintainer gives an email address in the README and invites forks and pull requests. ## Two kernels exist, and this one is the compatibility-first branch The README draws a distinction that matters more than anything else in the file. This version of the kernel is intended only for 8086 or 80386 and later IBM compatible computers, in continuation of the goals of the FreeDOS Project. The maintainer separately points to his 0xDC kernel, which is work on merging back in some of the original portability aspects and other supported features, at the cost of some compatibility with older hardware and software. So there are two lines of development with a different trade each. The 0xFD line, which this repository holds, keeps compatibility with old hardware and old software as its priority. The 0xDC line aims at portability and additional features, and pays for it in compatibility. A project that needs a DOS kernel on a 286 or a 386 with early revisions of a specific program is looking at 0xFD. A project that wants a kernel that runs on more than the IBM PC lineage is looking at 0xDC. The version scheme follows the same numeric logic. The README says the current 0xFD version is 2.45, and the release tags use the ke2046, ke2045 and ke2044 names with version numbers 2046, 2045 and 2044. The 204x series is the 0xFD build number, so ke2046 carries build number 2046 on that branch, and 2.45 in the README is the marketing version of the same line. That dual numbering is worth holding on to when you look for a specific build, because the kernel's internal version and the tag name are not the same string. ## Building means batch files on Windows and shell scripts on CI The build system is a DOS-era one, and the repository shows both faces of it. The Windows path is a set of batch files at the top level: build.bat, buildall.bat, clean.bat, clobber.bat, default.bat, MAKEPKGS.BAT and RELEASE.BAT. The names describe a build with stages. buildall.bat presumably builds everything, clean.bat and clobber.bat are two levels of removal, MAKEPKGS.BAT is the packaging step, and RELEASE.BAT is the release step. The Makefiles live in a makefile file at the top and a mkfiles/ directory, which is the convention of a build driven by a make variant that works on DOS. The configuration lives in config.m and config.b, and there is a setver/ directory that is presumably where the version number is set, since the version is part of the release process. The filelist file and the country file are the kind of data-driven inputs that let a makefile enumerate what to build. The Unix and CI path is separate. There are three shell scripts: ci_prereq.sh, ci_build.sh and ci_test.sh, which is a clean separation of installing prerequisites, building, and running tests. The README says the project now has automatic builds and soon tests, with a build workflow badge, and that phrasing tells you the test story is not finished. The CI scripts are also the practical answer to how you build this today. The batch files assume a DOS-era toolchain on Windows, while the shell scripts are the version that runs in an automated environment, so a contributor who wants a build without assembling the historic toolchain is relying on the CI path. ## Tests exist in the tree but the README calls them a work in progress There are both test/ and tests/ directories at the top level, and a ci_test.sh script, so the project has a testing story on disk even if the README describes it as coming soon. The distinction between test/ and tests/ is probably meaningful. A singular test/ directory next to the source layout often holds the harness or the test driver, while a plural tests/ directory holds the cases. In a kernel of this vintage, testing means running a kernel image and checking what it does, which is a different discipline from unit testing a library. The docs/ directory is also present, and it is where a project of this age usually keeps its specifications, the DOS function reference and the notes on behaviour that the code has to match. For a compatibility kernel, that documentation is often more valuable than the code, because the code exists to reproduce a documented behaviour that other software depends on. The honest framing is that the test infrastructure is present in the repository and wired into the CI scripts, while the README still lists automatic tests as forthcoming. For an adopter, that means the build is reproducible in CI but that the assurance you get from the test suite is uneven, and a kernel is exactly the kind of component where you want to know what has been exercised. It is also worth naming what a kernel test can check. A DOS kernel's contract is largely about what happens when a program calls a documented function: file operations, memory allocation, console output, and the error codes returned on failure. Those are testable. Whether every device driver in drivers/ works on every piece of hardware is not, which is the gap that remains. ## Prebuilt kernels are published, but the README flags the download links as stale The README offers a shortcut for people who do not want to build. Compiled kernels ready to use, described as just copying kernel.sys over an existing install, are available at the fdos.org kernel testing git page, and the source archive and fdpkg compatible packages are there too. Then there is a note attached to that sentence: a TODO to update the links and upload the archives. That is a small detail with a large practical consequence. The instruction to copy kernel.sys over an existing install is the fastest way to test a new kernel, and it depends on a download page whose links the README itself flags as needing attention. Anyone taking that shortcut should verify the page before relying on it, and anyone who needs a guaranteed artefact should build from source or take a package. The install model itself is worth noting, because it explains why the kernel is a drop-in replacement. kernel.sys is the operating system file that DOS loads at boot, and replacing it in place while keeping the same FreeDOS installation is the whole upgrade procedure. There is no installer, no package manager in the modern sense, and no configuration migration. The kernel is a file on a bootable DOS filesystem, and the compatibility guarantees that make it drop-in are the same guarantees the whole project exists to maintain. The fdpkg compatible packages mentioned in the README are the other distribution route, and they are the more modern of the two, since they fit into a tool that manages DOS packages rather than requiring manual file copying. ## GPL v2, an open invitation to fork, and one maintainer The licence is GPL-2.0, with the COPYING file in the repository as the authoritative text, and the README states the same thing in prose as GPL v2. This is a licensing statement rather than legal advice, and for a kernel the licence is the point rather than an afterthought, since a DOS compatible kernel is most useful when other people can take it, change it and redistribute it. The README ends with an invitation to fork and submit a pull request, and gives an email address for the maintainer. The release process and the download page both appear to depend on that one person. The version record backs that up. ke2046 was released on 2026-06-30, ke2045 on 2026-05-02 and ke2044 on 2026-01-25, and the last push to the repository was on 2026-07-05. The repository is not archived, so the work continues, but the interval between the recent releases, a few months at most, is one of the facts to weigh. For a project whose value is continuity rather than novelty, that is a reasonable trade. A kernel that has been shipping the same behaviour for decades does not need to move fast, and the risk is not that the code rots but that the surrounding infrastructure, the build hosting and the download page, does. The TODO in the README about those links is a small illustration of that risk. The main alternatives for anyone in this space are the other DOS-compatible kernels and the commercial DOS environments, and the difference in approach is the same one the README describes: compatibility-first versus portability-first, with 0xFD and 0xDC sitting on opposite sides of it. ## Conclusion Adopt FDOS/kernel if you need to read, modify or rebuild a DOS compatible kernel, if you are maintaining a FreeDOS system, or if you want a C codebase in the 8086 era style to study. Do not adopt it as a general purpose operating system, and do not expect a 16-bit protected mode story beyond what the README describes. Before you start, read the README note that the release kernel download page and archives still carry a TODO about the links, so the prebuilt binaries may not be where the README says, and check that the target hardware is 8086 or 80386 and later IBM compatible, since this version is not the portable one. ## FAQ ### What is the difference between the FreeDOS 0xFD and 0xDC kernels? The 0xFD kernel, which this repository holds, is intended only for 8086 or 80386 and later IBM compatible computers and keeps compatibility with older hardware and software. The maintainer points to his separate 0xDC kernel, which merges back in some of the original portability aspects and other supported features, at the cost of some compatibility. ### How do I install a new FreeDOS kernel? The README says compiled kernels ready to use are available at the fdos.org kernel testing git page and that you can just copy kernel.sys over an existing install. The README also carries a note that the links and archives on that page still need updating, so check the page before relying on it. ### How do I build the FreeDOS kernel from source? The repository ships batch files for Windows, including build.bat, buildall.bat, clean.bat, clobber.bat, default.bat, MAKEPKGS.BAT and RELEASE.BAT, alongside a makefile and a mkfiles/ directory. For an automated environment there are ci_prereq.sh, ci_build.sh and ci_test.sh scripts, and the README says the project now has automatic builds and soon tests. ### What licence is the FreeDOS kernel released under? GPL-2.0, with the COPYING file in the repository as the authoritative text. The README also states it is derived from Pat Villani's DOS-C kernel, which was released under the GPL v2. ### What does the FDOS/kernel repository actually contain? It contains the kernel half of the FreeDOS tree, with directories for kernel/, drivers/, lib/, sys/, boot/, hdr/ and utils/, plus the build data in config.m, config.b, filelist, country, a setver/ directory, a docs/ directory and test/ and tests/ directories. ## Sources - [FDOS/kernel on GitHub](https://github.com/FDOS/kernel) - [License: GPL-2.0](https://github.com/FDOS/kernel/blob/master/LICENSE) - [Project website](http://kernel.fdos.org/) - [README](https://github.com/FDOS/kernel/blob/master/README.md) - [Releases](https://github.com/FDOS/kernel/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fdos-kernel