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

Dimitrie O. Paun dpaun at
Mon Aug 25 23:58:01 CDT 2003

On August 26, 2003 12:35 am, Alexandre Julliard wrote:
> 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.

Well, first off, it's not clear that we provide any worthwhile extensions
to warant all the complications. In fact, due to the scattered nature of
said extensions, I don't even have a good idea of what extensions we have
and if they are worthwhile. BTW, any user (that is app developer) will be
in the same situation. Second, I don't think a simple include qualifies to
the rank of magic incantation -- it's the least obtrusive way of letting
people know they are using something non-standard. Thirdly, the backwards
compatibility you mention is a big can of worm, and I think it's a bit of
a red herring -- binary compatibility will most likely be busted anyway,
what are the chances we're going to pick the same binary value as MS?

I have to admit I play the devil's advocate role in this debate. From my
POV the biggest benefit is that we'll have a _simple_ rule for our headers:
keep them as close as possible to the MS' one. Not a simple task, and
experience has shown that the simple the rule/principle, the easier to
understand and implement. We've learned the hard way many atimes that playing
smart does not pay. There are places where it's worth doing, but it's far
from clear that we have such a compelling reason to break this principle
in this case.


More information about the wine-devel mailing list