Thursday, January 18, 2018

No, there is no "FreeDOS Licensed Retailer"

One user reported that a person on EBay is selling FreeDOS on USB fob drives and advertising themselves as a "FreeDOS Licensed Retailer." No, there is no "licensed retailer" program for FreeDOS.

But according to the GNU General Public License, anyone is allowed to sell FreeDOS (or any software distributed under the GNU GPL) so long as they provide the source code, too. And in the FreeDOS 1.2 release, we include the source code as part of the installer packages.

The seller seems questionable to me. A few examples that confuse me:

Is source code included?
I don't know exactly what this person is selling. If it's the FreeDOS 1.2 installer on a USB fob drive, we already have an image for that on our website. Or it could be a pre-installed version of FreeDOS on a USB fob drive. If it's the former, then the source code is already there, in the packages that you can install as part of FreeDOS 1.2. If the latter, it depends if the seller installed source code when they installed FreeDOS 1.2 to the USB fob drive. They advertise a 16GB fob drive, so there is plenty of room for source code if they chose to include that.

Is it a USB fob drive or CD?
The seller claims: "Please Note: We have been authorized under the developer’s GPL license agreement to provide a service to buyers by offering this software in a CD format. This is great news for individuals, companies and organizations who prefer the convenience and portability of a CD, that may not have an internet connection to download the software, prefer the install file to be on a CD for easy distribution to other computers and many other reasons." But it's odd that the seller mentions "CD" and they are selling a USB fob drive instead.

Are they contributing back to FreeDOS?
The seller also claims: "By purchasing this software you will also be helping the open source community, as a portion of sales will be donated to developers to support further development." Certainly no one has contacted me to arrange any donation of sales to benefit FreeDOS. So in this case, the seller appears to be advertising something that is not true. Note that there is no obligation to contribute anything back to FreeDOS under the terms of the GNU GPL, so it seems odd to claim that when they don't have to.

I guess my recommendation is to be careful if you buy FreeDOS online. You can always download the full FreeDOS distribution at no cost from our website.

I have been trying to reach this seller via email. He replied to me once in November, but since then has not responded to emails.

Saturday, January 13, 2018

A new alternative shell?

I've been thinking for a while that it would be awesome to have a modern alternative shell. The COMMAND.COM shell is the bog-standard DOS command shell. We have an alternative shell called 4DOS that was opened by JP Software—I helped them with that, but at the time I didn't have a lot of experience in open source software, and I gave them bad advice about licencing. So the current 4DOS system doesn't have a truly "open source software" license.

Maybe this is an opportunity to start fresh. Since people sometimes ask me how they can contribute to FreeDOS, I thought I'd share this idea here.

I'd love to see someone start from the ground up and write a replacement alternative shell. I don't think you have to start from complete scratch. I'd encourage a new developer to borrow features and code from the FreeDOS COMMAND.COM ("FreeCOM") and even from Unix shells like GNU Bash.

Of course, the shell should be a DOS shell, not a Unix shell. That means it must support the basic Internal Commands: EXIT, DIR, PATH, PROMPT, and CD/CHDIR. And the DOS Batch commands: CALL, FOR, GOTO, IF, REM, SET, and SHIFT.

If you compare that list to the standard list of DOS Internal Commands, you'll notice some commands are missing. But maybe you'll implement commands like MD/MKDIR, RD/RMDIR, CLS, and other traditionally-internal commands as external commands. Up to you.

My first systems administrator job was on an Apollo/DomainOS system, and the AEGIS display environment had terminal windows with a neat feature: input was always on the bottom. So the Apollo/DomainOS guy in me would suggest a terminal that looked sort of like this: (this is a mock-up)

CuteMouse loaded
Installed at PS/2 port

C:\> DIR

 Volume in drive C: is FREEDOS12
 Volume serial number is 2134-5678
 Directory of C:\

