Re: Remove support for old names in runtime

Hans Leidekker <hans-p/[email protected]> Sun, 21 Mar 2004 23:26:29 -0500
Newsgroups gmane.comp.gnu.mingw.patches
Organization VU Amsterdam - Dienst IT
Message-ID <[email protected]>
On Sunday 21 March 2004 14:14, Filip Navara wrote:

> >Those aren't Win32 projects are they? Who is building them
> >on MinGW?
>
> Lot of people including Danny Smith himself. You have little chance to
> force this to be commited. Is the patch needed for compiling Wine MSVCRT
> on MinGW or is it for another reason?

I know I can't force it, but it certainly is strange that
you keep very old, limited, *Unix* compatibility in there that
breaks compatibility with Win32 projects: you either have to change
your build to do -D_NO_OLDNAMES on MinGW or you have to change
anything that happens to conflict with the old names.

Compatibility is more important than being selfhosted if you ask
me. Calling the flag _OLDNAMES and not defining old names by default
would make more sense to me. Then the selfhosting build would need
to specify -D_OLDNAMES and other sources would not be affected.

We could work around the broken MinGW headers too. But take
fpclass() for example, which exists on other Unix platforms. Wine
already checks for it and expects it to return FP_NAN, FP_SNAN, ... 
constants. MinGW has fpclass() as an old name for _fpclass() that
has it's own set of constants. One solution would be to add the
constants to MinGW (I saw that lcc has them too), but they don't
really belong there since MSVC doesn't have them either. Another
would be to extend the configure check in Wine to check for missing
constants and define them ourselves.

  -Hans


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click