That is a pretty awesome tour de force. Somewhere deep inside your computer is an (emulated) PC/AT trying to get out :-).
An interesting lesson about the use of 'beep' for the assistive technologies. I see those sorts of things in architectures which have grown up over time and I wonder whether or not you could know at the time "Hey we're using this weird thing, please deprecated at your earliest convenience" or if it was more "there I fixed it."
Compatibility at the GPIO level was so ingrained in the PC community early on (there was even a code name for it, "Is it FlightSim compatible?" which referred to Microsoft Flightsim, a game that tested the compatibility limits of clones.) So as a tenet to the community all sorts of hacks could be committed in its name. Something like "Well we can depend on this, if they changed it then it would break compatibility and they can't do that."
Also an interesting take on how much Microsoft has had to unwind in a compatible way over the years.
Finally, the Linux console used to beep the speaker this way (I have no idea if it still does) and sometimes when I lay there sleeping I would hear my server softly feeping, yes feeping on its console bell. Sadly it wouldn't stop until I got up and logged in and figured out what was complaining.
"So," say I, "what is the madness, The state of awful system sadness,
That would cause Linux such distress?"
After all, the days of yore, from which this reference came before, those days are long since gone.
Yes, the PDP is long since gone, and though it legacy carries on, the once-great HACTRN is no more.
So once again this begs the question, which I ask through my HN session, what did feep upon your console's bell?
--qwertyuiop924 (with apologies to The Great Quux (with apologies to Edgar Allan Poe))
there should be a rule for this: all great & powerful modern emotional things can be reframed to point back to some work of Edgar Allen Poe. whether hacker related or not. the only dependency is the human condition
The way I remember FlightSim (from first official PC clone presentation, compaq in 1982! https://www.youtube.com/watch?v=7THrlGIL9k0 ) was that it jumped directly to raw hardcoded pointers in the bios instead of calling interrupts.
Another "test" was WordStar? using DOS/BIOS CP/M compatibility layer (afaik the only software ever to do that?). There were also programs expecting MS basic in the rom.
> Also an interesting take on how much Microsoft has had to unwind in a compatible way over the years.
It's very much self-inflicted technical debt. From a Spolsky on Software article from 2004:
> Raymond Chen is a developer on the Windows team at Microsoft. He's been there since 1992, and his weblog The Old New Thing is chock-full of detailed technical stories about why certain things are the way they are in Windows, even silly things, which turn out to have very good reasons.
> The most impressive things to read on Raymond's weblog are the stories of the incredible efforts the Windows team has made over the years to support backwards compatibility:
Look at the scenario from the customer's standpoint. You bought programs X,
Y and Z. You then upgraded to Windows XP. Your computer now crashes
randomly, and program Z doesn't work at all. You're going to tell your
friends, "Don't upgrade to Windows XP. It crashes randomly, and it's not
compatible with program Z." Are you going to debug your system to determine
that program X is causing the crashes, and that program Z doesn't work
because it is using undocumented window messages? Of course not. You're
going to return the Windows XP box for a refund. (You bought programs X, Y,
and Z some months ago. The 30-day return policy no longer applies to them.
The only thing you can return is Windows XP.)
> I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.
> This was not an unusual case. The Windows testing team is huge and one of their most important responsibilities is guaranteeing that everyone can safely upgrade their operating system, no matter what applications they have installed, and those applications will continue to run, even if those applications do bad things or use undocumented functions or rely on buggy behavior that happens to be buggy in Windows n but is no longer buggy in Windows n+1.
The Simcity case reminds me of Bryan Cantrill's talk on lx-branded zones: apparently, there was a bug in rpm which didn't touch Linux, because Linux wasn't doing things fast enough to trigger the condition. So there was some code added to check if the running program was rpm, and to pause it briefly if it was. Apparently the comment the people who wrote it left amounted to, "we wrote this, and even we feel dirty about it."
Well, an update is needed: the Windows testing team was huge. Now, if they remark at all a program has a problem, it will just be silently uninstalled during the next major Windows upgrade.
...That's actually worse. If a program has a problem, tell the user. Besides, the idea that things won't change has been firmly ingrained in Windows programmers' heads for years.
Heck, at this rate, we'll need WINE for Windows, so Windows can run apps for earlier versions of itself.
The answer to that question is a lot less obvious than one would expect.
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.
That's an "interesting" approach. Unfortunately, it is made worst by the fact MS laid off tons of testing engineers a few years ago, and now release clearly buggy versions of Windows. To add insult to the injury, it now does so (adding new bugs and new incompatibilities with perfectly fine programs) every few months...
It’s a quote from the HACTRN, the explanatory notes of which explains: “the TTY's bell […] on the CRT in the poem above is a particularly obnoxious flavor of "beep", […]”
An interesting lesson about the use of 'beep' for the assistive technologies. I see those sorts of things in architectures which have grown up over time and I wonder whether or not you could know at the time "Hey we're using this weird thing, please deprecated at your earliest convenience" or if it was more "there I fixed it."
Compatibility at the GPIO level was so ingrained in the PC community early on (there was even a code name for it, "Is it FlightSim compatible?" which referred to Microsoft Flightsim, a game that tested the compatibility limits of clones.) So as a tenet to the community all sorts of hacks could be committed in its name. Something like "Well we can depend on this, if they changed it then it would break compatibility and they can't do that."
Also an interesting take on how much Microsoft has had to unwind in a compatible way over the years.
Finally, the Linux console used to beep the speaker this way (I have no idea if it still does) and sometimes when I lay there sleeping I would hear my server softly feeping, yes feeping on its console bell. Sadly it wouldn't stop until I got up and logged in and figured out what was complaining.