Linked by Thom Holwerda on Tue 27th Dec 2016 11:54 UTC, submitted by
OSNews, Generic OSes

The FreeDOS 1.2 release is an updated, more modern FreeDOS. You'll see that we changed many of the packages. Some packages were replaced, deprecated by newer and better packages. We also added other packages. And we expanded what we should include in the FreeDOS distribution. Where FreeDOS 1.0 and 1.1 where fairly spartan distributions with only "core" packages and software sets, the FreeDOS 1.2 distribution includes a rich set of additional packages. We even include games.

But the biggest change you are likely to notice in FreeDOS 1.2 is the updated installer. Jerome Shidel wrote an entirely new FreeDOS install program, and it looks great! We focused on keeping the new installer simple and easy to use. While many DOS users in 2016 are experienced DOS programmers and DOS power users, we often see many new users to FreeDOS, and I wanted to make the install process pleasant for them. The default mode for the installer is very straightforward, and you only have to answer a few questions to install FreeDOS on your system. There's also an "Advanced" mode where power users can tweak the install and customize the experience.

Great Christmas gift.

Order by: Score:
html markup suggestion
by raglan on Tue 27th Dec 2016 17:21 UTC
Member since:

Hi Thom, any chance your quotes could be blockquotes instead of divs? So that they're visually distinct in RSS readers (I use and your posts are all one long paragraph.) Would be great. Regardless, thanks for your work ;)

Reply Score: 1

RE: html markup suggestion
by panzi on Tue 27th Dec 2016 23:10 UTC in reply to "html markup suggestion"
panzi Member since:

Indeed. It looks like that in Thunderbird:

Reply Score: 2

Member since:

I am impressed that the FreeDOS project has kept going on for so long. And it is excellent that the applications are still maintained. Not bad for an operating system concept which was supposed to die so long along.

It may even expend to fully utilize the newer CPUs. I recall a side project for porting to 32 bits. And there might even be a dream somewhere of porting to 62 bits.

It looks like a number of key milestones for open source operating systems will be reached during 2017 with Wine 2.0, ReactOS 0.5?, Haiku 1.0? It has taken some time to get near these milestones for them and, as long as the underlying community is not loosing faith, these will be reached.

Reply Score: 2

Hayoo! Member since:

It may even expend to fully utilize the newer CPUs. I recall a side project for porting to 32 bits. And there might even be a dream somewhere of porting to 62 bits.

And be 2-bits shy of 64-bits? That would be sensational.

Reply Score: 3

BlueofRainbow Member since:


What was I thinking while typing? A hybrid 32/64?

Reply Score: 2

by Rugxulo on Tue 27th Dec 2016 17:48 UTC
Member since:

Great Christmas gift.

Minix would've been more appropriate ("O Tannenbaum"). ;-)

Anyways, yes, just to state the obvious, it's great to have a formal FreeDOS release again. Big thanks to Jim, Jerome, Mateusz, et al (not to ignore over a dozen significant contributors in other indirect ways over the years since FD 1.1).

Also, the QEMU Advent Calendar 2016 website had two DOS images: FreeGEM (Day 3) and Epic Pinball Demo (Day 10). So big thanks also to such emulators that keep such wonderful OSes alive.

It's a great time to be alive in computing.

Reply Score: 3

No 32 > bit FreeDOS any time soon
by ml2mst on Thu 29th Dec 2016 12:01 UTC
Member since:

There will be no 32/64 bit release of FreeDOS any time soon:

I've tested both release candidates and the Final release under Virutal Box.

FreeDOS 1.2 comes with a brand new package manager, which is part of the installation program. The "stand alone" package manager can be started by:


Not all of the programs are by default in the path variable. Thus you'll have to edit your AUTOEXEC.BAT by adding some directories to the path variable.

For example, if you want to launch the Dillo web browser without the need to change to the \DILLO\BIN subdirectory each time, add to AUTOEXEC.BAT:


