41402-nyan, I can understand problems supporting Windows XP. I've been there myself, I had to write separate code to support it in that Telegram calls library I used to work on. But the way some open-source projects break compatibility with Windows 7, it feels intentional sometimes. Some minor crap like random number generation for example. Roll it back and everything just works.

@lanodan @grishka yeah, that's what I meant saying about not being able to convince everybody. It's fairly easy to make your own code work on outdated systems, but fixing everything down the dependency tree? Absolutely not. You might ask it's developers, and if they're chill like SDL devs for example, they might do something about it or direct you towards a better workaround. But if it's MSVC you probably won't hear anything from Microsoft dare you ask them about supporting XP or 7 in their compiler.

@grishka I don't believe it's intentional, they might just not use 7 and they'll never know because the documentation don't exist online anymore.

@a1ba @grishka Yeah MSVC you'd need to keep compat' with period-corrupt^Wcorrect compiler instead. And SDL, well depending on how ancient you might still need to keep compat' to an earlier release branch (say keeping SDL2 when you'd want SDL3 as the recommended setup).

41402-nyan, it would've been free to just not touch that piece of code. If I remember right, it was the Go runtime.

The win32 documentation still exists on the Microsoft website. The only thing that changed about it in the last 15 years is the design and the annoying machine translation that you have to undo.

Haelwenn /элвэн/ :triskell:, iirc MSVC can compile for any 32-bit Windows down to 95 if you specify the right flags and don't use new APIs

@grishka maybe, don't touch anything and it still works, that's a great rule. Except rewriting or refactoring old code is a thing.

As for MSDN, I remember it's just not telling the minimum supported OS for some Win32 calls or being misleading. Not to mention new bit flags or extended structs, those are never documented.

@lanodan @grishka the problem with older MSVC is that they're not C or C++ compilers as they barely understand standard conforming code. Newer versions better at understanding basic C99 stuff, it took them decades to implement it.

@grishka @lanodan yes, but you can forget about C++11 (or about C++ altogether because of standard library) and everything might randomly explode inside of CRT.

@a1ba @grishka At least that CRT doesn't also makes cathodic tubes explodes.

@lanodan @grishka if it's a program that enables custom resolutions...

41402-nyan, yeah that can happen. You may try to swap the newer C runtime with the older one after the fact but I'm not sure how interchangeable those msvcrt*.dll libraries are. There's also a static library component even if you link dynamically.

@grishka static build basically the same just allows to compile everything into one binary.

>swap the newer runtime

Oh, yeah, that doesn't really work. And linking to older versions is also not an easy task.