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

Alexandre Julliard julliard at
Tue Aug 26 12:23:41 CDT 2003

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

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

For things we invent ourselves the chances are pretty small, but most
extensions are for undocumented stuff, where the values/function
names/etc. are defined by MS already, only they are not part of the
normal headers; winternl.h is a good example of that.

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

The problem is that the "as close as possible" rule also implies not
creating new headers; so either way we are breaking the rule, and IMO
it's better to keep a few extra definitions in the normal headers,
close to where they belong (for instance the extra LANG_* constants
next to the other LANG_ stuff) than splitting them to a separate

Alexandre Julliard
julliard at

More information about the wine-devel mailing list