Re: [Mingw-w64-public] [PATCH] crt: Make a compat ___mb_cur_max_func on i386, to avoid forcing a dependency on XP
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. Therefore, make libmsvcrt-os.a for i386 provide this function statically, using the __mb_cur_max data symbol, to restore compatibility as it was before this commit. Signed-off-by: Martin Storsjö --- The patch looks good to me. Thanks, pushed. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MB_CUR_MAX breaks 2K/NT4 applications
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 to support > XP. To be pedantic, we only ever officially supported XP64 as the base OS, which is the 32-bit equivalent of Server 2003. 32-bit XP is actually on an older kernel than 2k3 and XP64. Also, to be more pedantic... the OP talks about applications built to run on older systems. You can certainly change the header in your own version and build for an older system and it should work. You're just on your own for support. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Make a compat ___mb_cur_max_func on i386, to avoid forcing a dependency on XP
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 this function statically, using the __mb_cur_max data symbol, to restore compatibility as it was before this commit. Signed-off-by: Martin Storsjö --- The patch looks good to me. Thanks, Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MB_CUR_MAX breaks 2K/NT4 applications
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 quoted, it was my (and certainly others' as well) understanding that mingw-w64 generally requires at least XP, and that it is ok to assume XP, anywhere in the mingw-w64 code. And the fact that it took two years for someone to notice suggests that the assumption is mostly right. 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 to support XP. Now, as noted on irc, these symbols are used in parts of lubmingwex, which is independent of version defines used in the calling code, and also is supposed to work with both msvcrt and ucrt, so an #if in the header would probably be brittle. But it should be doable to wrap this function in the x86_32 import library, keeping the interface towards the crt import libraries uniform. I'll send a patch for this. But the main question I see is, what's the project's policy wrt supporting older OS versions than the minimum (currently XP, but there have been discussions about raising it to Vista): 1) Require new code to be tested to still work with any older OS (essentially removing the minimum version concept altogether) 2) Disallow any workarounds for older versions 3) Allow reasonably non-intrusive workarounds, for things reported on the mailing list, but don't require people to test on versions prior to the minimum one (i.e. it can occasionally break and it's up to the users of said older versions to test and report) I think that the current 'status quo' solution is something like 3). I don't consider win2k as supported version (and at some point XP will be in similar position). In this case, Martin's patch fixing the problem is small and straightforward, so getting it committed sounds good. That said, Gravis, your use case is extremely rare and expecting us to treat it with the same amount of care as we do for recent Windows version is unrealistic. If you use 20 years old OS, you may just as well use older version of mingw-w64. Another solution would be to start using msvcr90.dll (which is redistributable for win2k), which will probably work better in future mingw-w64 versions. Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] crt: Make a compat ___mb_cur_max_func on i386, to avoid forcing a dependency on XP
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 __mb_cur_max data symbol, to restore compatibility as it was
before this commit.
Signed-off-by: Martin Storsjö
---
Run autoreconf in mingw-w64-crt after applying.
---
mingw-w64-crt/Makefile.am | 1 +
mingw-w64-crt/lib-common/msvcrt.def.in | 5 -
mingw-w64-crt/misc/___mb_cur_max_func.c | 18 ++
3 files changed, 23 insertions(+), 1 deletion(-)
create mode 100644 mingw-w64-crt/misc/___mb_cur_max_func.c
diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index b848f9c18..726cc4833 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -233,6 +233,7 @@ src_ucrtbase=\
src_msvcrt32=\
$(src_msvcrt) \
math/x86/_copysignf.c \
+ misc/___mb_cur_max_func.c \
misc/lc_locale_func.c \
misc/wassert.c
diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in
b/mingw-w64-crt/lib-common/msvcrt.def.in
index 4e7410c6a..2883c1dba 100644
--- a/mingw-w64-crt/lib-common/msvcrt.def.in
+++ b/mingw-w64-crt/lib-common/msvcrt.def.in
@@ -260,7 +260,10 @@ __STRINGTOLD
F_NON_I386(___lc_codepage_func)
___lc_collate_cp_func
___lc_handle_func
-___mb_cur_max_func
+; ___mb_cur_max_func exists (on all archs) since XP. Earlier, this function
was never used, but the __mb_cur_max data symbol was accessed instead.
+; For i386 we provide this function as a statically linked helper, that uses
+; __mb_cur_max, to avoid forcing the XP dependency here.
+F_NON_I386(___mb_cur_max_func)
F_X86_ANY(___setlc_active_func)
F_X86_ANY(___unguarded_readlc_active_add_func)
__argc DATA
diff --git a/mingw-w64-crt/misc/___mb_cur_max_func.c
b/mingw-w64-crt/misc/___mb_cur_max_func.c
new file mode 100644
index 0..61dcdb7a6
--- /dev/null
+++ b/mingw-w64-crt/misc/___mb_cur_max_func.c
@@ -0,0 +1,18 @@
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
+
+#include <_mingw.h>
+
+extern int* __MINGW_IMP_SYMBOL(__mb_cur_max);
+
+int __cdecl ___mb_cur_max_func(void);
+int __cdecl ___mb_cur_max_func(void)
+{
+return *__MINGW_IMP_SYMBOL(__mb_cur_max);
+}
+
+typedef int __cdecl (*_f___mb_cur_max_func)(void);
+_f___mb_cur_max_func __MINGW_IMP_SYMBOL(___mb_cur_max_func) =
___mb_cur_max_func;
--
2.17.1
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MB_CUR_MAX breaks 2K/NT4 applications
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 well) understanding that mingw-w64 generally requires at least XP, and that it is ok to assume XP, anywhere in the mingw-w64 code. 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 to support XP. Now, as noted on irc, these symbols are used in parts of lubmingwex, which is independent of version defines used in the calling code, and also is supposed to work with both msvcrt and ucrt, so an #if in the header would probably be brittle. But it should be doable to wrap this function in the x86_32 import library, keeping the interface towards the crt import libraries uniform. I'll send a patch for this. But the main question I see is, what's the project's policy wrt supporting older OS versions than the minimum (currently XP, but there have been discussions about raising it to Vista): 1) Require new code to be tested to still work with any older OS (essentially removing the minimum version concept altogether) 2) Disallow any workarounds for older versions 3) Allow reasonably non-intrusive workarounds, for things reported on the mailing list, but don't require people to test on versions prior to the minimum one (i.e. it can occasionally break and it's up to the users of said older versions to test and report) // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
