🚀 go-pugleaf

That subject line is a bit vague, let me expand. I am writing
an application in an embedded DOS environment. The product will
have no keyboard or video, I am just using DOS as a file-system,
basically. I will have a small task-switching kernel and
some extra hardware to attach to a special bus where I/O to the
user will occur.

I'm haven't much experience in DOS programming, so I'm not sure
about this part:

If I want one of my processes to, say, format the disk from
a user command, how do I do that? The DOS call will output
all the stuff about inserting the disk, format another?, etc.
But I don't have a keyboard that the BIOS function can get to.

I suppose I will be using the Microsoft C 'system()' call to
do the formatting. As I understand it, this will spawn a second
Command.com environment, but the child task will not inherit
the stdin and stdout of the parent.

The only way I can think of doing it is to write a device driver
for all my I/O processes and issue a redirection to them.

For example, if I have a device called PORTIN: and PORTOUT:
and install proper drivers, I can issue the format command
like this:

    error = system("format a: /s < PORTIN: > PORTOUT:");

and my I/O devices will get the proper characters.
I suppose I have to hook into the critical error interrupts,
control-break stuff, etc., to avoid other problems.

Has anyone done anything like this? Other possibilities,
gotchas, etc?

As I understand it, the device drivers get chained together.
If I have 30 or 40 I/O device drivers installed, will there be
any problems? Are there limits or significant real-time hits?

Any help at all will be greatly appreciated, I can study books to
figure out how to do the stuff, I just want to get off in the
right direction.
-- 
Jim Hurley --> jimh@ultra.com  ...!ames!ultra!jimh  (408) 922-0100
Ultra Network Technologies / 101 Daggett Drive / San Jose CA 95134