Date: Thu, 10 Apr 1997 17:52:23 +1200 From: physmsa AT cantua DOT canterbury DOT ac DOT nz (Mr M S Aitchison) Subject: Some goals, philosophy for OpenDOS? To: opendos-developer AT delorie DOT com Message-id: <199704100552.RAA27911@cantua.canterbury.ac.nz> 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.