UNIX front end for DOS -- remote!

[Paul Gillingwater]

I've been planning a program to hone my skills using my new Zortech
C++ 2.0 compiler (MS-DOS).  I use UNIX quite a lot, but mostly from
remote modems, and usually with terminal emulators on PC's.  I also
run a public access UNIX system, and was thinking of ways to add value
for my user base, when I thought of the following idea for a program...

Hit 'n' now if dreams bore you...

My program would run on an MS-DOS machine, as well as OS/2.  It may 
also be ported to UNIX, although this is less likely.  Amiga DOS is
another possibility, depending upon compilers.

It would use lots of C++ features -- the best way to learn is by doing,
in my experience.  Extensive use will be made of windows and color,
in a way that tries to assist rather than obscure.

Essentially, the program will insulate the novice user from a UNIX
shell running on a remote machine.  The connection can be made via
a comms package such as Procomm Plus, Kermit or Telix, and then the
user can shell out to run my front end.  A windowing environment would
then be available, which would use simple WIMPS to provide much of the
interactive shell functionality.  One window would show the UNIX
commands which are then generated and sent to the remote system to
achieve the objective.  A history of these commands will be maintained,
which can be edited and executed at will, thus adding command history
even to older Bourne shells.  A secondary benefit is that the user
would see the commands forming as they go, thus learning UNIX syntax.

When started, the shell (running under DOS) would try to learn what
it can about the UNIX environment which the user is connected to.
If not on-line, a simple dialling directory and login script can
be executed.  Useful information would be requested from the remote
system, such as pwd, id, logname, $HOME, $SHELL, $EDITOR, date, 
ls *, files *, etc.  This would be used to build a friendly
front end, with files sorted into functional groups, e.g. shells
scripts, data, binaries, etc.  

The F1 key would provide help at all times.  In particular, it will
be highly contextual, although keyword indexing of the help information
will be supported.  In addition, it will recognise events, e.g. if
another user executes a 'write' to the user's screen, the shell
will pick this up, and notify the user.  Because many events will
run asynchronously, (e.g. notification of job completion for background
jobs, chat requests, mail notification, etc.) the shell will continuously
monitor streams of output from the UNIX host, looking for keywords
(of course this is configurable via macros, allowing the advanced
user to modify the behaviour).

The stty command will be well emulated, e.g. for things like baud rate,
parity, echoing, interrupt and other signals, etc.  A later version
will support shell layers, by using windows (locally).

File transfer will be supported (Kermit, [XYZ]modem), using such
excellent products as DSZ and rzsz to implement them.  ASCII
file transfers will be supported too, a la cu.  

-----------------------

I have lots more ideas, and have started planning the screens, as
well as the objects for representing the data.  What i'd like to do is
start some dialogue -- maybe these ideas have already been developed,
so i don't want to re-invent the wheel.  In case this is new work,
I hereby Copright 1990 this message.  You may comment on it, but
don't rip off the ideas and sell them as your own.

Copyright (C) 1990 -- Paul Gillingwater


-- 
Paul Gillingwater, paul at actrix.co.nz