Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Microsoft Open Source Windows News

Life After MS-DOS: FreeDOS Keeps On Kicking 255

Posted by Soulskill
from the the-nineties-never-left dept.
angry tapir writes "FreeDOS — the drop-in, open source replacement for MS-DOS — was started after Microsoft announced that starting from Windows 95, DOS would play a background role at best for users. Almost two decades later, FreeDOS has survived and, as its creator explains in this interview, is still being actively developed, despite achieving its initial aim of an MS-DOS compatible OS, which quite frankly is somewhat amazing."
This discussion has been archived. No new comments can be posted.

Life After MS-DOS: FreeDOS Keeps On Kicking

Comments Filter:
  • Not surprising (Score:5, Insightful)

    by masternerdguy (2468142) on Tuesday February 05, 2013 @03:34PM (#42801169)
    To recreate something is to understand it, and msdos is worth understanding. Tons of legacy applications still depend on dos and are still in use! This is a step towards long term support of those applications.
    • Re:Not surprising (Score:5, Interesting)

      by Anonymous Coward on Tuesday February 05, 2013 @03:42PM (#42801267)

      It would work well in VirtualBox, if it weren't for a stupid VirtualBox bug. [sourceforge.net]

      • Re:Not surprising (Score:5, Informative)

        by idontgno (624372) on Tuesday February 05, 2013 @04:44PM (#42802081) Journal

        At least the bug has a work-around fix:

        The fix

        FreeDOS developer Eric Auer has provided a fix that corrects the buggy behaviour of the VirtualBox PCI BIOS. It can be downloaded at:

        http://lazybrowndog.net/freedos/files/vbox-fix.zip [lazybrowndog.net]

        His solution is a small TSR program that comes with new handlers for two PCI BIOS scanning functions, that make them scan only existing PCI bus numbers. VBOX-FIX.COM is supposed to be loaded in AUTOEXEC.BAT. The program checks if it is running inside a VirtualBox guest and loads only if it can verify that. Eric Auer writes:

        It does up to two PCI scans by vendor:device ID (int 1a.b102 calls) to check for two VirtualBox specific PCI devices. Only if at least one of them is present, the faster-on-VirtualBox int 1a handler for int 1a.b102 and b103 (scan by vendor:device or class- subclass-interface) is installed as a TSR. The VB vendor:device ID values are 80ee:beef and 80ee:cafe.

        VBOX-FIX.COM needs 416 bytes of DOS memory and can be loaded high.

        Gosh. "...can be loaded high.". I got a little tickle of nostalgia thinking about that. All those wonderful "load high and remain resident" hacks.

        Wait. Why is this good?

        • by Nyder (754090) on Wednesday February 06, 2013 @12:25AM (#42805495) Journal

          ...

          Gosh. "...can be loaded high.". I got a little tickle of nostalgia thinking about that. All those wonderful "load high and remain resident" hacks.

          Wait. Why is this good?

          640k is enough for everyone!

      • virtualbox is great because it runs well ontop of other modern opperating systems without real virtualization, in shear emulation.

        Dosbox, a complete dos machine emulator that utilizes FreeDOS, is available on many platforms to include windows, android, and GNU/Linux.

        it makes DOS era programs accessable for the modern computing era.
    • Re:Not surprising (Score:5, Interesting)

      by marcello_dl (667940) on Tuesday February 05, 2013 @03:45PM (#42801317) Homepage Journal

      Not only legacy- I had updated my aspire 5720's bios to suppress a bug which prevented 64bit linux using freedos because I had already got rid of the Vista installation (30 minutes after started using it, I think 8 will last less). Worked flawlessly but I acknowledge it's a risky procedure.

    • Re:Not surprising (Score:5, Informative)

      by hobarrera (2008506) on Tuesday February 05, 2013 @04:01PM (#42801501) Homepage

      Legacy applications?
      I've a 2010 intel motherboard with an integrated nic that reports "bad eeprom checksum" every time there's a power failure.
      Intel only provides a DOS utility to re-flash the firmware, if it weren't for FreeDOS, I'd have a useless nic (on a mobo with no free PCIs, BTW).

      Lots of hardware vendors still provide DOS-only BIOS updated, and similar utilities, regrettably, so FreeDOS still has plenty of uses - though not for the average user.

      • The ones I'm familiar with, such as SeaTools, just use DOS as bootable environment. I don't see any real reason they couldn't have used Linux or even a light version of XP if there were no modern DOS. Where there's a competent programmer and a problem, there's a solution.

        • by Pinhedd (1661735)

          The ones I'm familiar with, such as SeaTools, just use DOS as bootable environment. I don't see any real reason they couldn't have used Linux or even a light version of XP if there were no modern DOS. Where there's a competent programmer and a problem, there's a solution.

          They use it because a basic DOS distribution is nothing more than a filesystem driver and command line interpreter. There's no hardware abstraction and this allows programs to access device buses without issue, or risk exposing their hardware's service mode to malicious code.

      • change the battery (Score:4, Interesting)

        by Joe_Dragon (2206452) on Tuesday February 05, 2013 @04:28PM (#42801885)

        change the battery

    • Re:Not surprising (Score:5, Interesting)

      by ducomputergeek (595742) on Tuesday February 05, 2013 @04:02PM (#42801515)

      I have clients who still are using systems, like sales and inventory sales databases, running on DOS and now using FreeDOS.

      The owners don't want to replace something that works for new and shiny.

      • Re:Not surprising (Score:5, Interesting)

        by interval1066 (668936) on Tuesday February 05, 2013 @04:21PM (#42801793) Homepage Journal
        Real Time Systems: a certain PLC vendor (won't name whom, but they're American, and huge) only provides 16-bit drivers to one of their backplane products, if things haven't changed in 3 years, and I bet they haven't. If it wasn't for FreeDOS, third party licensors would be screwed. With FreeDOS and a real time ASIC, these licensors can create products that work with the main vendor.
      • Re:Not surprising (Score:5, Interesting)

        by mvar (1386987) on Tuesday February 05, 2013 @04:39PM (#42802029)
        I second that. Years ago I worked for a company where we installed-supported logistics & accounting programs from a specific vendor. The main software, the vendor's "best-seller" was DOS-based. When they released the newest, Windows-only version which completely changed the user experience by the introduction of the mouse, most customers went nuts upon hearing that the DOS version was going EOL. They were used to the keyboard and having to re-learn everything and memorize where and what to click in order to go to the next field or print an invoice was considered unnecessary by the majority of the customers. The vendor eventually had to recall the EOL and to this day they still support & release updates for this decades-old software.
        • OrCAD never recovered from the transition from dos to windows.

          The mouse thing got better with time, but the killer was that they broke keyboard macros. What replaced them (VB script) wasn't fit for purpose. A decade of carefully crafted tools to auto generate symbols from libraries got thrown in the toilet.

      • by Zemran (3101)

        There is often good reason for staying with a (Free)DOS based system. In real time systems you can write something that actually works but if you put it on XP or Linux etc. it no longer works in real time and that can be a big problem in control systems. Most of the added complexity in XP etc. is to make the UI pretty and if you do not want that UI then why tolerate that added complexity and additional probability of failure. POS systems may be called real time but they are not as real time as machine con

    • by rbprbp (2731083)
      Not only legacy: for BIOS/firmware updates it's often the only choice. There is flashrom (http://flashrom.org/Flashrom), for flashing from within Linux, but I don't dare using it.
  • by 0racle (667029) on Tuesday February 05, 2013 @03:34PM (#42801173)
    The graphics suck though.
  • by Ukab the Great (87152) on Tuesday February 05, 2013 @03:34PM (#42801175)

    If only I hadn't used all my 5.25" floppies trying to decapitate attacking zombies...

  • What's better for retro gaming: DosBox, or a virtual machine running FreeDos?

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      What's better for retro gaming: DosBox, or a virtual machine running FreeDos?

      Dosbox.

    • Neither, UAE is the one to use.
    • by TheCRAIGGERS (909877) on Tuesday February 05, 2013 @03:47PM (#42801339)

      Last I looked, FreeDOS couldn't slow down the environment to emulate old hardware. This is basically a requirement for many old games, and is the reason I use DosBox.

      • by Cro Magnon (467622) on Tuesday February 05, 2013 @03:57PM (#42801461) Homepage Journal

        In prehistoric times, when I upgraded from my olde 8088 to a speedy new 286, several of my games became nearly unplayable.

        • by jythie (914043)
          I actually had the same problem with Mechwarrior 3. Its physics engine did crazy things if the computer was too fast.... I suspect the problem of games that behave oddly or unplayably on hardware far faster then their developer had access too will be an ongoing on.
          • Re:Dosbox or freedos (Score:5, Informative)

            by VortexCortex (1117377) <VortexCortex@@@project-retrograde...com> on Tuesday February 05, 2013 @07:53PM (#42803813)

            As a developer, I can say no, that "problem" was just a dumb way to do physics, and it's been fixed forever to anyone who wasn't a moron, even in the AT/XT days. Back in the day we just checked wall clock time / CMOS ticks, you know, the ones we used to modulate PC speakers to make different frequencies, that's what we used to update game state and prevent binding physics to CPU speed. Today, RAM is plentiful, so I do physics state "commits" in fixed step sizes, say 30hz or 60hz, and interpolate from the last physics state to the temporary state that's being rendered.

            If enough time has passed to process the next full physics step, then it's processed and committed. Otherwise I reset state to last commit, and process the partial physics step, but do not trigger any important events like player death in the temp step. If the system is too slow to run a partial physics step without immediately requiring another full physics step then the partial steps are not processed and the game rendering updates screen positions only after the physics step can be computed. This is important for deterministic physics, for demo replay and also for synchronized network games because:
            UpdatePhysics( 20ms ); UpdatePhysics( 20ms );
            is not always equivalent to:
            UpdatePhysics( 40ms );
            Due to a number of factors, especially rounding errors.
            UpdatePhysics( elapsedTime );
            Is the worst on fast systems -- those very small fractions of time lead to physics explosions -- not the particle effect kind, the bounce off an object through the floor and to the other side of the universe kind.

            For comparison:
            Here is my rope physics with a fixed physics step size frames. [youtube.com]
            Here is the same physics running with actual elapsed time each frame. [youtube.com]
            The latter comments mention tiny jiggles propagating into a frenzy. Those tiny movements coupled with very small elapsed times create the physics explosion.

      • Re: (Score:3, Funny)

        by Eyezen (548114)
        Then just (de)press the turbo button!!! ;-)
      • by Nimey (114278)

        There are programs which can do this for you. They basically set up an idle loop and can be tuned to the speed you need.

    • Re:Dosbox or freedos (Score:5, Informative)

      by Parafilmus (107866) on Tuesday February 05, 2013 @03:56PM (#42801453) Homepage

      You can have both!

      Install FreeDos in the c:\dos folder of your DosBox machine. You'll get most of FreeDos' new functionality, while keeping the useful features of DosBox.

      see here: http://www.dosbox.com/wiki/TOOLS:FreeDOS [dosbox.com]

      • by Zordak (123132)

        You can have both!

        Install FreeDos in the c:\dos folder of your DosBox machine. You'll get most of FreeDos' new functionality, while keeping the useful features of DosBox.

        see here: http://www.dosbox.com/wiki/TOOLS:FreeDOS [dosbox.com]

        The problem is I need to find a good DOS-based virtual machine that can run DosBox from FreeDOS on DosBox.

    • What's better for retro gaming?

      Kega Fusion, Snes9X, Nestopia, Stella, MAME, KiGB...

      • 100% agreed... but ZSNES and BSNES are both also excellent emulators for the Super NES. Gens+ is also an interesting choice for Genesis, but admittedly not my favorite. I'd also add Stella for Atari 2600 games.

        If you want to take a trip down classic emulator memory lane, try out Nesticle, Genecyst, and the original Kega 98. They're old, no longer maintained and far inferior to the latest emulators, but they are what I first used in the late 1990s and early 2000s. They were awesome for their time and req

        • Duh, forget my Stella addition... somehow I passed that up when reading the original post, it was already covered...

    • Re:Dosbox or freedos (Score:4, Informative)

      by Anonymous Coward on Tuesday February 05, 2013 @04:15PM (#42801711)

      DosBox will be better because it's specifically built for retro gaming. It supports all the hardware needed for gaming including joystick, mouse, soundcard, and networking. Many years ago DosBox was too buggy to use, but I loaded the latest build about a year ago and it is awesome. Everything just works. This weekend my brother and I did some Doom2 Co-op using IPX tunneling, and it worked flawlessly.

    • by FreonTrip (694097)
      In my experience, DOSbox or DOSEMU with FreeDOS utilities and userland apps. A VM running FreeDOS will run pretty poorly in a 64-bit OS due to all the trapping and translation of 16-bit code, and DOS hasn't been a major target of optimizations for most virtualization solutions. If you're just planning to play video games, it would be foolish not to try DOSbox first.
    • by Hatta (162192)

      The best is an actual machine running DOS. A PIII/440BX system is easy to pick up, and great for DOS games. It's fast enough to run anything, and still has ISA slots for a sound blaster. BIOS options to disable L1/L2 cache will slow it to about the speed of a 386, perfect for Wing Commander. With one of these systems you can play just about any DOS game except the really early 8088 games that require a 4.77mhz processor for timing.

  • by jfdavis668 (1414919) on Tuesday February 05, 2013 @03:43PM (#42801285)
    They can take our lives, but they will never take our FreeDOS! William (Bill) Wallace
  • by Animats (122034) on Tuesday February 05, 2013 @03:45PM (#42801321) Homepage

    Why not? For embedded systems, when you need more than a boot loader, don't want all the excess baggage of Linux, and don't want to pay for one of the embedded OSs like QNX, it's a good option.

    You also know that FreeDOS doesn't have a "phone home" feature, a HTTP server, a mail server, or something else on an open port running in the background without your knowing about it.

    • by Patch86 (1465427)

      I can't really see there being a situation where a minimal install is required, but a minimal Linux or BSD install is "too big". Especially with the "embedded" flavours.

      Still, much kudos to FreeDOS. I always feel a little bad for it whenever I buy a computer with "no OS" on it, and it comes with FreeDOS. It's a real OS too!

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        The said baggage probably refers to OS overhead like task switching, which for some applications, is probably too much even with linux/bsd and probably even realtime linux.
        DOS is about as bare metal and real-time as you can get while still having filesystem access. There are probably people out there who need it to be that low level, unencumbered even by timer interrupts if desired. I'm not one of those people but I'll still speak in defense of freedos for that purpose.

    • by mlts (1038732) on Tuesday February 05, 2013 @04:05PM (#42801549)

      Exactly. For an embedded system, a MS-DOS variant with FAT32 is good enough [1] for a lot of tasks. Done right, it can be close to a realtime OS as one would need for most tasks, with very little overhead, especially with hardware saving every CPU cycle can be important.

      Security? The OS doesn't even have a TCP/IP stack unless explictly loaded. No finding ports open that shouldn't be.

      Malware? Within the realm of possibility (Stuxnet showed us that), but without physical access, highly unlikely, especially if there is no Internet connection. Done right, the embedded code could write via a serial port, and another machine (or a VM) could read that, making those files accessible to a TCP/IP network for audit purposes.

      [1]: It would be nice to have ExFAT available as sizes of disks and other items get larger, but the IFS code to handle the complexities of a modern filesystem can be larger than the rest of the DOS kernel combined.

      • since if you avoid TSRs you have full control over the hardware.

        I once implemented a digital PID controller (with a few extra bits) using Turbo C on a 486 with an A/D card. The drivers for the card sucked, so I had to rewrite them but the result was a read/calculate/write cycle that was 4x faster than the stock driver.

        • You don't even have to avoid TSRs. Just avoid TSRs which take over hardware interrupts. A TSR which does nothing but sit there until you explicitly call it doesn't interfere with realtime.

        • by TC Wilcox (954812)

          since if you avoid TSRs you have full control over the hardware.

          I once implemented a digital PID controller (with a few extra bits) using Turbo C on a 486 with an A/D card. The drivers for the card sucked, so I had to rewrite them but the result was a read/calculate/write cycle that was 4x faster than the stock driver.

          Just because it is possible to use DOS as a real-time OS doesn't mean that DOS *is* a real-time OS. It is similar to how people *can* program C in an object-oriented manner, but that doesn't make C an object-oriented language.

          • by gl4ss (559668)

            uhh..

            how not so? you run dos and it's cycle for cycle the same output time after time. it's friggin hard to introduce something that wouldn't make it realtime(incidentally you could fool many copy protection schemes to always ask the same question on the same machine)

            you'd have to provide an example of how it's not cycle for cycle predictable to deny that it's a "realtime os". it's as consistent as it can get!

            though your best bet would be to argue that it's not an OS at all.

        • by LWATCDR (28044)

          People forget just how much work was done on old DOS systems. An old PC with a printer port or two actually gives you a lot of IO and an easy development system two work with for very little cost.

      • by tlhIngan (30335)

        [1]: It would be nice to have ExFAT available as sizes of disks and other items get larger, but the IFS code to handle the complexities of a modern filesystem can be larger than the rest of the DOS kernel combined.

        Given the purpose of DOS is really to be a file management layer, the FS part of the DOS 'kernel' really ought to be the biggest part. After all, that's what the "disk" part of DOS is supposed to mean, contrasted with a regular OS. There's no thread handling, no memory management (beyond setting t

      • by Nimey (114278)

        Security? Pah. DOS doesn't have any security whatsoever. Viruses spread by infected floppies were fairly common.

  • But when we start work on 2.0, I'd prefer to take another look at FreeDOS and think about what DOS needs to do to take a step forward.

    How about a GUI?

    • Re: (Score:2, Informative)

      by MangoCats (2757129)

      http://www.metagraphics.com/metawindow/gui/mncppfaq.txt [metagraphics.com]

      1. Overview
      1.1 What is Menuet/CPP.
      Menuet/CPP is the third generation in Graphical User Interface
      packages from Autumn Hill Software. Menuet/CPP is implemented
      in the C++ language which is clear and intuitive for GUI programming.
      Many of the features included with Menuet/CPP are discussed in later
      se

    • http://en.wikipedia.org/wiki/Norton_Commander [wikipedia.org]

      I guess it's called a TextUI, but it's all I ever needed for DOS. Really never saw the point of a GUI until I started multitasking. But since I'm guessing FreeDOS is not a multitasking OS, I don't see the point in anything more than NC.

      PS when working with a Linux box from a windows workstation, WinSCP in NC mode ROCKS.

      • by Wolfrider (856)

        --Xtree Pro Gold was Teh Unbeatable file manager for DOS back in the day. For modern equipment, Midnight Commander does the job reasonably well (safest way to delete files, for one thing.) MC is also available for Cygwin.

        For the true diehards, see here:

        http://www.ztree.com/ [ztree.com]

  • What I want is a FreeDOS shell for Linux: FreeDOSH . If that existed, it would be exciting to write DOS batch scripts on linux. LOL
    • FreeDOSH would fit right in the Linux culture of giving things names with multiple meanings. (In this case, dosh is slang for money).

      I have converted a few batch files to BASH. BASH is surprisingly inefficient for simple batch file tasks, but quickly makes up for it once you add any complexity at all.

      • by ArsonSmith (13997)

        So you're saying what BASH lacks in efficiency it more than makes up for in complexity?

        • I'm saying it's inefficient compared to batch files when it comes to the very simplest scripts, but once you need to do anything complex, BASH is much easier and more powerful to use.

    • by drinkypoo (153816)

      What I want is a FreeDOS shell for Linux: FreeDOSH

      No, that's Sean Connery's OS. You want commandcomsh.

  • by rubycodez (864176) on Tuesday February 05, 2013 @04:23PM (#42801825)

    many thin clients (e.g. some of HPs) refuse to boot from anything other than a ms-dos partition. to turn them into BSD or Linux appliances I have a FreeDOS partition on usb drive with grub in it, which chain boots the next partition. if you choose to boot into the FreeDOS there is editor for grub config and whatever other handy things you might need (like alternate flash images or whatever). need a very low power consumption domain/mail/web/vpn/unix shell server at home? those thin clients can pull 18W or less

  • by jones_supa (887896) on Tuesday February 05, 2013 @04:27PM (#42801881)
    DOS could really use a modern composited OpenGL accelerated desktop. Maybe call it "GL Accelerated Disk Operating System". What do you think?
  • by Anonymous Coward

    If you want to access PC hardware directly without any abstraction layers and OS latencies that screw up timing, a copy of MS-DOS 5.0 or FreeDOS is still the way to go. In fact, I just set up a machine last week with a copy of MS-DOS 5.0 and TurboCNC, which is sending stepper motor step commands at precise intervals to the motors on a CNC machine using the PC's parallel port. USB is as useless as Windows and the more recent Linux distributions for things like this.

    • by gl4ss (559668)

      If you want to access PC hardware directly without any abstraction layers and OS latencies that screw up timing, a copy of MS-DOS 5.0 or FreeDOS is still the way to go. In fact, I just set up a machine last week with a copy of MS-DOS 5.0 and TurboCNC, which is sending stepper motor step commands at precise intervals to the motors on a CNC machine using the PC's parallel port. USB is as useless as Windows and the more recent Linux distributions for things like this.

      back when I was a kid.. some games did more than that.

      they were self bootables.. no dos. pretty neat actually. original pc pirates! was such for example.

  • by DCFusor (1763438) on Tuesday February 05, 2013 @04:41PM (#42802045) Homepage
    To run some older Protel CAD tools. The very old (and used to be free) pcb editor now costs in the tens of thousands of dollars, and for my use case, isn't even as good. The old one runs fine on freedos, is fast as crap on new hardware, and gets my job done. And, the graphics are great.
  • by mvar (1386987) on Tuesday February 05, 2013 @04:45PM (#42802095)
    Irrelevant to FreeDOS, a few days ago I was searching about MSDOS and in which language it was written. For whoever might be interested, there's a nice read here: What language was MS-DOS Written in? [google.com]. Summary: MS bought the QDOS rights, QDOS was based on the CP/M OS which was written in FORTRAN
    • Re:MSDOS history (Score:5, Informative)

      by gaudior (113467) on Tuesday February 05, 2013 @05:14PM (#42802353) Homepage
      Fortran?! No. CP/M is written in 8080 Assembly code. Later versions took advantage of Z80 op-codes.
    • Re: (Score:2, Informative)

      by Anonymous Coward

      "The last design requirement was that MS-DOS be written in assembly
      language. While this characteristic does help meet the need for speed
      and efficiency, the reason for including it is much more basic. The
      only 8086 software-development tools available to Seattle Computer at
      that time were an assembler that ran on the Z80 under CP/M and a
      monitor/debugger that fit into a 2K-byte EPROM (erasable programmable
      read-only memory). Both of these tools had been developed in house."

    • It was not possible to write an OS in Fortran. You lacked pointers, memory management and pretty much everything useful except the ability to do math and some basic I/O. Although the modern Fortran versions have a lot more features, I think it is still impossible to write an OS in Fortran, but I am no OS expert.

      • It was not possible to write an OS in Fortran. You lacked pointers, memory management and pretty much everything useful except the ability to do math and some basic I/O.

        You do realize that you just described MS-DOS, right?

  • ...I hear you can play Dwarf Fortress in native mode on it?

"No job too big; no fee too big!" -- Dr. Peter Venkman, "Ghost-busters"

Working...