Question

Several have pointed out that there exists an undocumented message that retrieves the IShellBrowser interface pointer from the common dialog HWND for the file open & save dialogs.

But there is conflicting information (or no information) on whether that pointer is AddRef’d, or if it is just the raw address returned, and no Release() should be called on it?

Answer 1

No. You might find the following link useful: The Rules of the Component Object Model .

Excerpt:

Reference-Counting Rules

Rule 1: AddRef must be called for
every new copy of an interface
pointer, and Release called for every
destruction of an interface pointer,
except where subsequent rules
explicitly permit otherwise.

The following rules call out common
nonexceptions to Rule 1.

• Rule 1a: In-out-parameters to functions. The caller must AddRef the actual parameter, since it will be Released by the callee when the out-value is stored on top of it.
• Rule 1b: Fetching a global variable. The local copy of the interface pointer fetched from an existing copy of the pointer in a global variable must be independently reference counted, because called functions might destroy the copy in the global while the local copy is still alive.
• Rule 1c: New pointers synthesized out of “thin air.” A function that synthesizes an interface pointer using special internal knowledge, rather than obtaining it from some other source, must do an initial AddRef on the newly synthesized pointer. Important examples of such routines include instance creation routines, implementations of IUnknown::QueryInterface, and so on.
• Rule 1d: Returning a copy of an internally stored pointer. After the pointer has been returned, the callee has no idea how its lifetime relates to that of the internally stored copy of the pointer. Thus, the callee must call AddRef on the pointer copy before returning it.

Rule 2: Special knowledge on the part
of a piece of code of the
relationships of the beginnings and
the endings of the lifetimes of two or
more copies of an interface pointer
can allow AddRef/Release pairs to be
omitted.

• From a COM client’s perspective, reference-counting is always a per-interface concept. Clients should never assume that an object uses the same reference count for all interfaces.
• The return values of AddRef and Release should not be relied upon, and should be used only for debugging purposes.
• Pointer stability; see details in the OLE Help file under “Reference-Counting Rules,” subsection “Stabilizing the this Pointer and Keeping it Valid.”

See the excellent “Managing Object
Lifetimes in OLE” technical article by
Douglas Hodges, and Chapter 3 of
Inside OLE, 2nd edition, by Kraig
Brockschmidt (MSDN Library, Books) for
more information on
reference-counting.