Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!batcomputer!sun.soe.clarkson.edu!nelson
From: nelson@sun.soe.clarkson.edu (Russ Nelson)
Newsgroups: comp.sys.ibm.pc
Subject: Re: MS-DOS puzzle #1
Message-ID: <NELSON.89Apr22234644@sun.soe.clarkson.edu>
Date: 23 Apr 89 03:46:44 GMT
References: <6893@bsu-cs.bsu.edu> <2936@ihuxy.ATT.COM>
Sender: news@sun.soe.clarkson.edu
Reply-To: nelson@clutx.clarkson.edu
Organization: Clarkson University, Postdam NY
Lines: 20
In-reply-to: vg55611@ihuxy.ATT.COM's message of 22 Apr 89 19:09:36 GMT

In article <2936@ihuxy.ATT.COM> vg55611@ihuxy.ATT.COM (Gopal) writes:

   In article <6893@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes:

   >     Question:  Why does COMMAND.COM allow redirection of standard
   >     input and standard output, but not standard error?

   I think the question really should be - why does MS-DOS allow stdin/stdout
   redirection but not stderr ?  Command.com simply goes through DOS to do
   the redirection (by playing with the filehandles etc.)

In some sense you are right.  However, when command.com gets control via a
critical error interrupt, it fiddles with the undocumented Process Handle
Table at offset $18 in the Program Header.  So I would say that, because
command.com also does critial error handling, it does *not* go through
DOS.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
America -- Socialism for the rich people, Capitalism for the rest of us.
	-- Michael Harrington, Co-Chair, Democratic Socialists of America