v2.6.0.0: HashCheckPackageHost.exe: design rationale and which problems it solves?

[SirKocur]

Hi Mounir,

I have a few questions about the architectural decision in v2.6.0 to use
HashCheckPackageHost.exe as a separate process. The answer would be very
useful for shell extension developers in general.

Looking at the implementation, I see that:

1. HashCheckPackageHost.exe is launched via CreateProcessW from
   IExplorerCommand::Invoke
2. It receives the operation type (/hashcheck-create, /hashcheck-verify,
   /hashcheck-options) and a path list file as arguments
3. The actual UI (property sheet, verify window, options dialog) runs inside
   the host process, not in explorer.exe

My questions:

1. Was this approach driven primarily by Win11/IExplorerCommand technical
   requirements (e.g., the sparse package model, COM apartment constraints
   in the modern context menu pipeline), or was it also intended to solve
   long-standing issues with shell extensions running in-process inside
   explorer.exe?

2. Specifically - does running the UI in a separate process help with:

   • DLL unloading races (where explorer.exe unloads the DLL while a
     worker thread is still hashing)?
   • Window theming issues (e.g., applying dark mode to property sheets
     hosted by explorer.exe vs. owning your own top-level windows)?
   • Crash isolation (a bug in OpenSSL/BLAKE3 taking down the whole
     explorer.exe process)?
   • COM apartment / message pump conflicts when showing modal dialogs?

3. Do you plan to eventually route ALL HashCheck UI invocations through
   HashCheckPackageHost.exe (including the classic IContextMenu path),
   or will it remain Win11-only?

4. Would you recommend the host-process pattern as a general best practice
   for shell extensions that show non-trivial UI, even if Win11 modern
   context menu support is not a goal?

The reason I'm asking: I'm working on a project that hits some of the
known pain points of in-process shell extensions (window theming, DLL
unload races during long-running operations) and I'm trying to decide
whether to invest in a similar host-process architecture or continue
fighting these problems in-process.

Any insights would be greatly appreciated.