mingw-dvlpr — MinGW developers list.

[MinGW-dvlpr] Problem with configure when trying to build gcc 5.3

[David G. <jdg...@ho...>]

I got mingw-pkg installed and started working on gcc 5.3.0

I immediately found a problem when mingw-pkg did a configure.
It did not configure to build the Ada compiler. I found nothing obvious
that would explain this in config.log, so I went to the MinGW installer
to see if I had anything missing and found that the mingw-gnat dll is 
still at version 4.8.1-4 and the repository version number is
also 4.8.1-4.

I have only built one Ada program since I upgraded to gcc 5.3.0,
and it compiles and runs with no problems, but this does look a bit
odd, and I suspect that the gcc configure may be  more demanding 
about runtime library compatibility than my little program is.

There was also a 4.8.1-4 version number on the 
mingw32-gcc-ada info file.

Re: [MinGW-dvlpr] Using mingw-pkg to build gcc 5.3.0

[Keith M. <kei...@us...>]

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

On 29/12/16 00:03, David Gressett wrote:
>> Conventionally; assuming you unpacked to $HOME/mingw-pkg-0.1.0:
>>
>>   $ mkdir $HOME/mingw-pkg-0.1.0/build
>>   $ cd $HOME/mingw-pkg-0.1.0/build
>>   $ ../configure && make && make install
> 
> No joy - I get
> sh: ../configure: No such file or directory

So, you need to run autoconf, to generate it from configure.ac:

  $ cd $HOME/mingw-pkg-0.1.0
  $ autoconf

Then you can cd to the build subdirectory, and the conventional
build sequence should run, as above.  (You may also wish to delete
the entire autom4te.cache subdirectory, created by autoconf; it is
of no further use to you).

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

iQIcBAEBAgAGBQJYZR98AAoJEMCtNsY0flo/iCIQAJOXy5u+PJFDLqWRcdsN1iqQ
slzU9CLsFc5YyT0AXjA2irc99fNvjGsDLLmlOcH3lK+kuOczZi/dCFbTafey4Z/1
/qNC9ZE2KsdVULNXd/6GnLAVy8rg5n9uB8Vo4Izm4+e+jkGljcfI/kJAdxRSJaZW
u5bFzK4PCZ0bfMwZ8OD4zwNvqE1VBjnOJ3vKq1u6xLIvENhk8EcM568Do958vC2p
HLz24KuAscOxb6N18fGVBN+fDwPxdKxwAuecpc8gIlr28K3rpiXHZwonuJAmP39f
Q/ng0pqJHXtwvJM5fTfzB/3Ck36pljYXFgQlabDN3zRCw1ypXtKSBIFKlEvlifpk
V8jNPReXhg7d/qFv3B3ZNVw4fGBIKVX1aEv0P736Q/oTvCqgZn2LlLC0aXbRAqQ9
3hB1iZsj6vNAJbqTac7oRY0z1LbBwGlU9lISlgl7R3B+CAr3ZwFU5n2eSxQGsulY
8LB7PZpSbKs+yb/Wm5D4vIXt5bZise2rMhehpV7H+xU39MsGnMXCNurXARtEgqxu
9FtZyIA2qBHFlWZxvoTdIbSutEQfK120MTtuMWa82pXnHsS36q04EP4AoFGDeKgV
gdO4dIAY23A3Uvtg5RWzszwYRixA5DN+sEZ1YjQseFhBcnrGTimN9gvmsjmhuVP+
RTEAqN9jZYy7W2vAiPlk
=ccUL
-----END PGP SIGNATURE-----

Re: [MinGW-dvlpr] Using mingw-pkg to build gcc 5.3.0

[David G. <jdg...@ho...>]

>On 28/12/16 16:38, David Gressett wrote:
>> Now I do have problems. How do I install and configure mingw-pkg
>> so that I can use it?

>Conventionally; assuming you unpacked to $HOME/mingw-pkg-0.1.0:

  >$ mkdir $HOME/mingw-pkg-0.1.0/build
  >$ cd $HOME/mingw-pkg-0.1.0/build
  >$ ../configure && make && make install

No joy - I get
sh: ../configure: No such file or directory

The mingw-pkg-0.1.0 directory contains three files:
Makefile.in
configure.ac
install-sh

and two directories
build (which I just created)
src

The contents of src and its subdirectories seems to be entirely
shell scripts.

Re: [MinGW-dvlpr] Using mingw-pkg to build gcc 5.3.0

[Keith M. <kei...@us...>]

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

On 28/12/16 16:38, David Gressett wrote:
> Now I do have problems. How do I install and configure mingw-pkg 
> so that I can use it?

Conventionally; assuming you unpacked to $HOME/mingw-pkg-0.1.0:

  $ mkdir $HOME/mingw-pkg-0.1.0/build
  $ cd $HOME/mingw-pkg-0.1.0/build
  $ ../configure && make && make install