FDOS              [DIR]     01-06-2017 3:00pm
3DOS    .EXE     89,123     01-02-2018 5:25pm
3DOSAUTO.BAT        998     01-02-2018 5:25pm
AUTOEXEC.BAT      1,234     01-06-2017 3:12pm
BOOTSECT.BIN        512     01-06-2017 3:12pm
COMMAND .COM     66,945     01-20-2016 7:37pm
FDCONFIG.SYS        848     01-06-2017 3:12pm
KERNEL  .SYS     45,344     06-21-2016 8:39pm
HELLO   .BAT      1,123     01-01-2018 1:25pm
     8 file(s)
     1 dir(s)
    208,441 MB free

C:\> _
So that black-on-white bar at the bottom is the command line input. That makes it really easy to see where you are. Yes, you are always scrolling up from the bottom of the screen, but let's face it; 99% of the time, we're scrolling from the bottom of the screen anyway.

The black-on-white bar should be dynamic. Maybe as you type a command that goes over 80 characters, the bar expands so you have black-on-white as you edit the whole command.

And the colors should be customizable. Maybe you want white-on-blue for the display area on top, and bright-white-on-cyan on the command line. You should be able to set that.

CuteMouse loaded
Installed at PS/2 port

C:\> DIR

 Volume in drive C: is FREEDOS12
 Volume serial number is 2134-5678
 Directory of C:\

FDOS              [DIR]     01-06-2017 3:00pm
3DOS    .EXE     89,123     01-02-2018 5:25pm
3DOSAUTO.BAT        998     01-02-2018 5:25pm
AUTOEXEC.BAT      1,234     01-06-2017 3:12pm
BOOTSECT.BIN        512     01-06-2017 3:12pm
COMMAND .COM     66,945     01-20-2016 7:37pm
FDCONFIG.SYS        848     01-06-2017 3:12pm
KERNEL  .SYS     45,344     06-21-2016 8:39pm
HELLO   .BAT      1,123     01-01-2018 1:25pm
     8 file(s)
     1 dir(s)
    208,441 MB free

C:\> _
I'd love to see an alternative shell that integrates, or at least shares themes with, the PG pager. As you view a file with PG, it should feel like you're still in 3DOS. So maybe that means adjusting the theme for 3DOS, or for PG.

And of course, standard application behavior applies: F1 for help. Actually, I'd recommend to implement that as a set of macros, so users can set things to their preferences, such as F1 to insert the HELP command on the command line, or F5 to insert CLS on the command line. A really cool option would let you define if that macro executes the command automatically or just inserts the string. For example:
In that simple example, /X means execute after inserting the text. So tapping F1 would have the shell insert HELP wherever you on the command line, then "hit Enter" for you. But tapping F2 would just insert HELP without doing anything else. (For example, you can then give HELP an argument.)

Up/down arrows should let you edit command history, maybe via a selector pop-up window, so you can see the list of commands as you scroll through the command buffer.

I'll even suggest a name for this alternative shell: "3DOS." If you pronounce "3DOS" it sounds like "FreeDOS," which is kind of cool. And the name suggests that it's a replacement for 4DOS.

But it's critical that this alternative shell be made available under a free/open source software license. I strongly encourage the GNU GPL, which makes it really easy to borrow code from Bash. And for other reasons, I ask that anyone working on such an alternative shell should not view the 4DOS source code. Let's make this a "clean" effort. Looking at GNU GPL'd source code, and even copying GNU GPL'd source code, is fine—if the new shell is under the GNU GPL, you can re-use any GPL'd code. But don't examine or re-use 4DOS source code, since that's not under the GNU GPL.

Anyway, just an idea.

Sunday, January 7, 2018

A new Help system?

The original FreeDOS Help was based on Unix man. FreeDOS Help simply displayed the Help page you asked for, in the same was that Unix man displays the manual page you ask for.

$ man fgrep
Later, we introduced an improved Help system, called HTML Help. This used a different design based on a text-mode web browser using simple HTML code. Called without options, HTML Help displayed a kind of "master index" page with links to different Help topics. This design also allowed Help topics to link to other Help topics, like related topics in a wiki.

