Microsoft maintains backward compatibility seemingly forever and it means a lot more complexity, more surface area for vulnerabilities, and critically that they are unable to ever get developers to buy-in to any new ideas. Developers know their current app will keep working, so why bother with the re-write? Then due to the lack of adoption, they kill the project and try something else. I believe this to be one of the core reasons why Apple is able to successfully launch in areas that Microsoft has routinely failed.
It’s been 6 years. If anything hasn’t been updated by now, it’s either been abandoned or the developer needs a hard deadline. There are various programs out there where I question if it’s been abandoned. Periodic exercises like this help make it clear.
Maintenance ain't free and letting one of the core elements of OS to be developed by community could lead to undesirable outcomes (ranging from battery/perf impact to introduction of some new bugs or esoteric workarounds). Consistency in codebase and software is important, especially for bigger companies.
Far too many companies aren't willing to embrace newer paradigms/toolchains/software on the principle - if it works don't touch it or inventing some wild workarounds. I think in the end it's for good
Apple wants everything to be consistent. I have mixed feelings on it, because I do greatly despise windows, partly because of how inconsistent everything is. It’s chock full of half finished “migrations”. Like, programs still installing to “Programs Files (x86)” Which doesn’t matter but adds the tiniest bit of friction.
I think only 32bit apps install there. Ideally there is a 64bit version that continues forward. This is mostly an issue for me with enterprise/etc software I support at work. A key system I just moved to Server 2022 (on prem and Azure VMs) is 32-bit and still uses 32bit ODBC. It's a great app for our need. Just, still 32bit...
The intent is only 32 bit apps get installed there, but there are a few problems in practice. Dunno why you're currently downvoted about it though.
The first is needing to know whether the app was 32 bit or not is sort of the main annoyance with that itself.
The second is not every app follows this rule correctly, for whatever reason.
The third is there isn't a clear path for mixed apps, e.g. Steam. On Windows, Steam is still a mix of 32 bit and 64 bit components, so there isn't really a "clean place for it to go. You could have one option of putting Steam in one or the other and then mixing 32/64 bit apps in that folder & you have the other option of duplicating things, moving the initial problem an extra directory level deeper. 3b is that Steam installs the games under its folder, and the games you can install can be 32 bit, 64 bit, or a mix - duplicating the problem yet again. Until the start of this year, Steam still supported 32 bit Windows and, therefore, you could also have 16 bit games be installed.
There were reasons to do the split in the early 2000s but holding on to each decision like this for decades after seems to cause more pain than it ends up avoiding.
Microsoft maintains backward compatibility seemingly forever and it means a lot more complexity, more surface area for vulnerabilities, and critically that they are unable to ever get developers to buy-in to any new ideas. Developers know their current app will keep working, so why bother with the re-write? Then due to the lack of adoption, they kill the project and try something else. I believe this to be one of the core reasons why Apple is able to successfully launch in areas that Microsoft has routinely failed.
It’s been 6 years. If anything hasn’t been updated by now, it’s either been abandoned or the developer needs a hard deadline. There are various programs out there where I question if it’s been abandoned. Periodic exercises like this help make it clear.
Maintenance ain't free and letting one of the core elements of OS to be developed by community could lead to undesirable outcomes (ranging from battery/perf impact to introduction of some new bugs or esoteric workarounds). Consistency in codebase and software is important, especially for bigger companies.
Far too many companies aren't willing to embrace newer paradigms/toolchains/software on the principle - if it works don't touch it or inventing some wild workarounds. I think in the end it's for good
Apple wants everything to be consistent. I have mixed feelings on it, because I do greatly despise windows, partly because of how inconsistent everything is. It’s chock full of half finished “migrations”. Like, programs still installing to “Programs Files (x86)” Which doesn’t matter but adds the tiniest bit of friction.
I think only 32bit apps install there. Ideally there is a 64bit version that continues forward. This is mostly an issue for me with enterprise/etc software I support at work. A key system I just moved to Server 2022 (on prem and Azure VMs) is 32-bit and still uses 32bit ODBC. It's a great app for our need. Just, still 32bit...
The intent is only 32 bit apps get installed there, but there are a few problems in practice. Dunno why you're currently downvoted about it though.
The first is needing to know whether the app was 32 bit or not is sort of the main annoyance with that itself.
The second is not every app follows this rule correctly, for whatever reason.
The third is there isn't a clear path for mixed apps, e.g. Steam. On Windows, Steam is still a mix of 32 bit and 64 bit components, so there isn't really a "clean place for it to go. You could have one option of putting Steam in one or the other and then mixing 32/64 bit apps in that folder & you have the other option of duplicating things, moving the initial problem an extra directory level deeper. 3b is that Steam installs the games under its folder, and the games you can install can be 32 bit, 64 bit, or a mix - duplicating the problem yet again. Until the start of this year, Steam still supported 32 bit Windows and, therefore, you could also have 16 bit games be installed.
There were reasons to do the split in the early 2000s but holding on to each decision like this for decades after seems to cause more pain than it ends up avoiding.