Re: [AD] font vtable patch

[Henrik Stokseth <hstokset@xxxxxxxxxx>]

On Monday 30 April 2001 11:54, Eric wrote:

> > A wrapper around ``blessed'' internals?
> >
> >     void *allegro_get_internal(AL_CONST char *key);
>
> I like the idea of some sort of a wrapper. With such a scheme, we could
> export only the regular API symbols plus this single one. The question is
> then which kind of dynamic linking we would use to implement it ?
>
> Either run-time linking as you are suggesting: the program must query
> Allegro for each internal symbol it wants to use and work around the
> problem or terminate if the symbol is missing.
>
> Or load-time linking: we build up in the sources a table of all internals
> that we want to be exported and export only this table. Therefore we still
> have only the regular API symbols plus one, this latter being a variable
> rather than a function.
> An add-on calls a specific internal with the help of a macro:
>    if (AL_INTERNAL(_textmode) < 0)
>       /* render as transparent */
>    else
>       /* render as opaque */
>
> with somewhere in allegro.h:
>    #ifdef STATICLINK
>       #define AL_INTERNAL(symbol)  symbol
>    #else
>       #define AL_INTERNAL(symbol)  *(internals_table.##symbol)
>
> This solution seems to be lighter than the previous one, but of course less
> safe.
>
> > A condition of using this function is that internals might become
> > unavailable in future.  Use it now, get burnt later.
>
> That's the rule of the game with internals. And the wrapper mechanism is
> there to make it clear that internals are not just like other symbols.
>
> > A better idea may be just to move said ``blessed'' internals into a
> > separate header file (ainternbutnotreally.h).
>
> But then they would still be exported with the same status as API symbols.
> Does the wrapper mechanism not ensure total binary compatibility for user
> programs using only API calls, even if we add or remove some internals ?
> I'm not sure this is the case with this solution under Windows.
>
> > But that still leaves the question of which ones to bless.
>
> Quite right. And I'm more and more thinking that the safest way is to bless
> every platform-independant global internal: if Shawn chose to make it
> global, this is because some other parts of the library, that could
> eventually be enhanced by an add-on, use it.

Nice solutions. But whatever you do, try to avoid at all costs any nasty 
#ifndef SCAN_EXPORT hacks and keep in mind that there must (*) be a clear 
distinction between normal functions and variables and internal functions and 
variables.

*) in order to link allegro without export definition files and get binary 
compatible dlls this is an absolute requirement.

-- 
Sincerely Henrik Stokseth.
----------------------------------------------------------------------------
E-mail: hstokset@xxxxxxxxxx  Homepage: http://hstokset.n3.net
"Linux is keyboard friendly. I don't smash it like I used to with Windows."