Newsgroup: comp.sys.ibm.pc.programmer

People have argued that they do not want to use the on-line help system
because it would force them to change the editor the use and switch to
the integrated environment. 

It is an infuriating feature of many DOS utilities that they ignore
standard input and output.  Colour pop-up windows and TSR's are
nice, but they have the problem that they don't COMBINE easily with
other tools.

More that twenty years ago the idea of standard input and standard
output appeared and it is supported - among other systems - by Unix and
MS-DOS.  Had the on-line system been designed to use this simple
feature one would be able to say something like:

	mshelp printf >foo

and then read foo into the editor (^K^R, :r, ^X^R or however the
particular editor does it).  Some editors even allow one to run a
command from within the editor and put the output in the edited file.

A batch file can be created with a set of help commands to create a
file with the whole manual.  Tha manual can then be filtered by a set
of programs to creat a KWIC index.  And so on.

Microsoft and many others instead opt for flashy useless windows.  Then
we all spend time arguing about whether we want to switch to their
environment or whether the space taken by the TSR is worth it.  Finaly
we try to come up with clever schemes that allow the running of
programs from within windows that appear simultenously on the screen,
and cutting and pasting from one application to the other.  Of course
one application will write directly to the screen, while the other will
directly manipulate the keyboard and so we need a 386 to emulate
virtual machines and horendously complicated software to find out what
each program is trying to do.  And I haven't addressed the hardware
compatibility problems yet.

PLEASE everyone try to make your programs easy to combine with others:

	- Make your program read its input from standard input and 
	  write its output to the standard output.

	- Errors go to the standard error channel of course.

	- Make the input of your program free form.  The positioning
	  of the input items should not be relevant.

	- Design the input to be line based if possible.

	- The output should also be line based if possible without
	  any headers, footers or pagination.  Special tools exist
	  to do these things.  Avoid screen positioning and other
	  control characters.

	- If you need a fancy user interface create a simple version
	  of your program that takes arguments from the command line
	  and prints output on stdout and a fancy popup colour menu 
	  shell that calls that program when needed.

	- Input editing should also not be a feature of the program.
	  By using the line input function provided by your system
	  the user will be able to use the DOS editing keys in the
	  worst case or whatever he has hooked on top of that.
	  The program can then be easily fed input by other programs.


If you follow the above guidelines your programs will be easier to
write, more portable and much more useful.  Their power will be
multiplied by the number of other programs that use the same philosophy
and you will find your programs put to uses that you never dreamt of.

I know this is a technical group and the above are not exactly the
latest information on DOS undocumented calls.  However we need sometimes
to stop hacking the VGA registers and try to see what we are trying to
accomplish.

Diomidis
--
Diomidis Spinellis                  Internet:                 dds@cc.ic.ac.uk
Department of Computing             UUCP:                    ...!ukc!iccc!dds
Imperial College                    JANET:                    dds@uk.ac.ic.cc
London SW7 2BZ                      #include "/dev/tty"

Unless otherwise expressly stated, all original material on this page created by Diomidis Spinellis is licensed under a Creative Commons Attribution-Share Alike 3.0 Greece License.