Free Associations : ie

IEProcess.h - IE inproc APIs

zekel — Wed, 05 Nov 2008 01:01:00 GMT

IE8 beta1 introduced Loosely Coupled IE (LCIE) which gives tab a level of process isolation from the frame: http://blogs.msdn.com/ie/archive/2008/03/11/ie8-and-loosely-coupled-ie-lcie.aspx.

For the most part this works pretty well. But certain binary extensions (activeX objecst, BHOs, etc) that are already deployed have assumptions about window hierarchy and process model. To get this to work the IE team has been diligently testing extensions and finding ways to fix them. For the most part we do this by using the Detours library to redirect Windows APIs to private wrappers. We have been using this technique since we added tabs. For tabs we were just avoiding tabs contending for window modality by calling functions like MessageBox(). Our hook would effectively created a queue of modal dialogs avoiding confusing dialogs from hidden tabs, etc.

But not all problems can’t be fixed by just detouring an existing API this way. A reasonable example is when an application has a custom modal dialog manager. This means that our hooks on DialogBoxParam() and related functions won’t be hit. Other hooking options are complex and fragile so we opted to expose the "right" way for external developers. IEProcess.h exposes functions for helping with this: http://msdn.microsoft.com/en-us/library/cc994365(VS.85).aspx

This API was designed with the idea that many components that are loaded in IE can actually be loaded elsewhere as well. So instead of linking to IE dlls directly, some level of indirection is required. This avoids the cost of loading a DLL when it won’t be used, and allows the IE dev team a little flexibility for how we expose these APIs. First a caller detects whether any IEProcess exports with the following code:

    HMODULE ieModule = IEProcess:GetProcessModule(); 
    //    if ieModule != NULL then there are exports available

After retrieving the module, the methods are grouped similar to COM interfaces, but are static, and exist for the lifetime of the process. This is similar to doing GetProcAddress() for a set of functions:

    static const IETabWindowExports* ieExports = GetTabWindowExports(ieModule);
    //   ieExports contains the methods we need to call

Now if you look here http://msdn.microsoft.com/en-us/library/cc994365(VS.85).aspx again, you will see how we implemented our detour of DialogBoxParamW(), and this can be fairly easily replicated to a custom dialog manager. WaitForTabWindow() queues your modal call with the tab; when it returns, its your turn. Then take the lock with AcquireModalDialogLockAndParent(), which will create an appropriate top level window if required for security boundary reasons. Then show the modal dialog, and call ReleaseModalDialogLockAndParent() when done. It’s that easy!

This is super straightforward if you always run in IE, but looks a little awkward to handle the error conditions if you run outside IE. So I wrote a wrapper class that does pass through logic when running outside of IE. It has an H and CPP file. This is how MSHTML does its IE synchronization for HTML Dialogs, which have a custom dialog manager. The header is below, and the CPP is attached.

#pragma once

/// 
/// Helper class that does delay load binding to the IEProcess
/// export tables with fallback logic for easy pass through.
/// 
class IEProcessHelper
{
public:

    /// 
    /// Detect whether per-process exports are enabled for this process.
    /// This does it's binding on demand and the result is cached.
    /// 
    static bool IsIEProcess();    

    /// 
    /// Retrieve the tab window related exports for this process.
    /// If they aren't available it returns a table of fallbacks 
    /// with pass through logic so that this never returns NULL.
    /// This does it's binding on demand and the result is cached.
    /// 
    static const IETabWindowExports* TabWindow();

private:
    
    static HRESULT WaitForTabWindowNotImpl(
        __in    bool    allowUnknownThread,  
        __in    HWND    hwndParentProposed,  
        __out   HWND*   phwndParentActual);  

    static HRESULT AcquireModalDialogLockAndParentNotImpl(
        __in        HWND    hwndParentProposed,  
        __out       HWND*   phwndParentActual,
        __deref_out HANDLE* phModalDialogLock);

    static void ReleaseModalDialogLockAndParentNotImpl(
        __in_opt HANDLE hModalDialogLock);

private:
    static const IETabWindowExports _TabWindowExportsNotImpl;
    static const IETabWindowExports* _TabWindowExports;
    static HMODULE _hmoduleIEProcess;
    static bool    _checkedIEProcess;
};

This simplifies our detour so that the following is the new calling pattern, and doesn’t require any kind of fallback logic.

INT_PTR WINAPI Detour_DialogBoxParamW(
        HINSTANCE hInstance, LPCWSTR lpTemplateName, 
        HWND hwndParent, DLGPROC lpDialogFunc, LPARAM dwInitParam)
{
    INT_PTR nRes = -1;

    HRESULT hr = IEProcessHelper::TabWindow()->WaitForTabWindow(
            false, hwndParent, &hwndParent);
    if (SUCCEEDED(hr))
    {
        HANDLE hModalDialogLock;
        hr = IEProcessHelper::TabWindow()->AcquireModalDialogLockAndParent(
                hwndParent, &hwndParent, &hModalDialogLock);
        if (SUCCEEDED(hr))    
        {
            nRes = Real_DialogBoxParamW(hInstance, lpTemplateName, 
                    hwndParent, lpDialogFunc, dwInitParam);

            IEProcessHelper::TabWindow()->ReleaseModalDialogLockAndParent(
                    hModalDialogLock);
        }
    }
    
    return nRes;
}

