Well, just some hints if someone really needs to:
Use the MSDN Help COM object that the MS document explorer (dexplore.exe) exports. This way you wont have any (future) version conflicts.
The corresponding type library ships in
"C:\Program Files\Common Files\Microsoft Shared\MSEnv\vshelp.tlb".
Here is some short example how i would do it (VC++ using ATL):
<pre>
// generate C++ wrappers for COM interfaces
#import <vshelp.tlb> no_namespace
// filescope MSDN automation interface instance
HelpPtr g_pHelp;
// initialization somewhere (plugin entry)
::CoInitialize( 0);
...
void some_shortcut_handler_method( const char* keyword)
{
try
{
if( g_pHelp == 0)
{
// instanciate the generated wrappers via COM smart ptr
HelpPtr ptr( __uuidof(DExploreAppObj));
g_pHelp = ptr;
}
// use the interface (e.g. we have a keyword and want api doc on it)
g_pHelp->DisplayTopicFromKeyword( _bstr_t( keyword));
}
catch( _com_error& ex)
{
// handle any com errors, e.g. log to ollydbg whatever
Addtolist( 0,0, "Plugin COM error: %s", ex.ErrorMessage());
}
}
...
// deinitialization somewhere (plugin unload...)
if( g_pHelp != 0)
{
// release instance
g_pHelp.Release();
}
// deinit COM
::CoUninitialize();
...
</pre>
Regards,
Anastasius Focht
PS: Im working on a C/C++ interpreter (scripting) plugin using open source interpreter which covers about 95% of ANSI C and 85% of C++. Even ollydbg api can be accessed from the interpreter. Due to limitations in the ollydbg plugin api (and limited spare time) the progess is not so fast. Expect something in a few weeks.
