problems mixing direct char i/o with handle i/o

[Bob]

Hi,

Are there any know problems mixing direct console input with handle
input under DOS (in particular Windows 95 MS-DOS, but without Windows
loaded)? I'm using the following code snippet to read the keyboard,
but to return whether a key has been pressed or not.

mov dl,0ffh ; input, no wait
mov ah,06h ; direct console I/O
int dos

Any standard character read in is written straight out to a device on
a specific port. However, if function key F1 is pressed I call a
routine to prompt for a file name and do some other stuff. However
the input prompt, which uses the following snippet of code, just
returns a single 0xA character in the input buffer - it doesn't even
wait anything to be entered at the keyboard.

mov dx,offset inbuf
mov cx,50h
mov bx,0 ; standard input
mov ah,03fh ; read file or device
int dos

I'm not having this problem in a dos box under Windows 7, so was
wondering if it is Windows 95 specific?

Any ideas?
Thanks in advance.

[R.Wieser]

Hello Bob,

First question: How do you check for the F1 key (you are aware that it
returns two chars instead of a single one) ? Does the same happen when you
check for a "simple" key (like ENTER/0x13) ?

Second question: Is there a reason you are mixing different methods of
reading the same input ? Your character retrieval is direct and
un-buffered, your string input is buffered and can be redirected. The odd
behaviour could be a result of that.

Third question: What happens if you try to read a second buffers worth of
data from the keyboard ? If it than waits (for the ENTER key to be
pressed) you should maybe first check if the INT 21, AH=3Fh buffer contains
data and clear it if so.

Suggestion: use INT 21h, AH=01h for character input and INT 21h, AH=0Ah to
read a string.

Hope that helps,
Rudy Wieser


-- Origional message:
Bob <ukp...@ic24.net> schreef in berichtnieuws
1b7e7966-d977-4b4f...@g16g2000vbf.googlegroups.com...

[R.Wieser]

> (like ENTER/0x13)

Thats ofcourse supposed to be either 13 or 0x0D ...

[Bob]

Hi Rudy,

Thanks for your response. Before I answer your questions, it might
help if I give a simple description of my application. It's basically
a console to an externally attached device and acts as follows:

device status port = 0280h
device i/o port = 0281h

loop:
read device i/o port (0x281)
if char read,
display it on PC

read pc keyboard (INT 21h, AH=06h, DL=0FFh)
if no key pressed,
jump to loop

if standard key pressed (AL<>0),
write char to device i/o port
jump to loop

if extended key pressed, (AL=0),
read keyboard again
If function key F12,
terminate

If function key F1,
call file processing routine

jump to loop


The above is an over simplification and doesn't show device status
port checking that also takes place.

The file processing routine simply prompts for a file, reads its
content and sends that to the device. The file handling works just
fine, it's just the reading form STDIN that appears to falter.

So, in answer to your questions.

1. I've no problem reading standard or extended key presses, as seen
above.
2. I can stick to traditional character i/o and it works OK (using
AH=0Ah for buffered input).
3. I haven't tried reading the keyboard twice (INT 21h AH=3Fh), but do
know that the buffer is initially empty (all 00h's).

The strange thing is that sometimes it does accept input from STDIN
OK, but most of the time returns immediately with 0Ah as the only
character in the buffer and a byte count of 1 in AX. I'm just curious
to know if there are know issues mixing the two methods.

Thanks again.

[Johann Klammer]

I've had similar problems when mixing getch() and scanf()/printf()
The solution was flushing stdin/stdout after calls to buffered I/O funcs.
Not sure what dos interrupt that equates to, or if it applies at all...

[R.Wieser]

Hello Bob,

> 3. I haven't tried reading the keyboard twice (INT 21h AH=3Fh),
> but do know that the buffer is initially empty (all 00h's).

I take that the above "the buffer" is *your* buffer (to write the read data
into), not a likely internal buffer (hint, hint) ....

> The strange thing is that sometimes it does accept input from STDIN
> OK, but most of the time returns immediately with 0Ah as the only
> character in the buffer and a byte count of 1 in AX.

As described the funtion stops when an 0x0A char is encountered. Its quite
possible that that one was already in the buffer, with possibly even more
data (including more 0x0A chars)behind it ... In other words: that first
(empty) string might be old data.

I've not tried it myself, but what happens when you ask for the "filesize"
of that StdInput handle ? If its more than Zero *before* reading the "file"
than you know that there is old data in there (which you need to purge
first).

Regards,
Rudy Wieser

P.s.
I tried to replicate the problem on a Win98se machine booted into DOS, but
could not. It works alright, though it shows a full CR,LF sequence in the
returned buffer (not only the LF you mentioned).


-- Origional mesage:

Bob <ukp...@ic24.net> schreef in berichtnieuws

d2115c41-4801-49fd...@g8g2000vbf.googlegroups.com...

[Bob]

Hi Johann,

I've tried resetting the input prior to reading from STDIN but it made
no difference. I tried DOS function INT 21h AH=0Ch AL=00h.
Depending on what documentation you read, register AL is supposed to
hold the function number of the I/O option to perform following the
reset or 00h to do nothing after the reset.


Hi Rudy,

I do use my own buffer for reading STDIN (INT 21h AH=3Fh) and I've
even added a little code to zero it prior to each read from STDIN, but
all to no avail. I also added an extra read if the first read
returned a single 0Ah in the buffer. Surprisingly, the second read
worked fine every time - it actually waited for keyboard input and
returned whatever was typed, terminated by 0Dh + 0Ah. The cursor just
appeared one line down from my prompt.

I'll take a look at checking the STDIN "file size" and probably also
try a different version of MSDOS.

Thanks

[R.Wieser]

Hello Bob,

> Surprisingly, the second read worked fine every time

:-) Not as surprising as you might think. What you most likely see is data
that was there from before you pressed F1 key. Thats why I suggested
purging/clearing that *internal* buffer (not your one) before trying to
retrieve a string.

You could try INT 21h, AX=0C00h just before the INT 21h, AH=3Fh

> Thanks
You're welcome.

Regards,

Rudy Wieser


-- Origional message

Bob <ukp...@ic24.net> schreef in berichtnieuws

36817804-4640-4c42...@w3g2000vba.googlegroups.com...

[Johann Klammer]

0x0a is the Linefeed after the carriage return...
RBIL(D-213F) sez that when reading from con it stops after CR(0x0D).
So I suspect the LF is still in there, and you get it on the next read...

[R.Wieser]

> Hello Bob,

> You could try INT 21h, AX=0C00h just before the INT 21h, AH=3Fh

Only now I see you wrote to Johann you already tried. that :-\

Regards,
Rudy Wieser


-- Origional message:
R.Wieser <add...@not.available> schreef in berichtnieuws
5140c386$0$6990$e4fe...@news2.news.xs4all.nl...