On Tue, 16 Jul 2019, Jacek Caban wrote:
On 7/16/19 11:31 AM, Martin Storsjö wrote:
Before b1634783c20dbae, we never used ___mb_cur_max_func() (available in
msvcrt.dll since XP). Since that commit (done to unify things between
msvcrt and ucrt), any use of MB_CUR_MAX uses this function.
On Tue, Jul 16, 2019 at 2:53 AM Martin Storsjö wrote:
> > What I don't understand is why there isn't a simple "#if WINVER >=
> > 0x0501" so that applications that are specifically built to run on
> > older systems can still run.
>
> Why? Because it was everybody's expectation that we only needed
On 7/16/19 11:31 AM, Martin Storsjö wrote:
Before b1634783c20dbae, we never used ___mb_cur_max_func() (available in
msvcrt.dll since XP). Since that commit (done to unify things between
msvcrt and ucrt), any use of MB_CUR_MAX uses this function.
Therefore, make libmsvcrt-os.a for i386 provide
On 7/16/19 8:52 AM, Martin Storsjö wrote:
On Mon, 15 Jul 2019, Gravis wrote:
So apparently, two years ago, someone decided to break all Windows
2K/NT4 applications that use MB_CUR_MAX. See also:
https://sourceforge.net/p/mingw-w64/mailman/message/36107291/
As reasoned in the mail you
Before b1634783c20dbae, we never used ___mb_cur_max_func() (available in
msvcrt.dll since XP). Since that commit (done to unify things between
msvcrt and ucrt), any use of MB_CUR_MAX uses this function.
Therefore, make libmsvcrt-os.a for i386 provide this function statically,
using the
On Mon, 15 Jul 2019, Gravis wrote:
So apparently, two years ago, someone decided to break all Windows
2K/NT4 applications that use MB_CUR_MAX. See also:
https://sourceforge.net/p/mingw-w64/mailman/message/36107291/
As reasoned in the mail you quoted, it was my (and certainly others' as
