假设我想实现对我的协议的支持foo,这样当foo://blablabla在浏览器中打开资源时,我的程序将被调用foo.exe参数foo://blablabla。这种支持应该适用于 Windows 7、8、10。对于 Windows 7,这很简单 - 只需在注册表中添加一个条目,例如:
HKEY_CLASSES_ROOT
myscheme
(Default) = "URL:Foo Protocol"
URL Protocol = ""
DefaultIcon
(Default) = "foo.exe,1"
shell
open
command
(Default) = "C:\Program Files\Foo\foo.exe" "%1"
但!带有此 API 的页面 ( https://msdn.microsoft.com/en-us/windows/desktop/aa767914 ) 已被标记为已过时(推荐的版本相对而言无处可寻 - 好吧,至少我没有找到任何东西在推荐的链接上)。据我了解,这种方法不能在较新的版本下使用(顺便说一下,它可以在 Windows 10 下使用——我不知道为什么)。我开始研究 Windows 8 的这个问题(https://docs.microsoft.com/ru-ru/windows/desktop/w8cookbook/file-type-and-protocol-associations-model),它说现在程序不能正确建立你的协会——但这怎么可能呢?因为上面的例子对我有用。
这是文档中的引用
Windows 8 中的文件类型和 URI 关联模型已更改。应用程序不再能够以编程方式将自己设置为文件类型或 URI 的默认处理程序。相反,现在用户始终控制文件类型或 URI 方案的默认处理程序。
据我了解,windows 10也不应该支持这样的关联设置?这三个版本的windows下怎么可能实现对这些协议的支持呢?老实说,我对文档一无所知。我只是模糊地想象,现在用户自己必须管理这些关联?这是Windows 8的简短摘录
如果您希望允许您的应用程序的用户访问默认管理 UI(不再支持应用程序内的管理 UI),请与“设置默认程序”控制面板集成
调用 IApplicationAssociationRegistrationUI::LaunchAdvancedAssociationUI 允许用户访问指定应用程序的“设置默认程序”控制面板页面
事实上,有一些关于它的文章。程序仍然可以设置它们自己的关联,你不能强迫它们成为默认关联。现在只有用户可以这样做,这是正确的。
如果您的程序是唯一具有此关联的程序,则应该没有任何问题。如果某些其他程序也与这些文件相关联,那么用户自己将选择他想用哪个程序打开这些文件。