At one time, M$ published user manuals and specifications for their products. Now, having learned that few people read them, and that the ones who do will sue them because their product isn't shipped in accordance with their manuals and spec's, they just don't publish 'em any longer. IF they don't tell us what their product is supposed to do, we can't blame them when it doesn't do that.

The fact that interprocess communication doesn't work well doesn't give them an excuse to publish a product that doesn't work well. That rundll32.exe, or whatever it was, is not the problem, but the fact that it frequently pops up as the process that isn't automatically dismissed when it should be indicates that one task isn't telling the other what it's doing and when it's finished. That can be caused by application programmers being sloppy, or it can be caused by the API being insufficiently rigorous in its description and handling of tasks under its management.

Which do you think it is? If they (M$) would design their products for test, they'd know, and be able to fix these problems rather than simply publishing a new product with a new version of the same old bugs.

RE