don's blog

Summary

A common requirement for an IE extension (BHO or toolbar) is for it to be able to manipulate any request that is made by the browser.  Another common requirement is for it to be able to view any response that the browser recieves.  For example, perhaps you need to add a header to every request that is sent.  Or you wish to view httponly cookies.  Unfortunately, this is no easy task.

PassThroughAPP

If you've ever needed to draw images or icons as if they are disabled ("grayed out"), you will find the Win32 API to be a disappointment.  DrawState with DST_ICON | DSS_DISABLED works but the images look much worse than the standard disabled images on Vista.  And DrawThemeIcon with PBS_DISABLED does nothing special.

I was debugging a release project, where I was in disassembly, and I needed to trace back up the callstack to look at some of the parameters.  The callstack context was jscript.dll, and it was making an IDispatch::Invoke call.  I wanted to look at the DISPPARAMS argument.

If you try (tagDISPPARAMS) 0x01fe3894, it won't work because in the context you are in, the tagDISPARAMS structure is not available.

The problem: A client's IE toolbar was crashing on the beta 2 version of IE 8 as soon as IE started up. This was an easily reproducible crash. The end of the story is that IE 8 has a feature called LCIE which runs each tab in its own process. The toolbar was sending messages to the parent rebar control which as of IE 8 beta 2 is now resulting in a cross-process SendMessage. If the message is not marshalled (more on that later), and contains pointers to memory space, then this could easily crash the receiving process.

Below is an analysis of the discovery process for this bug:

Shindig is an open source project that provides the base implementation for an Open Social container.  I'm exploring a potential Open Social opportunity that will require me to host my own Shindig server, so today was my day to get my hands dirty with a Shindig server.