Re: [AD] ALLEGRO_NO_ASM broken completely on windows

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

On Sunday 14 October 2007 16:36, Milan Mimica wrote:
> I also found that non-ASM alleg42.dll is not compatible with ASM 
> alleg42.dll. The cause is the same: _putpixel is inlined and it's 
> definition depends on ALLEGRO_NO_ASM. In ASM version it uses a custom 
> calling convention, which breaks if combined with a normal one.

That's right. To the best of my knowledge, known binary incompatibility 
between the ASM and non-ASM version of the library was always a reason not 
to remove ASM support in a stable series.
I don't think I posted about this when the change was proposed for 4.2.2, I 
remember reading at the time that someone tested wether it worked and 
reporting that it worked properly. I'm curious to know what was missed in 
that test, just so we know what to look out for in the future.

That, or we should just not make changes like that again in supposed 
bug-fix releases in the future.

> There is only one reasonable thing to do: Rename the lib and the DLL if 
> compiled without ASM. Add the _c prefix or something.

Yes. This should probably have been done as a precaution.
For post-4.2 releases where ABI compatibility with 4.2.0 is void anyway, 
the C version can be the default or the ASM version completely removed.

> Is there going to be a rerelease? 4.2.2.1?

I don't like adding another version number to the end just for this.
In my view, this qualifies as a (serious) bug, so just bump the version 
number up to 4.2.3 (which would include any other bugfixes or 
documentation updates) and advice everyone to upgrade, or at least not 
release binaries compiled against 4.2.2 (but most binaries should be 
released compiled against 4.2.0 anyway).

Evert