Hacker News Reader

Comment by duskdozer | Hacker News Reader

I do wonder how much support is removed because of genuine maintenance or compatibility burden, because I've encountered enough examples where it was done solely because some target was deemed "too old" arbitrarily, even if it would still work without any modifications.

View on HN

> even if it would still work without any modifications

even in this case, maintenance burden is still real. supporting the old target often prevents you from using features/tools that make maintenance easier

Perhaps the best example I can think of is the whole situation

InstallShield is....massive crapware and actually generated 16 bit installers way way after anyone was using 16bit PCs. Nobody notices until, I think it was W8 or W10 dropped support for running 16bit executables (something about dropping the subsystem that supported them.

It was 64-bit Windows versions, 16 bit was never supported not even on XP 64-bit. I think W8 was the first 64-bit only Windows.

Windows 11 was the first 64-bit only build of the NT-based Windows tree. There are 32-bit x86 builds of all previous versions.

Windows 11 drops IA32, and thus (first party) MS-DOS and Windows 3.x support.

Windows actually has some special cased support for (at least some of) the problematic 16 bit InstallShield installers to run a 32 bit version instead on AMD64.

> I think W8 was the first 64-bit only Windows.

Nope, that would be Windows 11! There is a 32-bit version of Windows 10.

Nobody noticed because Windows special cased InstallShield.

https://devblogs.microsoft.com/oldnewthing/20131031-00/?p=27...

From InstallShield’s perspective, why would they replace working 16-bit code which is still natively compatible with Windows and x86? Because Windows and/or Intel might (or might not) drop support a decade later?

In Rust or in general? Because an arbitrary "too old" moniker is not something I've seen happening, and the only target that was removed instead of demoted in recent times was i586-pc-windows-msvc, aka Windows 10 without SSE, which was...utterly pointless since Windows 10 requires SSE.

If anything, I quite like the way Rust handles it with target tiers and easy switching between targets, because it's an honest approach about how well a target is supported. Having a win7 target that is tier 3 is a reflection of the support it has, and much better than stringing it along in the main Windows target that promises tested support when there isn't even a Windows 7 CI to test on.

Reply on news.ycombinator.com