Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site druxv.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!mtuxo!drutx!druxv!sandy
From: sandy@druxv.UUCP (BishSL)
Newsgroups: net.micro.pc
Subject: Need help with DOS Read failures!
Message-ID: <1577@druxv.UUCP>
Date: Wed, 22-May-85 19:54:28 EDT
Article-I.D.: druxv.1577
Posted: Wed May 22 19:54:28 1985
Date-Received: Thu, 23-May-85 04:34:27 EDT
Organization: AT&T Information Systems Laboratories, Denver
Lines: 34


OK, all you DOS experts!  I have this funky bug that I'd love to let you
help me fix....

I'm doing repeated DOS (MSDOS 2.11) reads from a home-brewed device driver
that's reading from a COM port.  All reads are OK, until at some point
(can be reproduced in a couple of different scenarios) all reads begin
to return 0, and the device driver read routine is never invoked.  All
future reads are hopeless, due to 0 returns.  Not
having access to DOS source, I'm not sure what types of situations will
cause DOS to return 0, even though there is in fact data waiting at the
port.

Now for the weird part of the bug.  This problem cannot be reproduced
on some systems, even though these systems have the same DOS version, and
almost identical hardware and software configurations.  The problem can
be "fixed" by reducing the number of "set" environment variables, or by
INCREASING the number of characters in the environment!  Since this
environment can be found in memory immediately after the stack, a rampant
stack pointer or stack overflow is suspect, but cannot be located.

Has anyone seen anything similar?  Why is the stack loaded right before
the environment?  The environment seems to be copied to multiple places
in memory, rather than just in the location specified by offset 2C hex
of the Program Segment Prefix, as noted in the DOS Ref Manual.

In one such occurrence of this bug, doing a "peek" before each read, thus
preventing reads when there is no data available, seems to alleviate the
problem.

Anxiously awaiting all your helpful tips......
	
		--sandy bish, AT&T Information Systems
		--(303)-538-4717, ihnp4!drutx!druxv!sandy