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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Keith Marshall-3
-----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
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Earnie Boyd
On 11/10/2016 8:29 PM, Keith Marshall wrote:
>
> 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.
>

My vote is for this one.  The current MSDN documentation states Win2K
for the minimum supported use. It also states that Winuser.h should be
included by including Windows.h. Also from[1] we have the following
quote which suggests we just remove winable.h:

winable.h was moved from the Windows SDK in July 2005 because
functionality was duplicated in winuser.h. It was determined at that
time that efforts would be better spent on updating winuser.h to Windows
Vista-level functionality rather than updating the functionality of both
files.

[1]https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/ee57cc38-1dc6-4a5f-b7e3-1f16dbd91b83/missing-winableh?forum=windowssdk

--
Earnie

------------------------------------------------------------------------------
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
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Keith Marshall-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/11/16 16:43, Earnie wrote:
> On 11/10/2016 8:29 PM, Keith Marshall wrote:
>> 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.
>
> My vote is for this one.

Okay; from a maintenance perspective, it makes little difference to me
whether a small subset of the content remains in <winable.h>, (factored
out of <winuser.h>, and replaced by a "#include <winable.h> therein), or
the factoring goes the other way, (leaving <winable.h> as an empty stub,
which does no more than emit an "obsolete header" warning, followed by a
"#include <winuser.h>").  My only reservation about the latter course is
that it leaves legacy code, which requires only the lean 100 odd lines
of <winable.h>, now requiring the ~5000 line bloat of <winuser.h>, but
maybe that isn't so much of a concern ... especially if such code may
also require <winuser.h> anyway, (perhaps via <windows.h>).

> The current MSDN documentation states Win2K for the minimum
> supported use.

I know it does, but do you trust it?  Microsoft tend to be notoriously
untruthful about minimum support levels; for example, this:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa364418%28v=vs.85%29.aspx

claims WinXP as minimum supported version for FindFirstFile() ... an API
which has been exported, semantically unchanged, (at least in respect of
its so-called ANSI variant), by kernel32.dll, since Win95!

> It also states that Winuser.h should be included by including
> Windows.h.

Again, I know that.  It says the same about every header which ends up
being included (indirectly) by <windows.h>, yet we still see code which
eschews that advice.  Are you suggesting that we should emit annoying
warnings, for any direct use of such headers?  It would be easy to do,
but I doubt it would win us any popularity awards.

> Also from[1] we have the following quote which suggests we just
> remove winable.h: [...quote snipped...]

I won't do that ... it is extremely unfriendly to legacy code.  Sure,
Microsoft did it, precipitating a plethora of requests to reinstate it,
or advise whence it may be obtained, because so much legacy code wants
to include it.  By all means, deprecate it, but don't just discard it;
we can do legacy sooooooo... much better than Microsoft!

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

iQIcBAEBAgAGBQJYKNhnAAoJEMCtNsY0flo/HGsP/1Ea/E1PLp5EEzyzAr29YXVP
Pn59snudb3jFInJLxLU5cR0STwmTmRbxIUW8Ue3zia9sQuzVWUdmJscth1JDvZxW
stBIM7Wk7/Oo/Ux/isr8OZH0FLx+qfdxIxwEUVT2Seg3IpOJdzpzzQFBOx47SjvD
7zOhjHgfvG0TgMEBcrfutKzH9/0pqdkOQs1WZcPuHyyhHgitWl97X63loPx8+gtZ
hketGeb7SN97sPDbP1l9mf13DFLA/A3cb8ExAT22o+/zQwHoi72VCH3R/vQ1IJsC
zO6kWY6PKYURPpF7HJTPDfFzci/j3yyHhPhTWuiCL9dIOKOQzBnaiB9B+R3Wbsvi
iDgVjLJW7BW0YZnW5S9lpnjpvSbJHVqPiqCcFs7pffuLlFTpUrlb3lskFJy2Ldpq
SawkwyrF2ESEyDXRkDwuiLGNqTigLAZtS4tCnXkpCBVYOf+xjxhXJ8ZZWPSbLoDK
/mdKgHD0jZxXVmr4vXpSOz9aWMnnCnew9AIo2iS7sZSXg/O0YvibnWIE8A/yz8AT
SlV81ACZv5EKBr941zDjpNfC66mQjg06+QB5wjWrcTsq2CnbpP6TXA/lvzCE5ckI
vL2Jlj2opBQHt2KMJFztJrGiZca3RgiGCIww1x9cASPs4pHgAXlmNI6HH4kp/tnt
XILipzjS3z8W3zELNQJ4
=EF5I
-----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
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Keith Marshall-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 13/11/16 21:17, Keith Marshall wrote:
> Okay; from a maintenance perspective, it makes little difference to
> me whether a small subset of the content remains in <winable.h>,
> (factored out of <winuser.h>, and replaced by a "#include
> <winable.h> therein), or the factoring goes the other way, (leaving
> <winable.h> as an empty stub, which does no more than emit an
> "obsolete header" warning, followed by a "#include <winuser.h>").

Further inspection of <winuser.h> reveals three other headers containing
duplicate code ... <winable.h>, <dbt.h>, and <pbt.h>.  Of these, I have
refactored <dbt.h>, such that <winuser.h> may now include it to retrieve
just the formerly duplicated content.

<winable.h> and <pbt.h> both appear to have been declared "obsolete", by
Microsoft, (indeed, MSDN doesn't seem to mention <pbt.h> at all), so I
propose to provide an "obsolete.h.in" template, and let make translate
that into a pair of stubs, to emit a warning, then include <winuser.h>.

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

iQIcBAEBAgAGBQJYNBckAAoJEMCtNsY0flo/j0sQAIh6D19OYi+Q4wek6OE+5K8V
ABb5I6jk8QSvYfoXvsol2exhVuVJtS6FtjhvePsVg76Um7jsjuUDYC3GpJp46alJ
TUne3i6EJ6bt0hWTgXEXNmpKF+MFfi5WC6Iua64tZhOxYhed7bxbfHlZ0swV+P/9
VgAJjvvF3E7I1Sy0xVnaziJn/MG1ixSFqYSCylX0LqINmek+TF5qmpgNNS6jY6IY
qWY+8uiayW8bs9ScxJ/yrm3y1gReJjFkN0qcq3WOphd5reWk7TaQEJwa/xgNOEvs
UTIMweW6aTc1625F2myq/XJuffkBJMs0LyCI8mdo3g2YnC6cWB6tVfKGky5LlRXZ
OeM3126CxusmhZyIDkauxEUGnzQJFtszYt3qfyYiyKO6WBGHopG3Nz+JIiI2r+62
p8tRI8oAxkikYP92MNeWKecrFaeSJ4bU/G+XLvVff8f322e1Gi8+PnFbrBBAK627
OMTcfStUxwSodCl7aR0yQR3icFxwkQuy++UYGmMtTygwfHmI/dO1dcsIqv9ZyWoe
YJHvNG+HF9amMoPdHuS528VufGOdmrbJ5tZmG3cypCzI5vyWllA2sKhCRFb+5TEN
mau1zDvPYTO7lVsUqwwRzUoWO+c5ZbQ9B8PzoaP+EjYpFr5dWcBjrzm4TXh+M6Np
937Dz+YCtQoF8hKjpsnI
=hXej
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------

_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

obsolete.h.in (2K) Download Attachment
obsolete.h.mk (878 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Earnie Boyd


On 11/22/2016 5:00 AM, Keith Marshall wrote:

> On 13/11/16 21:17, Keith Marshall wrote:
>> Okay; from a maintenance perspective, it makes little difference to
>> me whether a small subset of the content remains in <winable.h>,
>> (factored out of <winuser.h>, and replaced by a "#include
>> <winable.h> therein), or the factoring goes the other way, (leaving
>> <winable.h> as an empty stub, which does no more than emit an
>> "obsolete header" warning, followed by a "#include <winuser.h>").
>
> Further inspection of <winuser.h> reveals three other headers containing
> duplicate code ... <winable.h>, <dbt.h>, and <pbt.h>.  Of these, I have
> refactored <dbt.h>, such that <winuser.h> may now include it to retrieve
> just the formerly duplicated content.
>
> <winable.h> and <pbt.h> both appear to have been declared "obsolete", by
> Microsoft, (indeed, MSDN doesn't seem to mention <pbt.h> at all), so I
> propose to provide an "obsolete.h.in" template, and let make translate
> that into a pair of stubs, to emit a warning, then include <winuser.h>.
>

Sounds like the correct way to do this to me.

--
Earnie

------------------------------------------------------------------------------
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Loading...