dalegass@dalcsug.UUCP (09/02/87)
I have just recently completed work on a set of routines which
will allow running programs as background processes on an IBM PC.
These routines are tailored towards RS-232 communications, allowing
terminal programs, file transfer programs, bulletin boards, etc., to be
run without losing the use of the PC.
Any program which is not extremely CPU intensive (almost all
communications programs) can be modified to make use of these routines.
The background handler is a small program which is installed and
remains resident. Access to the specialized functions is through the
use of interrupt calls.
The following interrupt requests are available:
o Initialize the user's program as a background job (reserve its
memory and making it resident).
o Release user's program as a background job (free it's memory).
o Initialize communications (select buffer size).
o Reset communications to their previous (pre-initialize) state.
o Update communications parameters.
o Send data to the serial port, and return control to the foreground
until the data is completely sent.
o Receive data from the serial port (with buffering and time-out).
If a wait is required, then control is returned to the foreground
process.
o Read communications status.
o sleep() - returns control to the foreground for the specified
amount of time: Useful for somewhat CPU-intensive jobs, to give
the foreground a bit more time.
These routines require only 2000 bytes of memory, plus space for
any communications buffer desired.
Support and interfaces are supplied for Assembly code, as well as
Turbo C. Interfacing to other compilers is not difficult.
The problems of DOS usage in the background are handled invisbly
to the user. Thus, all library functions in Turbo C work in the
background.
Support for toggling between foreground and background jobs is
planned in the near future. Currently, this can be manually done by
the background program.
Potential uses for this program include:
o Background bulletin boards - use your machine for yourself while
your BBS is chugging along in the background. It should not be
too difficult to apply this concept to popular BBS programs such
as Fido, likely increasing the number of willing Sysops.
o Background file transfer - x/y/z modem or kermit working in the
background.
o A 'cron' type program which wakes up every 'x' minutes and
performs necessary tasks.
I am interested in marketing these routines, but I am not sure of
the best route to take. Possibly some type of share-ware arrangement
would be possible, where a royalty is paid for the usage of these
routines in a commercial product.
I would appreciate any advice and guidance anyone could give me in
the marketing aspects of this type of software, as I am very new to
this.
dalegass@dalcsug.uucpdavidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (09/03/87)
I have had very good luck using DesqView to run communications programs
in background. The one I normally use is Procomm, but I have done Kermit
as well. Given source, etc, I would rather use the routines mentioned in
the previous posting, but this is a way to get by the long transfers
without any serious hacking. I set the foreground/background time slice
to 1:1.
--
bill davidsen (wedu@ge-crd.arpa)
{chinet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me