Win32 dynamic link library - need an example

[TimoVJL]

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.

[CommonTater]

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...

[drgott]

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

[TimoVJL]

Without .def file you can build Wizard generated dll.

[drgott]

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

[aardvajk]

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

Code: [Select]

; 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.

[CommonTater]

@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 ) 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.
 

[Bitbeisser]

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

[CommonTater]

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 

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.

[drgott]

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

[CommonTater]

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....