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

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