will set it up in /usr/local; if you want it elsewhere, e.g. /mingw,
add ' --prefix=/mingw' to the configure command, (or alternatively,
append ' prefix=/mingw' to the 'make install' command.

You may then wish to customize it, by creating a $HOME/.mingw-pkgrc
configuration file; e.g. mine (for cross-compiling) is attached.

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

iQIcBAEBAgAGBQJYZEhmAAoJEMCtNsY0flo/nakQAMW/hl1EqWhI8JM99dRRr+yx
f2FBkfSwhnSFwkKfMuSSFgino6Gu8ktOGAbZw3NSfXe1TuBT8klvGBcabxORhHJ/
ytDLbVMkC7iaXrasoqwJ7A/cFLFzFTJo6wVouPHN7rSb7STyGwVpUTxaTrcG16Bp
KDg0CKFDQ/3gBsc+EUUFDyoOWibyX3JvuGBzn8M2QqrjhN3Ff3zruWZ/gt/kzauw
0u+UEoTAO6+YRAsbV5D9j3d6IZn+Q6JtI1Q9e/8kqw2ENTczFIv2a6dC3kX6ZGis
rY0hbdFuU5PO5XzuvhWteAcROFdvwQXaDpSu9KaalQCjHEZwI5ld+/YvOw/lRF2A
haoG5F+ilaiXoj29CFWWybHAPirZfk//+iIFLwPRS70Adn2sL3DlzXrR4ekdL+6X
DpCG7F4uaNhXctTlCRpqzmwvTNcedMRTOC5eZjZhtXepJajlvTEovrSALhkUz+xt
BGUdL9I6Wbs69h1jZC51hYHG7fh9WpW1HBt6dTjsAK30mA+xQZhosRczmHYPEqkk
e2E2h1RDAWM0PKpbMWSZLccJBJoIOycM55l4tmV6GUR62XWhXRsCWa6XT5nbSHfX
yK523cceJeo+m25BWf0sHuVstZbPB+Zog/8q32L4v9LG/QwuKFz2hHJ0d7Pw6rCo
H121hdiYYV11lDSJFKyj
=R64M
-----END PGP SIGNATURE-----

[MinGW-dvlpr] Using mingw-pkg to build gcc 5.3.0

[David G. <jdg...@ho...>]

I have set up the downloaded gcc 5.3.0 with src and adjacent build 
directories, with gmp, mpfr, and mpc set up in the appropriate 
places. There are no problems here, this is all the same as I did for 
builds of previous releases.

I have used git to get  mingw-pkg from
https://sourceforge.net/u/keithmarshall/mingw-pkg/ci/master/tree/

Now I do have problems. How do I install and configure mingw-pkg 
so that  I can use it?

I found no useful information at www.mingw.org - the web site has
not been updated.

Re: [MinGW-dvlpr] Windows CE support in MinGW.org headers

[Earnie <ea...@us...>]

On 12/19/2016 4:12 PM, Keith Marshall wrote:
> Do we really want to keep this?  Right now, I see a dozen WinCE
> specific references, distributed among five W32API header files.
> Not only does this barely scratch the surface of what would need
> to change, to properly support WinCE, but AFAICT, much of it is
> wrong anyway.
> 
> Frankly, this is a maintenance burden I would prefer not to carry.
> Unless someone else is prepared to take this on, I propose ripping
> out all of the existing WinCE specific references.  FWIW, I have
> already done this for <winuser.h> and <wingdi.h>, while retaining
> the attached patch to reinstate them; (the FIXMEs are my additions,
> indicating what I perceive to be wrong with the present references,
> and how I believe they should be corrected).


Hard for me to say.  I doubt anyone using MinGW for WinCE anyway.  Maybe
tag the repository so someone looking might have a chance to find what
was included to begin with.

-- 
Earnie

[MinGW-dvlpr] Windows CE support in MinGW.org headers

[Keith M. <kei...@us...>]

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

Do we really want to keep this?  Right now, I see a dozen WinCE
specific references, distributed among five W32API header files.
Not only does this barely scratch the surface of what would need
to change, to properly support WinCE, but AFAICT, much of it is
wrong anyway.

Frankly, this is a maintenance burden I would prefer not to carry.
Unless someone else is prepared to take this on, I propose ripping
out all of the existing WinCE specific references.  FWIW, I have
already done this for <winuser.h> and <wingdi.h>, while retaining
the attached patch to reinstate them; (the FIXMEs are my additions,
indicating what I perceive to be wrong with the present references,
and how I believe they should be corrected).

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

iQIcBAEBAgAGBQJYWE1LAAoJEMCtNsY0flo/RU8QAMKorjv+WJbgaVZcxxAhycsE
Y3P84EbYZcMSP4IJZV3LhcCtwVaLnATmCB+d0pgr7anMBGTV7NUfqI+8syXJBrkk
zWXlhSpBS7Vk4+6eqyf0UwDmHT2FAXnoE8Pcm0pEmUGh9a9w0mfNpGn4Mw98E3IB
2QOu9D4Yd5mrcid8VUDpFeTEuW3ScAid6X6e6Tofn1zWf9LQnDo4xXtjsgineq+W
/YUlGe+yB7mJBKhOjS63Z9uP5SK4ZO2G/JMNVZ98AHq/EGo28WSJXofmlPC4XEgJ
Qvsy9PAmtmnO8K4BB3DjgJ/kYegcmH+iYjYBlDL/RWjjDN1XOlNdGgHFPJTuSXEz
ABwoB8Kbeerz9+YYRHS0xBKvFR1TmFUWLjOgLpn490iggVbB+GHc3+kllQCYS6UL
9OAmLr5KQPV3sAOCSGCGqekp2OyBl1eXJoosKmNHwXXYor6RJO8CFQI/8kcAR9d9
vDoblMp18hyac55IKz7iIX3RRcUW5qi4SUd0w8jIsvwrqIuMIJnNf8h0sk4y/b3b
htEOQIWB6ECoLef3uBvYhpQy0PjDgBmurLskl+r9vKvVFdzyDCzAtZBY37G5f31U
N0/y0w34/JLQJIr+ed2iMJ1kJWVt1Bzze3ZPqI8Tet07sAWpx0Y7JG6nST+aNoUM
PTVIJchBHnKDTiBaS8jv
=R2cS
-----END PGP SIGNATURE-----

Re: [MinGW-dvlpr] RFC: Make w32api headers (effectively) self-contained

[Earnie <ea...@us...>]

On 12/12/2016 5:52 PM, Keith Marshall wrote:
> 
> I'd like to start adding #include statements, as required, to make each
> system header (effectively) self contained, and implement unit tests to
> verify them.  Any reasons why I shouldn't do this?

It's a horrid mess, feel free to simplify, it can only make maintenance
easier.

-- 
Earnie

[MinGW-dvlpr] RFC: Make w32api headers (effectively) self-contained

[Keith M. <kei...@us...>]

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

Guys,

I've started playing with autotest, to implement unit tests for mingwrt
and w32api; (so far, I've implemented several tests for mingwrt, among
them a test group to verify self-containment of system headers).  This
is fine for mingwrt, but right now, if I invoke (say):

  $ echo '#include <winuser.h>' | mingw32-gcc -c -xc - -o /dev/null

I see a swathe of error messages, relating to undefined (custom) data
types; (winuser.h has inherent prerequisite dependencies on windef.h,
stdarg.h, and by default wingdi.h).  I don't know how Microsoft handle
this, but IMO it is just dreadfully poor software engineering; users
should not need to be concerned by such interdependencies among system
headers.

I'd like to start adding #include statements, as required, to make each
system header (effectively) self contained, and implement unit tests to
verify them.  Any reasons why I shouldn't do this?

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

iQIcBAEBAgAGBQJYTypIAAoJEMCtNsY0flo/a1gQAKYnRpZs0swYs84/mOXbNXWI
wogHlm6Cm6MdW4/k3Nx7mvrBCCFuS6pJrluL/qKKF4hdquUpFPjtwnrD6DSaycc1
C4TL7Dsm+nibzYa989y185BZK/JwEkChhoJhnxFG8woYLt41jVV2nSADgdJTgnv4
zvJKHjXbO7Tcp3BZAkhAi4jCwzxf7BSaTBUWhoQh6gL/Lv1M6WeooQID0oDIJxwG
dr8bt+0T8OakgR+SHkzkfnjj4ki19DqtHIOi+AtQ6DNDzlmyel74Q8wWSv2XtYdm
PFas3DjeE5yTgGvgpd+i/CGmfu9NPlTqmB7yYZ7LqY/1A7GqFtaFkutgFxYzYqTN
H66OA92QxYdHjneqVXDpRB3eoZMtWWDSYrmeMti+LGb2RdXloVZ4iFd23yXuEo/h
v93dagGGiPwPSe47/gxKovudXiLJzucWxqSQ5OEkxrfII9lgDcnAzw54wbRi4Wi3
+6GnacSC+53M4Xq7ccCw4wkMpzit3zRvh1FWw/ivu67Z0N5TGszjmx8tJrOZE48M
9IORR82aolBHKmOptf/8TeVQ8UNrZ/W29gwCrKEB0qOS3nago0CScjVsZCUDZVV6
gVODeVoMBvbbSgjXHU4inXT5jOjNIsxp8TIftoFpVwlTUMOHQ8TrDID9ydJsOTn8
Qzytalkbzkt+z7a9Du3E
=AA2q
-----END PGP SIGNATURE-----

Re: [MinGW-dvlpr] RFC: Why these <winuser.h> vs. <winable.h> conflicts?

[Earnie <ea...@us...>]

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

Re: [MinGW-dvlpr] RFC: Why these <winuser.h> vs. <winable.h> conflicts?

[Keith M. <kei...@us...>]

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

Re: [MinGW-dvlpr] RFC: Why these <winuser.h> vs. <winable.h> conflicts?

[Keith M. <kei...@us...>]

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

Re: [MinGW-dvlpr] RFC: Why these <winuser.h> vs. <winable.h> conflicts?

[Earnie <ea...@us...>]

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

[MinGW-dvlpr] RFC: Why these <winuser.h> vs. <winable.h> conflicts?

[Keith M. <kei...@us...>]

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

Re: [MinGW-dvlpr] RFC: <excpt.h>: __try1/__except1 are broken; are they worth fixing?

[Keith M. <kei...@us...>]

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

On 21/06/16 16:37, Earnie wrote:
> It's been too long for me to remember what I was thinking about the
>  change but I'm guessing that it never worked as intended.

I suspect that you were simply trying to provide an element of 64-bit
readiness, without any consideration of whether, or not, the original
32-bit implementation actually worked; consequently, you've adapted
broken 32-bit code, to create an equally broken 64-bit derivative.

Admittedly, I might have done the same, if I hadn't searched the bug
tracker, for any potentially related issue, and reviewed those which I
found; in particular, the one I mentioned earlier in the thread, which
was, erroneously IMO, closed as invalid.

The good news is that it may not be as difficult to fix as I had first
thought; indeed, I have a working adaptation which may resolve one of
my own FIXMEs, (in mingwex/glob.c), so it's likely worth pursuing.  I
do have one reservation: the current __try1(exception_handler)
followed by free-standing __except1 semantics seems rather
back-to-front to me.  Surely, __try2 { action code }
__except2(handler) { remedial code } seems more logical?

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

iQIcBAEBAgAGBQJXcBuPAAoJEMCtNsY0flo/KLwQAMOmPsrI2v1FEFW3KnaEXhgw
9PCYMp7lyzHldRqTFxtRvRErZ7fUhhQRRqkoR/c9dyN0DG34orZ/bQjaMYa0esb5
AhEfN8rqcPReod7VG8QzOA0fq/llUOkXng5ngcWAI81asmc6qp8uPiSHcc67P6a3
8rL7h757aJ2aG2+MEboXjwKLOYELWRFq+Nxd/golDjBxEH8g/d3mcKBDvlaSn8b/
HwBU6fuG1j3CzsewXCOk/nko6Vvt+K8MoRGyWjKT5vxGmh0BQEop5bCjMPqcru5U
/jyLBzMa2HYYIB2rFFRPFnlD748VLagZRN/krXczR+I3lOW9gW890dDlvdwQrl4q
RQw9o09tT2Q6xpr75+YslBpUg+CciXrfzk45C0SYIjedY0p+S8RPO07E+kookm9c
8cklnalaIpequc7VN8/J1CbRbsYB55De1Q+FxbhESaz2LA7hGKX1zdf9e0lkkTec
tB17dBHA6zIhpjcHWrN1wbDrubVlvnd+njjXS/u5ESIl+UoiGlXOLezA8nX2NGRq
6OQc79mfwjmVxKkqI/+Pz2kwVV6suGm7a8QjHqWzKT7I6a7T/hL+Cxvevic2XDdN
R/tfMupKT1mrqzljgrlx+N0astxpoJAgisg0V+FnqsvnWoWcOdOUIQsmUloZ1Exe
inkTkzR7CpD2lJTdjgaz
=j7dE
-----END PGP SIGNATURE-----

Re: [MinGW-dvlpr] RFC: <excpt.h>: __try1/__except1 are broken; are they worth fixing?

[Earnie <ea...@us...>]

On 6/20/2016 4:08 PM, Keith Marshall wrote:
> Guys,
> 
> Further reviewing Cesar's clone of our original CVS:
> https://sourceforge.net/u/cstrauss/mingwrt/ci/56e6189f267527e4dd710d55a16de39f7bf21c4a/
> 
> I stumbled upon:
> https://sourceforge.net/p/mingw/bugs/1328/
> 
> IMO, this bug report was inappropriately closed, as invalid.  I've
> reopened it, accordingly, because, as may be seen from the extensive
> analysis which I've appended thereto, this commit:
> https://sourceforge.net/u/cstrauss/mingwrt/ci/3eac8de7de5be34a9b58918ae8500697a7ddc1c4/
> 
> does nothing even remotely useful to resolve the issue; in fact the
> entire __try1/__except1 implementation is so utterly TARFUBAR, that I
> wonder if it is worth expending any effort on fixing it, or should it
> simply be allowed to disappear without trace?
> 
> Thoughts?


It's been too long for me to remember what I was thinking about the
change but I'm guessing that it never worked as intended.

-- 
Earnie

[MinGW-dvlpr] RFC: <excpt.h>: __try1/__except1 are broken; are they worth fixing?

[Keith M. <kei...@us...>]

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

Guys,

Further reviewing Cesar's clone of our original CVS:
https://sourceforge.net/u/cstrauss/mingwrt/ci/56e6189f267527e4dd710d55a16de39f7bf21c4a/

I stumbled upon:
https://sourceforge.net/p/mingw/bugs/1328/

IMO, this bug report was inappropriately closed, as invalid.  I've
reopened it, accordingly, because, as may be seen from the extensive
analysis which I've appended thereto, this commit:
https://sourceforge.net/u/cstrauss/mingwrt/ci/3eac8de7de5be34a9b58918ae8500697a7ddc1c4/

does nothing even remotely useful to resolve the issue; in fact the
entire __try1/__except1 implementation is so utterly TARFUBAR, that I
wonder if it is worth expending any effort on fixing it, or should it
simply be allowed to disappear without trace?

Thoughts?

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

iQIcBAEBAgAGBQJXaE01AAoJEMCtNsY0flo/29YQALi6VnW5WxyiyV77+v/vp5XZ
Y4gI2TP2L65tC9+0XNCIGoPUxctEa3SIA8tOXU5xTizIBoTVgofAMwfBwvpxMFNK
msel0LANyc+bRRiYQlequYfHEq8VRWoae+Yw28vdPsNCiC0MDdmpGaxNgAwVnteQ
ztTji+M3SKxCOE8XBI/mjQ7K22IXD+YF70Hjs/KxEV6ESc/0vbFrXcJRgr1o5Mdt
J3/VLW35rwn9Wxz/aQNvOpsF1YcY/jfQCpvNCO/75vq97lpjIJWcqecas172Manp
fg9RYG0c8y33VgJCPqQvFvb9Ja2+/hps0myzedv4OgvfZ6wMNj5c4Bg5AKnl1KtP
/5+p4hI4cJ6+ZleQgq7gaiXwMkQrt/zm/eF/bqT5VY/vdpnwC2dZviyjL50AZ5LU
URMlL6zt5GV8BO5OVlOph/eZzK/kWYI9aG5vn5fxfnbD0jHFtFGeQ4wih+gq8VQF
Z28XNc1KFxpzrA6JkR4UrEtD+hboxBQWNqmbZu+qPK9W0CDQ1yPhpnBmWY0e5PsY
hJ6uAMZW2LB015f1fX2QZGFe0XkjTilS8SGYKIT4kp6gujolWyucAuqHVemh5FYt
GHHGldmMh0b8Ds5E15kcnUDH/6eRY9m7j7AaFrI6NDc9PhbTTNOZURov9Lg5DuvK
KJNE54TjznPYQwRrnwEZ
=NL9z
-----END PGP SIGNATURE-----

Re: [MinGW-dvlpr] Is WSL still a viable identification choice for our system libraries?

[Earnie <ea...@us...>]

On 6/11/2016 6:22 AM, Keith Marshall wrote:
> Guys,
> 
> I know we used it first, but Microsoft have hijacked WSL, as a TLA
> designation for their "Windows Services for Linux".  We certainly
> don't want to take on Microsoft over it; do we really want to live
> with the potential confusion it may cause, or should we consider an
> alternative for our own use?
> 
> Any thoughts?  Alternative suggestions?
> 

The full git package name is mingw-org-wsl.  I think our use of WSL for
Windows System Library is valid and predates Microsoft's use of it.  I
haven't seen any confusion to date about it and Microsoft hasn't issued
a complaint as yet so I think we should leave it alone.  However we
could use the full git package name as the file name if you wish to make
a change.

-- 
Earnie

Re: [MinGW-dvlpr] Can someone please help me to understand this commit?

[Earnie <ea...@us...>]

On 6/14/2016 10:00 AM, Keith Marshall wrote:
> Guys,
> 
> Looking at Cesar's clone of our original CVS, I'm utterly confused by:
> https://sourceforge.net/u/cstrauss/mingwrt/ci/56e6189f267527e4dd710d55a16de39f7bf21c4a/
> 
> It appears to have been committed, originally, by Earnie, and I have
> too issues with it:
> 
> 1) The declaration of _locale_t surely belongs in <locale.h>, not in
> <_mingw.h>.  Furthermore, as a reference to an opaque type, we could
> just as well define it as a pointer to void, (although a pointer to a
> single incomplete structure type may make sense); I can certainly see
> absolutely no advantage in defining it as an aggregate of *two* other
> opaque structural types.
> 
> 2) I am utterly mystified by the changes to mingwex/tsearch.c, (which
> appear to have accidentally have crept into the commit).  AFAICT, the
> original code, (which has come from NetBSD), works just fine; I have
> no idea what issue these changes were intended to resolve, but once
> again AFAICT, they should have absolutely no functional effect whatsoever.
> 
> What am I missing?
> 

