如何将 IFileOperation 与相对路径和绝对路径一起使用？

Windows Shell 被组织成称为 Shell命名空间的层次结构：Shell命名空间简介：

Shell 命名空间将 Shell 管理的文件系统和其他对象组织到一个单一的树结构层次结构中。从概念上讲，它是文件系统的更大、更具包容性的版本。

它的意思是，在 Shell 命名空间中，有文件系统（或我称之为“物理”，也将可能的内核文件系统视为物理的）项和虚拟项。虚拟物品的例子是：

• “这台电脑”文件夹
• 回收站（项目链接到文件系统的地方）
• 控制面板（完全虚拟）
• 搜索文件夹（其中项目是指向其他项目的链接）
• 自定义命名空间扩展（可以扩展Shell空间与自定义Shell空间扩展到连接到数据库，云存储等）
• 等等。

所有这些项目都使用相同的系统进行标识：PIDLs。一个PIDL是壳牌项目一个完整的文件路径是到（物理）文件或文件夹的内容。

项目也可以使用它们的解析名称来标识，该名称由IShellFolder::GetDisplayNameOf 方法和_SHGDNF 枚举间接定义，如果包含的文件夹支持它。请注意，PIDL是严格必需的（每个项目都有一个），而解析名称则不是。

从 Windows Vista 开始，建议使用IShellItem基于 API。并且IFileDialog也被推荐，因为它支持 PIDL（=> 虚​​拟项目），而不仅仅是文件系统路径。

伪代码SHCreateItemFromParsingName或多或少是：

1. 调用SHParseDisplayName(name)=> PIDL（旧的基于 PIDL 的 API）
2. 调用SHCreateItemFromIDList(pidl)=> 一个 IShellItem

这确实证明SHCreateItemFromParsingName可以被称为SHCreateItemFromDisplayName......

在内部，SHParseDisplayName的代码或多或少是：

1. 获取桌面IShellFolder（桌面是 Shell 命名空间的根）
2. call IShellFolder::ParseDisplayName(name) => a PIDL（相对于桌面，与绝对相同，因为桌面是命名空间根）

IShellFolder是所有命名空间文件夹实现的接口：标准的 Windows 提供的和自定义的，为文件系统项目或虚拟项目提供服务。

现在，IShellFolder::ParseDisplayName实施各不相同。自定义 Shell 文件夹可以选择以它喜欢的方式实现它（这可能会导致问题）。

然而，桌面的IShellFolder实现非常复杂，并且理解文件系统路径而不是显示名称。该DOC这样说：

带有显示名称的以空字符结尾的 Unicode 字符串。由于每个 Shell 文件夹都定义了自己的解析语法，因此该字符串可以采用的形式可能会有所不同。例如，桌面文件夹接受诸如“C:\My Docs\My File.txt”之类的路径。它还将接受对命名空间中具有使用“::{GUID}”语法关联的 GUID 的项的引用。例如，要从桌面文件夹中检索控制面板的完全限定标识符列表，您可以使用以下命令：

::{控制面板的CLSID}\::{打印机文件夹的CLSID}