ret_key.asm

[MyLanguage]

Trying to use proc ret_key found in\m32lib\retkey.asm and \macros\macros.asm and referenced in \include\masm32.inc and \m32lib\masm32.inc as "ret_key PROTO".  Tried several variations of includes in my .asm file but the best I've gotten is:
masm32.lib<retkey.obj> : error : LNK2001:  unresolved external symbol __imp___getch
The assemble part of the assemble and link goes OK.
Have found no examples using "ret_key".  Code has been stripped down to a minimum for testing.
Am I missing something (such as an include or whatever)?

    .486                      ; create 32 bit code
    .model flat, stdcall      ; 32 bit memory model
    option casemap :none      ; case sensitive

    include \masm32\include\masm32.inc
    include \masm32\include\kernel32.inc
     
    includelib \masm32\lib\masm32.lib
    includelib \masm32\lib\kernel32.lib

    include \masm32\_MyProjects\_MyMacros\input.asm             ; Macro: input

    .data?
        hInstance dd ?

    .code

start:
    call input_text

    call ret_key

    invoke ExitProcess,eax

input_text proc
    LOCAL txtinput:DWORD            ; a "handle" for the text returned by "input"
    mov txtinput, input(13, 10, "MASM32 Project.", 13, 10)

    ret
input_text endp

end start

[PBrennick]

You need to add the following to your source and it will assemble and link properly:

    include \masm32\include\msvcrt.inc
    includelib \masm32\lib\msvcrt.lib

Paul

[MichaelW]

To expand a little on Paul's reply, the ret_key procedure (see \masm32\m32lib\retkey.asm) calls the C run-time library (CRT) function _getch, and for this to work your source must include the necessary include file (msvcrt.inc) and import library (msvcrt.lib).

[MyLanguage]

That solves my problem and it also helps forther my understanding a little.
Thank you!

[Mark Jones]

Curious Michael, why did we (Hutch) ever decide on a reference to the VC lib for this feature anyways? I mean, couldn't we have just written an equivalent wait-key function and put it in the masm lib? To save the dependency, that is.

[MichaelW]

Hi Mark,

Both wait_key and ret_key use the CRT. I'm not sure how the decision was made, but I recall a thread were this was being discussed, and I favored the CRT versions because they were smaller and cleaner and because execution speed did not matter. I suppose the dependency could be a small problem for some, but for people who use the CRT frequently for other things, as I do, it's not a problem.

[hutch--]

Mark,

The key algos wer mainly developed by Greg and they are both simple and reliable where a custom coded version is messy and some of the information is unreliable. The old MSVCRT DLL has been around since win95b and has changed less than the API so its very reliable and highly available.

Interestingly enough I have done one using GetAsynchKeyState() that seemed with limited testing to work OK.

[PBrennick]

IMO, since we all as a matter of course use lots of libraries in our coding, one more does not make much difference. However, a dependancy that is NOT very obvious on the surface really should be documented so that newbies will not get confused. I am just not sure if there is any good way to do that. Most will not look at the source of the algo (which shows it as being obvious).

Paul

[GregL]

Like Hutch said msvcrt.dll is included in all Windows versions since Windows 95B, including Windows 7.

Adding a note in the help files for the macros and procedures that have a dependancy for msvcrt.dll would be helpful.

From what I remember, at the time, we tried writing some equivalent functions that didn't use the CRT (C Run-Time Library) and used the Console Functions but they weren't reliable. The CRT is tried and tested.