I don't have an answer; too long ago and I've not been thinking MinGW
for a while.  The tsearch.c change does to appear to have been
accidentally entered since the change isn't documented.

-- 
Earnie

Re: [MinGW-dvlpr] RFC: updating CPU identification macros

[Earnie <ea...@us...>]

On 6/11/2016 1:51 PM, Keith Marshall wrote:
> On 31/05/16 18:03, Keith Marshall wrote:
>> As I've noted at https://sourceforge.net/p/mingw/bugs/2301/, ...
> 
>> Please add your comments on the 2301 ticket.
> 
> Ping.
> 
> In the absence of any evident interest, I committed:
> https://sourceforge.net/p/mingw/mingw-org-wsl/ci/39e2fc7fccb558df06e4051d147a582b115d92d3/
> 
> This adjusts the set of mapped MSVC defines to _M_IX86 and _M_IX86_FP,
> or _M_X64 and _M_AMD64, or _M_IA64, as appropriate, while preserving
> only the reverse mapping to _X86_, (i.e. it no longer defines _ALPHA_,
> _PPC_, _MIPS_, or _68K_).
> 
> If you disagree with any of these changes, you need to respond on the
> ticket, and justify your objections.

I think it's good.

-- 
Earnie

[MinGW-dvlpr] Can someone please help me to understand this commit?

