Re: VS 2015 support in src/tools/msvc

* Alvaro Herrera wrote:

> Michael Paquier wrote:
>> On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier
>> <michael.paquier@gmail.com> wrote:
>>> Now, I have produced two patches:
>>> - 0001-Support-for-VS-2015-locale-hack.patch, which makes use of
>>> __crt_locale_data_public in ucrt/corecrt.h. This is definitely an ugly
>>> hack, though I am coming to think that this may be the approach that
>>> would us the less harm, and that's closer to what is done for VS 2012
>>> and 2013.
>>> - 0001-Support-for-VS-2015-getlocaleinfoex.patch, which make use of
>>> GetLocaleInfoEx, this requires us to lower a bit the support grid for
>>> Windows, basically that's throwing support for XP if compilation is
>>> done with VS 2015.
>>> Based on my tests, both are working with short and long local names,
>>> testing via initdb --locale.
>>
>> The first patch is actually not what I wanted to send. Here are the
>> correct ones...
>
> This thread seems to have stalled.  I thought we were going to consider
> these patches for 9.6.  Should we simply push them to see what the
> buildfarm thinks?  Has anyone other than Michael actually tested it in
> VS2015?

I built them both, and for lack of a better idea, ran initdb with all 
(short) locales in the Vista list 
(https://msdn.microsoft.com/en-us/goglobal/bb896001.aspx, second column) 
whose ANSI codepage is not either 0 or 1252. The former probably means 
"no such thing", the latter is my own default which I excluded to detect 
cases where it falls back to that.

Both patches behave exactly the same in this test. Of the 102 remaining 
locales, I get an unexpected codepage for just four:

- kk: Expected 1251, used 1252
- kk-KZ: Expected 1251, used 1252
- sr: Expected 1251, used 1250
- uk: Expected 1251, used 1252

I suspect that "sr" is a bug in MSDN: 1250 is Eastern European (Latin), 
1251 is Cyrillic, and "sr" alone is listed as Latin. So either the 
script or the codepage are likely wrong.

-- 
Christian