Re: [AD] font vtable patch

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


On Thu, Apr 26, 2001 at 11:51:16PM +0200, Eric Botcazou wrote:
> > as an added bonus we can remove the old-style export definition files
> > for all win32 platforms. i'm convinced this can be done without breaking
> > binary compatibility between dlls created with msvc and mingw.
> 
> As George said it, the export definition file might be there specifically to
> ensure the compatibility between the 4 Windows compilers. But I'm not a
> specialist of the win32 dynamic linking scheme.

I just checked with Shawn, and he's a bit hazy on it but thinks
that MSVC programs link to DLLs purely by symbol index number.
So if two DLLs don't have the same enumeration, MSVC executables
linked against one will not be able to run with the other.
Specifically, if MSVC-built DLLs have different numberings to
Mingw32-built DLLs, they will not be binary-compatible from the
point of view of MSVC executables.  This may affect other
compilers too.  (IIRC, RSXNTDJ was like this last time I used
it.)

As I said, he's a bit hazy on it -- maybe there isn't a problem.
But I think you should make a test first -- using export
definition files, create two DLLs with the same symbols, and see
whether programs linked to the import library of one DLL can
run, linking at runtime to the other DLL.  This needs to be
tested on MSVC as well as Mingw32 though, and if it works on
both then it also needs to be tested on the less significant
Windows compilers people are using.  The best test would be a
DLL with two identically-prototyped functions numbered the
opposite way around in one export file to the other.  One can
print "OK", the other can print "not OK", and the test program
would call only the one which prints "OK".  On failing systems,
it would instead print "not OK", by calling the wrong function.

George



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