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
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
To expand a little on Paul's reply, the ret_key procedure (see \masm32\m32lib\retkey.asm) calls the C run-time library (CRT) (http://msdn.microsoft.com/en-us/library/abx4dbyh(VS.71).aspx) function _getch (http://msdn.microsoft.com/en-us/library/078sfkak(VS.71).aspx), and for this to work your source must include the necessary include file (msvcrt.inc) and import library (msvcrt.lib).
That solves my problem and it also helps forther my understanding a little.
Thank you!
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.
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.
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.
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
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 (http://msdn.microsoft.com/en-us/library/ms682073.aspx) but they weren't reliable. The CRT is tried and tested.