On 09/01/19 20:00, Eli Zaretskii wrote: >> From: Keith Marshall >> Date: Wed, 9 Jan 2019 19:47:05 +0000 >> >>> Well, we do want MinGW Binutils to work on Windows 9X, don't we? >> >> Yes, but from a user's POV, it seems more logical to me to say >> "Hey, MinGW-GCC, give me the best level of support you can, all the >> way back to Win95", not "Hey, MinGW-GCC, I'd like you to enable >> this obscure feature which is among several which I think may >> possibly be needed on Win95". > > That assumes defining _WIN32_WINDOWS indeed gives "the best level of > support". Which is exactly what it should do. > But it could also remove some features, i.e. produce a binary that > works well on Windows 9X, but is somewhat crippled on later systems. MinGW headers rely on _WIN32_WINNT, to control support levels for later systems, so if you've set (say) -D_WINNT_WINNT=_WIN32_WINNT_WINXP, then you can expect WinXP features to be supported, regardless of how you've defined _WIN32_WINDOWS. But just pause for a moment, and give a little rational thought to the implications of this; if you build your program to gratuitously depend on WinXP features, then it's hardly going to run on Win9x anyway, is it? Okay, you may be able to write the program to depend only on features of Win9x initially, (with WinNT support demanding no more than WinNT4), and then use PSAPI, LoadLibrary(), and GetProcAddress() to selectively enable optional features which depend on later APIs -- and MinGW's dlfcn API can help with this -- but that's going to take some effort, and demand some advanced programming techniques ... feature test specifications alone are not going to get the job done. In general, what you are asking for is feature support on two mutually exclusive levels. No combination of compile-time feature test macros is going to give you that ... you need to put in the programming effort to identify the platform capabilities at run-time. -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: <https://lists.osdn.me/mailman/archives/mingw-users/attachments/20190110/1d92fa45/attachment.sig>
Fork