crt__kbhit deadlock ??

[GregL]

dedndave,

The CRT functions are generally large and slow, but they are very stable and reliable. They have been "tried and tested" by years and years of C programmers. So, I tend to have the opposite view, I would trust a CRT function much more than a "home brew" function.  It is a lot of fun to write your own though.

[Ficko]

very stable and reliable

Yes I use CRT a lot as well but this particular case it seems to have a bug. :naughty:

[jj2007]

The CRT functions are generally large and slow

Can't you safely assume that crtdll.dll sits in C:\WINDOWS\system32?? In that case, they can be as large and bloated as Microsoft wants them to be - but calling them costs only a handful of bytes - the same as for Masm32 lib functions. And the crt algos are not slow. In fact, it's generally hard to beat them.

It is a lot of fun to write your own though.

I agree 100% :bg

[dedndave]

well - it is fun - and i have learned a lot in doing so (even if i didn't need to - lol - oops)
as for this particular bug, it's not the first one i have run across with the console
i am not sure about how different windows versions act, but this makes my console bug count = 4
i am using windows xp pro mce2005
(i guess my next little project will be to ID OS's like we did for CPU's)

[GregL]

jj2007,

MSVCRT.DLL is included in every version of Windows since Windows 98.

And the crt algos are not slow. In fact, it's generally hard to beat them.

What??  You're the last person I'd expect to hear that from.  :bg  The CRT functions usually come in much slower in speed tests when comparing them to asm functions that replace them.

Yes I use CRT a lot as well but this particular case it seems to have a bug.

Yes, I would expect it to just work.  But, I think the work-around would be to remap the low-level handles as shown in the link I posted above (haven't tried it).

[GregL]

Ficko,

You got me, I can't get it to work.  _getch doesn't work either.

[jj2007]

MSVCRT.DLL is included in every version of Windows since Windows 98.

Indeed. That's why the statement "they are large" is pretty meaningless. You call them, you don't embed them in your executable.

And the crt algos are not slow. In fact, it's generally hard to beat them.

What??  You're the last person I'd expect to hear that from.  :bg  The CRT functions usually come in much slower in speed tests when comparing them to asm functions that replace them.

It depends. There are some you can beat only with SSE2 versions...

Code Select Expand

Algo           memcpy   MemCo1   MemCo2  MemCoC3  MemCoP4  MemCoC2   MemCoL
Description       CRT rep movs   movdqa  lps+hps   movdqa   movdqa   Masm32
                       dest-al    psllq CeleronM  dest-al   src-al  library
Code size           ?       70      291      222      200      269       33
---------------------------------------------------------------------------
2048, d0s0-0      556      566      363      363      373      363      560


[MichaelW]

I changed the name to waitkey because unlike _kbhit this coding removes all events from the buffer and leaves it empty. I chose to respond to the key-release event instead of the key-press event to avoid having the pending release trigger unexpected actions. Build as a console app.

Code Select Expand


; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    include \masm32\include\masm32rt.inc
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

; ---------------------------------------------------------
; The INPUT_RECORD structure in the MASM32 windows.inc,
; prior to MASM32 version 10, is a direct translation of
; the structure from the API header files and as such it
; lacks the alignment padding that the C/C++ compiler
; would add, and that Windows expects, ahead of the union.
; ---------------------------------------------------------

_INPUT_RECORD STRUCT DWORD
  EventType           WORD ?
  UNION
    KeyEvent              KEY_EVENT_RECORD          <>
    MouseEvent            MOUSE_EVENT_RECORD        <>
    WindowBufferSizeEvent WINDOW_BUFFER_SIZE_RECORD <>
    MenuEvent             MENU_EVENT_RECORD         <>
    FocusEvent            FOCUS_EVENT_RECORD        <>
  ENDS
_INPUT_RECORD ENDS

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    .data
    .code
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

waitkey proc

    LOCAL hStdIn: DWORD
    LOCAL nRead:  DWORD
    LOCAL ir:     _INPUT_RECORD

    invoke GetStdHandle, STD_INPUT_HANDLE
    mov hStdIn, eax
    invoke FlushConsoleInputBuffer, hStdIn

  waitLoop:

    ;----------------------------------------------------------------
    ; A 10ms sleep is sufficient to drop the CPU usage to near zero.
    ;----------------------------------------------------------------
 
    invoke Sleep, 10

    invoke ReadConsoleInput, hStdIn, ADDR ir, 1, ADDR nRead
    cmp nRead, 0
    je  waitLoop

    ;-----------------------------
    ; Discard any non-key events.
    ;-----------------------------

    movzx eax, ir.EventType
    cmp eax, KEY_EVENT
    jne waitLoop

    ;----------------------------------
    ; Return on the key-release event.
    ;----------------------------------

    cmp ir.KeyEvent.bKeyDown, 0
    je  @F

    jmp waitLoop

  @@:

    ret

waitkey endp

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

start:
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

    print "print to original console",13,10
    invoke crt_printf, chr$("crt_printf to original console",13,10)

    print "Press any key to continue...",13,10
    call waitkey

    invoke FreeConsole
    invoke AllocConsole

    print "print to new console",13,10
    invoke crt_printf, chr$("crt_printf to new console",13,10)

    print "Press any key to exit...",13,10
    call waitkey

    exit
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
end start


[jj2007]

Compliments, that works perfectly even with multiple consoles :U

Code Select Expand

    print "print to original console",13,10
    invoke crt_printf, chr$("crt_printf to original console",13,10)

    print "Press any key to continue...",13,10
    call waitkey
REPEAT 5
    invoke FreeConsole
    invoke AllocConsole

    print "print to new console",13,10
    invoke crt_printf, chr$("crt_printf to new console",13,10)

    print "Press any key to exit...",13,10
    call waitkey
ENDM
    exit


[dedndave]

didn't i already do that on page one of the thread, guys ? - lol
in fact, with my routine, you can continue executing other code until a key is pressed (i.e. it polls the keyboard)
with waitkey, it requires a keypress in order to exit

[GregL]

jj2007,

That's why the statement "they are large" is pretty meaningless. You call them, you don't embed them in your executable.

If you statically link them they are embedded in your executable.

You just want to argue, don't you?

[jj2007]

jj2007,

That's why the statement "they are large" is pretty meaningless. You call them, you don't embed them in your executable.

If you statically link them they are embedded in your executable.

You just want to argue, don't you?

No, Greg. But I am curious to know why several people apparently think that calls to crt bloat the executable. For example, I have a proc that uses crt_strstr. Here is what I get from Olly:

Code Select Expand

004030B7       |.  FF15 68404000           |call near [<&msvcrt.strstr>]           ; \strstr
strstr           8B4C24 08                 mov ecx, [esp+8]
77C17C64         57                        push edi                                ; ntdll.7C920738
That doesn't look like a part of my executable... or am I wrong?

[dedndave]

well, to be honest - there are problems associated with the console keyboard
it is a pain in the arse, when it should be very simple
problems arise because keyboard events are placed into the same buffer as mouse and other input events
this is logical, as it provides a time-line for managing input events without time-stamping them
the problems i have been having involve the mouse events, especially with regard to copy/paste
in fact, copy/paste is buggish, even when the console is sitting at the command prompt (i.e. no process running)
but - these are bugs - it's not something that is easy to program around
in other words, if the functions acted like they ought to, there would be no problems
one problem is that mouse-pasted text can show up in the output buffer
so, as a plan to eliminate that problem, i have tried using SetConsoleMode to disable the mouse events
well - SetConsoleMode does not do what it is supposed to do
the fact is, if the console has bugs, even with no process running, it may be impossible to make it act correctly
that means that the problems arise, whether you use the crt or not
it doesn't matter how stable it is or how many years of improvement it has seen
one soultion i have been looking at is to modify the contents of the output buffer - removing the pasted text
that means you have to process all input events, not just the keyboard events we are interested in
another problem i have seen is that the display positions may get bumped if you use right-click/mark
once they have been bumped this way, that console window is trashed
terminating the program and restarting it in the same console still yields bumped positions
you have to close that window and open a fresh one to make it act right again
this could be programmed around, but not simply
at some point, you have to start looking into fixing the console instead of trying to fix your program
i haven't attempted to contact ms and report these bugs
that may be the best solution, too
that way, they can generate KB999999 and fix everyones console windows
i don't know if they care enough about console-mode apps to mess with it

[dedndave]

i may have a solution for the paste bug
prior to writing text to the screen, you could flush the output buffer by writing it to the NUL device
let me play with it...

[GregL]

You are right about the Windows Console, it does have it problems. Design problems from the beginning, I think.