Why are there broadcast-based mechanisms in Windows?


Many Windows information mechanisms are based on message broadcasts, among them DDE, WM_FONTCHANGE, and changes in system settings. Why do these mechanisms use broadcasts, when we know that broadcasts can result in the system grinding to a halt due to windows that have stopped processing messages?

Because in 16-bit Windows, you didn’t have this problem.

Recall that 16-bit Windows was co-operatively multi-tasking. When a program received control of the CPU, it could do anything it wanted, knowing that no other programs could run until it explicitly yielded control by calling a function such as GetMessage or PeekMessage. The downside of this, of course, was that a single hung program caused the entire system to hang, because it wasn’t releasing the CPU.

The upside, however, was that if your program was running, then you knew, a priori, that there were no hung programs in the system. How do you know that? Because if there were a hung program, it would be running and not you.

If there’s only one thing, and you have it, then you know that nobody else is hogging it.

Therefore, broadcasting messages was completely safe in 16-bit Windows. You didn’t have to worry about non-responsive programs because you had proof that there weren’t any.

Of course, when the switch to pre-emptive multi-tasking occurred, this assumption no longer applied, but by then it was too late. The broadcast-based model was already in use, and consequently had to be preserved for compatibility reasons. (It would be bad if, for example, Lotus 1-2-3 stopped working on Windows NT because DDE broadcasts were no longer supported. If the Windows NT team had tried that gambit, nobody would have upgraded and Windows NT wouldn’t have survived to make a second version.)

On the other hand, given the risks involved in DDE broadcasts, you probably would be better off designing your program to not use dynamic data exchange as a data communication mechanism, thereby avoiding the pitfall of message broadcasts. No point contributing to the problem.

