PATCH - winnt.h move non-standard language IDs to wine/port.h

[Dimitrie O. Paun]

On August 22, 2003 12:12 pm, Alexandre Julliard wrote:
> No, actually the more I think about it the less I like it. The problem
> with that approach is that if an app uses wine/extensions.h, not only
> you can't it build under Windows without somehow obtaining the Wine
> header first, but once you compile it it will use all sorts of
> extensions that won't work under Windows.
>
> IMO it's better to leave the extensions in the normal headers and make
> the code deal with missing definitions in case you are building under
> Windows. So instead of importing the definition of say LANG_GAELIC
> from some Wine header, you wrap that code in a #ifdef LANG_GAELIC, and
> then the app can build and run correctly both on Windows and Wine. We
> could also wrap the extensions with #ifndef WINE_NO_EXTENSIONS in our
> headers so that you can define that symbol when building under Wine to
> make sure your code is portable.

[Sorry for the late reply, it got stuck somewhere in my reply queue :)]

I agree with this, but the two issues are completely orthogonal.
One deals with how we organize extensions, one on how to use them.
I am 100% with you that a portable implementation is better -- it
is in fact the same pattern adopted by 'configure'. However, this
says nothing about where to place such extensions. In fact, I would
argue that placing such extension in explicitly designated headers
will actually help Winelib developers. For one, it will make it a
lot more explicit when they will have to use the portable pattern
you were advocating. Otherwise, if development happens user Winelib,
this can be easily missed. Moreover, it allows projects to easily
enforce (by giving them the means to trivially check were Wine
extensions are being used) certain policies about when/where/how
Wine extensions are acceptable.

For portability, people will have to simply do:
#ifdef __WINE__
#include <wine/extensions.h>
#endif

just like they do with HAVE_XXX_H tests. It fits in rather well, no?

-- 
Dimi.