RFC: Why these <winuser.h> vs. <winable.h> conflicts?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Guys,

This bug report:
https://sourceforge.net/p/mingw/bugs/2317/ has set the alarm bells
ringing; I'm utterly flabbergasted by the extent of the conflicts,
(apparently introduced by Dimitri Papadopoulos in 2003, and judging
from his ChangeLog entries, with deliberate intent), between this
pair of header files.  Here's just one example:

- - in <winuser.h> I see:
  #if (_WIN32_WINNT >= 0x0403)
  #define INPUT_MOUSE 0x00000000
  #define INPUT_KEYBOARD 0x00000001
  #define INPUT_HARDWARE 0x00000002
  #endif /* (_WIN32_WINNT >= 0x0403) */

- - whereas, in <winable.h> I see:
  #if (_WIN32_WINNT < 0x0403)
  ...
  #define INPUT_MOUSE 0x00000000
  #define INPUT_KEYBOARD 0x00000001
  #define INPUT_HARDWARE 0x00000002
  #endif /* (_WIN32_WINNT < 0x0403) */

Note the conflicting sense of the feature test macros, between the
two samples; this is just so wrong that it beggars belief!  Worse
still, (and this is just one of many similar conflicts), ChangeLog
documents this as intentional, (on consecutive lines within just
one change-set entry):

  * include/winuser.h [_WIN32_WINNT >= 0x0403] (INPUT_MOUSE,
  INPUT_KEYBOARD, INPUT_HARDWARE): Guard constants...

  * include/winable.h [_WIN32_WINNT < 0x0403] (INPUT_MOUSE,
  INPUT_KEYBOARD, INPUT_HARDWARE): ...and duplicate.

I don't know why Dimitri may have been motivated to introduce these
absurd conflicts, (if indeed they were intentional, as they appear
to have been).  I am well aware that Microsoft declared <winable.h>
to be obsolete, years ago, with <winuser.h> subsuming it; I can only
imagine that Dimitri was somehow trying to reflect that obsolescence,
such that the declarations and definitions would be visible across
all Windows versions, by inclusion of the header appropriate to each,
while avoiding possible redefinition errors, in the event that both
are included by a single translation unit.  However, if that is the
case, well ... a more disgusting example of appalling software
engineering is hard to contemplate.

So, how do we set about fixing it?  On the one hand, duplicating
definitions in two independent header files is dreadful engineering
to begin with; they should be implemented in one only, and included
by the other, as may be required.  On the other hand, if the APIs
in question are truly available in all Windows versions, (which
may not be the case), then the feature tests are bogus anyway.

I can envision two possible stratagems for tackling this:

1) Make <winable.h> obsolete in MinGW, while retaining a stub which
emits an appropriate warning, and then includes <winuser.h> instead.

2) Keep all relevant content within <winable.h>; factor it out of
<winuser.h>, and have <winuser.h> include <winable.h> to retain the
effect of the removed definitions.  Again, have <winable.h> emit a
warning, to the effect that it is obsolete, but suppress this when
inclusion is via <winuser.h>.

Each of these has its respective advantages: (1) is closer to the
Microsoft stratagem, (while not leaving users in the lurch, if they
try to compile legacy code which expects <winable.h>).  It suffers
from a degree of namespace pollution, by pulling in the much more
extensive content of <winuser.h>, where the leaner <winable.h> may
be sufficient; (2) avoids such pollution, without incurring loss of
<winuser.h> capability, but it does differ from Microsoft's current
header structuring conventions.

I'm undecided how to progress this.  I think I have a slight leaning
toward option (2), but am amenable to persuasion otherwise ... any
thoughts?

In either case, I do note a few definitions in <winable.h> which should
have been propagated to <winuser.h>, but seem to have been omitted; we
should fix that.

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJYJR7nAAoJEMCtNsY0flo/jvwQAI9iE/kFf48BuvWj2XKh4frj
lA5vZQFbGqZQ5SV5ZmGzPCCCFfmwNE9qDg7Xzq+sb9ZOaEIg3LU9RXnfQ7Lt6u2Z
E024WVILoOtzgfI+TvRaK+FqgV5axUw3mWKxwHn3lm08KUSYnotyzod7LW1goGu+
tdawMUWqSNHe7Iyxyn2e8oHhJjsF7Je6/vxHVGYAb9L31Rbj7NWeyDPTGK/hepzg
DX4bZZFed12vdYXs/zVhMykwS5LZDHsnbOQGHhCQ/mmB3eWQWgK8gJp8dne62QJE
cwW0raG5jzaCS9anrJODa4N/T9t2ZslQvX5fBHRmCGcvWqKczkEAsdAJmEotIQfP
pVfJbVQJj0ZtxXFJmkp0ftddPF6qCDz7x5KiknzbH3/tquCQAwB4Ho+o6IDZFaAr
dAJMXJrSKxzg0v8Z3O94lpemDJweUpVema7smYcyUuzuvygdF4h+F/GDI4nMc/Pi
0tB0vW8IxRAdvQK548S1iVU59E3GVbr8bMycJO0OCoSr2PzUlJS8kqWmLYBYT6VR
H1brir01zHW3sdRK+3D1p90ys+RZMh5MOw962RiG1AtfXJlVcLCjeUKGw1Nzd9Gd
OVEl54e58w8hqFtCi9Tqr2BXK7TROoaw1pk8zzE6lYsC+YtuwfEZxwrRYzkxDCLw
11BnPNTHJ/CB4Aspqw2K
=CM1f
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi