I have now removed myself from the Webmasters page. Technically, I'm still a webmaster, and I may even update a few web pages occasionally, but new contacts should go to Aitor and Eric. Obviously, I'm still around until sometime in May, so you can feel free to email me with questions, etc.
New ibiblio maintainer
As I plan my transition in May, I also need to remember to pass on my role as 1/3 FreeDOS ibiblio maintainer. (The other maintainers are Aitor and Blair.) It's worked well to have 3 of us maintaining the FreeDOS files archive at ibiblio. With 3 maintainers, it's very unlikely that the FreeDOS Project will completely lose the account info if one of us suddenly becomes unavailable.
Anyway, around May 4 I'll make Mateusz Viste an ibiblio maintainer, so he can upload FDUPDATE files there. I'll stop doing any ibiblio stuff after that date.
Update: (Apr 9 2009) I've been thinking about this, and it's silly to wait until May for me to transition my role of 1/3 FreeDOS ibiblio maintainer to Mateusz. We should do it now, so that if anyone has questions about our file archives at ibiblio, I'm still around to ask. I've just shared the login info with Mateusz. I'll stop doing any file maintainer stuff on ibiblio after today - Aitor, Blair, and Mateusz are now the official FreeDOS ibiblio maintainers.
Multitasking in DOS?
People sometimes ask me what I'd love to see in a future version of DOS. I would like to see some level of running multiple applications at once. The difficulty will be maintaining compatibility with older DOS applications; DOS was not originally designed to support more than one active application (excluding TSRs.)
True multitasking would be ideal, but I'd be happy if we supported the simpler "task switching" - this would be a huge leap forward for FreeDOS. MS-DOS5's DOSSHELL supported hotkey "task switching" and a welcome addition. But we need this at the kernel level to be really powerful.
But so far, I've only mentioned incremental changes to the FreeDOS paradigm. Let's think transformatively: throw off the chains of 8088 backwards compatibility, and look to the modern systems!
What would you change in a "next generation" version of FreeDOS to make it stand out?
Networks and FreeDOS
I'd like to take a moment to look at the state of FreeDOS support, and what would help move FreeDOS to the next level.
DOS needs drivers, plain and simple. Video cards are one thing, but simple VESA support can go a long way to support video on DOS. The urgent need is with networking: when DOS was first created, no one ran PCs on networks. So DOS wasn't built with network support. Since then, TCP/IP is the way, and wireless networks are very common. FreeDOS needs to build a library of network card drivers, supporting both wired and wireless networking over TCP/IP.
The network stack in FreeDOS needs to be simplified. Old applications needed to have the TCP/IP stack linked in (WATTCP, for example.) Imagine a new FreeDOS that provided its own TCP/IP stack, so that applications could make an API call to access network resources. Legacy applications would need to be supported here, but new "FreeDOS 2.0" applications would be able to take advantage of the new framework.
A web browser is essential here. The Arachne browser is very limited, and needs a complete overhaul. I wrote a comment on the mailing list earlier today about Arachne - my #1 wish is that it supports stylesheets.
Mapping drive letters to access the LAN should be a thing of the past. I'd like to see a mapping system that connects a network resource (say, a CIFS share) to a path, similar to "mount" on UNIX. While drive letters are a simple mapping (and probably a necessary evil, given the amount of DOS software that already exists and assumes drive letters) imagine a system where C:\NETWORK\CIFS\HOME maps a CIFS connection to a remote server on the network (the name HOME is merely a label, chosen when I "mount" it.) Note that old DOS applications would still work under this model, as there is a recognizable drive letter and path to the resource - but the resource happens to be on a server on the network.
As you work on the future of FreeDOS, what things would you change?
What would it take to create a "modern" DOS? I can think of a few things:
We need to have native USB support, rather than relying on "legacy mode" to access keyboards, mice, and USB storage. FreeDOS should recognize USB storage devices as they are connected, and disassociate them when they are unplugged. This will require massive changes to the DOS hard drive/floppy drive infrastructure, as I could connect one USB fob drive to my system as easily as I can connect 6 or 7 fob drives. FreeDOS should have a way to access them all. As I mentioned in anohter post: drive letters are probably a necessary evil. But imagine a method that maps a USB fob drive to an easily-located path on C:
A GUI is also necessary to take FreeDOS to the next level. That GUI needs to be a stable system with an API support that makes it easy to write new applications. We never picked an official GUI - but OpenGEM is a possibility, and it's very solid. But the user interface could be prettier. I don't necessary mean eye candy, but two changes will dramatically improve the look: support for loading TTF fonts, especially if the user can select one of those fonts as the "system" font, and an updated icon theme. User-loadable themes (ala GNOME and KDE) aren't necessary—but simple, outlined multi-color icons would improve GEM usability dramatically.
Of these, the GUI is easiest to tackle. I'd encourage anyone who wants to contribute to FreeDOS to consider helping OpenGEM.
Inside the box
Sometimes, thinking "outside the box" means working inside a box. Or a container, like a virtual machine.
In an email with someone (I think it was Rugxulo) I proposed an interesting new path for FreeDOS:
Create a very lightweight Linux system that boots, run DOSEmu on virtual console #1, which immediately boots. The other virtual consoles provide an ability to run DOSEmu, which also can boot FreeDOS.
There should be a simple method to direct the Linux host system to "shutdown" or "reboot" from within the DOSEmu - but it could be as simple as: when DOSEmu exits on virtual console #1, present a quick menu to do a "soft reboot" (restart DOSEmu) or "hard reboot" or "shutdown" (both affect the Linux host system.)
In this way, a certain level of abstraction or virtualization is realized. You can run separate instances of FreeDOS in the different virtual consoles, providing a kind of "DOS multitasking" (but really, it's just instances.) An interesting step forward (and not too different from what some virtualization companies are proposing) but it's missing the things necessary to bring DOS to the next level. (See my other posts.)
Still, it's an interesting idea, and I'd be very curious if anyone ever created such a thing. Any takers?