Tutorials: Visual C++ DLL: How to build a resource-only DLL?
How to build a resource-only DLL?
A: On the 'Project Menu', select
'Settings'. Select the 'Link' tab of the 'Project
Settings' dialog, then in the 'Project Options' box, add
the '/NOENTRY' option.
the linker from linking a reference to '_main' into the
DLL; this option is required to create a resource-only
.RC file to an empty DLL
is involved in this process. If your application needs to
access the resources from the DLL, it is easier to use the
Win API functions to access these resources
than MFC. You need to
with the name of resource DLL,
and then the Windows API 'FindResource()'/'LoadResource()'/'LoadBitmap()'
etc. functions to find and load the resource.
The reason why the API functions are easier to manage than
MFC is that the API
functions require that you give it the handle to the
loaded DLL (the return
value when you called 'LoadLibrary()'),
while the MFC
functions do not have this parameter. Requiring the DLL
handle allows much more flexibility, since you can have
multiple resource DLL's
loaded, and you don't have to fool around with the 'AfxSetResourceHandle()'
function (for example, compare the MFC
'LoadBitmap()' with the Windows API 'LoadBitmap()'). When
you call 'AfxSetResourceHandle()',
you are globally making a change to which resources your
application is going to reference, which I do not like, so
I don't ever use that function.
If you want to use the MFC
functions after using the API function to load your
bitmap, just call the 'Attach()' method, and then
the 'Detach()' method.
Visual C++ DLL: How to build a DLL to be used from another programming language?
How to build a DLL to be used
from another programming
When you create a DLL
with Visual C++, and
you want to use the DLL
with other languages, there are a few things that you
should do (creating a DLL isn't just compiling code).
sure your exported functions are declared as extern
"C". The reason for this is so that the C++
name mangling is not used on the exported function
sure your exported functions use '__stdcall' calling
convention. The reason for this is that most other
Window's languages assume the exported functions
retrieve parameters starting from the rightmost
parameter, and that the function called is responsible
for stack cleanup on return. By default C and C++
functions assume '__cdecl' calling convention.
You won't know when this problem exists until you call
the exported function in your Delphi program. You did
your function as '__stdcall', so your [insert porgramming
language, other than C/C++,
here] program would have crashed as soon as you called
This is so that the function can be exported (of
module definition file (.def-file). This removes the
"@x" decoration that appears at the end of VC++
exported function names, where "x" is the
total number of bytes in the arguments passed to the
function. When the user of the DLL is using another
language, the programmer would rather call
"tempest", not "tempest@4". Yes,
many of these other languages have an
"aliasing" features so that you can access
the function by a different name, but it is a pain in
the neck. Just use a .def-file to remove the
additional decoration and you won't have to do
Just exporting the name does *not* remove all the
decoration - you must follow steps a) *and* d). A lot
think that you only need to do a) and b) and c). This is
if you plan on using the DLL
in only Visual C++. If
you leave the module definition file out of these steps,
you will get what you're seeing now -- an exported name
that is not what you expect.
If you do a search on CodeGuru, your question has been
ucancode.neted many times in various ways, and the reason for the
problem is almost always that step d) was left out.
Here is a sample of a module-definition fie (DEF file).
DESCRIPTION 'This is my DLL
command must match the name of your DLL. So if your DLL is
named YOURDLL.DLL, the LIBRARY command is followed by
The DESCRIPTION is any description you feel is appropriate
for your DLL. The actual description is preceeded by a
single quote (').
The EXPORTS lists the functions that you exported, along
with an ordinal number. It doesn't matter what ordinal
numbers you use, so long as you maintain different numbers
for each function, and you shouldn't change the ordinal
numbers when you create an upgraded version of your DLL --
persons preferring to use ordinal numbers to call your
functions will get angry.