Nearly 30 Years Of FreeDOS And Looking Ahead To The Future

Blinky, the friendly FreeDOS mascot.
Blinky, the friendly FreeDOS mascot.

The first version of FreeDOS was released on September 16 of 1994, following Microsoft’s decision to cease development on MS-DOS in favor of Windows. This version 0.01 was still an Alpha release, with 0.1 from 1998 the first Beta and the first stable release (1.0, released on September 3 2006) still a while off. Even so, its main developer [Jim Hall] and the like-minded developers on the FreeDOS team managed to put together a very functional DOS using a shell, kernel and other elements which already partially existed before the FreeDOS (initially PD-DOS, for Public Domain DOS) idea was pitched by [Jim].

Nearly thirty years later, [Jim] reflects on these decades, and the strong uptake of what to many today would seem to be just a version of an antiquated OS. When it comes to embedded and industrial applications, of course, a simple DOS is all you want and need, not to mention for a utility you boot from a USB stick. Within the retro computing community FreeDOS has proven to be a boon as well, allowing for old PCs to use a modern DOS rather than being stuck on a version of MS-DOS from the early 90s.

For FreeDOS’ future, [Jim] is excited to see what other applications people may find for this OS, including as a teaching tool on account of how uncomplicated FreeDOS is. In a world of complicated OSes that no single mortal can comprehend any more, FreeDOS is really quite a breath of fresh air.

25 thoughts on “Nearly 30 Years Of FreeDOS And Looking Ahead To The Future

  1. Been using FreeDOS for ages, and sometimes it’s just the right too for the job. Recently, however, things like USB and networking started to be taken for granted, and on FreeDOS they require extra steps for the initial bring up, which limits the possibilities. I am sure FreeDOS will be still alive as long as x86 is, but it’s unlikely to see a popularity icreace.

    1. I prefer MS-DOS 6.20, but the FreeDOS utilities are nice to borrow from FreeDOS. ^^

      What I don’t like is the Linux-style setup program/package manager program.
      It’s too ugly and needs too much user intervention.

      FreeDOS would be better off with something that looks like MS-DOS setup or a Turbo Pascal looking GUI/TUI.

      It would be nice if the user could select everything once at the beginning and then leave setup running unattended without further input.

      Also, the use of sub directories is a mess, IMHO.
      It’s unix style again. The separation in BIN and DOC directories, I mean.
      Real DOS was much more clean looking.
      Additional files in same directory had same name, but a different file extension.

      Aside from these mistakes, FreeDOS is quite nice, I think.
      It could need some more 286 optimized utilities, though. Maybe in a separate folder or with a separate file extension (*.286).

      Because, somehow it’s either 386+ or plain 8088, but optimized 16-Bit code is still lacking.
      It’s with Arachne browser, I think, which also lacks good 286 builds/optimized 16-Bit builds.

      That may sound like nitpicking, but considering that DOS was defacto a 16-Bit OS, it means that full 80186/80286 optimization wouldn’t be silly.

    2. Requiring extra steps for the initial bring up of hardware may be annoying, but it sure beats not having that functionality at all.

      You really can’t know what will and won’t be popular.

      It’s unlikely to displace other operating systems as a daily driver, but that doesn’t mean it couldn’t see a surge in use on single-purpose setups.

  2. Looking ahead, Jim Hall envisions FreeDOS continuing to serve as an educational tool due to its simplicity, offering a stark contrast to today’s complex operating systems. This milestone underscores FreeDOS’s remarkable journey and its potential future contributions.

        1. Don’t be fooled, WINE and ReactOS aren’t meaningless by any means.
          The developed code helps to make things like VirtualBox possible.
          Years ago, I remember, WineD3D had been used to provide experimental 3D support in both VMware and VirtualBox.

          What’s also important, maybe, is that ReactOS team is very hesitant to change status, probably to avoid use in productivity yet.
          The code has matured quite a lot in the past years, despite code being formally stuck in Alpha and Beta status.

    1. A 64-Bit HDD driver would make sense, maybe.

      The rest needs a memory manager/Protected-Mode Extender that handles conversion between 16-Bit BIOS and DOD and 64-Bit Protected-Mode.
      In pure 64-Bit mode without v86 support, it’s a bit more complicated, even.

      GPU drivers aren’t really possible, because DOS programs usually talk to graphics hardware directly.

      The only exception would be emulation of something like Glide API, maybe.
      Or 8514/A via VBE graphics modes.

      An software emulation of one of the early 2D or 3D accelerators, so to say (IBM 8514/A, ATI 3D Rage, S3 ViRGE 325, Matrox Mystique, Rendition Verite 1000, 3dfx Voodoo, Nvidia NV1, NEC PowerVR etc).
      DOSBox has an emulation of a Voodoo card, for example.

        1. 86Box doesn’t allow direct access to physical hardware, I think.
          That’s like running DOSBox on DOS, which already works.
          The Win32 version can be run via HX DOS Extender.

          A real DOS system used to be popular for direct hardware manipulation.
          Users used to use a bootable DOS medium to flash the BIOS, etc.

          Others used DOS to run MESS/MAME in arcade cabs.
          DOS allowed direct programming of VGA’s CRTC, so a simple VGA to RGB cable could be used to drive an original arcade monitor with its non-standard timings.
          On Windows, this wouldn’t have been possible so easily.

          The 64-Bit HDD driver (a back-end driver) *merely* involves intercepting BIOS interrupt 13h, essentially.:
          DOS m doesn’t talk directly to HDD. That’s why it can be tricked to run from Live CD or USB pen drive.

          For other things, a complete emulation would be necessary.
          That’s what EMM386 does, using V86 mode.
          EMM386 also understands DPMI, which is a control protocol that helps to coordinate things with DOS Extenders such a DOS4GW.

          So in essence, we need some 64-Bit versions of DOS4GW or DOS32A, if we want to code 64-Bit DOS applications that run on normal 16-Bit DOS.

          If DOS gets ported to 64-Bit itself, it has to have a built-in DOS Extender, in order to stay compatible with classic DOS applications and the BIOS.

          But it’s questionable if that still makes sense, since UEFI has taken over.
          Then, there’s Intel’s x86S which aims to kill off the remaining backwards compatibility to x86.

          IMHO it’s wiser to provide 64-Bit extensions to FreeDOS only and leave the system core as is.

      1. looking maybe to do some close to the metal game development and dos is the perfect os for that. to see what can be done on modern hardware without a huge kernel in the way. most see it as a way to run old code and thats not what im interested in at all.

  3. Great project, congratulations to FreeDOS team. I have used it over the years whenever I needed to have some bare metal experience or run older software and hardware.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.