Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!ucbcad!ucbvax!ucsfcgl!cca.ucsf.edu!mis.ucsf.edu!simrin
From: simrin@mis.ucsf.edu (Steve Simrin)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Undocumented 34h Call
Message-ID: <1078@ucsfcca.ucsf.edu>
Date: Mon, 16-Nov-87 13:22:52 EST
Article-I.D.: ucsfcca.1078
Posted: Mon Nov 16 13:22:52 1987
Date-Received: Wed, 18-Nov-87 05:49:38 EST
References: <558@wolf.UUCP>
Sender: root@cca.ucsf.edu
Reply-To: simrin@mis.ucsf.edu.UUCP (Steve Simrin)
Organization: UCSF Medical Information Sciences
Lines: 14
Keywords: TSR,Critical Section Flag
Summary: indos flag,critical error flag

The address returned by function 34h is the indos flag address. this flag
is clear when DOS is waiting for keyboard input, for example when the DOS
prompt is displayed.

The flag referred to in your posting is the critical error flag. This
flag is set when a critical error (hardware error) occurs.

The simplest way to make sure the disk and keyboard are not busy is to
trap interrupts 16h and 13h with a handler which sets a flag, calls the
old handler, and clears the flag on return. The new handler simply
"irets" if the flag has previously been set.

There are example TSRs in PC magazine which demonstate these and other
techniques used in writing well behaved programs.