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

[Alexandre Julliard]

"Dimitrie O. Paun" <dpaun at rogers.com> writes:

> 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?

I don't agree that the issues are orthogonal, I think that how we
organize the extensions very much depends on how we want people to use
them. Also I think your approach does not encourage the right pattern,
it actually suggests using #ifdef __WINE__ everywhere.

I think the main question is whether or not we want to encourage use
of the extensions. If we want to encourage it, then they should be in
the default headers; if you need some magic incantation to make them
available nobody will bother. Now, if we'd rather encourage portable
code that doesn't use extensions, then IMO we shouldn't export them at
all, and let people who really want them go to the trouble of copying
them from Wine internal headers.

There's also the issue of backwards compatibility; many of the
extensions are for things that aren't documented by Microsoft at this
point, but that may become documented one day. If that happens and the
extension is already in the standard headers then it's completely
transparent; but if it's in wine/extensions.h then we'll have trouble
keeping everything in sync.

-- 
Alexandre Julliard
julliard at winehq.com