Неогороженное минное поле – это еще не повод по нему ходить

Пришло письмо с вопросом:

Обнаружилась следующая проблема:

Наша программа сохраняет и считывает последнюю открытую ею директорию в разделе реестра, где сохраняют последние посещенные ими директории и другие программы, а именно в ветке «HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRU». Это в 32-х разрядной версии. Но оказывается, что в 64-х разрядной версии данной ветки реестра в узле HKCU не существует, а она находится в «HKEY_USERS<некий идентификатор пользователя>\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRU».

Так вот вопрос: как мне программно доступиться к этой ветке, если идентификатор пользователя неизвестен? Или, может, есть способ узнать этот идентификатор каким-то образом? А может где-то есть в реестре зеркало этой ветки, к которой можно получить доступ более простым способом?

Вообще-то, «HKCU» и «HKEY_USERS<некий идентификатор пользователя>» - это одно и то же, так как псевдо-описатель HKEY_CURRENT_USER отображается именно на «HKEY_USERS<SID пользователя>». Но в процессе обсуждения я на этот момент не обратил внимание, так как нарисовалась более глобальная проблема:

Исторически так сложилось, что эти данные хранятся в реестре в ветке «HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRU». Причем это в версиях ОС начиная с Висты. А в ХР эта ветка была чуть другая: «HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedMRU». Да и формат был чуток другой. Вот и приходится под каждую версию ОС корректировать нашу логику.

Возникает логичный вопрос: «Почему это стороннее приложение озабочено форматом списка недавно открытых файлов стандартного диалога сохранения?» В процессе дальнейшего разговора выяснилось, что программа использует свой собственный диалог сохранения, но при этом хочет сохранять список файлов в том же ключе реестра, что и стандартный диалог. Откуда происходит такое требование – не очень понятно. Стандартный диалог сохранения в любом случае держит отдельный список файлов для каждого приложения, так что особой причины разделять список между приложениями вроде бы и нет.

В конце концов, мы с автором письма сошлись на том, что ему нужно создавать свой собственный ключ и хранить там списки файлов в любом удобном формате. Это наиболее универсальный совет в подобных случаях. Каждый раз, когда заходит речь об использовании существующего ключа в реестре, стоит задать себе вопрос: «Кто владеет этим ключом?» Если ключ не документирован в MSDN - им владеет кто-то другой. Что, в свою очередь, означает, что, как минимум, польза от использования этого ключа должна перевешивать дополнительный геморрой, связанный с обеспечением совместимости с чужим кодом. Геморрой не только разработчиков, которым нужно будет заново разбираться «как это работает» и переписывать свой код под каждое изменение чужого кода, но и пользователей. Ну и геморрой разработчиков этого чужого когда, если подобная программа, не дай бог, стала достаточно популярной.