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


Forgot your password?
Microsoft Open Source Windows News

Life After MS-DOS: FreeDOS Keeps On Kicking 255

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:
  • Re:Dosbox or freedos (Score:5, Informative)

    by Parafilmus ( 107866 ) on Tuesday February 05, 2013 @04: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]

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

    by hobarrera ( 2008506 ) on Tuesday February 05, 2013 @05: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.

  • Re:What's next? (Score:2, Informative)

    by MangoCats ( 2757129 ) on Tuesday February 05, 2013 @05:08PM (#42801611)

    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
            sections of this FAQ.
        1.2 Version.
            Autumn Hill is currently shipping version 2.0a of Menuet/CPP.
        1.3 Supported Operating Systems.
            Menuet/CPP supports MS-DOS 3.3, 5.0, and 6.0. Other versions of DOS such
            as PC-DOS, DR-DOS, Novell DOS, and CompaqDOS may also work, but are not
            explicitly supported by Autumn Hill Software.
        1.4 Supported Graphics Packages.
            Menuet/CPP supports several graphics packages for a wide variety of needs.
            MetaWINDOW by Metagraphics Corporation, BGI from Borland International,
            and the Microsoft Graphics Library are all supported. Section 1.5
            lists the compatability between compiler, extenders, and these graphics
        1.5 Supported Compilers and extenders.
            See the file COMPILER.DOC for a description of supported compiler, extender,
            and graphics package combinations.
        1.6 Autumn Hill's development environments.
            Autumn Hill prefers two development environments for Menuet/CPP.
            The first includes the Borland C++ 3.1 compiler with all of the
            graphics packages. The Borland compiler is an excellent compiler,
            it is fast, creates compact code, and has the best debugger on the
            market. The Zortech C++ 3.1 compiler with Flash Tek's X32-VM extender
            is also used in development. The X32-VM is a
            great extender, it is royalty free, and works well with the Zortech
            compiler. Programming in protected mode is excellent for debugging
            purposes since many "bugs" in programs can be found as they will cause
            a program to crash when the "bugs" are encountered. For instance,
            in real mode a reference outside of an array will return bogus
            information. In protected mode a reference outside of an array will
            cause a protection viloation and the program will halt at that point
            of execution.
        1.7 CUA compliancy.
            IBM developed the Common User Access(CUA) paradigm to unify the many
            user interfaces in the world. OS/2 and MS-Windows are the major
            user interfaces that are CUA compiant. The full CUA documentation
            sets are available through IBM. Most of Menuet/CPP is CUA compliant.
            For instance, The ALT-F4 key combination will close a window. But
            There is no idea of a currently active control that can be changed
            by pressing the TAB key to move to the next control.
        1.8 Memory requirements.
            See the file MNSAMP1.DOC for a list of executable sizes for the "Hello,
            World" example program.

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

    by Anonymous Coward on Tuesday February 05, 2013 @05: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.

  • Re:FreeXP and XPBox (Score:3, Informative)

    by maxwell demon ( 590494 ) on Tuesday February 05, 2013 @05:22PM (#42801805) Journal

    I wonder in 2023 we will be having XPBOX or FreeXP since it has so many die hard users who refuse to leave kicking and screaming the whole time.

    I think that one is called ReactOS. [reactos.org]

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

    by idontgno ( 624372 ) on Tuesday February 05, 2013 @05: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 maxwell demon ( 590494 ) on Tuesday February 05, 2013 @05:54PM (#42802153) Journal

    If it works like MS DOS, you need to have the ANSI.SYS driver loaded, and can then just use the ANSI code for inverse video: $E[7m (where $E generates an escape character)

  • by Dahan ( 130247 ) <khym@azeotrope.org> on Tuesday February 05, 2013 @06:03PM (#42802239)

    Whoa, what command prompt code did you use to get your command line in inverse color? Mine's the standard white on black.

    If ANSI.SYS is loaded, PROMPT $e[7m$p$g$e[m

  • Re:MSDOS history (Score:5, Informative)

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

    by Anonymous Coward on Tuesday February 05, 2013 @06:23PM (#42802417)

    "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."

  • by Nimey ( 114278 ) on Tuesday February 05, 2013 @07:43PM (#42803193) Homepage Journal

    Bah, too fancy. My prompt:

    set prompt=Master, what is thy bidding$_in directory $p$g?

    which makes a prompt of:

    Master, what is thy bidding
    in directory C:\DOS>?

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

    by VortexCortex ( 1117377 ) <VortexCortex.project-retrograde@com> on Tuesday February 05, 2013 @08: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.

"Well, it don't make the sun shine, but at least it don't deepen the shit." -- Straiter Empy, in _Riddley_Walker_ by Russell Hoban