Comments (22)
  1. Mike Dimmick says:

    Here’s a weird piece of behaviour that I encountered again today. If you’re running a debugging session between Visual Studio .NET 2003, and a Pocket PC device, which has a partnership with your computer (i.e. not connected as Guest), Explorer’s DDE stops working. Any DDE conversations that Explorer starts – for example, to open a document using DDE – hang, including hanging the Explorer window, until you stop debugging.

    In this particular case the application – TextPad from http://www.textpad.com – wasn’t running, but I’m pretty sure it’s been an issue before when the app was already running.

  2. foxyshadis says:

    Is there a better way than broadcasts to push system settings changes? I remember you pushing for their use in the "don’t hack the registry" articles, but I’m not sure if you’re saying there’s something else better now or just another "it’s this way because of some ancient design". Hrm.

  3. KaiArnold says:

    >Is there a better way than broadcasts to push system settings changes?

    Anything you need to alert all programs to will ultimately be a broadcast of some sort. I suppose if it’s just an asynchronous notification, i.e. return value not required immediately or at all, broadcasts could be done with PostMessage instead of SendMessage, and the issue would go away. In fact, isn’t DDE all asynchronous anyway? Why is Send used instead of PostMessage?

  4. msemack says:

    "In this particular case the application – TextPad from http://www.textpad.com – wasn’t running, but I’m pretty sure it’s been an issue before when the app was already running. "

    Ah-ha! That’s what it is!

    I’d been having problems with launching TextPad via associated files at home. I wouldn’t have a problem if I launched TextPad and then opened the file. I made the problem "go away" by turning off DDE in the file associations.

    I was stumped as to why I was having problems on my home machine, but not at work. It makes sense now. At home, I have an iPaq.

    Thanks for troubleshooting my problem Mike :-)

    I’d been meaning to post to TextPad’s forums about this, but I lost interest in the problem once I had found a workaround.

  5. Mike says:

    A question:

    As NT was (basically) emulating Win16, couldn’t it also have kept this behaviour in the Win16 code and do something more reasonable (more sane) for Win32/preemptive?

    I know of many things I immediately spotted as "impossible" to do in Win95 due to how 3.11 was cooperative – and I was right on every one of them (the very useful Recorder was the most obvious one).

  6. William says:

    Is there any way to determine whether my system is suffering from this broadcast halt? Because I encounter randomly ‘hanging’ for a few seconds EVERYDAY, even the mouse cursor doesn’t move during that period :{

  7. Centaur says:

    @William

    I have had such symptoms when my hard drives’ connections were insecure. An HDD powers down, Windows tries to communicate with it for several seconds (especially when some file on it is opened), fails and logs an event. Then everything works until the next access to the (now disconnected) drive. Drives me nuts :)

  8. Moi says:

    Huh? Couldn’t the broadcasts not have been restricted to those programs running within WoW, and another way have been found of achieving the same end for newer applications?

  9. oldnewthing says:

    There are already ways of achieving the same end for newer applications without resorting to broadcasts. (COM servers and OLE, for example.) Too bad people didn’t use them.

    That’s because when you’re trying to convince an industry to do something (port their code from Win16 to Win32), you want to make it as easy as possible – best case is to make it happen for free. Otherwise nobody will do it.

    It’s the problem of surviving to v2 all over again.

    (As a counter-example: To be a good power management citizen, you have to change your application in certain ways. This takes work. Therefore nobody does it.)

  10. GregM says:

    Raymond, are these "good power management citizen" things documented anywhere? I don’t think I’ve run across them before.

  11. Norman Diamond says:

    Tuesday, June 28, 2005 5:40 AM by Centaur

    > @William

    > I have had such symptoms when my hard

    > drives’ connections were insecure.

    I’ve had them with CDs that are going bad and the drive + OS are making multiple retries. That’s the lucky situation. Next the unlucky situation:

    > An HDD powers down, Windows tries to

    > communicate with it for several seconds

    > (especially when some file on it is opened),

    > fails and logs an event. Then everything

    > works until the next access to the (now

    > disconnected) drive.

    Or in a noisy environment (electrical noise) where the HDD or CD drive are powered properly but not responding properly. Windows NT4 would give up and continue with its other stuff. Windows 2000 tries to log an event exactly as you say. In order to try to log an event, it writes to the hard drive that is located on the exact same cable that is suffering from noise, so 2000 hangs. It doesn’t give up, it doesn’t work until the next access, it needs to be powered off and on again. I haven’t had XP or 2003 in an equally noisy environment so don’t know if they’ve improved or not.

    Tuesday, June 28, 2005 8:11 PM by GregM

    > Raymond, are these "good power management

    > citizen" things documented anywhere?

    DDK.

  12. GregM says:

    Norm, does this mean that these "good power management citizen" things are only for device drivers?

  13. oldnewthing says:

    There is plenty for applications to do too. SetThreadExecutionState, closing network resources when going on suspend, turning off power-wasting animations when running on battery… I believe there will be a PDC talk on this subject.

  14. Johan says:

    So does this mean that you think that TaskbarCreated shouldn’t be broadcasted and that it should instead do something involving COM servers and OLE?

    For the record, I think the responses to the question about documentation of how to be a good power management citizen is a better explanation on why so few are than that you need to change your applications. It’s tough to handle those unknown unknows – just ask Donald Rumsfeld.

  15. Norman Diamond says:

    Wednesday, June 29, 2005 11:04 AM by GregM

    > Norm, does this mean that these "good power

    > management citizen" things are only for

    > device drivers?

    Ouch. I gave that answer because I’m most aware of it in the case of device drivers. Further examples in a moment. But Mr. Chen gave some correct answers, and indeed he had already stated it correctly and I misread it:

    Tuesday, June 28, 2005 10:08 AM by oldnewthing

    > (As a counter-example: To be a good power

    > management citizen, you have to change your

    > application in certain ways. This takes

    > work. Therefore nobody does it.)

    APPLICATION. Right. Sorry for misreading that as driver.

    But now this leads to a question. When Windows 2000 refused to enter hibernation on a machine that was capable, there was some way of finding which driver vetoed the hibernation request. I’m positive I once read a Knowledge Base article saying where to find a log file, I read the log, and found what to fix.

    When Windows XP refuses to enter hibernation on a machine that’s capable, how can the user find the reason? For example on a machine with a single Windows XP (preinstalled by OEM), 20 times in a row it will hibernate and wake up, then one time it will refuse. From that point until the next reboot, Control Panel will not even be aware of a theoretical possibility of hibernation. After rebooting it will be possible to hibernate another 50 times until the problem resurfaces. There is no change to any driver during this time. In fact I have a sneaking suspicion that an application is doing it, and the application is a famous integral part of Windows. Is there a log file anywhere so the user can find where the veto came from?

    When hibernation is unavailable standby still works, but then the result is the same as a crash if the battery fully drains.

  16. GregM says:

    Raymond, since I’m not going to PDC, if you could point out a summary of the presentation, or some other resources, that would be helpful.

    Norm, I have 2 GB memory in my current notebook. I had 1 GB in my previous notebook. This notebook will refuse to hibernate on a regular basis. I was able to reproduce this quite readily by having Visual C++ break 1GB commit charge during the link phase of building my application. This was done working with MS support, and disabling all non-windows stuff from startup. Unfortunately, since then, I haven’t had time to get back to this issue to pursue it any further.

    This sounds very much like an XPSP1 issue for which there was a hotfix, and that fix was included in SP2. The problem is that this machine shipped with SP2.

  17. Norman Diamond says:

    Wednesday, June 29, 2005 11:06 PM by GregM

    > Norm, I have 2 GB memory in my current notebook.

    Me too, but I don’t run Visual Studio on it directly, I occasionally run Visual Studio in guest machines under Virtual PC, or more frequently run Visual Studio on real machines but not on my current notebook.

    > I was able to reproduce this quite readily

    > by having Visual C++ break 1GB commit charge

    After you exited from Visual Studio your commit charge went down, right? But did hibernation remain impossible after that?

    During days of XPSP1 I learned to close all Virtual PC guests and close the main Virtual PC application itself before trying to hibernate. But this was not the only cause of refusals to hibernate. For example if I last ran Virtual PC on Sunday and closed it down, then hibernated once after that on Sunday, twice on Monday, twice on Tuesday, once on Wednesday, then suddenly the next time on Wednesday it refuses to hibernate and forgets that the word hibernation ever existed, then I think that Virtual PC is not the reason.

    I applied XPSP2 nearly a year ago, and VPC2004SP1 shortly after that. They have had no visible effect on this issue. I suppose I could experiment trying to hibernate while VPC is running and see if there’s been any improvement in that part of it, but I haven’t tried it.

    > This sounds very much like an XPSP1 issue

    > for which there was a hotfix, and that fix

    > was included in SP2.

    I’m not sure if I was aware of the hotfix for SP1. Some time ago I made a list of hotfixes I wanted and phoned Microsoft, but they wouldn’t even let me tell them the Knowledge Base numbers of the hotfixes that I wanted unless I opened a paid support incident. As for whether the fix was included in SP2, it might be included and it might help for some causes that are different from whatever’s hitting me, or it might not be. There are some fixes that get into English language versions without getting into others.

  18. It reserves a DC for the entire class.

  19. It’s a legacy interface.

  20. We had an issue recently where DDE broadcasts were being blocked on a system. The customer noticed that

Comments are closed.