Re: [AD] 4.9 on MSVC 2008

[torhu <torhu.lists@xxxxxxxxxx>]

Thomas Fjellstrom wrote:
> On July 11, 2008, Elias Pschernig wrote:
> > On Fri, 2008-07-11 at 04:28 -0600, Thomas Fjellstrom wrote:
> > > Its mainly used to make sure all symbols are in the same place and order
> > > they were in previous and future dlls. dll's are indexed by a simple
> > > integer under the hood, so if a symbol changes places, its not going to
> > > be found in the right spot. Or at least that's how I understood it. (all
> > > new symbols are appended to the end, none are removed, and none move)
> >
> > I think we switch to symbol lookup - I guess it was a slight performance
> > advantage 10 years ago, but I doubt it can make a measurable difference
> > today. Of course, assuming DLL linking/loading can be made to do symbol
> > lookup, and someone can figure out how to do it..
> >
> > Compatibility with existing .exes expecting to load the .dll with symbol
> > lookup is no problem with 4.9 - so now would be the perfect time to
> > change. But well, I'm assuming a lot of how things works, I have no idea
> > about DLLs. Google suggests though that the lookup-by-index we are
> > apparently using is only an optional feature.
>
> I wasn't aware that Win32 PE-COFF DLLs were capable of anything more complex 
> than lookup by index.

If anyone's interested:
http://en.wikipedia.org/wiki/Dynamic-link_library#Symbol_resolution_and_binding

In addition to what it says there, all symbols are resolved when the dll 
is loaded, so importing by ordinal (which allegro 4.2 does) will only 
improve the startup time, not general performance.  And before starting 
the binary search, the hint index contained in the exe will be tried. 
The hint is an index into the dll's export name table.  If the hint was 
correct, no binary search is needed.  But this requires that the dll's 
export name table matches the one in the import libary that the exe was 
linked with.  So at least some of the hints will be wrong if using a dll 
containing more symbols, etc.  Probably no big deal, as this is what 
happens with many of the dll's that are loaded by the exe anyway.