Microsoft has published their UI Design Guidelines, but it gets largely ignored as far as I can see - as long as developers don't see UI polish as a high priority issue, it gets pushed back as long as possible like other "polishing" tasks. I know I was certainly guilty of this when I was working in Delphi, less so nowadays.
(And if Raymond Chen's stories are any indicator, developers in general are too lazy to RTFM at all, why would they bother looking for any guidelines for a low priority task.)
If you develop a desktop app on your company's time, your boss will find a million more important things to do than to make sure keyboard accelerators work, make sense, or are configurable. If you do it on your own, you will probably find a different million of things to improve, like the main number crunching loop. After all, you're coding it primarily for yourself so why do you care what Alt-W or Ctrl-U do in your app, you use the mouse. Maybe if you publish it, you'll get some feedback from users and you fix it, but it's more likely that they'll just decide it's "no more limited than that other tool" and you'll never know that it is a problem for them.
Not to mention there are varied GUI toolkits available depending on the programming language you use, each with its own style - Borland's VCL, especially with its button graphics which stand out to this day; MFC; wxWidgets... each with their own idea of how things should be handled. And there's OwnerDraw, giving the more "hardcore" coders another chance to shoot themselves in the foot by allowing the application to draw the control as it saw fit, which of course means they cannot take advantage of the new Windows common controls themes.
Comments
Microsoft has published their UI Design Guidelines, but it gets largely ignored as far as I can see - as long as developers don't see UI polish as a high priority issue, it gets pushed back as long as possible like other "polishing" tasks. I know I was certainly guilty of this when I was working in Delphi, less so nowadays. (And if Raymond Chen's stories are any indicator, developers in general are too lazy to RTFM at all, why would they bother looking for any guidelines for a low priority task.)
If you develop a desktop app on your company's time, your boss will find a million more important things to do than to make sure keyboard accelerators work, make sense, or are configurable. If you do it on your own, you will probably find a different million of things to improve, like the main number crunching loop. After all, you're coding it primarily for yourself so why do you care what Alt-W or Ctrl-U do in your app, you use the mouse. Maybe if you publish it, you'll get some feedback from users and you fix it, but it's more likely that they'll just decide it's "no more limited than that other tool" and you'll never know that it is a problem for them.
Not to mention there are varied GUI toolkits available depending on the programming language you use, each with its own style - Borland's VCL, especially with its button graphics which stand out to this day; MFC; wxWidgets... each with their own idea of how things should be handled. And there's OwnerDraw, giving the more "hardcore" coders another chance to shoot themselves in the foot by allowing the application to draw the control as it saw fit, which of course means they cannot take advantage of the new Windows common controls themes.