If what you’re doing is undocumented, it’s not guaranteed to keep working, and your promise not to complain doesn’t really hold water

A customer (via their customer liaison) wanted to know how their application can control another application's common dialogs.

They have code that works on Windows XP that extracts the common dialog history from an undocumented registry key, then edits the history in order to inject themselves into it. It all works great. But on Windows 7, the structure of this registry key changed, and they cannot figure out how to reimplement the feature. Can you tell us where Windows 7 stores this information, and how to decode it, and how to re-encode the desired replacement data? Thanks!

The feature you desire is not supported. Mucking about in undocumented registry keys is not supported. The implementation can change at any time, and as your customer noticed, it did.

The customer liaison replied,

Yes, I was afraid that this was the case. But maybe somebody can tell us how to do it anyway. I have already told the customer that what they are doing is unsupported and can change at any time. I can provide a strong warning that this is something they should not be doing.

I replied, "The strong warning didn't help last time, when they complained that their trick stopped working in Windows 7. There's no indication that they won't complain again when they test on Windows 8 and found that the keys changed again."

The customer liaison conceded, "Good point."

Comments (13)
  1. skSdnW says:

    While I can see how this could be useful if these applications complimented each other (SVG and Bitmap editors etc) but odds are that they are doing this for other reasons and that is pure evil. Too bad you have the naming policy because some apps deserve to be called out.

    1. Medinoc says:

      Indeed, this sounds like “bonus for that feature” material.

  2. Nick says:

    Pretty sure the Official Answer® is to call the Other Application’s creator and ask how to control their common dialogs (and be told some strong version of “no”).

  3. Joshua says:

    Huge proxy fight. I wonder what the response might be if presented with choice of abuse undocumented behavior or leave Windows.

    1. Alex Cohn says:

      I am afraid that it will be much harder to control common dialogs of a third-party Windows application from an app running under some alternative OS.

  4. alegr1 says:

    As a coincidence, a few years ago I actually implemented my variant of the file dialog in Windows 98 then Win2K then XP with history for directories (and also folder select dialog with history). File dialog used custom template. It’s been a pain to keep them compatible.
    I haven’t have time to make it working with latest MFC because the latest MFC relies on the new file dialog API.

  5. Boris says:

    I suppose the correct answer would be that the functionality is unsupported, but Microsoft would really, really like to help if only they would describe the reason for doing so more clearly and explicitly. We assume the best of intentions, but if it should turn out to be unsupported or even illegal activity, then Microsoft can’t very well help, now can it?

  6. Scarlet Manuka says:

    Surely it is only a matter of time before a malware author contacts their customer liaison to complain that the exploit they were using has been patched, and asking for another method they can use to achieve remote code execution.

    1. cheong00 says:

      I think if they’re not able to find one themselves, they pay for others for one.

      I heard there’s market on this sort of things on those hacker sites, but never go and confirm myself. :)

    2. Kevin says:

      I am 99% certain there is at least one script kiddie who was dumb enough to do exactly that.

  7. Ray Koopa says:

    That’s just pure lazyness right away. Since Windows 7, there’s a custom section for program-specific links in the open/save dialogs at the very top of the explorer tree where their cheap program could throw its own interesting locations in.

  8. Cesar says:

    We can go further: the implementation can change at any time, not only on major upgrades (XP -> 7 is a major upgrade).

    It could change on a minor upgrade (SP1 -> SP2 for instance). It could change on a small patch (KBnnnnnn…). It could even change with no upgrade at all! For instance, the history they are meddling with might be a cache which can randomly be discarded and regenerated.

  9. Pierre says:

    Win RT: the OS/2 of the 21st century.

    BTW you don’t accept suggestions anymore.

Comments are closed.

Skip to main content