[Keith M. <kei...@us...>]

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

Guys,

Looking at Cesar's clone of our original CVS, I'm utterly confused by:
https://sourceforge.net/u/cstrauss/mingwrt/ci/56e6189f267527e4dd710d55a16de39f7bf21c4a/

It appears to have been committed, originally, by Earnie, and I have
too issues with it:

1) The declaration of _locale_t surely belongs in <locale.h>, not in
<_mingw.h>.  Furthermore, as a reference to an opaque type, we could
just as well define it as a pointer to void, (although a pointer to a
single incomplete structure type may make sense); I can certainly see
absolutely no advantage in defining it as an aggregate of *two* other
opaque structural types.

2) I am utterly mystified by the changes to mingwex/tsearch.c, (which
appear to have accidentally have crept into the commit).  AFAICT, the
original code, (which has come from NetBSD), works just fine; I have
no idea what issue these changes were intended to resolve, but once
again AFAICT, they should have absolutely no functional effect whatsoever.

What am I missing?

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

iQIcBAEBAgAGBQJXYA37AAoJEMCtNsY0flo/nCAP/13t8lgVFBMCrZ4opkNdoZBm
Iloxz71cgeUjf8QdO0FGWxoknIV2vlhu9FjR4KlJ4yzQKpZfj+YGHrWplD05Oav1
dw+/R5qN3tz2reiZIDwx/9X0uFwCOQtZ90/mKuER0wC/BgEbGpOt78+jgrvbBc42
xa5f7T9bK0ImA7CDFy1sNhvSeteeZ+49HvYEZqc5PLJnnwSiz+z1Yf3fULu/BgJL
eN6Leu570VsQARFajHgfpqfF1/KMlGxR2JBOTpa7V8W5loCClnOzk/zZAxtmmXQW
N6CDA3iq71MJ2KQXNCEnGG9A6VnoidkuwQIpU9C2ALtnpqfkoW92W7E/tdQU1aW5
YVNJawnD5yHmfFmBzUeJk0cA7CXWBncURYv24KCj8cX8PjtENpJGil1dnea+tGgh
m87/mcPqtKTshe84P30ZIwqhnJ75pfnUp7ORUC8Val/eLGr7b1yVswyzWqBYhQmk
Ct7rx4xllPh23ORFKSEZ8KvuzRec7YlnOJKzEomwkkB746zTj4uo6PWTUOrnYg3O
tU/dnSA7n1+LpuO6BF7hEy+X7bV+6CsVx8oip0vctW4skbvES8nENt1Ibc7m+j8Z
skf2ODjs+Zih/KwDFCyxWhfdmQUf0Y7XpoaD/bo3h00i41cE83X+98RCU7S7Isq0
Ufw5Fgt468HoPejY0s71
=lVWf
-----END PGP SIGNATURE-----

