BrandonLive

The key to getting Explorer to do your dirty work lies in the IShellDispatch2 interface.  Particular, the ShellExecute method. 

IShellDispatch2 is one of the shell automation objects used to support scripting languages.  However, that doesn’t mean you have to use VBScript to gain some value from it.  In this case, IShellDispatch2::ShellExecute is exactly what we want, because it wraps the normal ShellExecute call but runs it from the context of the object implementing the interface – in this case, we want the IShellDispatch2 associated with the desktop shell.

Knowing this is only half the battle, though.  The next trick is to figure out just how to get to the right IShellDispatch2 object (the one for the desktop shell instance of Explorer.exe).

Fortunately, one of our architects, Chris Guzak (seen on C9 here), was able to point me in the right direction and connect up all the dots.

Our hunt begins with the IShellWindows interface, which can be used not only to reliably find the HWND for the desktop shell window, but also to get an IDispatch interface for it:

IShellWindows *psw;
    HRESULT hr = CoCreateInstance(CLSID_ShellWindows, NULL, CLSCTX_LOCAL_SERVER, IID_PPV_ARGS(&psw));
    if (SUCCEEDED(hr))
    {
        HWND hwnd;
        IDispatch* pdisp;
        VARIANT vEmpty = {}; // VT_EMPTY
        if (S_OK == psw->FindWindowSW(&vEmpty, &vEmpty, SWC_DESKTOP, (long*)&hwnd, SWFO_NEEDDISPATCH, &pdisp))
        {

Next, we need the IShellBrowser interface, and we get that by querying for IServiceProvider and asking the SID_STopLevelBrowser service for an IShellBrowser interface.  And from there we can get the IShellView.

IShellBrowser *psb;

hr = IUnknown_QueryService(pdisp, SID_STopLevelBrowser, IID_PPV_ARGS(&psb));
if (SUCCEEDED(hr))
{
    IShellView *psv;
    hr = psb->QueryActiveShellView(&psv);

From there we need to get to that IShellDispatch2 interface that started this whole adventure. 

IDispatch *pdispBackground;
HRESULT hr = psv->GetItemObject(SVGIO_BACKGROUND, IID_PPV_ARGS(&pdispBackground));
if (SUCCEEDED(hr))
{
    IShellFolderViewDual *psfvd;
    hr = pdispBackground->QueryInterface(IID_PPV_ARGS(&psfvd));
    if (SUCCEEDED(hr))
    {
        IDispatch *pdisp;
        hr = psfvd->get_Application(&pdisp);
        if (SUCCEEDED(hr))
        {
             IShellDispatch2 *psd;
             hr = pdisp->QueryInterface(IID_PPV_ARGS(&psd));

At this point you should be able to figure out where to go from here.

If that’s not easy enough, watch out for Part 3 of this series in the next day or two.  It will contain a sample and describe how the Start++ installer makes use of it.

Some people seem to think that calling ShellExecute or ShellExecuteEx and passing the path to an executable will have the effect of telling the shell to launch an application for you.  However, that’s not quite what happens.  These functions simply allow your application to take an action (like launching a process) in the manner the shell typically would (for instance, recreating the behavior of using the Run box).

What’s the difference?  Well, child processes inherit several things from their parents.  They inherit processor affinity, for example.  Most important these days, it seems, is the fact that processes inherit Integrity Level from the process that started them.  That is, except in the case of elevation from medium to high IL (the operation that causes the UAC dialog to appear).

So let’s say you write an installer, and you want to run the application installed at the end of the installation process.  Or heck, maybe you just want to call the application once with a special “/setup” parameter that tells it to do something you couldn’t do from your chosen setup utility.

Where do problems begin?  Well, installers typically run with admin rights.  When your installer launches your application as a convenience to the user, it’s now running with admin rights.  The primary concern here isn’t even the security implications of running at high IL.  After all, the next time your program starts it will run at its normal privilege level.

The problem is that your program is now running in a manner you may not have accounted for when writing it.  For example, users won’t be able to drag-and-drop anything to your application from normal processes.  If your program interacts with other non-admin processes, you may face other problems.  My own Start++ application faced this problem, as it needs to inject a small amount of code into Explorer.exe and then communicate with that code to coordinate its magic.  It can’t do this when running as an admin.

The recent 0.8.x release of Start++ solved this issue, and Start++ now runs immediately after install, in the proper non-admin context.  This is accomplished by having Explorer launch the application on the installer’s behalf. 

Others have addressed this problem in the past.  However, the proposed solutions always seem to take one of these forms:

1. Write an invoker process that runs with non-admin privileges, starts the elevated installer, and then runs your app at the end.
2. Use the task scheduler to launch the app.
3. Inject some code into Explorer and launch from there.

I don’t like #1 because it’s cumbersome and limits how you can name your installer.

#2 also seems cumbersome to me, and is a bit hacky.

#3 is totally hacky, and not something I trust people to do without accidentally destabilizing Explorer (there’s a reason the code Start++ injects into Explorer is incredibly tiny and very carefully crafted).  It can also introduce complications when dealing with multiple target platforms (x86 versus x64).  For example, the CodeProject sample linked to above doesn’t even restrict its WH_CALLWNDPROCRET hook to the thread that it’s targetting.  That means this hook code is immediately going to be loaded by every process on the desktop with a window.  Yuck.

Fortunately, there is a better way.

In Part 2, I describe a better way to get Explorer to run code for you, without having to inject anything into Explorer or use cumbersome workarounds like those described above.