Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

A Question for DavesTips

Status
Not open for further replies.

AndyHollywood

Programmer
Oct 7, 2001
30
GB
DaveTips

you helped me the other day with my program (key32) which used a dll to deploy system wide hooks, and it now works a treat i was just wondering if you could explain what you did?!

I was under the impression that to export functions from a dll you needed a *.def file? or is this a different method of exporting functions?

Also I had a project in Visual C++ holding the main program and then inside of this another project with the dll code, was this a mistake/bad practise? and did this cause more problems when trying to compile and link the the project?

Cheers again for your help

Andy
 
Yes, I played around a bit with your projects:)

If you use __declspec(dllexport) you don't need the .def file for normal exported functions. The only case where you might want that is if you require completely unembroidered names, because __stdcall with extern "C" and dllexport creates names like _Func@4, but since both import and export are doing the same, there's no problem in your case. If you want to call the routine from VB for example (which requires __stdcall) and you don't want to declare the names like _Func@4, rather just as Func, then you need to put the names in the EXPORTS section of a .def file.

As far as project structure is concerned there's no real right or wrong. I put the projects in two workspaces because I prefer to work that way. I'd say it's partly a matter of taste, although also a question of how you want to organize your work with regard to size of project, number of developers and so on. If you're developing common components for several unrelated projects for example, you don't necessarily want the code too closely related with just one of those projects.

It's quite a good idea though to use relative path names as I did rather that absolute paths for things like headers and .lib files pulled in from other projects. It means you can move or copy the folders as a group without changing #includes or project settings. If you have a lot of stuff like that it's probably better to put shared files in some common directory(ies).
:) Hope that this helped! :)
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top