Pelles C forum
C language => Windows questions => Topic started by: codez1 on September 13, 2011, 03:33:32 AM
-
I am new. I have created a win 32 static library and it works fine. I would like to create a win32 dynamic link library. Do you have a minimum skeleton code for this and how do I call a dll function from my program. I am writing console applications right now.
-
Since I asked, I found the dll wizard and it helped setup basic code.
Is the code setup by the wizard, the bare minimum?
-
Pretty close... The absolute bare, not one byte extra, minimum is the DLLMain callback which is executed by LoadLibrary();
http://msdn.microsoft.com/en-us/library/ms682583(v=vs.85).aspx
Also give this a read...
http://msdn.microsoft.com/en-us/library/ms682589(v=vs.85).aspx
-
This example is just for making minimum dll without CRT (C runtime libraries).
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
//#pragma nodefaultlib
//BOOL WINAPI DllMain(HANDLE hDLL, DWORD dwReason, LPVOID lpReserved)
#pragma comment(linker, "/NODEFAULTLIB")
#ifdef _WIN64
#pragma comment(linker, "/ENTRY:DllMainCRTStartup")
#else
#pragma comment(linker, "/ENTRY:_DllMainCRTStartup@12")
#endif
BOOL WINAPI DllMainCRTStartup(HANDLE hDLL, DWORD dwReason, LPVOID lpReserved)
{
return TRUE;
}
int __declspec( dllexport ) __stdcall SampleFunction(int a, int b)
{
MessageBox(0, "SampleFunction", "TestDLL", MB_OK);
return a * b;
}
To make normal DLL using crt-library you can create empty DLL project and insert your source files to it,
and polink.exe insert code for DllMain-function if it is missing.
Exported functions can be listed in DEF-file if you don't use that __declspec( dllexport ) definition.
-
Ok, I will check out the links. As for the code, that helps also, thanks.
-
/* first the dll ( myDll.dll ) in myDll.c */
#include <windows.h>
BOOL APIENTRY DllMain(HINSTANCE hInstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
switch (fdwReason)
{
case DLL_PROCESS_ATTACH: break;
case DLL_THREAD_ATTACH: break;
case DLL_THREAD_DETACH: break;
case DLL_PROCESS_DETACH: break;
}
return TRUE;
}
__declspec(dllexport) int __cdecl plusI(int a, int b) { return a + b; }
__declspec(dllexport) double __cdecl plusF(double a, double b) { return a + b; }
/* end */
/* and , for test */
/* you must check in Project,Project options,Compiler,Enable Microsoft extensions */
#include <windows.h>
#include <stdio.h>
typedef int (__cdecl *ProcAddress_1)(int,int );
typedef double (__cdecl *ProcAddress_2)(double,double);
int main(void)
{
HINSTANCE testDll = LoadLibrary("myDll.dll");
ProcAddress_1 plusI =(ProcAddress_1) GetProcAddress(testDll, "plusI");
ProcAddress_2 plusF =(ProcAddress_2) GetProcAddress(testDll, "plusF");
int a = plusI(100 , 50 );
double b = plusF(0.33 , 0.67);
printf( "\n\n a + b = %d + %.2f = %.2f test\n\n" , a , b , plusF ( (double) a , b ) );
FreeLibrary(testDll);
return 0;
}
-
still waiting for the lightbulb on this thread. i've followed it and done some external research, but i can't get beyond the "unresolved external" error.
i come from the static .a unix environment. .dll's are not completely alien, but this is my first try at building one and using one.
i have a simple project that makes one call to a function residing in my dll.
i used the .dll wizard to create a .dll with that one function. i end up with a .lib, .dll and .exp file from the dll wizard.
the simple project adds the .lib file to the linker options. when i build the project, i get the unresolved external error.
POLINK: error: Unresolved external symbol '_getTotal@8'.
POLINK: fatal error: 1 unresolved external(s).
i've copied the .lib to the \pellesc c\lib\win directory (which is the first choice in the project folders options). i don't know what to do with the .dll or the .exp, but for the purposes of a build, i'm thinking the location of a .dll doesn't matter at this point. so, is it the .exp? who uses it?
i turned verbose mode on for linking, and, among others, i see:
Searching C:\Program Files (x86)\PellesC\Lib\Win\mydll.lib
so i know the .lib is at least found and being searched
the .def file has this line:
"MyExportFunction"=_getTotal@8 // <---- my function
and at the very end of the .exp file, i can see the name of my function. so i'm guessing the .def and the .exp files are ok.
if podump /all on my .lib is supposed to show the name of my function, it doesn't. do i have to tell the wizard something that i missed? it seems to create all the necessary boilerplate without my telling it anything.
as for the function itself, the example provided by the wizard was pretty much what i was going to do anyway, so i just left the code that was there. i changed the name of the function if for no other reason than to make myself useful. was that wrong?
thanks for pointing me in the right direction.
-go
-
Compile the DLL as a separate project.
Write a header with your DLL's exports in it and include it in your main project.
Tell the linker to link with the library.
Use LoadLibrary() to make sure the DLL is in memory...
Compile
Run...
Should work...
Take a look at a few Windows headers... and look up a few function calls in the SDK... the windows API is just a bunch of DLLs... so you should handle yours the same way windows does.
-
i changed the name of the function if for no other reason than to make myself useful. was that wrong?
Because you change function name to undecorated form, you should use dynamic linking with LoadLibrary or tell linker what altername name is.
Examples:#define WIN32_LEAN_AND_MEAN
#include <windows.h>
int __stdcall MyExportFunction(int a, int b);
typedef int (WINAPI MYEXPORTFUNCTION)(int a, int b);
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR lpCmdLine, int nCmdShow)
{
static MYEXPORTFUNCTION *MyExportFunction;
HANDLE hLib = LoadLibrary("TestDllNew.dll");
if (hLib) {
MyExportFunction = (MYEXPORTFUNCTION*)GetProcAddress(hLib, "MyExportFunction");
int rc = MyExportFunction(1, 2);
char szTmp[100];
wsprintf(szTmp, "return value: %d", rc);
MessageBox(0, szTmp, "TestDllNew2Test", MB_OK);
FreeLibrary(hLib);
}
return 0;
}//TestDllNew.c
int __stdcall getTotal(int a, int b)
{
return a + b;
};TestDllNew.def
LIBRARY TestDllNew.dll
EXPORTS
"MyExportFunction" = _getTotal@8EDIT:
Or this with import library:
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#pragma comment(lib, "TestDllNew.lib")
#pragma comment(linker, "/ALTERNATENAME:_MyExportFunction@8=MyExportFunction")
int __stdcall MyExportFunction(int a, int b);
int PASCAL WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR lpCmdLine, int nCmdShow)
{
MyExportFunction(0, 0);
return 0;
}
-
ii've copied the .lib to the \pellesc c\lib\win directory (which is the first choice in the project folders options). i don't know what to do with the .dll or the .exp, but for the purposes of a build, i'm thinking the location of a .dll doesn't matter at this point. so, is it the .exp? who uses it?
Let me just add a note of caution here... It is very unwise to pollute the Pelles C folders with project files... way too much risk of a name collision and way too much risk of losing needed files.
If you need to indicate an outside path you can add it to the folders lists in your project options, so you would set those for your main project to also look in your DLL project's main folder.
(menu) Project -> Project Options -> Folders
I'm attaching an older project of mine that used a DLL... It shows one of several ways of doing this. You should be able to unzip this to a folder and get a good look at how it's setup... no promises that it will compile on your machine since it uses a couple of external private libs.
-
thanks to CommonTater and to timovjl for timely responses. still some issues.
to CommonTater:
"Compile the DLL as a separate project."
the .dll and the .exe are 2 separate projects.
"Write a header with your DLL's exports in it and include it in your main project."
i declared my function as an extern in the main project. for the purposes of this test, that should be the same thing, no?
"Tell the linker to link with the library."
i believe i have already done that. as i indicated, i had told the linker to use my .lib in the project options. and, as i indicated, the verbose output from the build shows that the .lib is being searched.
"Use LoadLibrary() to make sure the DLL is in memory..."
isn't LoadLibrary() a runtime call? unresolved external is link time. i don't get beyond link time.
thanks for mickey.zip. i appreciate your comment about polluting the pelles c directories. your mm.dll doesn't seem to have used the wizard. it looks quite different from what the wizard generates.
no .def, no .lib. as i ask below in this post: is the .dll wizard not actually supposed to be used for building a .dll?
--------------------------------------------------------------------------------------------------------------------------------
to timovjl:
thanks for all the examples - lots of work for you - but i want to continue to do what i always do: link with a .lib and have a corresponding .dll somewhere convenient.
if i have done something that prevents that - and judging by your suggestions, what i have done is seriously wrong - then i want to undo that and do it right.
you say:
"Because you change function name to undecorated form, you should use dynamic linking with LoadLibrary or tell linker what altername name is. "
ok, 3 things:
1) i realize LoadLibrary() is an option, and i have used it in other projects where the .dll was 3rd party, but i didn't have the unresolved external errors.
and as just stated, i would like to be able to add a .lib to the linker options and build normally.
2) you say i changed the function name to "undecorated form". what i did was change "SampleFunction()" to "getTotal()" in the dllmain.c and .h. i then changed "_SampleFunction@8" to "_getTotal@8" in the .def. isn't that still "decorated"? what's not decorated here?
and
3) have i not told the linker what the alternate name is? didn't i tell the linker what the alternate name was by linking with the .lib, which has the alternate decorated name? this is what i'm not following.
your second example looks just like what i already see in my dllmain.c and .def.
what you have in your example .def file:
LIBRARY TestDllNew.dll
EXPORTS
"MyExportFunction" = _getTotal@8
what i have in my .def file
my .def file:
LIBRARY "mydll"
EXPORTS
; TODO: Add your exports here!
"MyExportFunction"=_getTotal@8
why is your .def right and mine wrong? this is what i don't get.
i'm guessing i could just build the sample .dll from the wizard as is and link to my test project, and it would work fine, but that doesn't help me see
how to build .dll's. i can't have a .dll that only does 1 thing. and i can't name all my library functions "SampleFunction()" because that's the only
name that works.
so, yes, i changed the function name in the files generated by the wizard, but i believe i kept the decoration, and the .dll builds without error.
that should count for something, no? what do i do if i don't want SampleFunction()? are we saying i can't use the wizard because it's only meant
to build and export SampleFunction() and nothing else?
i would like to fire up the .dll wizard, add a bunch of functions, save and build a .dll and have a .lib file with the exports and add it to the linker options, just like i do with every other project that i build. is this doable? if so, what do i do differently? i've seen an example for vc++. it doesn't look terribly different from what the pelles c dll wizard generates. is there something i have to do with the pelles c wizard that i'm missing?
using the .dll wizard to build mydll.dll, and having a function called getTotal(), what do i have to do beyond declaring the function and coding it? let's say for argument's sake that i declare it in mydll.h and put the code in maindll.c i'll just ignore SampleFunction() and leave it be. is there a missing step in this scenario? how did my .dll build without an error if i made an error?
thanks again and sorry to ramble on.
-go
-
thanks to CommonTater and to timovjl for timely responses. still some issues.
to CommonTater:
"Compile the DLL as a separate project."
the .dll and the .exe are 2 separate projects.
Ok... that's the right way since they are two separate (and different) executables.
"Write a header with your DLL's exports in it and include it in your main project."
i declared my function as an extern in the main project. for the purposes of this test, that should be the same thing, no?
Not exactly... all functions are "extern" by default.
What the header does (look at mm.h) is declare the function as __declspec(dllimport) ... You can do this in your main program as well... but the header will be needed if you link to the DLL from other sources, anyway.
"Tell the linker to link with the library."
i believe i have already done that. as i indicated, i had told the linker to use my .lib in the project options. and, as i indicated, the verbose output from the build shows that the .lib is being searched.
Hmmmmm.... ???
"Use LoadLibrary() to make sure the DLL is in memory..."
isn't LoadLibrary() a runtime call? unresolved external is link time. i don't get beyond link time.
Correct... I just wanted to make sure you had it in there someplace. The goal is to load the DLL at runtime.
thanks for mickey.zip. i appreciate your comment about polluting the pelles c directories. your mm.dll doesn't seem to have used the wizard. it looks quite different from what the wizard generates.
no .def, no .lib. as i ask below in this post: is the .dll wizard not actually supposed to be used for building a .dll?
The wizard is one way of doing it... I prefer to start from blank pages. I consider the wizards to be "examples" of how it can be done. But like all software, there's usually more than one way to do things. Plus you would be absolutely amazed how much you learn when you have to struggle for every byte... :D
The Def and Lib files are on my system... but the zip-files command didn't include them. If you were to set it up and recompile it, it would produce them for you.
to timovjl:
thanks for all the examples - lots of work for you -
drgott ... trust me on this.... Although Timo's responses tend to be a bit terse, he is by far the more advanced programmer... I tend to defer to his wisdom on most things.
-
@drgott.... I'm attaching the simplest DLL project I can think of...
Pay particular attention to the project settings.
Hope this helps.
-
If def file is this when creating dll
LIBRARY "mydll"
EXPORTS
; TODO: Add your exports here!
"MyExportFunction"=_getTotal@8we need def file like this when creating import libraryLIBRARY "mydll"
EXPORTS
; TODO: Add your exports here!
_MyExportFunction@8Can anyone confirm this ?
-
If def file is this when creating dll
LIBRARY "mydll"
EXPORTS
; TODO: Add your exports here!
"MyExportFunction"=_getTotal@8we need def file like this when creating import libraryLIBRARY "mydll"
EXPORTS
; TODO: Add your exports here!
_MyExportFunction@8Can anyone confirm this ?
Hi Timo ...
I don't know how much help I can be here. When compiling Pelles always produces it's own .lib so I've never done it manually from a .def ... so, no, I don't believe the .def is actually necessary in this case.
However; from what I've seen on other sites, I do believe your setup is correct.
-
When compiling Pelles always produces it's own .lib so I've never done it manually from a .def ... so, no, I don't believe the .def is actually necessary in this case.
But in this case when someone wants unmangled __stdcall name it doesn't work ?
It works with mangled names.
Using LoadLibrary you need correct name of function and then unmangled __stdcall name is handy.
odbc32.dll is example of unmangled names in dll and mangled names library and SQL_API is __stdcall
I myself use __declspec(dllexport) in source code with dll's.
-
But in this case when someone wants unmangled __stdcall name it doesn't work ?
It works with mangled names.
Ahhh ... I didn't know that. I know there's some mangling but I didn't know you could avoid it...
I don't do a lot with DLLs. Most of my projects are small enough that a single .exe does the trick. Most of my DLL experience is from writing add-ins.
Using LoadLibrary you need correct name of function and then unmangled __stdcall name is handy.
That's why I write a header... makes life a little easier.
odbc32.dll is example of unmangled names in dll and mangled names library and SQL_API is __stdcall
I myself use __declspec(dllimport) in source code with dll's.
Interesting ... I'm going to have to experiment with that when I get a chance.
Thanks Timo...
-
just fyi:
1) if i build the sample .dll as provided by the wizard (ie, touching nothing generated by the wizard):
; This file was generated by the Win32 DLL Wizard.
; Syntax:
;
; NAME [appname]
; LIBRARY [libname]
; BASE address
; DESCRIPTION "text"
; STACKSIZE reserve[,commit]
; HEAPSIZE reserve[,commit]
; SECTIONS
; name [{EXECUTE|READ|WRITE|SHARED}]
; EXPORTS
; entryname[=internalname] [@ordinal] [DATA]
; VERSION major[.minor]
LIBRARY "mydll"
EXPORTS
; TODO: Add your exports here!
"MyExportFunction"=_SampleFunction@8
and,
2) if i put the resulting .lib in with all the other .lib's in the \pelles c\lib\win folder, and
3) if i link to that .lib in the project linker options, and
4) if i turn on verbose mode, and
5) if i call the function (whose name SampleFunction() was generated by the .dll wizard) that's in the .dll from within a project, and
6) if i build the project, the build still fails with unresolved external, that is, the SampleFunction() generated by the wizard:
...
Searching C:\Program Files (x86)\PellesC\Lib\Win\mydll.lib
Searching C:\Program Files (x86)\PellesC\Lib\crt.lib
POLINK: error: Unresolved external symbol '_SampleFunction@8'.
POLINK: fatal error: 1 unresolved external(s).
*** Error code: 1 ***
so it would seem to me that
1) there is a problem with the wizard or
2) any .dll's created by it are not meant to be linked at build time, but rather loaded exclusively at runtime via LoadLibrary(), and other ancillary code needed to locate the function within the .dll or
3) there is a missing step that one (me) has to do with a home-generated .dll that is not required with the hundreds of .dll's on a windows-os box.
and what i mean by #3 is; if i want to build a project that uses winsock, as an example, all i have to do is
include the winsock2.h header, link my project to ws2_32.lib in the linker options, and code something which uses one or more of the winsock-related functions in the library. period. done.
i have used pelles c wizards for years without a problem. and starting with a blank page, is a waste of time for me, since i would only have to cut-and-paste all the usual windows boilerplate startup that already comes with the wizards. the only time i can't build a project in this manner is if i don't have the necessary .lib to link to. in the case of my test .dll, not only do i have the .lib, i built it! (well, the wizard built it. but with my blessing and oversight.) and the fact that there is a .lib would tend to mean that it was supposed to be used (eg, for linking).
it seems that timovjl is questioning how the wizard generates the .def file. i just wanted to clarify that i finally did built a .dll using only the wizard's boilerplate with its sample function, and that building a project that calls that function fails as described above.
-go
-
Without .def file you can build Wizard generated dll.
-
i should have held off for 10 minutes before my last post.
it's not a step that's missing, it's a step that's added which (apparently) shouldn't be added (unless you know what you're doing!)
here's the deal:
when you use the wizard to create a .dll, she asks if you want a .def created. what's the harm, right? well, it's harmful enough to prevent the thing from working (unless you know what you're doing.) if you say, yes, create the .def, you get the unresolved external references in the main project build (with appropriate linking), as described earlier.
if you say, no, no .def, then you get boilerplate that looks more like the examples which have been posted in this thread. plus, there is the added benefit of the thing building without error, which is always handy.
if you add LoadLibrary() to the main project, and point that call to where the .dll is, the project runs as expected.
so that's another disaster averted. thanks again to those who took the time to look into my question.
with luck, i'll be able to have more than a single function in the .dll. i'm hoping the sample code i've been sent will shed some light on that aspect.
-go
-
The generated dll works fine in either case, the problem is in the importing exe/module and misjudged expectations.
The clue is in these parts of the def
; EXPORTS
; entryname[=internalname] [@ordinal] [DATA]
EXPORTS
"MyExportFunction"=_SampleFunction@8
entryname is the name used by external code, (in this case that's 'MyExportFunction'), internalname is the name of the function in the DLL (in this case a WINAPI decorated 'SampleFunction'). So, if you're wanting to use this function from outside, you use the name "MyExportFunction". Your application code is trying to use 'SampleFunction', but that doesn't exist in the lib (because the def told Pelles to rename it to MyExportFunction).
Granted its not explicit, but I think a logical leap can be made that if SampleFunction is on the internalname part of the def file equation and external code isn't finding it, that it has been named differently with MyExportFunction being a rather overwhelming candidate.
-
@drgott ...
If you follow the form and substance of the example I posted you can add hundreds... even thousands of functions to your DLLs... all the rudimentary steps are there, it's just a matter of following the concept EXPORT in the DLL source and IMPORT in the header...
Yes you will need LoadLibrary() to get them into memory where you can use them. But you should not have the DLL and EXE in different folders; note how my example project automatically places them in the same folder... that's done for a reason. If you use a path in LoadLibrary() and that path does not exist on an end user's system, it's going to fail. DLLs for end user code should always be in the same folder as their parent executable.
Also note that in most cases the Windows API functions transparently include LoadLibrary() in their initialization calls... The common controls DLL is loaded by InitCommonControls(), winsock is loaded by WsaStartup() and so on. The only difference here is that you are seeing the call, whereas it's the API usually hides it in another function.
If you want to link at build time, instead, you should create "Windows Static Libraries". These will link functions right into your main program, no DLL is created. They are also much simpler since you don't need to EXPORT or IMPORT, just write the code, prototype it in a header and use it.
The only thing that needs to be done differently in libs is that each separate function needs to be in it's own tiny .c file. This is because each .c file produces one .obj file when compiled and the linker works on the .obj level. So, if you are using (say) 10 functions from a library of 100, having them all in one source file will result in all 100 functions being linked in. With separate source files, you'll only get the needed 10 functions. Take a look at the File Associations library I put in User Contributions ( http://forum.pellesc.de/index.php?topic=3685.0 (http://forum.pellesc.de/index.php?topic=3685.0) ) for an example of form and style.
I will once again warn you against putting your own .lib files into the Pelles C folders. Quite simply: don't do it. Add a new path to the project options ( menu -> Project -> Project Options ) where the .lib and .dll were compiled DO NOT split them up or move them into the Pelles folders. If you should inadvertantly overwrite something you may find yourself producing rather a lot of corrupt code before you catch the problem. (Review the project settings in my example...)
Now; about the Wizards... I tend to view them as "beginner stuff" because that's what they are; a quick start for someone in the early phases of learning C programming. The Wizards are not smarter than you. They are merely a convenience and there's nothing special about them. In fact one point of view would hold that relying on Wizards lets you off the hook for learning how this stuff really works.
That said; there is nothing preventing you from writing your own Wizards to give you the desired base code, as you like it. Examine my VC++ Addin and Wizard or any of the other user contributed wizards for an example of how it's done. (If you install the addin SDK from Pelle's website you also get the source for the standard wizards to look at.)
Good luck with this... It's only confusing until you understand it.
-
DLLs for end user code should always be in the same folder as their parent executable.
Sorry, but that is a bit against the purpose of creating a DLL Lin the first place. A DLL should contain code that is re-usable across projects/application, so it wouldn't make much sense to to copy that file over and over again into the program folder of all possible applications.
To minimize the issues for the OP however, it would be a good thing to use it that way, at least until he has familiar with the way how this whole procedure works...
Ralf
-
To minimize the issues for the OP however, it would be a good thing to use it that way, at least until he has familiar with the way how this whole procedure works...
Ralf
Hey Ralf 8)
I have a rule about that...
1) If the code in the DLL is only used in one place; why bother, just make a .lib and link it into the main exe.
2) If the code is applicable system wide (eg. a codec, driver or service) put it in system32
3) Otherwise... put it in the folder with your product's executables.
And as we agree... at least for testing... he should have all this stuff in one folder.
-
thanks again, one and all, for the comments. mercifully, the world is still free enough for discussion about the purpose of wizards, and the best places to store and how to access libraries.
but in a way, it's all becoming moot, as - yet again - the wizards in redmond change the rules: no more win32 for windows mobile, which i greatly enjoyed programming over the years. and soon, apparently, conditional win32 for w8. enjoy while it lasts!
-go
-
thanks again, one and all, for the comments. mercifully, the world is still free enough for discussion about the purpose of wizards, and the best places to store and how to access libraries.
but in a way, it's all becoming moot, as - yet again - the wizards in redmond change the rules: no more win32 for windows mobile, which i greatly enjoyed programming over the years. and soon, apparently, conditional win32 for w8. enjoy while it lasts!
Don't feel bad ... 64 bit Vista and 7 will not run 16 bit software anymore... it's all in the name of progress.
Right now it's all heading to 64 bit, as it should... soon, I suspect we'll be having a similar discussion about 128 code.
Good luck with your DLLs....