"Dimitrie O. Paun" dpaun@rogers.com 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 header.