Re: [Mingw-w64-public] [PATCH v2 8/8] winpthreads: Use GetModuleHandleA to prevent Unicode errors

2024-01-22 Thread Jonathan Schleifer

> 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

2023-10-24 Thread Jonathan Schleifer

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

2023-10-23 Thread Jonathan Schleifer

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

2023-10-22 Thread Jonathan Schleifer

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

2023-10-21 Thread Jonathan Schleifer
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