Mail Archives: opendos/1997/04/10/02:00:14
I don't know how far we can go with setting goals for OpenDOS (given
that it isn't really in the same open state that Linux is), but this is
what I was thinking... (It includes some of what others have suggested,
but goes beyond a mere wishlist of features, and tries to imagine where
OpenDOS could most likely be accepted).
These aren't in any particular order...
1. OpenDOS SHOULD BE THE MOST SECURE DOS.
Microsoft are notoriously bad with security; DRDOS and successors
already has understood unix-like permissions (even if the code
was stripped down to simple passwords). Those worried about
viruses, or hacking or data security in general should be able to
turn to OpenDOS.
2. YOU SHOULD BE ABLE TO USE PARTS OF OpenDOS TO UPGRADE OLDER DOSES.
I like the phrase "not just racing stripes" - i.e. it is an upgrade
that doesn't just look good but actually helps your system, but still
can be thought of as an add-on rather than a replacement. If you
prefer the MSDOS syntax for the DIR command then fine, keep using it.
It is no disgrace if the memory manager, cache, editor, etc work with
MSDOS or PCDOS or OS/2 or Linux or SoftPC. An ideal install program
would look at your system, ask you what are your priorities, and
suggest an upgrade plan (with advantages and disadvantages at each
step, like MFT provides). At the end it should say things like "you
can now do xxx" or "the yyy program now runs aa% faster and has bbb Kb
more RAM to work with". It is possible (easy) to improve at least some
important facilities in every popular operating system I know of, and
people wouldn't mind paying for such a facility (although I'd like to
start out by seeing what we can develop for free!)
3. OpenDOS SHOULD MULTI-TASK REALLY WELL. Win95 doesn't; OpenDOS
*could* but it is buggy, and lacks some features other systems have
(look at Desqview). It is probably more worthwhile trying to keep
happy those whole need threads, and real-time process control systems,
than those trying to play the latest games, but both should be
possible. In fact, allowing OpenDOS's own multitasking or Desqview's
to be slotted in would be nice; each can be better at different things,
but the programming interface should be compatible. Looking at what
OS/2 does to get millisecond timing would be sensible too.
4. THE "NICEST" USER INTERFACE. I happen to like text user interfaces,
especially those with tab-completion. But everybody has their own
ideas. MS tends to control every aspect of what it sells, so people
feel pressured into the same O/S, GUI, apps and server whereas the Unix
(and X11 especially) philosophy is interchangeable modules. I'd like
to be able to run Unix shells, or any variant of command.com, or any
style of GUI irrespective of the choice of programs. This shouldn't be
just an endless source of fiddling with system parameters but genuine
productivity gains - e.g. one of the features I appreciate most with
DRDOS is the ability to use wildcards in the TYPE command. Overall, I
guess I'm talking about style, the type of people who steer the design
(i.e. people who actually use the system themselves, on moderate
hardware!). People should be able to not only say OpenDOS is
technically better, but it is more likeable - less keystrokes, less
frustration, generally friendlier and responsive.
5. ALL MODERN CONVENIENCES. OpenDOS should have long filenames and all
the other things, but should be known as the platform that gets tnew
features first and best (because, like Linux, there is constant keen
development going on; none of the delays we've seen with Win 9x).
Good features to get real soon are:
* IFS: A driver/TSR (uses DPMS??) to support long filenames on (V)FAT
partitions (while handling passwords/permissions correctly), as well
as accessing HPFS & ext2 partitions.
* A much better installation program (I'm working on it)
* Minor fixes & new features to command.com and its friends:
- support /S (recurse into subdirectories) on DIR, ATTRIB, COPY, etc
- support /O (order) on DIR and similar commands
- if the PATH contains "." don't automatically search the current dir first
- PATH should be able to be longer than 127 characters (65500?)
- a .ZIP file should mean the contents of the archive are search and UNZIPped
if needed (for efficiency cache the contents of the .ZIP's directory).
- fix up a few minor syntax differences between MSDOS and OpenDOS that affect
batch files (DATE and FOR I think).
- dynamic allocation of environment space to avoid the /E parameter on command.com
- DELTREE
- allow command1 [! command2] to place the standard output of command2 into the
command line of command1 (same as Data General's AOS; a litlle like the Unix "`"
but allows nesting and has less problems with existing batch files that use such
characters (i.e. "[" is still passed intact to command UNLESS it is immediately
followed by a "!" or some other special caracter, and matches up with a "]" in the
command line).
- implement block if-then-else commands, e.g.
IF [!FQDN %hostname%] !~ *.phys.canterbury.ac.nz THEN:
echo "Sorry, I cannot allow access from $HOSTNAME"
log /priority=warning Access attempt from [!FQDN [$hostname]]
ELSE:
stty %Hostname%
:END IF
6. MAKE THE IMPROVED COMMAND.COM SYNATX POPULAR IN OTHER AREAS.
Everybody can understand batch and BASIC files, but "better designed"
languages haven't achieved such acceptance... a menu program or a
configurable Windows program launcher would be better with a simple
language that people can make use of, than a system that has to be
learnt (and relearnt when the developers get a better idea). If the
batch interpreter had a little more to it (not a lot, compared with
tcsh and other "serious" shells), it could be very popular embedded in
all manner of situations Visual BASIC nearly works in now.
I feel the long-term life of DOS is going to lie to two areas:
A. hardware systems that *must* run a lean and fast operating system,
eg for speed or economy or low power;
B. inside more complicated systems, where "finding the exact thing you
need to click on" isn't the answer to much of your work. This
battle was held years ago when menu programs were set against
command interpreters; menus are brilliant in situations where you
only attempt a limitated range of actions, while command
interpreters are better if you need flexibility. In the same way,
controlling a computer by a GUI asumes the designer has thought in
advance of all the things you might ever need to do (and there is
enough screen real estate for those icons!). In general you need
both. Especially when command interpreters can evlove into
something that acts on reasonable voice commands (ever used voice
recognition in a GUI? You find yourself saying "dow!" "down!"
"select!" unless a word is aliased to the job). So I expect there
will remain the need for a mixture of GUI and command interpreter,
and if we're going to have a command language it may as well be the
same one use to define the actions behind the non-trivial icons. In
the same way, you might use some Unix on a powerful Alpha server,
but you could benefit from a friendly command interpreter in place
of one that expects strange abbreviations. Imagine a command.com
that understands what you want (from voice or whatever input) and
invokes the appropriate program (of whatever type) to carry it out.
Fewer and fewer of those programs will by DOS-native apps, but that
doesn't matter - simplicity, efficiency and understandability can
remain where it counts - clos eto the user, while there are powerful
(complicated) applications servers (or simply LInux!) a little
further back.
- Raw text -