Re: [MinGW-dvlpr] RFC: updating CPU identification macros

[Keith M. <kei...@us...>]

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

On 31/05/16 18:03, Keith Marshall wrote:
> As I've noted at https://sourceforge.net/p/mingw/bugs/2301/, ...
> 
> Please add your comments on the 2301 ticket.

Ping.

In the absence of any evident interest, I committed:
https://sourceforge.net/p/mingw/mingw-org-wsl/ci/39e2fc7fccb558df06e4051d147a582b115d92d3/

This adjusts the set of mapped MSVC defines to _M_IX86 and _M_IX86_FP,
or _M_X64 and _M_AMD64, or _M_IA64, as appropriate, while preserving
only the reverse mapping to _X86_, (i.e. it no longer defines _ALPHA_,
_PPC_, _MIPS_, or _68K_).

If you disagree with any of these changes, you need to respond on the
ticket, and justify your objections.

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

iQIcBAEBAgAGBQJXXE+nAAoJEMCtNsY0flo/y1QP+wWuZb8fEYJPxme70rWz0JXL
91VJ23uOLXRmg2EEh78pyXLf3RwX+l+y0o9HBiF5eDCKF38e/Eonj50uZDGJIbR5
JaORg61JjtyR7moVBkDu5uNfZ4hX0oYrE46S6BEm7b8j1C4g5YkIbJc/jhZL+EEG
e/orqBeWp6hSXHK+v/YjyQ4GpHv+tAN0dWHp+0UvCfuDefcYGoc+UNZsGxLj3TU7
d7Vh7UFB6Sy2Du1P27YhqjH/1YmBsbi8zUaIkcIPa5lyX2X2a4CO6qWH+hU6nwE5
pP/BnU8PUV7W4cHore2Ru45rVgdhEYUIObpO8Z8Ivb0fpvzKSSAhhyjLbGfor9zA
EIE3PTy2GagmscZGU4RUHTEIbEV02Q1CcI4WcGcQU/j2vzZJft6p3bE+p0RDQhkY
5noCstcAq02+/3nhHtP1Nsja1geDWAqTlh1HRb1a/lq4oKQBZ41D7idIf/OroPan
O+x4utbcUySudFIa8NsP2K4ODH4O4NCWz3U47ydzcuM2MZzHgXC2FsoWdWP9iyMU
qQXLER7xHGupJIz72549xWaZdGeUn++Cccgfdq0FSzcIEXmcQntkRUKs0KsYZt8C
lRQfVGJO7gOFDSbn0ycGBPkLDlfuABal3ExprU1FT4NLevQ194GMRpOoLvyW9pIj
H/198HL0pnyhfycbCu0d
=r9I1
-----END PGP SIGNATURE-----

