Re: [Mingw-w64-public] [PATCH v2 8/8] winpthreads: Use GetModuleHandleA to prevent Unicode errors
> Am 15.01.2024 um 23:01 schrieb Martin Storsjö : > > On Fri, 12 Jan 2024, LIU Hao wrote: > >>> 在 2024/1/11 23:41, Antonin Décimo 写道: >>> The non-suffixed macro GetModuleHandle depends on whether the file is >>> being compiled in Unicode mode or not. Prefer using the char string >>> literal in this simple case. >>> Signed-off-by: Antonin Décimo >>> --- >>> mingw-w64-libraries/winpthreads/src/misc.c | 2 +- >>> mingw-w64-libraries/winpthreads/src/thread.c | 2 +- >>> 2 files changed, 2 insertions(+), 2 deletions(-) >> >> In my opinion the W variants should be preferred. Most A functions convert >> their arguments to wide strings then call their W variants anyway. > > I don't have a strong opinion on this matter. However, I have a very faint > memory, that such unicode functions were absent in the Win9x series - I'm > looping in Jonathan who posted the patches for making winpthreads work on > Win98 recently. So if it makes a difference for Win98, I'd prefer going with > the -A version, otherwise I don't have a strong opinion, and don't mind going > with the -W version. > > // Martin Thanks for looping me in! I appreciate it a lot. Yes, the W version will indeed not work on Win98. The A version also has the advantage of needing half as much space for the string when it doesn’t contain Unicode anyway ;). I’m all for using the A suffix than none at all, to make it explicit. -- Jonathan ___ 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] Make winpthreads work on Win98
I see you imported this now, thanks very much! -- Jonathan ___ 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] Make winpthreads work on Win98
Am 23.10.23 um 07:41 schrieb LIU Hao: Our decision is that the change shall be within a `#if ...` block. Whether it is ``#if !defined(_WIN32_WINNT)` or `#if _WIN32_WINNT < 0x0500` is questionable, but the patch will not be accepted otherwise. The problem with this is that this is a library that ships with the compiler and is required by binaries created by the compiler. This would mean the decision which Windows version to target would need to be made not when compiling an application, but when compiling the compiler. That seems rather bad. Could you please explain why a compile time check would be preferable over a runtime check here? The cost of this runtime check should not be noticeable, most likely not even measurable. Doing runtime check seems extremely common on Windows, and I've seen it all over the place for checking functions that were only introduced in Vista. If you grep MinGW code for GetProcAddr, you'll see it be used plenty, including in libwinpthread in src/clock.c, for example. I'm trying to understand what's the difference in clock.c vs. my patch and why it's acceptable there but not in my patch? BTW I am also curious: does the CRT work well for you? I thought the Windows 98 MSVCRT.DLL (?) would have lacked some symbols. Yes, it works perfectly! With this patch, I'm able to create a single .dll for https://objfw.nil.im/ that works all the way from Windows 98 to Windows 11, and a single .exe for the test suite that has *all* tests pass on Windows 98 to Windows 11 (testing everything from exceptions, threads, file system APIs, sockets, etc.). Hence it would really be nice to get this patch in, since Windows was always about having one binary that works on all versions and #ifdef would be contrary to that. Thanks, Jonathan ___ 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] Make winpthreads work on Win98
Am 21.10.23 um 12:15 schrieb Biswapriyo Nath: May I ask who is still using Windows 98 in year 2023? I'm using it for a retro game project where I'm writing a 3D engine for 3dfx Voodoo cards, which work best on Windows 98 SE. I don't see any problem in running an offline Windows 98 system in 2023, or even in 2033. MinGW still has excellent support for Windows 98, and everything works after this patch, from exceptions, to threads, sockets, file system calls etc. Why does mingw-w64 still support that ancient operating system? I really don't see why not to be honest, given how Windows has always maintained forward and backward compatibility. It's not like this patch adds a lot of cost, neither in binary size, nor in code size, nor in maintainability problems. And it's everything that's needed to also make exceptions work on Windows 98, since libgcc_s needs winpthreads. -- Jonathan ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] Make winpthreads work on Win98
The following patch makes winpthreads work on Win98: https://objfw.nil.im/downloads/winpthreads_win98.patch I've been running with this patch since the beginning of the year (when I wrote it) without any problems whatsoever, so it would be great if this trivial patch could be imported. -- Jonathan ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