Check out MSDN related docs for running in Protected Mode: http://msdn.microsoft.com/en-us/library/bb250462.aspx

The Bizarre and Unhappy Story of 'file:' URLs

zekel — Thu, 19 May 2005 19:15:00 GMT

For my first blog entry, I will start with something I wrote for my team back in 1997 (reedited for this blog) that has been helpful to generations of subsequently bewildered developers:

Go back to 1995 and a small team dreaming an impossible dream of the Internet on Windows! URLs were young, so young they still hadn't been seen in a television ad....

IE1.0 was just a fledgling trying to get some features that Mosaic (or the looming competitor) didn't have. Since we shipped with Win95 and a big feature for Win95 was Long File Names, so IE needed to have support for spaces in names. Since there was no spec for the "file" protocol scheme (heck there was practically no spec for any protocol) we added automagical escaping spaces. We happily escaped spaces all over the place, and since nobody used our browser it didnt make a whits difference.

Now IE began to mature and grew into a precocious 3-year-old, and when the powers that be noticed this, they decided that 3 was such a big number that the browser needed a new image. That image was componentization. The browser was taken and split in three major parts. One part became mshtml (for rendering HTML) another shdocvw (for hosting DocObjects), and the third was wininet and urlmon (two binaries that were basically inseparable for downloading and caching content). Unfortunately a key component from the platform was missing, so it was replicated into each of the other components. That was an URL parsing platform.

No one component could agree with the others about the best way to handle the wild URLs that were so plentiful. So each component came up with slightly different rules, although very logical, based on its personal fantasies of the one true URL. The fantasies were fairly similar but the devil is in the details and these URLs went through a lot of metamorphoses on each trip down the stack to the wire. Now each breed of URL had its own issues with these transformations, but in the end all children must be pushed from the nest to learn to fly on their own.

Enter IE4, Nashville, Win98, the next generation of everything. And with it the new patron saint of URL parsing. Now someone undertook the plight of the underrepresented URLs very seriously and wished to give them the respect they deserved. Some cried with fear, and others with joy, but none could debate the necessity of a savior. So the little URLs were taken and given a safe place to live and be loved: shlwapi.dll. And the saint went amongst the browser and the browser's friends and said, "Let no one but the chosen ones touch or talk or molest these URLs, and there will be a peace among us." Some resisted, but they were put down as heretics should be and a peace came upon the land. Except for the one abused problem URL: file:.

No one had been quite as abused as the the little file: URL. This URL was special because we had always used files and DOS paths (and no one at the time knew about path canonicalization attacks), everyone was quite sure what they looked like , acted like, and even tasted like. It didn't help that the file: protocol remained in RFC limbo as a platform/OS specific protocol. So the browser and the browser's little friends would take turns dressing a DOS path like an URL in a pink bunny suit and undressing the URL with a pair of rusty scissors, pretending it was the same DOS path they started with. Only the simplest of URLs was able to withstand this abuse, and it soon became clear that something would have to be done, lest the little file: URLs go off on their own and be lost forever.

After much praying and meditation and consultation, it was finally decided that file: URLs must have two forms, one being the well formed easily communicable URL form and the other a legacy mutant form of a DOS path. These two forms had different purposes, and soon different personalities. The URL form lived happily inside the browser, but any time the browser needed to talk about the file: URL with its friends, it would clone and mutate the URL into its ugly half DOS form.

What this MEANS:

There are two kinds of file: URLs. The first is the well formed URL style. This is allowed query strings, fragment IDs, escape sequences and all the other goodies that URLs are supposed to support. We call this a healthy file: URL. The other kind is basically a DOS path with "file://" stuck on the front. We use this for legacy communication with outsiders only. We call this the legacy file: URL. Examples:
DOSPATH:         c:\windows\My Documents 100%20\foo.txt 
HEALTHY:         file:///c:/windows/My%20Documents%20100%2520/foo.txt

LEGACY:          file://c:\windows\My Documents 100%20\foo.txt 


DOSPATH:         \\server\share\My Documents 100%20\foo.txt 
HEALTHY:         file://server/share/My%20Documents%20100%2520/foo.txt 
LEGACY:          file://\\server\share\My Documents 100%20\foo.txt 
NOW all of the Url* APIs in shlwapi, and thus everyone in IE4, understand the difference between these two types of URLs and act accordingly. as long as a client of the APIs, doesn’t try to access the data directly, there is no issue whatsoever. in other words as long as you dont have code anywhere that looks like this:
LPTSTR GetFilePath(pszUrl)

{

     if (0 == lstrcmpn("file://", pszUrl, sizeof("file://")))

     {

          return pszUrl + sizeof("file://");
     }
     return NULL;
}
but instead always call shlwapi like this:
PathCreateFromUrl(pszUrl, pszPath, cchPath, dwFlags);
You will always be happy and golden. Straying from the path is straying into unknown lands. There are of course flags that you can pass into some of the APIs that will change the form the file: URLs when they come out, but I highly recommend not using it for any reason, as it just increases the chances of creating more bizarre unsupportable behavior.