[MinGW-dvlpr] Is WSL still a viable identification choice for our system libraries?

[Keith M. <kei...@us...>]

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

Guys,

I know we used it first, but Microsoft have hijacked WSL, as a TLA
designation for their "Windows Services for Linux".  We certainly
don't want to take on Microsoft over it; do we really want to live
with the potential confusion it may cause, or should we consider an
alternative for our own use?

Any thoughts?  Alternative suggestions?

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

iQIcBAEBAgAGBQJXW+ZYAAoJEMCtNsY0flo/TkQQALc5Ky3mN7d396mRxLw9X8zJ
jILdwSikUgincriVQdqIoMBfn3n0ZFyP16KJWEKJ9Yroe/zCjYcvam65LJhlgE9T
fB+DsgY2gcm1rOuFubC7bpzCf1gHRhpH9ZgcWKNAiHEcFqZXQc0yFvMYyOLETNUU
cHS4gzlncjqKkKKlum7p6oxioUkf2C6dm1tTIKvUSYsa1ylo1aVf/d6us2xo8k/R
XaS8RZCHcQwoITRj4IKv5XTvY7Bn9sbuC6BhyX8zraPnZRX8Vkm0CmQStYu1r5wz
3EV+ntgfB4sIZdCv/XiQmjlSl7iYRiDjWlw/7UbAw0BzhN8AOIKHeNdKgUWuHkPB
Q8dcycXUQkkHfacLuFwYeIpsB1yGyaQb7lVCy6muBslEQ3wfDMf6T5fiZE5BaJ8d
2IUtdf/byCOnqRpNBfpPJt/iH9XQu5Nbtlh1VG+lzI5uQJPus0chlNJ6szdvIoEd
7xbasNAN1woAihO0Szr6ffFqXymXRbIfBqgz6lBmhE2XtcTXIvX5d0FSxE45aZTr
y6m5D+yGIoUUEouTfroJh/Ph+m2ZAR9VNtdcs0veAiclm+wK478uz+KJo54frjT8
2qLczUEhwX0wLYywtrgI6pRTjIvMnbbNhSDq5Q2a+HjEi148ZFValwunU9v2DA08
crnUvj1VnjxmqdHV8Lnh
=eM+P
-----END PGP SIGNATURE-----

