@grishka I would've agreed if XP users weren't a headache for me.

41402-nyan, you mean for the game engine you're working on?

@grishka yeah. And I don't want to spread such nonsense.

Yes, the old software will continue to work, there is no reason not to. The problems arise when you expect that modern software will work on top of the old operating system.

And while it's technically possible for the developers to keep outdated software limitations in mind, you can't convince everybody to do that.

I understand some people might be nostalgic about computers from their childhood, and it's fine to revisit your past occasionally, but bringing it to current times and pretending that everything is fine is... no.

@grishka that said, I'm talking about people still using XP and 7/8 in 2025, not about those who will use 10 for few years after it will be dropped by Microsoft.

Though I would prefer if they uninstalled Windows altogether.

41402-nyan, ReactOS isn't ready yet, unfortunately

@grishka though I guess masturbating for old software isn't something specific for windows users, because it reminds me of a dude who reported a bug about something not compiling on his ubuntu 18.04 machine. Why 18.04? Who fucking knows!

@a1ba @grishka And well given modern software, keeping compatibility with EOL systems isn't just your own code but also dependencies, and in the case of operating systems, sometimes entirely different system APIs/ABIs for which it might be really hard to keep compatibility with both.
(And of course given it's EOL, the all the bugs stay unfixed, so workarounds pile up)

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.