<tt><font size=2>Klaus,</font></tt>
<br>
<br><tt><font size=2>> Right now I'm scratching my head why you designed
this in such a </font></tt>
<br><tt><font size=2>> backwards manner (at least that it feels to me
right now, maybe it has </font></tt>
<br><tt><font size=2>> just holes in its functionality which confuses
me) - essentially I'm </font></tt>
<br><tt><font size=2>> lacking an understanding how you think the new
callback should be used </font></tt>
<br><tt><font size=2>> to implement a HGCM module. A little pseudo code
explaining where it is </font></tt>
<br><tt><font size=2>> called (and where it gets its parameters from)
should make this far </font></tt>
<br><tt><font size=2>> easier to understand. Also don't forget to hint
how such a loaded HGCM </font></tt>
<br><tt><font size=2>> service would be used afterwards. I don't see
any way for sending </font></tt>
<br><tt><font size=2>> messages etc etc - please enlighten me :)</font></tt>
<br>
<br><tt><font size=2>I agree that I should have included an example of
how this is intended to</font></tt>
<br><tt><font size=2>be used.</font></tt>
<br>
<br><tt><font size=2>First, my patch isn't intended to implement an HGCM
module, only to allow an</font></tt>
<br><tt><font size=2>external HGCM module to be loaded by VirtualBox. I
haven't (yet) implemented</font></tt>
<br><tt><font size=2>a useful HGCM module, only a shell to verify that
my patch does indeed allow</font></tt>
<br><tt><font size=2>an external HGCM module to be loaded.</font></tt>
<br>
<br><tt><font size=2>Here's a snippet with the pfnVMConfigureVMM callback
of my extension pack</font></tt>
<br><tt><font size=2>module:</font></tt>
<br>
<br><tt><font size=2>        #define kHGCMServiceName
"HGCMShell"</font></tt>
<br>
<br><tt><font size=2>        static int extPack_VMConfigureVMM(PCVBOXEXTPACKREG
pThis,</font></tt>
<br><tt><font size=2>           
               
              IConsole
*pConsole, PVM pVM)</font></tt>
<br><tt><font size=2>        {</font></tt>
<br><tt><font size=2>           
    int rc;</font></tt>
<br><tt><font size=2>           
    char szPath [RTPATH_MAX];</font></tt>
<br>
<br><tt><font size=2>           
    rc = gpExtPackHlp->pfnFindModule(gpExtPackHlp,
kHGCMServiceName,</font></tt>
<br><tt><font size=2>           
               
               
     NULL, VBOXEXTPACKMODKIND_R3,</font></tt>
<br><tt><font size=2>           
               
               
     szPath, RTPATH_MAX, NULL);</font></tt>
<br><tt><font size=2>           
    if (RT_FAILURE(rc))</font></tt>
<br><tt><font size=2>           
            return rc;</font></tt>
<br>
<br><tt><font size=2>           
    rc = gpExtPackHlp->pfnLoadHGCMService(gpExtPackHlp,
pConsole,</font></tt>
<br><tt><font size=2>           
               
               
          szPath, kHGCMServiceName);</font></tt>
<br><tt><font size=2>           
    if (RT_FAILURE(rc))</font></tt>
<br><tt><font size=2>           
            return rc;</font></tt>
<br>
<br><tt><font size=2>           
    return VINF_SUCCESS;</font></tt>
<br><tt><font size=2>        }</font></tt>
<br>
<br><tt><font size=2>Then you have HGCMShell.dll that is part of the extension
pack and implements</font></tt>
<br><tt><font size=2>VBoxHGCMSvcLoad like any other HGCM service.</font></tt>
<br>
<br><tt><font size=2>That's the basic idea. It seemed to me that the main
stumbling block to more</font></tt>
<br><tt><font size=2>and better HGCM examples is that current HGCM modules
have their names and</font></tt>
<br><tt><font size=2>loading hard coded in VirtualBox, with no exposed
mechanism to load an external</font></tt>
<br><tt><font size=2>module. I won't claim that this is the only or the
best way to accomplish that</font></tt>
<br><tt><font size=2>goal, but it gets the job done.</font></tt>
<br>
<br><tt><font size=2>Jeff Westfahl</font></tt>