It’s no secret that I’ve been obsessed with fixing Explorer’s Automation-related unresponsiveness bug. (Yeah, they made that KB page just for little ol’ me.) A few months ago, Microsoft’s developer support rep told me that advising users to use the old SysListView32 control instead of the default control was the best solution Microsoft would provide me with. They will not issue a hotfix for it, but they’ll “look into it” for Windows 8. To me, that solution is unacceptable. How can I say to people, “Yeah, QTTabBar makes Explorer so much better, except you also have to make it worse by using an ugly, outdated control as the main component“?
Well, today, I’m thrilled to announce that I have accomplished what others might have called impossible: I have effectively fixed Microsoft’s bug for them, without access to a single line of source code. After a lot of painful stepping through assembly code and some cleverly placed API hooks, the scrolling lag is completely and totally gone, even after tens of thousands of queries. Hotfix? I don’t need no stinkin’ hotfix!
Needless to say, this calls for a much earlier Beta 2 than anticipated. I want to test a little longer to make sure the lag is really gone for good, and I’m going to try to get a few more bug fixes in there too, but I plan on releasing within in a week or so. Stay tuned; I’ll post the gory details of exactly how the hack works in a future blog post.
EDIT: A friend of mine pointed out that this post sounds a little egotistical. I’d be lying if I said I didn’t feel good about this accomplishment, but just to be clear: the reason for my exuberance in this post isn’t so much that I fixed it, but that it was fixed. Not so long ago, I was feeling little depressed thinking that we would probably be living with this bug forever. But now that it’s fixed, I feel like QTTabBar is finally truly compatible with Windows 7. And that’s what makes me the happiest.