Unexpected Linking Errors

I've written a program that will hopefully install windows hooks except when it compiles i get some unexpected linking errors, can anybody shed any light onto the cause of these, and or give me directions on how to go about fixing them:


--------------------Configuration: key32 - Win32 Debug--------------------
Linking...
key32.obj : error LNK2001: unresolved external symbol "int __stdcall PaintHooksDll(struct HDC__ *)" (?PaintHooksDll@@YGHPAUHDC__@@@Z)
key32.obj : error LNK2001: unresolved external symbol "int __stdcall InstallFilter(int,int)" (?InstallFilter@@YGHHH@Z)
Debug/key32.exe : fatal error LNK1120: 2 unresolved externals
Error executing link.exe.

key32.exe - 3 error(s), 0 warning(s)



I enclose my project so if anybody would like to take the challenge be my guest, because it baffles me!!

cheers in advance

Andy:confused:

Did you use WINAPI/CALLBACK/__stdcall as a modifier on the function definition in your .h file, but not provide it in the actual code definition? I can't download the file since my mouse is a bit defunct :(

in the .h file they are:
int FAR PASCAL InitHooksDll(HWND hwndMainWindow, int nWinLineHeight);
int FAR PASCAL PaintHooksDll(HDC hDC);
int FAR PASCAL InstallFilter (int nHookIndex, int nCode );


and in the .cpp:

int CALLBACK InitHooksDll(HWND hwndMainWindow, int nWinLineHeight);
int CALLBACK PaintHooksDll(HDC hDC );
int CALLBACK InstallFilter (int nHookIndex, int nCode );


this is what it said in the example iwas working from so thats what i did! was it wrong?

what is callback, far pascal etc..?

as you've probably guessed i havent done a lot of win32 programming, infact non before this really!

In 32-bit programming, near and far pointers are irrelevant (it's all about segment:offset addressing which I don't want to go into now because I hate it).

I think PASCAL and CALLBACK are basically the same. What they represent is the "calling convention", which should be "stdcall" in most cases. The calling convention is how the function is called, how parameters are passed, and whether the function or the caller is responsible for cleaning up. The stdcall convention is needed for DLLs.

Rewrite the prototypes to correspond to their functions and see if that helps at all.

the result of renaming the prototypes to match is:

Linking...
key32.obj : error LNK2001: unresolved external symbol "int __stdcall PaintHooksDll(struct HDC__ *)" (?PaintHooksDll@@YGHPAUHDC__@@@Z)
key32.obj : error LNK2001: unresolved external symbol "int __stdcall InstallFilter(int,int)" (?InstallFilter@@YGHHH@Z)
Debug/key32.exe : fatal error LNK1120: 2 unresolved externals
Error executing link.exe.

Erruuuggghhhh :eek:

Just opened up your code - why do you have a load of 16-bit code sitting in there? Is dllstuff.c ANYTHING to do with your project? One thing that may not help is accidentally compiling it as C and then trying to link to a C++ object file - name mangling will mess that up (it's 00:24 so I can't really explain that).

The code i have is from a microsoft example from MSDN
I asumed it was C++ as that was what the article talked about!

If indeed it is c then how do i compile it as c?

*sigh*

I wonder just how old that example is - it still has references to FAR in it which no 32-bit code needs. I really wish they'd sort some of this out, because this isn't the first time people have had problems with this sort of thing :rolleyes:

are there any easy ways to sort it so it would work, or do i have to redo the whole thing?

If you tell me what it is you're trying to accomplish with it (or a link to where you got that example from) then I might be able to do something for you.

http://msdn.microsoft.com/library/de...dn_hooks32.asp

above is the link from msdn where i got the original example!

I need to monitor all events in windows, inorder to log what exactly the user is doing withthe system, mainly their mouse clicks, mouse movement and keyboard presses. The final aim is to monitor these and tell whether a user has changed i.e. a new person at the computer.

I was told hooks would be the easiest way to achieve this!!

so what are your recommendations?

Andy

Quote:

---

Created: July 29, 1993

Revised: February 1994

---

Huh. So much for future-proofing :rolleyes:

OK I'll see what I can do - looks like I might have to do a bit of a rewrite ;)

Thank you very much for your help!!

Andy:)

How's this? :)

I had to use two separate log files because the multi-threaded nature of the hooks meant that as one keyboard event was being written to the file, another mouse event jumped in half-way through. Make them use the same file and see what I mean :eek:

Thank you very very much for helping me so much, however Whe ni compile the code i still get errors!


the attacher prog, says it cannot load input library?!?!

And when it trys to compile the inputhook files it gives me these linking errors!

--------------------Configuration: InputHook - Win32 Release--------------------
Linking...
Creating library Release/InputHook.lib and object Release/InputHook.exp
Copying library...
The system cannot find the path specified.
0 file(s) copied.
Error executing c:\winnt\system32\cmd.exe.

InputHook.dll - 1 error(s), 0 warning(s)



Are these connected, or am i just being stupid in the way i am using your program?
:confused:

Sorry i was being stupidly dense then!!! It does work a treat!!

Its the dogs dangly's! cheers again

Andy :D

Nope not you being dense, it was me being stupid. It copies the DLL from its own Release folder to the Attacher's Release folder, but since the folder doesn't initially exist it complains. If you build twice in a row it seems to work :)

No problem, glad it worked (in a lot less code than MS churned out :D)