However, HTML Help is really is a parallel Help system. If someone adds a new command line option to a program included in FreeDOS, then someone (else) needs to update HTML Help, too. FreeDOS contributor Fritz did most of the work to improve FreeDOS HTML Help content. You can see the amount of effort that Fritz had to put into the HTML Help documentation in our ebook, 23 Years of FreeDOS. Fritz says this about HTML Help:

FreeDOS Help 1.0.6 had more than 100 English HTML sites with a lot of expressions from the readme.txt files that I had never heard before, because I am not a programmer, only a trained user. But eventually, the last translation was done and I could publish FreeDOS Help 1.0.6.

Version 1.0.6 was still a little buggy, so I did an update to 1.0.7 shortly after. This must have been in Spring 2008. […]

I would like to see a new dynamic Help system that adjusts based on the installed packages. I had a few weeks ago with a FreeDOS developer, and I wanted to share the idea we came up with in case someone out there wants to take on this project:

I've wondered if it would be possible to create a new Help system that picked up "Help" documentation from each package in some dynamic way. You are thinking in a similar direction. I think it will end up being a rewrite of the current Help. I'm not sure what it would look like or how it would function, but a few thoughts: Maybe Help could pull the description from the installed package, and use that in a menu, perhaps with some "sections" that represent the package groups. For example:

 [APPEND] - APPEND enables programs to open data files in specified directories
  as if the files were in the current directory.

 [ASSIGN] - Assign a drive letter to a different drive

 [ATTRIB] - Display and set file attributes


 [BCC - BRUCE'S C COMPILER] - Bruce's C compiler is a simple C compiler that
  produces 8086 assembler for tiny/small models.

 [BYWATER BASIC] - The Bywater BASIC interpreter

 [CPP2CCMT] - A C++ to C comment converter.
…and so on…

Each of those is the package title and description copied/pasted from the Software List, which itself is pulled from package metadata. The only difference is I've cast the package titles to all-uppercase.

If the [bracketed] text represents "clickable" text, users could select that entry and view the Help file for that program. When showing the Help file, I'd also have a "Back to menu" option somewhere that lets users go back to the main Help menu.

The problem is there's no defined standard for what a "Help file" should be named. The package spec just says there's a HELP\ directory that contains Help files, and we encourage developers to name the Help file after the package. This has worked well for most packages, which were named simply after the command or function it implemented; a package called Choice typically has a help file called CHOICE. But some developers might have reason to use a different name than the package name (for example, package names that are multiple words, like Bywater BASIC use BWBASIC as its Help file name.

Other developers might choose to split up very long Help files into individual topics. For example, let's assume a very complicated program called Foo. The developer might include a main Help file called FOO, and two other Help files that detail specific usages of Foo called FOODATA about how to use Foo with databases, and FOONET about how to use Foo on a network. So maybe the Help menu might instead list the Help files that you can click on:
FOO - A very complicated program that does lots of things.
This exposes an underlying problem with my suggestion for a dynamic Help system: how does a dynamic Help know what Help files to associate with each program? I suppose one solution is to modify the package manager to automatically create/remove Help entries when you install/uninstall packages. But that assumes that you only install or remove packages via the package manager. Since FreeDOS packages are just zip files, users could also install packages via the Unzip program. So a slightly better solution might be for packages to contain a Help Index file.

I'm sure there's a better way to implement a dynamic Help. Maybe this article will give someone a starting point to implement a new Help.

Monday, January 1, 2018

Write about FreeDOS!

It's a new year, and we wanted to encourage people to contribute to FreeDOS in new ways. If you're already working on FreeDOS through code, design, testing, or some other technical way - thank you!

If you aren't sure how to contribute to FreeDOS, or want to contribute in a new way, we'd like to encourage you to try something new: Write about FreeDOS!

Please share your tips about programming for FreeDOS. Post them on your own blog, or email them to us and we'll do guest posts for you.
What should you write about?
Write about something that interests you! Others will want to see how you're using FreeDOS, to run existing programs or to write your own programs. A few suggestions:
Tips and tricks:

1. Partitioning
2. Optimizing RAM usage
3. Getting the network up and running
4. Make some noise (sound cards)

Recipes and use cases:

1. Gaming
2. Office work
3. Internet usage
4. Multimedia consumption (jukebox)
5. Home/Office file server
6. Development
7. Database server for other FreeDOS clients of old accounting software of some sort
suggestions by FreeDOS member Nicolae Crefelean—or come up with your own!
Or if you're a programmer, you might write a "how-to" article about how to manage very large arrays in memory, or how to load very large files. Or maybe you could talk about how to optimize a DOS program's I/O operations, such as how to read chunks of a file into a memory buffer using read() rather than using streams. Or you might want to write an article about how to use the conio functions to control the screen and read from the keyboard. Or maybe you could write something a little more "entry level" like tips to use the FreeDOS Kitten library to support multiple languages in your program.

Your "how-to" articles don't necessarily need to be about coding in a language like C or Assembly. If your preferred programming language is Pascal or BASIC, then write something about how to write programs in those languages for FreeDOS. If it's a programming language that's included in FreeDOS, we'd like to include it in the FreeDOS summer coding challenge.

Don't limit yourself to compiled languages, either. You can do lots of clever things at the FreeDOS command line and in BAT ("batch") files. So you could write an article about how to use a batch menu tool, like Jerome's V8 PowerTools included in FreeDOS 1.2, to create a neat interactive "program" as one smart batch file.

We want to hear from everyone! It's not just about developers, or people who contribute to the FreeDOS Project directly. Tell us how you use FreeDOS.
How do you write an article?
If you don't often write for a blog, then writing a FreeDOS "how-to" article might seem a little daunting. But really, it's easy!

I recommend you write your article as though you were explaining it to a friend. If it helps, write a draft in your email program, so you can convince yourself you're emailing someone about programming in FreeDOS. And if you like, you can actually send that email message to me (jhall@freedos…) and I'll use it as a guest post on the FreeDOS blog.

If you have your own blog or website, post your story on your blog, and email me to let me know where to find your article. If you don't have your own blog, I would be happy to post it for you as a "guest post" here. I'll even do light editing for you and take care of formatting.

Don't worry about making it perfect. I can do light editing for you before I put it up as a guest post. I'll edit for spelling, grammar, and style. I won't make changes to content or to the flow of your article—but if I do, I'll always run the changes by you first.
If we can gather enough articles by Spring, we'll try to collect them in a "how-to" ebook in time for the 24th "birthday" of FreeDOS on June 29.

Tuesday, December 26, 2017

Top ten of 2017, part 2

As promised from part 1, here is the rest of the top ten favorite blog posts about FreeDOS in 2017:

(6) Happy 23rd Birthday to FreeDOS
FreeDOS turned 23 years old this year. While there's nothing really special about "23 years old," I thought we should mark our anniversary by sharing some interesting moments in FreeDOS history. Throughout June 2017, I've asked others to share their own stories about how they got started with FreeDOS, or how they joined FreeDOS, or how they contributed to FreeDOS, as part of the FreeDOS Blog Challenge. And I was impressed and humbled to see so many people respond to that challenge. We later collected these essays into a book, 23 Years of FreeDOS.
(7) How to Support Different Spoken Languages in FreeDOS
When you write a new program, you probably don't think about spoken languages other than your own. But what about others who don't speak English, or who only know a little English? They can't understand what yours programs are saying. Use the FreeDOS Cats/Kitten library to add multi-language support to your programs.
(8) FreeDOS for OEM
Jerome Shidel contributed this article for the FreeDOS summer coding blog challenge, about how to use FreeDOS for OEM PCs.
(9) Unix Utilities for FreeDOS
Years ago, there was the "GNUish" project, which ported the GNU utilities to DOS. But eventually the project stalled. In the absence of a "GNUish 2.0" project, I have started to collect the Unix-workalike programs to a single directory on our files archive. This led to many new developers contributing to FreeDOS for the first time, by porting or re-implementing Unix utilities to FreeDOS.
(10) What is FreeDOS 2.0?
In October, we started a conversation on the freedos-devel email list about what the next release of FreeDOS should look like. We used this to update the FreeDOS Road Map to help shape what the next FreeDOS distribution should look like. To follow up from our email list discussion, we decided the next version will be an incremental improvement over FreeDOS 1.2, with minor changes and additions and no structural changes. We decided not to change the Base package group, and that the Base package group should still replicate the functionality from MS-DOS (no packages moved to a "Compat" package group). With no grand changes planned, this means the next release will be "FreeDOS 1.3."

Tuesday, December 19, 2017

Top ten of 2017

2017 has been a great year for FreeDOS. We released the FreeDOS 1.2 distribution a year ago, on Christmas Day, December 25 2016. And this year, we celebrated FreeDOS as it turned 23 years old.

I wanted to take a moment to look back on 2017 and highlight a few of our blog posts that I think show off some great moments in FreeDOS this year:

(1) 100,000 Downloads
We released FreeDOS 1.2 on December 25 2016, and it only took a month and a day to reach 100,000 downloads! And later in June, we hit 500,000 downloads.
(2) Why DOS has Sixteen Colors
Do you wonder why DOS only supports sixteen colors for text? With DOS, you had a list of sixteen available colors, enumerated 0 (black) to 15 (white). This article explains why all DOS systems have a sixteen-color pallette.
(3) Our April 1st Website
Rather than invent something fake with an intention of making a cheap joke, I decided to update the FreeDOS website. So for all day on April 1, the FreeDOS website was a "throwback" to the 1980s. If you missed it, this is what it looked like.
(4) A Brief History of the FreeDOS Logo
The FreeDOS Project has had several logos. Do you know them all? As part of the FreeDOS Blog Challenge, I wrote about the different logos we've used in the FreeDOS Project.
(5) All FreeDOS Distributions
They say that for any open source software project to get traction at the beginning, it needs to release early and release often. And that's just what we did when we started the FreeDOS Project. Also part of the FreeDOS Blog Challenge, I walked through all of our FreeDOS distributions, and how they evolved.

I'll post the rest of the list next week!

Monday, December 18, 2017

Talking about FreeDOS 1.3

Following up from the previous post asking "What is FreeDOS 2.0?" we heard from a lot of FreeDOS developers and users about what the next version of FreeDOS should look like. A few thoughts:

The FreeDOS Project builds consensus via the freedos-devel email list, so most of the discussion occurred there. I also forwarded comments from Facebook and other sources to the discussion. In the freedos-devel email discussion, the consensus is that compatibility is key—and therefore, the next FreeDOS should not deprecate packages into a "Compat" package group. The "Base" package group should contain everything that replicates the functionality from MS-DOS. As Ralf commented: "One should be able to just replace a MS-DOS 5.0/6.22 set of disks with a Base FreeDOS disk set and have identical functionality."

Several folks suggested the install CDROM should be a live disk. Tom suggested this: "there is literally no good reason that FreeDOS must be installed to experience the beauty of a C:> prompt. just put every binary on the CD as it would be installed … I'd leave the sources in zip archives, though."

Not many comments on what programs should be "promoted" to the "Base" package group. Suggestions included Zip/Unzip, and the MD5 and other hash functions.

Since the changes would be incremental, we agreed the next version would be "FreeDOS 1.3."

Aside from that, we also heard recommendations to update certain packages (for example, Help). There's also continued interest to include development tools, and free games. More on that:

Certainly we want to make it easy for developers to get involved and make contributions in FreeDOS, so providing options for compilers and assemblers makes sense.
This can be more flexible. We included many games in FreeDOS 1.2, and I agree we should continue to include free software games in the next FreeDOS. I don't consider the list of games to be static; we can change the list of games with each distribution.

What do you think? Join the discussion on the freedos-devel email list. You are also welcome to leave a comment here. Note that to limit spam, you must be signed in to leave a comment.