If you want to use OpenGEM as a desktop environment, my advice is to download (via Dillo) and install OpenGEM 6, in stead of the shipped and limited OpenGEM 3 release:

Happy FreeDOS-ing ;-)

Edited 2016-12-29 12:03 UTC

Reply Score: 2

Member since:

The big reason for not making a 64 bit version of DOS is that memory manage is VERY different.

I'm going to use VERY simple examples instead of real examples that might be hard to understand. I would suggest reading something about the difference between 8 bit, 16 bit, 32 bit and 64 big memory addressing to get the hard facts.

In using a very simple example. Say that 8 big uses 1 digit for memory addressing, 16 bit using 2, 32 using 3 and 64 bit using 4. Each "bit" using 0 to 9 as an easy example

8 bit = 1
16 bit = 11
32 bit = 111
64 bit = 1111

If you are running DOS in 64 bit mode then how do you tell 8 bit or 16 bit versions how to access memory? You can't because a lot of those programs either aren't being maintained anymore or the programmer either can't or won't change their program to check to see what type of DOS it is running inside.

So you have to have DOS take care of all the memory addressing and fooling that 16 bit program (or 8 bit or 32 bit) into thinking it is running on a DOS version it was written for and expecting.

Because of this you can't just tell it to save something at, for example, 1781 because the program isn't prepared to read a number that bit. It might only be expecting one or two digits for the memory address. I'm keeping this VERY simple!!! So you now have to keep track of where you are having the program save data to while keeping track of where DOS is --really-- saving the data at. And the file table has to keep track of both so the file table now has at least one extra field in it. The address that you are telling the program and the address where the data is really stored. And you have to do this for each program.

You might think it doesn't sound _THAT_ hard but it is. Because as soon as you make a 64 bit DOS you will get a mixture of 8 bit, 16 bit, 32 bit and 64 bit programs that want to run. And now you probably have to have three more fields in that file table. One for each bit size.

* So you have a 8 bit memory address that you are telling the program and a 64 bit memory address where it is really storing it.
* And you have a 16 bit memory address for 16 bit programs along with the 64 bit memory address for where it is really storing it.
* And a 32 bit memory address field...
* And a 64 bit memory address field...

Okay. So you have those. But exactly how are you figuring out whether the program is a 8 bit, 16 bit ... program? The program isn't going to tell you because it will --expect-- to be running in the version it was designed for and not this, "I'll run anything that is DOS" OS.

By the time you open a program it is too late to be checking to find out what version of DOS it was designed for. Why? Because as soon as you open the program you will already have to be opening memory for it. And since it isn't running in the version of DOS it was designed for it will crash if you get it wrong. A program expecting 1, 2, or 3 memory bits, if they get a 4 digit memory address they will crash.

It gets complicated fast. It doesn't mean someone can't figure it out but it will not be easy. It will be like writing 4 (or more) different OSs because in a lot of ways you are. Each different kind of DOS (8 bit, 16 bit, etc.) has its own way of memory address which the others do not understand and aren't expected to. So someone will have to figure out many things staring with how to get installers for the programs to be able to install them in the first place because the DOS installers are just DOS programs too. And how do you tell the difference between the different installers? They probably won't have different names and the size of the installer will probably be different for each and every program.

This isn't just a problem times 4. It's more like a problem times 64. There is that much more work to do to get this working.

Would it be worth it? If done right you would be a GOD. But what about how much time you would have to spend to create this. Do you expect to be compensated for this? If other versions of DOS work great and there isn't a NEED for multiple versions of DOS programs work together on one computer then people aren't going to want to shell out money. Just being honest. I would but most wouldn't. They would complain if it was even 99cents, which is pathetic considering how much work people put in their programs. And programming is hard to begin with even for people that program all the time.

Anyway, this is just a tiny taste of why there isn't a 64 bit DOS and why there isn't a 64 bit version of DOS that can run any bit version of DOS programs.

Good luck to any that try.

Reply Score: 2