[MinGW-dvlpr] RFC: updating CPU identification macros

[Keith M. <kei...@us...>]

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

Guys,

As I've noted at https://sourceforge.net/p/mingw/bugs/2301/, in both
<windows.h> and <winnt.h> I see:

  #if defined(__i686__) && !defined(_M_IX86)
  #define _M_IX86 600
  #elif defined(__i586__) && !defined(_M_IX86)
  #define _M_IX86 500
  #elif defined(__i486__) && !defined(_M_IX86)
  #define _M_IX86 400
  #elif defined(__i386__) && !defined(_M_IX86)
  #define _M_IX86 300
  #endif

This may have been okay when Anders Norlander first wrote it,
(although why he chose to duplicate it -- unnecessarily, as it happens
- -- in the two headers noted above is something of a puzzle), but I
doubt that it is good enough today.

I've indicated how I propose to update this, on the 2301 ticket, but
I'd particularly appreciate your thoughts on which, if any, of the
other Microsoft predefined macros, as documented at:
https://msdn.microsoft.com/en-us/library/b0084kay(v=vs.140).aspx
we should consider adding.  Also, how much of:

  #if defined(_M_IX86) && !defined(_X86_)
  #define _X86_
  #elif defined(_M_ALPHA) && !defined(_ALPHA_)
  #define _ALPHA_
  #elif defined(_M_PPC) && !defined(_PPC_)
  #define _PPC_
  #elif defined(_M_MRX000) && !defined(_MIPS_)
  #define _MIPS_
  #elif defined(_M_M68K) && !defined(_68K_)
  #define _68K_
  #endif

