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

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On Wed, 6 Jun 2001, Bob wrote:

> Although I think he meant that we should do this inside allegro_init(). 
> However, this woul cause problems for people who shut down Allegro 
> temporarily and re-init it later - we don't want to load the DLL twice.

In glwrapper, I cached the values of the functions.  I did this so that I
could switch between the real functions and special profiling/debug
versions.

However, I'm not sure you are thinking about this right.  If allegro_exit
unloaded the DLL, then you would then be reloading it if you called
install_allegro again . So, there would be no double loading of DLLs.

I don't see why Allegro would need to be dynamically loaded anyway.  With
glwrapper it is because there exist 5 different implementations of OpenGL
in Windows and I wanted to be able to load all of them.  (for the curious,
there is MS's opengl32.dll, SGI's opengl.dll, mini quake opengl32.dll,
3dxf stand alone opengl for Voodoo 1&2, and Mesa)

But, Allegro has no similar problem.  The solution to exporting too many
symbols, and making a DLL that will work accross API additions is to use
the @ordinals in the EXPORT script correctly.

Right now, they are pointless because they are just assigned in order.  
But, this is the default I think.  May as well not have ordinals in the
export file at all.  If you want to be able to add and remove API points
without breaking binary compatibility, then you are going to have to find
a way to make sure that new functions get new ordinals and that old
functions always keep the same ordinal, and that if you change a
function's interface, that it gets a new ordinal, and delete the old
ordinal to break old clients.

I think that this job is best done by hand, because new functions don't
get added that often I think.

Simply don't export any of the internal functions and data structures if
you think thats a Bad Thing(tm).  A person who needs such secret things
could always link against the static library ^_^





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/