Slashdot Mirror
Life After MS-DOS: FreeDOS Keeps On Kicking
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."
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.
To offset political mods, replace Flamebait with Insightful.
The graphics suck though.
"I use a Mac because I'm just better than you are."
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?
Dosbox.
They can take our lives, but they will never take our FreeDOS! William (Bill) Wallace
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.
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.
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
In prehistoric times, when I upgraded from my olde 8088 to a speedy new 286, several of my games became nearly unplayable.
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
Calm your tits. If it was a spoken interview, such lapses are forgivable. If it was written, it could be a problem of editing. For example, maybe he intended to say: "we don't have the number of developers today that we had 10 years ago". Then he thinks: it would sound better if I said "we don't have as many developers today as we had 10 years ago". So he edits part of the phrase, but misses just one word, and you have a weird mix of versions.
Some mistakes are a bit harder to forgive, though. Such as "alot", or using "y'all" as singular. Those are quite annoying indeed.
Circumcision is child abuse.
Then just (de)press the turbo button!!! ;-)
http://www.metagraphics.com/metawindow/gui/mncppfaq.txt
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
toolkits.
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.
What's better for retro gaming?
Kega Fusion, Snes9X, Nestopia, Stella, MAME, KiGB...
Circumcision is child abuse.
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.
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
-- Betting on the survival of the media industry is a serious risk. I advise investing elsewhere.
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.
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.
The Tao of math: The numbers you can count are not the real numbers.
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
DOS could really use a modern composited OpenGL accelerated desktop. Maybe call it "GL Accelerated Disk Operating System". What do you think?
change the battery
Only in French. And you forgot the apostrophe.
Check out my sci-fi/humor trilogy at PatriotsBooks.
what's better: DOS Box or sex with a mare?
That depends on whether you are a gamer or a donkey.
The Tao of math: The numbers you can count are not the real numbers.
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.
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.
Why guess when you can know? Measure!
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?. Summary: MS bought the QDOS rights, QDOS was based on the CP/M OS which was written in FORTRAN
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.
Give me Classic Slashdot or give me death!
would you guys quit whorsing around?
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
The problem is I need to find a good DOS-based virtual machine that can run DosBox from FreeDOS on DosBox.
Today's Sesame Street was brought to you by the number e.
--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/
.
== WolfriderV6 == I'm willing to admit that *I just might* be wrong... Are you??
You said you like to run DOS, so...
:-)
Aw, screw it. You knew it was coming.
When you're dead, you don't know you're dead. It only affects the people around you. Same thing when you're stupid.
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.
Here is the same physics running with actual elapsed time each frame.
The latter comments mention tiny jiggles propagating into a frenzy. Those tiny movements coupled with very small elapsed times create the physics explosion.
Segments were a horrible chapter in uP history. From flat memory we went to the horrors of segments, then eventually, back again, thank goodness.
If those people at Motorola had the silicon skills of those at Intel, IBM might have gone with the 68000 and up, and we'd be years ahead of where we are now. Instead, we got slammed with the 8088 and up, and good grief, what a freaking nightmare.
Segments. Ugh. Someone oughta be shot over that. Also whoever invented pantyhose, while I'm making a list. :)
I've fallen off your lawn, and I can't get up.
Not to be pedantic, but you are describing EPROMs above, not EEPROMS. EPROMs are the devices that you program using higher voltages, and erase using UV rays (they had a transparent window to the die to enable that). Nobody makes those anymore. There is a variation of that called MTP, where instead of the UV rays, one can apply the higher voltage to the VPP and a particular address line to erase it, and program it normally putting the higher voltage just on the VPP pin. These products, to the extent that they are made, are the replacements of EPROM. Then there are mask ROMs for the high end equivalents of these things: while EPROMs and MTPs were in the 1 mebibit range, mask ROMs are in the 1 gibibit range.
EEPROMs, otoh, are NOR flash memory devices. Flash memory works this way - while read operations are the same as static or dynamic RAM, depending on design, program operations are done in software - by sending a certain address/data combination sequence before a program cycle(s) can start. That is what is known as in-system programming, and that is what PCs use. So any software that tries to 'flash a BIOS' essentially has to first determine who the manufacturer of the flash memory is (since different manufacturers tend to use different algorithms - most JEDEC endorsed) and then accordingly, send the appropriate command cycles to the flash before loading it w/ the addresses and data to be programmed into it.
Batteries are needed to maintain the system clock. Every time you power down a laptop, how does the thing remember the time when it boots up again? The battery is how - there is no way a flash device, which simply stores the last state that was programmed into it, would be counting down the time. When the battery goes down, that's when one sometimes sees motherboard failures and the like.
CMOS has forever been the standard that's used to build transistors, due to their scalability - TTL was never used, and ECL was tried on occasion by 1 company called Exponential Logic to build high performance PowerPCs for Apple in the 90s, but they went bust. CMOS will stop being used when silicon stops being used.