remains relevant today?  (Indeed, did Microsoft /ever/ support the
Motorola M68K processor?)

Please add your comments on the 2301 ticket.

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

iQIcBAEBAgAGBQJXTcPFAAoJEMCtNsY0flo/OEIP/2lDYl1YIzfE5/MxVXrIoj9l
npT5dUYE7ht40oPAzwkAOrB0Z7YFpsbgpVMiA1eEMtySaDz/v1ODrzrGp7t8R4YA
EGK87dKt34gT2TGudhyt5ER3xTvqynMFneIyApcLcP/Ul+0wmenP0FoMEpvGZt19
9kgl29zGBaIwFccPII8CFPARRrGycxr607nWBdpDIz/8zCsrU5tGLk3nnMZa6WB9
jOu8uzNQcKGWnpYdet/DWiRqLETxyCwAiY5mnLrWiIZw6qPDKd9U2vKjB4OB9BhU
FNzaCpU4Q70Rugzthh386M1VPUgD+5TZD4rrQ2cuUaLrgL/zgr5oKNzKX5d8dIfj
TmJuvuNnpWFzK1p5cQn5w6oZRhFzM0b+zOPXT81vVEcdQ8ysNHrGjLLV70UTziEw
Kk5yJndHqBPbLqCZC3whT24rHTlbp2/wKK8ZxRi7ZE9r+1gu86Y8SG+eWkTwn+5Y
QAnkSAMXpqGZwXR5afGjrYnxc/Clw3e3EZ8KhCvS6ovUj7hwlr5PetFD1ckumNAT
WuHOFO82zCruiXA5Ko6eHOaHhnXn8tFEWXuDwWWbqZoDNA2rMMCivdJ8kq+Gmld/
aVe/v/9vuduc/N6x23bnCG5LfZTIf6lY/tzAyv3eQE7FVwMLqzi/nz8kYhQUv86j
mNhuv1KX6ZqLZKFk4NyO
=NRJa
-----END PGP SIGNATURE-----

Re: [MinGW-dvlpr] RFC: time for a new mingwrt/w32api release?

[Earnie <ea...@us...>]

On 5/18/2016 10:51 AM, Keith Marshall wrote:
> On 16/05/16 16:14, Keith Marshall wrote:
>>> On the other hand, there is a good chance that the number of 
>>> affected people, actively tracking the "5.0-dev" branch, is 
>>> actually zero.
> 
>> That's a metric I hope we might be able to establish, at least as
>> it relates to participants on this list.  I'd like to think that it
>> *is* zero, since there seems to be no actual head branching from
>> that label; it appears to be no more than a place holder,
>> currently referring to the same location as 4.0-rc1, (which begs
>> the question: why was it designated as 5.0-dev in the first
>> place?)
> 
> Given that the branch point was named, but no actual branch was ever
> created, is there any *real* justification for keeping that original
> (virtual) branch ... especially since the 4.0-rc1 tag marks the self
> same point?  I'm thinking we might just as well delete this spurious
> branch, without bothering to
> 
>> 1) Rename the existing "5.0-dev" branch as "5.0-deferred".
> 
> since there's no deferred development sitting on that branch anyway.
> 
> Thoughts?
> 

Go ahead and remove it.  If someone needs it they can always recreate
it.  As you know I'm not currently developing on it anyway.

-- 
Earnie