> From: Keith Marshall <keith****@users*****> > 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". 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. Without studying all the uses, how could one know? And even after studying, it might remain a mystery of sorts, since the documentation is scarce and sometimes non-existent. > > My problem with _WIN32_WINDOWS is that it appears in a dozen places in > > our w32api headers, and just analyzing its impact is a serious job. > > By contrast, __USE_MINGW_FSEEK is a much more focused knob. > > More focused, yes; *too* focused maybe ... as a user, I have to know in > advance, that it enables a feature that I will almost certainly need, if > I want my application to work correctly on Win95, and I also need to > think about any other such features I may need. OTOH, with > > -D_WIN32_WINDOWS=_WIN32_WINDOWS_95 > > I can cover all bases at once. This again makes the same assumption I mentioned above. Perhaps you know about this more than I do, but from my POV using _WIN32_WINDOWS is a bit scary.
Fork