What’s up with the Beep driver in Windows 7?
Earlier today, someone asked me why 64bit versions of windows don’t support the internal PC speaker beeps. The answer is somewhat complicated and ends up being an interesting intersection between a host of conflicting tensions in the PC ecosystem.
Let’s start by talking about how the Beep hardware worked way back in the day[1]. The original IBM PC contained an Intel 8254 programmable interval timer chip to manage the system clock. Because the IBM engineers felt that the PC needed to be able to play sound (but not particularly high quality sound), they decided that they could use the 8254 as a very primitive square wave generator. To do this, they programmed the 3rd timer on the chip to operate in Square Wave mode and to count down with the desired output frequency. This caused the Out2 line on the chip to toggle from high to low every time the clock went to 0. The hardware designers tied the Out2 line on the chip to the PC speaker and voila – they were able to use the clock chip to program the PC speaker to make a noise (not a very high quality noise but a noise nonetheless).
The Beep() Win32 API is basically a thin wrapper around the 8254 PIC functionality. So when you call the Beep() API, you program the 8254 to play sounds on the PC speaker.
Fast forward about 25 years… The PC industry has largely changed and the PC architecture has changed with it. At this point they don’t actually use the 8254 as the programmable interrupt controller, but it’s still in modern PCs. And that’s because the 8254 is still used to drive the PC speaker.
One of the other things that happened in the intervening 25 years was that machines got a whole lot more capable. Now machines come with capabilities like newfangled hard disk drives (some of which can even hold more than 30 megabytes of storage (but I don’t know why on earth anyone would ever want a hard disk that can hold that much stuff)). And every non server machine sold today has a PC sound card. So every single machine sold today has two ways of generating sounds – the PC sound card and the old 8254 which is tied to the internal PC speaker (or to a dedicated input on the sound card – more on this later).
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.
But why does that matter? Well it turns out that many enterprises (both governments and corporations) have requirements that prevent them from purchasing equipment that lacks accessible technologies and that meant that you couldn’t sell computers that didn’t have beep hardware to those enterprises.
This issue was first noticed when Microsoft was developing the first 64bit version of WIndows. Because the original 64bit windows was intended for servers, the hardware requirements for 64bit machines didn’t include support for an 8254 (apparently the AT requirements are relaxed on servers). But when we started building a client 64bit OS, we had a problem – client OS’s had to support AT so we needed to bring the beep back even on machines that didn’t have beep hardware.
For Windows XP this was solved with some custom code in winlogon which worked but had some unexpected complications (none of which are relevant to this discussion). For Windows Vista, I redesigned the mechanism to move the accessibility beep logic to a new “user mode system sounds agent”.
Because the only machines with this problem were 64bit machines, this functionality was restricted to 64bit versions of Windows.
That in turn meant that PC manufacturers still had to include support for the 8254 hardware – after all if the user chose to buy the machine with a 32bit operating system on it they might want to use the AT functionality.
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.
There was another benefit associated with this plan: Remember above when I mentioned that the 8254 output line was tied to a dedicated input on the sound card? Because of this input to the sound card, the sound hardware needed to stay powered on at full power all the time because the system couldn’t know when an application might call Beep and thus activate the 8254 (there’s no connection between the 8254 and the power management infrastructure so the system can’t power on the sound hardware when someone programs the 3rd timer on the 8254). By redirecting the Beep calls through the system audio hardware the system was able to put the sound hardware to sleep until it was needed.
This redirection also had had a couple of unexpected benefits. For instance when you accidentally type (or grep) through a file containing 0x07 characters in it (like a .obj file) you can finally turn off the annoying noise – since the beeps are played through the PC speakers, the PC mute key works to shut them up. It also means that you can now control the volume of the beeps.
There were also some unexpected consequences. The biggest was that people started noticing when applications called Beep(). They had placed their PCs far enough away (or there was enough ambient noise) that they had never noticed when their PC was beeping at them until the sounds started coming out their speakers.
[1] Thus providing me with an justification to keep my old Intel component data catalogs from back in the 1980s.
Comments
Anonymous
January 04, 2010
Isn't it an 8253, not an 8254? Your previous post http://blogs.msdn.com/larryosterman/archive/2005/11/04/489135.aspx refers to it as such, as does the other information I can find about it. How hard would it be to make a beep driver that utilizes the older chip? On my system, and a quick google shows that this is by no means unique, the only sound outputs are headphones and the internal speaker. Headphones are useless if not worn, and as such the internal speaker is the only speaker that I can hear while not at my PC. In previous versions of Windows, Beep() could be used to notify a user even if the normal output was muted.Anonymous
January 04, 2010
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.Anonymous
January 04, 2010
Looking a bit further, it seems that the 8253 and 8254 are both timers with the same interface.Anonymous
January 04, 2010
There's a linux driver for the beeper that not just beeps but actually plays sampled sounds over the beeper - horribly. (sure something similar existed for DOS back in the day).Anonymous
January 04, 2010
This is a welcome change. On more than one occasion a programmer at work has accidentally sent a binary file to the console and turned his workstation into a beeping monster, attracting the attention of everyone around him. The next step is usually a hard reset, since Ctrl+Break doesn't flush the 10,000 beeps that are queued up. It's also good for laptops since for some reason the laptop hardware manufacturers like to set the volume of the PC speaker emulation to something like 200dB.Anonymous
January 04, 2010
Of course, the PC beep is still often used for diagnostics. When you put together a machine for the first time, you want to hear exactly one short beep after POST. Of course, the POST doesn't cover everything. I fried my old nVidia 6600GT by not plugging in the auxilliary power, but trying to run the PC normally. There was no warning. Things were different when I accidentally tried the same trick with my Radeon 5870: it makes an ungodly screaming noise instantly upon power-up when not fully plugged in.Anonymous
January 04, 2010
blah: I know some games pulled the same trick. The good news is that CPUs were so powerful back in the day that they could be dedicated to doing nothing but fiddling the silly square wave generator.Anonymous
January 04, 2010
Ah, the good ole PC speaker how I love to hear you sing back in the day. Mostly thanks to this gem: http://support.microsoft.com/kb/138857Anonymous
January 04, 2010
You are imprecise a couple of places in your post. The 8254 is the PIT, a Programmable Interval Timer. The 8259 is the PIC, the Programmable Interrupt Controller. You refer to the 8254 as the PIC a couple of times. Quite confusing.Anonymous
January 04, 2010
@blah >> There's a linux driver for the beeper that not just beeps but actually plays sampled sounds over the beeper - horribly. (sure something similar existed for DOS back in the day). It was actually easy to write a program doing that.. I did. You just reprogram the timer so that it stops generating a wave and stays always in 0 or 1 status.. and then reduce the wave file to 1 bit per sample and play that bit on the timer.. the inertia of the speaker does the smoothing between samples, but the result is horrible anyway :)Anonymous
January 04, 2010
Great article.Anonymous
January 04, 2010
If you think that KB entry is a gem, check out this one: http://support.microsoft.com/kb/261186Anonymous
January 04, 2010
Um, the plural of "American" is "Americans", not "American's". An apostrophe makes a noun possessive, not plural.Anonymous
January 04, 2010
Is there still a way to play a tone of a certain frequence forever? Old Pascalprograms on DOS used to play sounds by activating the speaker, sleeping a while and stopping it. Now I tried to port these functions and I found a solution for W9x (using old assembler) and WinNT-32bit (Calling directly DeviceIoControl with IOCTL_BEEP_SET), but this fails on 64bit (and after your article it should also fail on Win7)Anonymous
January 04, 2010
Dell desktops (Optiplexes, at least) have an internal speaker, presumably on-board. They also wire the output of the actual (on-board) sound card to it, in case nothing is connected to the speaker or headphones ports. So even if Windows 7 routes Beep() to the sound card, it could get re-routed back to the internal speaker! Sound routing is funny. I was one testing different speakers, and found that my computer was still playing when no speakers were connected! After ruling out the internal speaker, I found it was the VoIP phone connected as a USB audio device!Anonymous
January 04, 2010
Back in the day, I wrote a DOS program that taught spoken Chinese using the pc speaker as the sound output device if there was no SoundBlaster on the system. One drawback was that since it used the system clock chip, If you used the software for long, your system time would get out of sync with the actual time. The good old days...Anonymous
January 04, 2010
This is very interesting, but it brings up a question. On my boxes the GoogleTalk instant messaging client beeps on new messages if the client doesn't have focus. But it always goes through what I assumed was the PC speaker rather than the sound card speakers, because I hear it even without my headphones on. This is on Win7 64Bit. I always assumed it was calling Beep() and that was why. But this seems to indicate that those Beep() calls should go through the headphones I always have attached. Weird.Anonymous
January 05, 2010
Wow, it astounds me that this change took until Windows 7 to make.Anonymous
January 05, 2010
Now all we need to do is set the default "Start Navigation" sound to (none) so IE doesn't keep clicking at us and Windows will finally sound right :) Every time I build a machine it's the first tweak I do!Anonymous
January 05, 2010
The comment has been removedAnonymous
January 05, 2010
The comment has been removedAnonymous
January 05, 2010
Josh: Yes there are people who love the "start navigation" sound. They use it as a confirmation that the browser has actually followed a link. This is especially important with web sites that aren't 100% responsive to navigation. The problem is that IE fires the start navigation sound whenever someone changes document.location which happens a lot in heavily asynchronous web pages.Anonymous
January 05, 2010
I actually use sticky keys because I am disabled. In fact, setting them up as one of the first things I do with the new PC or OS. Windows 7 is different than all previous versions and that it change the three tone functionality used in conjunction with sticky keys. The first beep tone announced modifier key had been pressed, a second and different tone announced that that same modifier key had been pressed again (i.e., locking it), and finally a third and different beep tone announced that the modifier key had been released by pressing on it a third time. When you just press a modifier key once, the control key for example, and then the key to be modified, for example, V , there is no tone to indicate the release of the modifier key. (And as a matter of ergonomics, that would probably be undesirable.) I have actually found these three deep tones to be very useful because the sticky key display in the notification icon area in versions of Windows before Windows 7 was actually very buggy. It would disappear at random and would only reappear if the sticky key setup procedure was repeated. In any event, after 10 or more years of three beep tones, the two tones that Microsoft has niggardly provided in Windows 7 is still hard to get used to.Anonymous
January 05, 2010
@BeniBela >> Now I tried to port these functions and I found a solution for WinNT-32bit (Calling directly DeviceIoControl with IOCTL_BEEP_SET), but this fails on 64bit (and after your article it should also fail on Win7) << Actually, these functions should work in Windows 7 on both 32 and 64-bit. IOCTL_BEEP_SET in Win7 uses the user-mode service that Larry describes. On the plus side, this means that beeping is no longer broken on 64-bit for apps that do this. Of course, if you actually wanted to get to the timer chip, this method no longer works. Sending IOCTL_BEEP_SET in Windows 7 does effectively the same thing as calling PlaySound() with a buffer containing a sine wave.Anonymous
January 05, 2010
Wow I would never think so much has gone into just 1 beep! I wonder what else is kept over from the old days.Anonymous
January 05, 2010
I remember Star Control II had the option of PC speaker music. I also remember being blown away that the MOD music sounded so good on the speaker, and several years later when I heard it through a sound card it wasn't substantially different.Anonymous
January 05, 2010
Thanks for a great walk through history. I've spent nearly thirty years hating those d*mn beeps whenever I accidentally typed a binary file. Now I can tell everyone why I like Windows 7 so much :-)Anonymous
January 05, 2010
Most of the PC's in the company I program for do not have sound systems/speakers (by design). I need the beep().Anonymous
January 05, 2010
To those looking for making music with the internal speaker, the .NET Framework has a static Beep method in the Console class: D:> $frequency=1500 D:> $duration=2000 D:> [Console]::Beep($frequency, $duration) PS: I don't know whether this uses the 825x or the sound card.Anonymous
January 05, 2010
I remember playing Out of this World on my 386 (before buying my SB pro!). I always wondered why other games sounded so awful comparing to it. So it seems they did the trick simulating a PWM through the speaker. Very clever.Anonymous
January 05, 2010
Interesting topic, but I re-read a couple of times but am still confused what the real problem is. What does "client OS’s had to support AT so we needed to bring the beep back even on machines that didn’t have beep hardware." mean? How do you make a PC beep if it does not have hardware to generate a beep? Are you referring to using the sound card on these machines? If so, it is nothing really exciting and still does not resolve the problem of having beeps before the OS is fully booted and drivers installed. I think that servers need beeps badly, not for AT, but for diagnostics, especially when you are using a shared display in a rack. I am totally confused by "Because the only machines with this problem were 64bit machines, this functionality was restricted to 64bit versions of Windows. That in turn meant that PC manufacturers still had to include support for the 8254 hardware – after all if the user chose to buy the machine with a 32bit operating system on it they might want to use the AT functionality." Which is the problem being referred to? Why doesn't the "functionality" designed for 64-bit also work on 32-bit systems? Hope you can help to "unpuzzle" me. Thanks.Anonymous
January 05, 2010
The comment has been removedAnonymous
January 05, 2010
@Rodrigo - I LOVE Out of this World! That game totally AMAZED me... I never got very far though... I tried for YEARS to simulate sound through programming the PIC (or PIT, whichever is used), of course I was only 14, sometime around the age of 17 I realized the trick was pretty much obsolete and gave up. It seemed sooo clever!Anonymous
January 05, 2010
Is this the same speaker which beeps on bios start up (like post errors etc) ?Anonymous
January 05, 2010
The comment has been removedAnonymous
January 05, 2010
Do you have more information on the Windows XP logon problem with beeps that you mentioned? Great article!Anonymous
January 05, 2010
With this workaround on Win 7 x64, beep() will not work if you have no sound card installed. I still want beep(). Otherwise good post. Nice to read the history, though some references (as pointed out in earlier comments) are wrong.Anonymous
January 05, 2010
Great article. Minor correction on the first few paragraphs though: The 8254 is a counter/timer, not an interrupt controller (PIC). You are getting it confused with the 8259 Programmable Interrupt Controller. The 8254 had little to do with interrupt CONTROLLING (although it was hooked to IRQ0). The 3x timers in the 8254 on a PC have three purposes: (1) Generation of IRQ0 for timer interrupts (2) Generation of the ISA Refresh signal. (3) The speaker beep Intel 8259 Datasheet: http://bochs.sourceforge.net/techspec/intel-8259a-pic.pdf.gz Intel 8254 Datasheet: http://ftp.utcluj.ro/pub/users/calceng/PMP/231164.pdfAnonymous
January 05, 2010
@RyanBemrose >IOCTL_BEEP_SET in Win7 uses the user-mode service that Larry describes. On the plus side, this means that beeping is no longer broken on 64-bit for apps that do this. Thanks, but what I need to know is, how the user-mode service behaves in these two corner cases: What happens if you send a beep request with a duration of (dword)(-1) ms to the driver? And if you send a beep a request to the new driver/service, whiel another beep sound is emitted, will the first beep stop? The old driver accepted a duration of (dword)(-1) ms as almost infinite, and stopped the first beep in the second issue. (since I have neither XP-64 nor Win7, I can't test it)Anonymous
January 05, 2010
The comment has been removedAnonymous
January 06, 2010
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. The team which owns the console subsystem could have chosen to change the way they handle beeps but for whatever reason they didn't (they were busy with fixing other issues in the console subsystem during Win7).Anonymous
January 06, 2010
So does the cost savings form OEMs come in to play because they no longer need SuperIO chips with 8254 capability integrated into them? Once the die is made, the cost savings should be negligible, even if you count tenths of a cent. Or is the savings from not needing some sort of dongle connecting the beep speaker to the soundcard output or needing an internal speaker? For accessibility reasons you'd still need a speaker, either internal or external.Anonymous
January 06, 2010
Derlin: I don't actually know. It might be that the cost is simply the cost of the wire (and yes it actually makes a difference when you're trying to cut costs - just ask Walmart)Anonymous
January 06, 2010
Makes interesting reading. There appears to be an assumption that every computer has a soundcard. We write bespoke software for POS Terminals, and use the beep for such things as drawer opening alerts or login errors. These machines have typically nothing else but our own software installed on them, and currently run under XP. (they are not used for wathing video's or sending emails, their only and exclusive function is to deal with Sales Transactions). The machines we use are not fitted with soundcards. The good news is, that because our software runs perfectly well on 10 year old hardware, and the software gets absolutely No Benefit from either Vista or Win7 (only problems), that it is probably in 10 years time before we start finding we cannot find hardware without an internal speaker. :)Anonymous
January 06, 2010
bram: Every PC that's built to the PC99 client hardware standard is required to have audio hardware (that's been the case for decades). But obviously the PC99 standard doesn't apply to embedded systems. IMHO in your shoes I wouldn't be using XP for your POS machines, instead I'd be using XP Embedded (or Vista Embedded or Win7 Embedded). I believe that the licensing is cheaper and it allows you to remove a bunch of OS functionality that you don't need for your dedicated solution.Anonymous
January 06, 2010
> that's been the case for decades The decades of the 1990's, the 2000's, and now the 2010's. Decades indeed. Nice technicality there. :PAnonymous
January 06, 2010
"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." In the original IBM PC it was a 8253, in the IBM PC/AT it was upgraded to a 8254. "(it's on the SuperIo chip in every PC)" Actually the southbridge. "8254 PIC" PIT, not PIC, as Myron A. Semack pointed out. "And every non server machine sold today has a PC sound card." Actually, it got integrated into the southbridge. "At this point they don’t actually use the 8254 as the programmable interrupt controller" Timer, you mean. Also, the use of "AT" for assistive technology can be confused with the IBM PC/AT, the full name should have been used instead. "Which is the problem being referred to?" LarryO probably was referring to the Itanium port, and Itanium was a fresh start that did not have to be x86 or AT compatible. "IMHO in your shoes I wouldn't be using XP for your POS machines, instead I'd be using XP Embedded (or Vista Embedded or Win7 Embedded)." Don't forget WEPOS too.Anonymous
January 07, 2010
LarryOsterman: Did you see my correction I posted above?Anonymous
January 07, 2010
>> that's been the case for decades >The decades of the 1990's, the 2000's, and now the 2010's. >Decades indeed. Nice technicality there. :P Technically the decade doesn't start until 2011. There was no year 0. The year went from 1BC to 1AD. Same for centuries, everyone got excited about on the wrong night way back in 1999. They should've waited until 2000/12/31. On topic(ish): @Josh: customise the beeping sound in control panel. If you don't have permissions to do that because of group policy, try deleting/editing the corresponding .wav file (changing permissions so it's not accessible might work too). Fascinating article - i wired a couple of resistors into a PC I had to reduce the volume of the speaker (a trick I later used on a dozen phones that were too loud even on their quietest ring -- trying to code in a concrete room with 12 phones ringing just after each other, then the echo).Anonymous
January 08, 2010
The comment has been removedAnonymous
January 08, 2010
It seems that the new BEEP.SYS breaks NTVDM compatibility. The Usermode Sound Agent seems to not react in a timely manner as the PC Speaker Hardware does. Now with the old BEEP.SYS from Windows XP (which called the HalMakeBeep API which in turn uses the IO-Ports of the 8254 to drive the real PC Speaker) everything works fine and as expected. But if you try to run a DOS application with the new BEEP.SYS, you won't hear anything as the Beeper is toggled too quickly by the DOS Application via the IO Port 0x61. As far as I know the only solution to get the beeper running properly in NTVDM is to restore the old BEEP.SYS from Windows XP which uses the System Beeper. Is there any plan to Fix the Beeper or adapt the NTVDM to resolve this issue?Anonymous
January 10, 2010
The comment has been removedAnonymous
January 11, 2010
The comment has been removedAnonymous
January 16, 2010
I wrote a little fix for the PC Speaker problem with the Windows 7 NTVDM. If you are interested, you can download it here: http://www.waldbauer.com/tmp/reference.php? Detailled description can be found in docREADME.TXT, sourcecode is included.Anonymous
February 01, 2010
This is the dumbest article I have read in a long time. On a chipset with several million transistors, the few thousand required for a PIT costs practically nothing. The choice is the motherboard makers. Most have already connected the PIT output to an input on the on-board sound chip.Anonymous
February 09, 2010
Maybe I'm missing something here, but will the user mode agent route sound to the PC speaker if the [other] audio device is disabled? I have an application that MUST use the PC speaker, whether or not there are other audio devices present. Is this possible? Currently the app is using Beep(), which works on XP and Vista 32bit, but not on Win7...Anonymous
February 09, 2010
NeilS: If the audio device is disabled, then it doesn't redirect audio. How does your application (which must use the PC speaker) work on machines that don't have a PC speaker? Moving forward the set of machines that have a PC speaker is going to become significantly smaller - the cost of maintaining the old system has become prohibitive so the PC manufacturers are removing that hardware support (much as they've all removed floppy drive support).Anonymous
February 10, 2010
Thanks for the quick response Larry. Up until now, we've set a hardware requirement for our application: PC speaker required. The app will not sound if there is no PC speaker. This is an app that runs on safety/security systems, and it is an agency-requirement to have an audible tone in certain scenarios. I understand that the PC speaker is old and doesn't compare to newer audio technology, but how can one guarantee audio output on the newer devices? It would have to require that speakers be connected, turned on, and the volume set to an audible level, at all times. Unless newer PCs come with internal speakers that can be forced to play a sound at a certain level in all cases, this requirement would be difficult to enforce.Anonymous
February 10, 2010
Larry, every student in my wife's middle school classroom has access to an XP system with no external speakers. A lot of her students have discipline issues. As such, they have recently discovered the StickyKeys activation sequence with associated beeps and have taken to disrupting the class with the beeping. Is there a way to disable the beep so that the students cannot turn them back on? My wife has tried the settings dialog, but the kids know how to reset them in the same manner.Anonymous
February 10, 2010
demasb: Disable the beep.sys driver (sc disable beep.sys), that should fix it.Anonymous
February 11, 2010
Larry, I have noticed that in an RDP session, the beep no longer works on certain hardware. As you know, RDP uses the endpoint interface for audio. Is the new beep functionality compatible with this?Anonymous
February 11, 2010
Thanks, we couldn't get the sc command to disable the beep.sys, but we were able to disable it via the device manager. My wife disabled most of the systems in her classroom, she said it was a lot quieter.Anonymous
February 11, 2010
Mustafa: beep should work on all hardware on Win7. On machines without beep hardware it should work too.Anonymous
February 11, 2010
While we're being off topic (sorry), can you please explain why such obvious bugs as Vista's volume mixer's display being incredibly buggy don't get fixed? They're sometimes acknowledged in the support KB (eg 938308 - that's only part of the buggyness of the mixer), but never ever fixed. Yes, I understand things like security fixes take precedence, but there's no way there hasn't been time for someone to do 5 minute bug fixes in the last 3 years. I know there are processes to be followed, paperwork to be done, and loads of testing, but come on. There's been plenty of time.Anonymous
February 12, 2010
Databmoose: Can you please give more context? As far as I know all the known issues in the volume mixer were fixed in Win8 (the black background issue was a buffered painting issue for example)Anonymous
February 12, 2010
A21Anonymous
February 12, 2010
Larry: I assume you mean Win7, not Win8...? Regardless - yes, of course it's fixed there, being a new Windows version, but my point is it's not fixed in Vista.Anonymous
February 12, 2010
If I understand this article and several posts elsewhere correctly,.. the internal PC speaker will no longer beep with my Windows 7, 64-bits. Not a biggy I would say,... except... Skype has a choice to have the PC speaker ring. This way you will hear an incoming call at all times. (imagine your headphones are plugged in and you just stepped away, or you don't ave any other speakers than the headphones and the internal pc speaker). It is good to have the ringing just through the internal pc speaker as you just answer and put on your headphones. No need to switch on/off your monitor or surround sound speakers all the time. So, it would be great if the internal PC speaker could beep for ringing purposes with communication tools like Skype. ??????? Is there a fix to have 64-bits Windows 7 beep/ring the internal PC speaker? ???????Anonymous
February 13, 2010
NeilS: If you need PC speaker sound, you can use the beepxp.sys driver from my NTVDM-fix mentioned above. To interface with it from usermode, just use the simple BEEP()-Compatible API form beeper.c, that should do it. If you are having questions, feel free to ask.Anonymous
February 19, 2010
Larry: Databmoose was probably asking it to be fixed in something like a hotfix or a service pack, instead of requiring a new Windows release.Anonymous
February 20, 2010
Yuhong: Databmoose should feel free to file a service request against Windows Vista. He or she should include a business justification for the fix including what impact the bug has on customers and how much money the bug costs his (or her) business. After that the windows servicing team can decide if it's appropriate to spend the money to create the hotfix. The incremental cost of bug fixes like this during the product cycle is very small (because there is a significant amount of testing going on which will hopefully catch any regressions in the fix) but the incremental cost of bug fixes out-of-band is many orders of magnitude higher. Because of this, making hotfixes costs beaucoup bucks and thus the costs have to be justified.Anonymous
February 21, 2010
Come on Larry, you don't have to be passive aggressive about this. Your second paragraph would have sufficed. I had a feeling what you said was the "reason", but it's a poor justification. Do service packs not count as "during the product cycle"? Surely there is a lot of testing for those, during which regressions can be caught, as you say can be done between releases. Vista has seen two service packs so far. That's plenty of opportunity. But even disregarding that, it's still a weak excuse - the bugs I'm talking about aren't exactly deep in the kernel. If there is any chance of bad regressions for fixing simple drawing bugs, then Windows is very poorly coded. I know that's not really the case. At the end of the day, Microsoft is not exactly hurting for cash, so fixing a dozen of the most obvious and annoying bugs with a hotfix or in a service pack, for an operating system that's going to be around for many years, is not going to destroy the company.Anonymous
February 21, 2010
Databmoose: This isn't being passive aggressive. It's the process that MSFT has established for creating hotfixes. The process starts with a service request submitted through customer support channels and wends its way through to the support teams who actually do the work of creating the hotfixes. Service packs are also not "during the product cycle". Service packs contain rollups of all the previously issued hotfixes and changes necessary to react to emerging technologies. They do not undergo the same level of rigorous testing that a product release does. As I said before, if you would like to see these bugs fixed, open a support case with CSS and they can prioritize the fix appropriately. Product development (where I work) has essentially no say in what gets fixed once the product ships, the decision to take a fix or not is (in general) solely in the hands of CSS.Anonymous
February 22, 2010
I don't run a business, so I doubt anything I say is going to get them fixed. Besides, such bugs would hardly be cause for concern for any business. That's the problem really - bugs that only affect "normal" customers get ignored until the next release. Microsoft, it seems, only likes to look after its business customers. The average customer doesn't have a voice, despite making up the largest group. I do know that getting bugs fixed in Microsoft land isn't up to developers. I'm not faulting you or the other devs for anything (well, except the for fact that such blatant bugs existed in the first place). It just seems like a very consumer-unfriendly thing to have so much red tape. Most devs take pride in their work, and like to ensure it's bug free, and I'm sure you do too. Being at the whim of what essentially comes down to the accountants is not something I envy. It's just such a shame that everything is looked at in dollar terms.Anonymous
February 22, 2010
Databmoose: Bugs that affect "normal" customers get fixed too. But people have to report them to CSS. If the bugs aren't reported through official channels they don't get fixed.Anonymous
February 23, 2010
Yet the types of bugs I mentioned still remain. They have no doubt been reported through official channels multiple times over the last 3 years. CSS has obviously decided not to fix them for Vista. That doesn't really help, does it? They may fix security bugs and the like, but not these bugs.Anonymous
February 24, 2010
Databmoose: I'm not aware of ANY software product (including OSS products) that routinely provides fixes for non critical bugs once the product has shipped. Sure on OSS projects, you can make private bug fixes but when you do, you lose all support.Anonymous
February 24, 2010
Really? Any software? A very quick check on Google (give Mr Ballmer my apologies) reveals a good example: http://developer.pidgin.im/wiki/ChangeLog Most of those are non critical, and many are quite trivial. Some more: http://www.opera.com/docs/changelogs/windows/ https://developer.skype.com/WindowsSkype/ReleaseNotes http://www.kde.org/announcements/changelogs/changelog4_2_2to4_2_3.php http://www.worldofwarcraft.com/patchnotes/ So there you go. 5 random projects from a minute searching that demonstrate projects that fix non-critical bugs once the product has shipped. It's interesting that you added the qualifier "routinely". Why do that? My complaint isn't about whether non-critical Windows bugs are routinely fixed, it's that they're never fixed (for that release). For OSS projects, you don't have to do "private" fixes. You can submit a patch for inclusion in the release trunk. People do this all the time. Sure they could deny it, but I've never seen any bug fix get denied because they didn't want to test it. It might just go into the dev branch until it's deemed stable.Anonymous
February 25, 2010
None of the examples you provided disprove my thesis. As best as I can see, these projects are ALL only providing patches for their current shipping version. You're asking for a fix to be made to Vista, which is an older version of the operating system (the current Windows version is Windows 7). Microsoft is very unusual in the industry because unlike all the examples you cited, we'll continue to issue bug fixes for older versions of our operating systems (for example we still produce service packs for Vista even though Windows 7 is our current OS). But you need to start the process by talking to our CSS organization.Anonymous
February 25, 2010
No, I'm asking why it didn't get fixed in the 3 years Vista was around when it WAS the latest Windows version. And like I said, many people have undoubtedly already gone through the proper channels about this - the bugs I'm talking about are so obvious that millions of people will have experienced them. The other thing is that Windows 7 is not a strict "upgrade" from Vista. Other applications and systems are much more easily upgraded. I still use Vista most of the time, even though I also have Windows 7 on this computer, for instance (because I haven't had the time to migrate all my applications). So the fact that Microsoft supports older OSs with service packs is thus no surprise.Anonymous
February 26, 2010
Databmoose: It wasn't fixed because as far as I can tell, nobody reported the bug to CSS (posting on a forum isn't the same as reporting a bug to CSS). Even if it had been submitted, it's likely it wouldn't make the bug bar- as I've said many times before, the decision to fix a bug is always the result of a strict cost/benefit analysis (both before and after a product is shipped). There's a very real cost (in both dollars and risk of regression) to fixing a bug. Bugs like this one which are primarily visual glitches typically have a low benefit (it's highly unlikely that either MSFT or our customers is losing money because of this bug). Of course MSFT can't determine the benefits of fixing a bug which is why we ask our customers for feedback about how much the bug is costing them. Before a product is shipped, the costs of making a fix are relatively low - the extensive regression testing we do as a function of the release cycle ensures that most regressions are caught for instance. But once the product as shipped, the cost of doing fixes goes up dramatically (we don't have as much time to test the fixes). So we need to have strong data to quantify the benefits associated with the fix before we can decide to fix it. A bug that affects millions of customers is much more likely to be fixed than a visual glitch which affects dozens.Anonymous
February 26, 2010
"Bugs like this one which are primarily visual glitches typically have a low benefit (it's highly unlikely that either MSFT or our customers is losing money because of this bug)" This is what I'm getting at. The only motivation appears to be money. If no one is losing money because of the bug, it doesn't get fixed. Doesn't Microsoft care about user experience? Obviously to some degree, but it seems it doesn't like putting the money into supporting their products when they can't justify it in immediate dollar terms. I know Microsoft is a business, but what about the examples in the links I provided above? There are many small "user experience" bugs there that get fixed. Visual glitches, at least the ones I'm talking about, don't just affect "dozens". Almost everyone experiences them. They're not the end of the world, but they're still annoying, and degrade both the user experience and perception of the quality of the product. This can even have a flow-on effect where the user is less likely to buy or recommend Microsoft products if they perceive them to be glitchy. There's your monetary justification if you need it. Regarding the CSS - I can't even find it, despite knowing the name. Is this it? Is this the magical form where you can submit bugs to, where they actually have a chance to get fixed?: https://support.microsoft.com/contactus/emailcontact.aspx?scid=sw;en;1539&ws=morecust&ws=support That's the closest thing I can find going by your description. If it hasn't been reported there, then no wonder - no one can find it.Anonymous
February 26, 2010
Databmoose: Microsoft cares passionately about user experience. But that doesn't change basic economics. In this particular case, the bug was NOT trivial to fix and involved making significant changes to the volume scrollbar control - enough that it wasn't easy to backfix the change to Vista without also bringing along a boatload of other fixes, enough to invalidate the testing that was done. That meant that this "simple" fix would have taken a multi-day test pass across literally hundreds of computers. And that means it's going to be massively expensive. That testing is easily absorbed in a product release cycle but it's prohibitively expensive as a hotfix or service pack. CSS is the name for Microsoft's support group(Customer Support Services). The page for MSFT support is: http://support.microsoft.com/ You can access online help by selecting one of the links off that page.Anonymous
February 26, 2010
If Microsoft cared so deeply about user experience, then it should be willing to give up a few dozen grand* to fix the top dozen most obvious UX bugs. *certainly no more than $1m - if it would cost more than that, then I would suggest there's something very wrong with MSFT's processes (well, I am suggesting that already) Fixing the mixer bug IS trivial compared to many of the bugs Microsoft does fix, as I'm sure you're well aware. But it was just an example anyway, perhaps a poor one. Here's one that has no excuse, albeit it's hardly anything worth anyone complaining about - in Paint's Edit Colors dialog, the "Define Custom Colors >>" button goes off the edge of the window when it's not expanded. There is no chance of any regressions for fixing that, and it would take less than a minute to fix. It would even be simple to fix it by editing the binary itself. In fact I might have a go myself. Trivial in all senses, but it contributes to the perception of "bugginess" and thus a degraded user experience in Windows. There are plenty of these small bugs all over the place. What about this one: The mouse cursor sometimes shows as a corrupt, stretched image of itself for a single frame when it changes from one cursor image to another. Probably harder to fix, but it should still be relatively easy. Oh and what about this doozy from the days of XP - this one isn't a display bug, it's much worse - selecting or hovering over .avi files in Windows Explorer sometimes crashes it and/or keeps the file open (stopping it from being deleted). This bug is very well known. There's even a fix for it in a third party utility (XdN Tweaker). There's no excuse for not fixing crashing bugs - but nope, never fixed.Anonymous
March 08, 2010
FYI, an update on my issue (see Feb 9, 10): We fooled around with an open-source I/O port driver (PortTalk) to program the PIT. We're able to control the PC speaker for our needs - seems we'll go with this solution.Anonymous
March 18, 2010
The comment has been removedAnonymous
March 26, 2010
Don't know if this question applies, but I'm having this problem with the internal speaker beeping whenever i connect/disconnect the a/c adapter to my laptop, and I've tried just about everything to make it stop. Funny thing is, in Vista, all I had to do to stop the beeping was mute "pc beep" in speakers properties, but in Win 7 (I'm using home 32 bit version), the "pc beep" slider doesn't show up at all. I guess this could be a driver problem, but judging by various posts across the web (and the article on this page) that seems unlikely. Disabling the beep.sys doesn't work, which is understandable seeing as it no longer has anything to do with the internal speaker (if I'm not totally misunderstanding the article, that is!) Just to be clear, this beep is not coming from the laptop's speakers, but from what I gather is a chip on the motherboard itself, so can't be shut off by turning off windows sounds. I would appreciate tremendously any suggestions!Anonymous
March 30, 2010
Update: it seems the beep is coming from my laptop speakers after all, because when i mute them, there is no beep when i (dis)connect the a/c adapter. But the beep is definitely not a wave file, it's the familiar pc beep. So the problem remains: how to get rid of it in Win 7?!?Anonymous
March 31, 2010
I always disable the beep.sys driver since I don't want dialog boxes to beep at me. Setting Sound Scheme to None doesn't handle this part, for some weird reason (at least in XP).Anonymous
March 31, 2010
The comment has been removedAnonymous
March 31, 2010
The comment has been removedAnonymous
March 31, 2010
This 32/64-bit distinction reminds me of the 16/32-bit distinction in Windows 9x - for some reason the Beep API was only available to 16-bit code; 32-bit code calling Beep just gets the default system sound :-(Anonymous
April 01, 2010
@someone: You're right - the beep sound is a full scale sine wave (it was a full scale square wave before) while the windows sounds are authored at reduced volume. I'll file a bug to reduce the amplitude of the beep sound to match the other windows sounds.