Subject: Re: DLL musings
From: [email-masked] (Benjamin Riefenstahl)

17 Jan 1998 12:40:05 -0800
Message-ID: <[email-masked]>
References: <01BD1FB4.71E2B860@cerebus>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "[email-masked]'" <[email-masked]>

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 ([email-masked])
Crocodial Communications EntwicklungsGmbH
Ophagen 16a, D-20257 Hamburg, Germany
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".