Thanks for the suggestions, André, Erich, and Reece. Got a few more ideas at least, though I still haven't found the answer.
Reece Dunn wrote:
The code above is using different methods to locate an IHlinkTarget object, and then calling the Navigate method on that (and presumably returning the HRESULT of that call, although the code listed does not return anything).
I found this interesting, so investigated a bit more. I pulled out the code path from MSDN with no IHlinkSite and no IHlinkBrowseContext (as my HlinkNavigate call does). The test makes a moniker, binds its object to an IHlinkTarget, and executes IHlinkTarget::Navigate.
On native, the test succeeds navigating to winehq.org. But IHlinkTarget::Navigate returns S_OK, not 0x40100. So that probably eliminates IHlinkTarget::Navigate as the source of the mystery value. It was a good guess, anyway.
As near as I can tell, the "unwrapped" version in the test should have all of the same information as the call to HlinkNavigate, but at no point does 0x40100 appear.
Per Erich's suggestion, I tried a number of different flags to both HlinkNavigate and IHlinkTarget::Navigate, but was never able to get either to change their return values at all. On success, HlinkNavigate always seems to return 0x40100.
NOTE: The test is incomplete (there are a lot of methods on the interfaces that are returning E_NOTIMPL), especially the QueryInterface and QueryService methods.
Yeah, I'm aware of that. Native doesn't seem to care, and just removing the IHlinkSite reference entirely returns 0x40100 from HlinkNavigate anyway.
Finally, I've got a test for this which doesn't require any interaction from the user, but will leave a browser window open after the test finishes. Is this acceptable, or should I still leave it in a "winetest_interactive" if statement?
Andrew