I've always liked using System.Beep in VB6 as a sort of audible debug. It's so much easier than msgbox or writing to some stupid debug textbox if you just want a very quick confirmation that you got here.

Well, it looks like it's gone. But why was it there in the first place? From that same link:

There’s something else that happened in the past 25 years. PCs became commodity systems. And that started exerting a huge amount of pressure on PC manufacturers to cut costs. They looked at the 8254 and asked “why can’t we remove this?”

It turns out that they couldn’t. And the answer to why they couldn’t came from a totally unexpected place. The American’s with Disabilities Act.

The ADA? What on earth could the ADA have to do with a PC making a beep? Well it turns out that at some point in the intervening 25 years, the Win32 Beep() was used for assistive technologies – in particular the sounds made when you enable the assistive technologies like StickyKeys were generated using the Beep() API. There are about 6 different assistive technology (AT) sounds built into windows, their implementation is plumbed fairly deep inside the win32k.sys driver.
For Windows 7, we resolved the issue completely – we moved all the functionality that used to be contained in Beep.Sys into the user mode system sounds agent – now when you call the Beep() API instead of manipulating the 8254 chip the call is re-routed into a user mode agent which actually plays the sounds.

Bottom line for the change? Money.

Simon: You're right that there are other solutions. But we weren't trying to solve the console beep problem - we were solving a manufacturing cost problem.

Strangely, even if your hardware has the internal hardware to Beep, in Win7 64 bit, you're out of luck. I don't see a slick way to grab the speaker, though, since It's All Just 0s and 1s (c) 1970, there's got to be a way, right?

I also don't see exactly how this solves the ADA problem. If I buy a computer, there's no guarantee it has external speakers. With an internal speaker, the sound will be there [as long as the speaker works properly, etc]. And it'll be distinctive to boot. How does moving to the standard sound jive help? Save System.Beep!

Anyhow, I'm awfully sad to see Beep go. It's fun. And a cool Easter Egg.

EDIT: I couldn't help but play a little. In 32 bit Windows 7, I tried it out as explained here with Console.Beep(1000,1000); Interestingly, it most certainly did go through the headphones if they were plugged in, but more interestingly, this HP Compaq 6005 Pro MT PC made the sound through an excellent internal speaker (which it apparently does always have: "Integrated High Definition audio with internal speaker") when I unplugged the headphones -- though no other sounds have come out of this thing since I've used it.

(Hrm, now I can't turn the danged thing back off. Maybe I just had it on low all this time?)

I know Macs have had excellent internal speakers since forever (? -- my LC had one and everything through now has too), but perhaps I missed that standard hardware usually has one too? So perhaps this is a win-win, and using the "user mode system sounds agent" still routes to the internal speaker even when, for normal sounds, it's off. Perhaps the ADA simply mandates that you have an internal speaker of some sort, but Windows 7 allows that sound to move through the headphones if they're in? Still seems like the ADA would prefer these sounds not be mutable. /EDIT

Btw, has anyone noticed that logging in to blogger routes you through YouTube now? Wonder if YouTube is getting bundled with Blogger for a quick sale...

Labels: , ,