Re: [AD] [WIN] dll export file patch

["Henrik Stokseth" <hstokset@xxxxxxxxxx>]

Eric Botcazou <ebotcazou@xxxxxxxxxx> wrote:

> We have then three options:
> - satisfying ourselves with that,
> - hiding internals in a way similar to that I proposed some time ago,
> - using Henrik's approach of making the dynamic linking process explicit.
>
> I now think the last two ones are somewhat an overkill...

Solution one is preserves backwards compatibility as long as only internals
change, if the API changes we're back where we started.

Solution two is what most windows coders like to use i think, but it will
break programs that uses clobbers with allegro internals at source-level and
requires a large symbol table.

My approach was to rethink allegro's dynamic linking. if we use run-time
linking instead of load-time linking we won't need to worry about symbol
offsets which again means that we're free to change around the contents of
the DLL without breaking any binary compatibility. I've shown Eric that this
will work with some macros. (redefine AL_FUNC, AL_VAR using nested macro
etc...) I should perhaps also mention that the import library will disappear
too.

from the head: (warning: might contain syntax errors)

before allegro.h make sure to call allegro_dll_handle = LoadLibrary();

#define AL_FUNC(type, name, args) \
type (*name)(args) = (void*) LoadProcAddress(allegro_dll_handle, \"name\");
\
if(!name) Exit(-99);

#define AL_VAR(type, name) \
type *var_##name = (void*) LoadProcAddress(allegro_dll_handle, \"name\") \
\#define name *(var_name)

i've heard gcc 3.0 uses a single-pass preprocessor. but AL_VAR needs two
passes, but that can be dealt with running the preprocessor twice...

Solution #2 and #3 might be overkill, but an aparently perfect solution like
#3 is tempting... I'm just curious to know how you other coders feel on this
subject.

-henrik