What’s up with the Beep driver in Windows 7? (2010)
blogs.msdn.microsoft.com
blogs.msdn.microsoft.com
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.
http://www.csd.uwo.ca/~magi/personal/humour/Computer_Audienc...
"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))
and/or to Shakespeare, etc.
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.)
> 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.
Heck, at this rate, we'll need WINE for Windows, so Windows can run apps for earlier versions of itself.
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.
You can find the actual talk at https://youtube.com/watch?v=TrfD3pC0VSs
I remember days of playing SimCity 2000 and Doom without a sound card, so it was just beeps and buzzes. Then one day I discovered that driver and started to enjoy small sounding wave sound
[0] https://boutell.com/faq/oldfaq/winsound.htm [1] ftp://ftp.microsoft.com/Softlib/MSLFILES/SPEAK.EXE
That calculator was amazing. Real nice programming environment there for a high school kid that didn't have programming everywhere like we do today.
As for calculators, my school unfortunately standardized in TI: You guys had RPL, we have TI-Basic, which is worse than actual BASIC. And our calculators cost more! (Second-hand, anyways, because let's face it, nobody buys their calculators new)
Was a fairly common thing back in the day for software to support it, also went by the name Disney Sound System.
This is: echo Magic Mushroom Echo -------------- echo This Program was made by the R&D Team at echo the Cleveland Corp. of Australia at Hendra echo To turn 'Magic Mushroom off press any key echo Bye,Bye,Bye
virus total scan (its clean): https://www.virustotal.com/en/file/34b703cace0a2464899c67fa1...
Because its so small (206K), it fits in a pastebin: curl http://pastebin.com/raw/D95mhEvE | base64 -D > mushroom.zip
[1] Actually only 6 bits per byte are used; presumably this was done to improve decoding speed or something.
curl http://pastebin.com/raw/uunJFtcK | base64 -D > mushroom.mp3
The result is 6 bits of resolution, along with a high pitched squeak during playback, depending on the output circuitry and speaker characteristics (it's less noticeable when a low-pass filter is added).
The beeper using ancient interface is also long gone. Nowadays, the HDA chip handles it most of the time. There is no reason except ancient compatibility to call into the beeper via the ancient interface.
j/k... but I hope a Hero Will Rise
[1] https://www.amazon.com/SANOXY-PS2-Keyboard-USB-Adapter/dp/B0...
The motherboards that do come with PS/2 usually implement their chipset.
Also PS/2 stopped being electrically compatible a while ago around about the same time that the combo Keyboard/Mouse PS/2 ports became available.
It offers pretty low current only about 250ma so you might have issues with older AT keyboards even if the chipset is still AT command compatible.
For Intel system super I/O was eaten by the ICH which initially kept compatibility with most Super I/O functions.
By ICH 6 or 7 which is around the mid 2000's most of those legacy features were all gone.
By 2008-9 the ICH was also gone and replaced by the PCH which doesn't have almost any compatibility or features with the Super I/O architecture.
Frankly, I'm a little surprised at the hate for the couple thousand or so transistors required to support the set of 8253/8259/8250/8042/etc chips that form the basis of the original XT/AT. Especially given the love for all things ARM, which tend to implement their peripherals in a very 1980's way with simple fixed MMIO ports punched into the address map, but without the standardization that form the basis of PC/AT hardware.
And just to stay on topic, almost every single decent ATX/ITX board I've used in the last decade has a 4 pin PC speaker port. Including the skylake machine I built last night. Same thing goes for RS232 ports, which are still on the vast majority of decent PC hardware even if they don't have headers soldered on. The X99 in that review actually had the headers, and I owning the older version of the board actually have a cable plugged into it which I attach to assorted hardware for firmware/etc work.
Isn't that a source of flexibility, though? The fact that that stuff is not standardized and is instead hidden behind a hardware abstraction layer (the OS kernel) means that ARM systems get the freedom to drop the legacy interfaces and centralize the hardware abstraction where it belongs: in the kernel.
However, for that you need:
1) a specific kernel for specific hardware, there's no universal kernel like for PC and
2) lot of hope that the maintenance or support of that specific kernel is not going to be dropped as soon as the hardware ships out of the gates (which is the fate of many routers or android phones, which cannot be updated to newer OS releases).
As someone who works on embedded systems, the serial port is really useful for debugging when nothing else works.
In a modern PC, almost none of these are used - why would anyone want to use the crummy old AT 24-bit DMA controller when you can use PCIe bus mastering - but they're there if want to boot into an old real-mode OS.
I guess no v86 mode still makes it a dealbreaker for NTVDM type applications. Nobody wants to go back to a windows 95 style OS where a 16bit application runs unprotected and can stomp over anything and bring the machine to a halt. (For example, in win95 you could run debug.com and overwrite the first blocks of physical memory with zeros, which would immediately crash everything since that's where interrupt vectors like the IRQ timer is stored)
Would it be possible to bounce from 64bit long mode to 16bit real mode with some trusted code that bounces on to a mini kernel in 32bit protected mode that hosts v86 16bit applications, and then back again?
As far as I know it's possible to do all that and have a very-mixed OS.
Haswell?
I think what you mean is the vm86 mode is not available in 64-bit protected mode (no hardware task switching and 64-bit IRET ignores EFLAGS.VM).
But you can jump into real mode from 64-bit protected mode by clearing PE and PG at the same time. There are a couple more chores to do (clear EFER.LME and CR4.PAE) if you want the real mode code to be able to enter 16- or 32-bit protected mode. This[1] is an example.
[1] https://github.com/tianocore/edk2/blob/master/MdePkg/Library...
Back when I made that post I thought it was an 8253. But I checked the sources for the function that Beep.Sys uses to program the timer and it claims that it’s an 8254 so I went with the source code.
How hard would it be to use the chip? Not hard but now that Win7 has shipped, the number of machines with an 8254 that’s actually wired to something is going to dwindle to around 0. The machines will still have an 8254 (it’s on the SuperIo chip in every PC) but it won’t be connected to any hardware.
[1] nowadays the 8042 is mostly emulated in SMM because it needs to convert USB to PS/2.
Clever me noticed that the pinout of the CD drive matched the pinout of the PC's internal speaker. Aha, I thought; I can connect it up so that the internal speaker noises come out through my sound system.
Turns out that full-voltage square-wave 5V, amplified and pushed through a set of decent speakers, is... slightly loud.
(I was actually lucky not to damage the speakers. Or have a heart attack.)
I wonder how much this act has cost society. Just in this particular instance, let's say keeping this chip on PC motherboards adds 5¢ to the cost of each motherboard. Multiply by a billion PCs sold in the last 10 years (The actual number is higher, but maybe some don't have the chip. Macs and stuff.). Did having the PC beep provide $50M worth of utility to society over the last ten years? I doubt it. $50M of research into e.g. sight restoration technology would also likely have been more useful to blind people in general.
This act is not just about 'blind people', but people with all kinds of disabilities. If you read the article, you'll see that Beep() API is used for assistive technologies, which can be anything, from devices for motor impairment to deafness. Not everyone who is disabled is blind.
If this API would have suddenly disappeared the 'cost to society' would have been much higher than the assumed figure of $50M that you're stating here. Imagine if you'd wake up one day and your mouse doesn't work anymore because it's no longer compatible. That's how important assistive technologies can be to disabled people.
Furthermore, the suggestion that blindness can be 'fixed' by donating $50M to 'sight restoration technology' (whatever that is) grossly underestimates the complexities and variety of sight related disabilities. Vision is not a switch you can turn on again with an operation.
>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.