Re: [Hla-stdlib-talk] non-buffered 'stdin.getc' function

[Nathan B. <eve...@ya...>]

Frank Kotler <fbk...@ve...> wrote: Nathan Baker wrote:
> Just coded this real quick and haven't tested it, but this is close to 
> what a 'non-buffered' stdin.getc() function (for Windows) would look like:

Okay...

> unit StdInput;
> #include( "../include/stdinunit.hhf" )
> 
> procedure nb_getc; 
>     @nodisplay;
> 
> var
>     hStdIn    :dword;
>     curMode    :dword;
>     newMode    :dword;
> 
> begin nb_getc;
> 
>     w.GetStdHandle( STD_INPUT_HANDLE );
>     mov( eax, hStdIn );

You're opening a new stdin handle with every call of this puppy. 
"Herbert's version" of "Beth's game" checks to see if we've got an 
handle (which means it has to be initialized to zero), and if so, skips 
over acquiring a handle and "tweaking" it. Since you're "untweaking" it 
at the end, you'd only want to skip acquiring a new one.
Well there is probably something like a global variable containing the handle... perhaps in the "../include/stdinunit.hhf" which is included in the above code.  I haven't taken the time to look... just wanted to get the discussion started.  IIRC, Randy asked questions about the issue many, many months ago.  He ran into a problem with it on BSD, or something... I can't remember what the "show-stopper" was.  I just think it is worth looking at again.

>     w.GetConsoleMode( hStdIn, curMode );
>     mov( curMode, eax );
>     and( #$F9, al );

HLA knows the names of the bits in question. Why not use 'em? I don't 
know how to say " ~(ENABLE_LINE_INPUT | ENABLE_ECHO_INPUT)" in HLAese, 
but I think that's what you want.
Yeah, good point!  HLAese is simply prepending a "w." in front of those -- same goes for the STD_IN_HANDLE above.
>     mov( eax, newMode );
>     w.SetConsoleMode( hStdIn, newMode );
>    
>     w.ReadFile( hStdIn, &InputBuffer, 1, InputIndex, 0 );

Who "InputIndex"? I'm thinking we want an address here (? remember I 
don't do Windows). Perhaps that's what you've got...
I cribbed InputBuffer and InputIndex from the original getc() -- again, I am guessing they are defined in "../include/stdinunit.hhf" -- probably need to call stdin.read() { the original calls readln() but that won't work here }.
>     w.SetConsoleMode( hStdIn, curMode );
>     mov( InputBuffer[ 0 ], al );
>     ret();
> 
> end nb_getc;

"Leaking handles" is a pretty bad problem. Other than that, it looks 
good to me!
I don't think so.  To my understanding, the 'standard I/O' handles are created (by the OS) for each process when it starts, and are closed automatically when it terminates.  The 'GetStdHandle' doesn't actually create a new handle... it just asks the OS for the handle that was already created when the process started.  I think closing it prematurely might be a bad thing.  I'll check the book to make sure.
What I've got for Linux does a similar thing... we "get" a whole 
bleedin' structure for "current mode" - but only clear two bits, and 
"set" to that. It is not strictly "right". If the pesky user suspends 
the program with control-z, and restarts it with "fg", we're back 
reading one key... but waiting for "Enter" again! :( A similar problem 
may occur if the window size is changed (in an Xterm). We could fix that 
by blocking control-c/control-z entirely - handling it ourselves, 
perhaps. Or we can "catch" these signals and do the appropriate 
cleanup/restoration of our "tweak". (I'm not sure how to do that one).
Could you post the code?  Or is it already at Linux-nasm-users?

Nathan.

I'm fairly certain that this code is Linux-specific, and *won't* work 
with BSD... nor MacOSX, I imagine. I think they've got sys_ioctl, but I 
think "TCGETS" is Linux-specific. Dunno how they do it (and what issues 
we'd encounter).

In any case - I agree that it's a nice thing to be able to do. Good start!

Best,
Frank


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Hla-stdlib-talk mailing list
Hla...@li...
https://lists.sourceforge.net/lists/listinfo/hla-stdlib-talk


       
---------------------------------
Looking for last minute shopping deals?  Find them fast with Yahoo! Search.