What’s up with the Beep driver in Windows 7? (2010)

>Imagine if you'd wake up one day and your mouse doesn't work anymore because it's no longer compatible.

Huh? This analogy doesn't make any sense. Things aren't compatible because of the ADA; they're compatible thanks to standards bodies and market pressure.

> That's how important assistive technologies can be to disabled people.

Only a small fraction of people need the beeper, and from what I understand based on a presentation from a deaf coworker a few years back, the best assistive technologies are those that emerged naturally, not from archaic ADA-imposed requirements. She cited OS X's accessibility features.

>Vision is not a switch you can turn on again with an operation.

I'm aware. I never said $50M in research would cure blindness; I said it would do more for blind people than a little beeper in the PC chassis. $50M is also quite a conservative estimate.

Windows installation upgrades (hereafter "migration") have been blocking setup if a known-incompatible program[1] is detected during installation, telling the user to uninstall it prior to allowing the upgrade to continue.

For Windows 10, the goal was to make the migration process (which would take ~40 hours to gather/apply on a typical system from Vista -> 7, the same process takes 20 minutes to an hour on upgrades to modern 10 nowadays) a lot faster, and a lot more seamless, as to get as many users as possible on the latest OS release to reduce effort supporting other software versions[2] and such.

Of course, blocking the installation with a known-incompatible program would result in popping up to the user, say, 'hi, this update can't install until you uninstall this program. please do so!', and they of course will respond 'what update? I don't want to uninstall my program so you can install an update! [I don't trust this at all/I'll forget/...]', and therefore said update (which wouldn't just be from 7/8 -> 10, but also cross-build on 10 itself) would never get installed.

There is no sane way to ask the user, since this will reduce adoption of new builds further than what people not understanding/accepting Microsoft's POV on this will attempt by 'not upgrading'.

[1] A common case to cite is the deinstallation of the product 'Speccy', which, funnily, will cause a system crash in a kernel driver shipped with the product if said older version is later installed on the new OS version and run. Given the chance people will have odd ways to automatically start this, and that people's systems will instantly crash if run, it makes sense to block the installation on this product. [2] I maintained a hobby product that worked with fringe cases in the OS for a long period of time, and over time as I moved to newer OS versions myself, I'd end up having a large amount of features break on downlevel systems due to depending on new implementations/refactors done in 8, 8.1 or 10 with regards to those components of the OS.