RE: DLL musings

RE: DLL musings

[Michael Pymm]

Further to my last post, I've got a partial solution, although it's a little urgh.
(this is only for the glide2x.dll, a library to use the 3Dfx card - I've got other
3rd party dlls to work using the SOP).

Say there's a function (void)grGlideInit(void) in the DLL. My code looks like

void (*pgrGlideInit)(void);

void LoadFuncs(void) {
	HINSTANCE m;
	FARPROC f;

	m = LoadLibrary(<path to glide2x.dll>);
	f = GetProcAddress(m, "_grGlideInit@0"); pgrGlideInit = (void (*)()) f;
	
	return;
}

int main(void) {
	LoadFuncs();

	(*pgrGlideInit)();

	return(0);
}

This works! The function LoadFuncs is quite easy to generate from a .def
file, as long as all the DLL functions return void.

I suppose a c preprocessor could be used to extract function definitions
from the glide.h file and construct the (*p<funcname>) stuff at the top and
do proper casting in the LoadFuncs procedure (any ideas?)

dlltool probably creates a library that provides wrapper functions with the
same name as the DLL functions that simply call what I've called (*p<funcname>).

Obviously, my approach is very unportable but I suppose is slightly faster
as it doesn't use a wrapper function.

The question is that if the above works, why does dlltool and ld produce
an executable that Win95 OSR2 says is in the wrong format?

Michael

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: DLL musings

[Benjamin Riefenstahl]

Hi Michael,


Michael Pymm wrote:
> Say there's a function (void)grGlideInit(void) in the DLL. My code looks like
> 
> void (*pgrGlideInit)(void);

That declares a pointer to a function with C calling convention.

>         f = GetProcAddress(m, "_grGlideInit@0");

This function name looks like a mixture of a function with C calling
convention (the leading underscore) and __stdcall calling convention
(the trailing "@0"). There is not much difference for a function without
parameters, but if there are parameters there sure is a difference. If
this is actually a __stdcall function, I would declare the function
pointer like

  typedef void __stdcall grGlideInit_T(void);
  grGlideInit_T * pgrGlideInit;

(You can try to do this in one line without the typedef, but don't ask
me if it doesn't work ;-)


> Obviously, my approach is very unportable but I suppose is slightly faster
> as it doesn't use a wrapper function.

I don't know what the current round of dlltool/ld actually does but in
theory what they do internally can be more efficient than anything that
you can do in code.

The initialization can arranged to be done by the OS loader and the
wrapper that you refer to can be implemented with a jump table. That
should have approximatly the same cost as calling through a function
pointer.

If you don't care about minimizing the memory foot print of the DLL
code, you can even instruct ld to collapse the call site and the entry
in the jump table. With a jump table the OS loader needs only fix-up the
few jump table pages, without it it needs to fix-up all call sites. As a
result without jump table you can share less code pages between
instances, but it is faster.


so long, benny
======================================
Benjamin Riefenstahl (benny@crocodial.de)
Crocodial Communications EntwicklungsGmbH
Ophagen 16a, D-20257 Hamburg, Germany
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

DLL musings

[Michael Pymm]

For the moment, I've accepted that certain 3rd party DLLs can't be used by a
gcc program given the currently available toolset. Would it be possible to convert
a DLL into a static library? If I understand things properly, DLLs are in-process 
components, same as a library, and you'd call DLL procedures using the same
stdcall method as procedures in modules.

Before I start reading up on .a file format and DLLs, does anybody have any comments
to make on the feasibility (or lack thereof) of such an idea?

Finally, do the libraries that an application like dlltool creates simply contain code to
load a DLL (if not already done so) and call a function at a particular offset into the DLL?
Or is this way too simplistic.

As you might guess, I'm a bit hazy about the specifics of all this.

Michael

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".