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?
- ▼ April (6)