[AD] Windows binary compatibility

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

I've attached a patch that is a test-bed for DLL binary compatibility under
Windows. So far we have been wondering if the DLL loader links by symbol
index number or by symbol string.

The patch removes the Window specific internal symbols from the export file.
It doesn't break anything (even AllegroGL :-) but obviously changes the
symbol index numbers: for example, play_sample() is initially #0x01fa and
get shifted to #0x01da.

Here's the procedure for the test:
- make sure some test programs are already compiled and working (for example
the dibsound test from test/win),
- go to the lib/mingw32 (or msvc for MSVC users) and delete all393x.dll,
then rename allegro.def into allegro.def.orig
- apply the patch (can be done by hand)
- run 'fixdll.bat', a new allegro.def file will be generated (verify that
the new allegro.def is smaller than the original allegro.def.orig, about 2k)
- rebuild the dll with 'make lib'
- *very* important, overwrite the old dll with the new one in the Windows
system directory
- run the dibsound test

On my box (Windows 95 OSR2), dibsound still loads and runs. So it seems that
the DLL loader actually links by symbol string.
Although I don't see why this could be compiler-dependent, we have to be
sure. I used Mingw32, could any MSVC user do the test ?

If everything went fine, it would be far easier to maintain backward binary
compatibility under Windows and I could throw away my proposal on internals
(which has at least one strong opponent :-).

--
Eric Botcazou
ebotcazou@xxxxxxxxxx

Attachment: export2b.diff
Description: Binary data