之前的一篇文章中，我们讲到了在 16 位 Windows 中，实例句柄(HINSTANCE)唯一标识了一个进程。到了 32 位 Windows，内核得到了完全的重新设计，其中之一是：它引入了 “内核对象” 和 “安全描述符”。
在 16 位 Windows 中，实际上是没有进程 ID 的，它使用了实例句柄作为标识进程的手段。这就是为什么 WinExec 和 ShellExecute 会返回 HINSTANCE 的原因。
但在 32 位世界中，HINSTANCE 不再唯一标识正在运行的程序，因为它只是可执行文件的基址(Base Address)。由于每个程序都在自己的地址空间中运行，因此该值在整个系统中几乎不是唯一的。
那么，你可以用 ShellExecute 函数返回的 HINSTANCE 做什么呢？你可以检查它是否大于 32，如果是，则表示调用成功。如果该值小于 32，则为错误代码。在大于 32 的情况下，HINSTANCE 的精确值毫无意义。为什么我费心告诉你 MSDN 中已经涵盖的内容？因为人们仍然很难举一反三。
我一直看到有人采用 ShellExecute 函数返回的 HINSTANCE，并在系统中的所有窗口中寻找具有匹配 GWLP_HINSTANCE 的窗口（如果你仍然生活在未开明的非 64 位兼容世界中，则为 GWL_HINSTANCE）。
由于我上面描述的两个原因，这是行不通的。首先，你得到的 HINSTANCE 的精确值是没有意义的，即使它是有意义的，它也不会对你有任何好处，因为 HINSTANCE 不是唯一的。（事实上，进程的 HINSTANCE 几乎总是0x00400000，因为这是大多数链接器分配给程序可执行文件的默认地址。）
人们想要首先使用这种技巧的最常见原因是他们想对刚刚启动的程序做一些事情，通常是等待它退出，表明用户已关闭文档。
不幸的是，这个计划有其自身的陷阱。首先，正如我们所指出的，你从 ShellExecute 函数获得的 HINSTANCE 是无用的。你必须使用 ShellExecuteEx 函数并在 SHELLEXECUTEINFO 结构中设置 SEE_MASK_NOCLOSEPROCESS 标志，此时将在 hProcess 成员中返回要处理的句柄。
但这仍然行不通。
可以在不创建新进程的情况下打开用户的文档。你会遇到这种情况的最常见情况（但不是唯一的这种情况）是文档类型的注册处理程序请求 DDE 对话。在这种情况下，程序的现有实例已接管对文档的所有处理。等待进程退出与等待用户关闭文档不同，因为关闭文档不会退出进程。
大多数程序可以让你从 “文件” 菜单中打开一个新文档。打开新文档后，用户可以关闭旧文档。（打开新文档时，单文档程序会隐式关闭旧文档。更重要的是，关闭与文档关联的所有打开的窗口不会导致程序退出。）
有些程序甚至在你关闭所有窗口后也在后台运行，要么是为了提供某种持续服务，要么只是因为它们只是预期用户很快就会再次运行该程序，所以他们会延迟最终退出几分钟以查看是否需要它们。仅仅因为进程退出并不意味着文档已关闭。
某些程序检测到以前的实例并将文档移交给该实例。其他程序是启动另一个进程来完成实际工作的存根。无论哪种情况，新创建的进程都会快速退出，但文档仍处于打开状态，因为文档的责任已移交给另一个进程。
没有统一的方法来检测文档是否已关闭。每个程序处理它的方式不同。如果幸运的话，该程序会公开允许你监视打开文档状态的属性。如前所述，Internet Explorer 通过 ShellWindows 对象公开其打开窗口的属性。我知道 Microsoft Office 还为其组件程序公开了一组相当复杂的自动化接口。
总结
进入到 32 位 Windows 的世界后，实例句柄我已经很少用到了。
