They call me “LoadPicture Lippert”

promised, my least customer impactful bug ever.  "urn:schemas-microsoft-com:office:office" />


version 1.0 was written by one of the VB compiler devs, one of those uber-productive
guys who implements compilers on the weekend for fun.  It
was implemented and tested extremely rapidly, and as a result, a few of the less important
methods in the VB runtime were not ported to the VBScript runtime.  My
first task as a full timer at Microsoft was to add the missing functions to VBScript


August 5th, 1996, I implemented LoadPicture, which, as you might imagine, extracts
a picture from a storage.  Here’s a scrap
of the code I wrote:


* pdisp;

// […
open storage and stream …]

= OleLoadPicture( pstream, 0, TRUE, IID_IPicture, (void **)&pdisp );


I mention that I’d been writing COM code for all of two weeks at the time?


a boneheaded bug there.  I’m asking for
IPicture and
assigning the result to an
IDispatch.  This
is going to crash and burn the moment anyone tries to call any method on that picture
object because the vtable is going to be completely horked. 
I’ve violated one of the Fundamental Rules of COM.
The fact that this bad code
shipped to customers indicates that:


Most seriously, I did not adequately test it before I checked it in

my mentors did not adequately review the code

the test team did not adequately test it before it shipped to customers


are all bad, and I am happy to say that today we are much, much more hard-core about
peer-reviewing, self-testing, buddy-testing, and tester-testing code before it goes
to customers than we were seven years ago.


there is a silver lining of a sort — obviously no one at Microsoft bothered
to run this code after I wrote it.  But neither
did any customers
.  We didn’t get
a bug report on this thing until February
of 1998
.  This thing was in the wild
for almost a year and a half before someone noticed that it was completely, utterly
broken!  No one really cared.


next day the name plate on my office door said “LoadPicture Lippert”.  Ha
ha ha, very funny guys.

Comments (7)

  1. Blake says:

    *chuckles* That is a great story. I do remember when those functions were added, and looking them over in the new docs, thinking that it must mean there was going to be support in the language for dynamically creating images. I also clearly recall finishing reading and concluding that I couldn’t think of _anything_ actually useful to do with that function in VBScript.

    So, that’s the question – is there anything useful you can actually do with that OlePicture, even if the code had been flawless?

  2. Jérôme Tremblay says:

    Not receiving bug reports is hardly evidence that no one used the code. When I try something that crash & burn, I usually assume that I’m doing something wrong. (Ok, ok, I *try* to assume)

    Without the source code to verify the bug, it’s easier to assume I’m too dumb to understand correct usage.

  3. Eric Lippert says:

    > is there anything useful you can actually do with that OlePicture, even if the code had been flawless?

    Not really. You can’t use it in "HTML" IE for security reasons, and why would you want to in WSH or ASP? That leaves "HTA" IE, but IE already has the ability to display pictures.

  4. Peter Torr says:

    LoadPicture is useful for other hosts (or trusted web pages) where you are using ActiveX controls (such as an ImageList) that need to get their images as IOlePictureDisps (or whatever the interface is called). There are regular requests for it to be implemented in JScript —

  5. Pavel says:

    I find it ironic that you consider smart pointer evil, and still your most famous bug is exactly the kind of problem that smart pointers are designed to prevent.

    Are you also using ::CoCreateInstance() instead of CComPtr::CreateInstance()? If yes, are you sure your IIDs and pointer types match everywhere?

  6. Eric Lippert says:

    Yes, I am quite certain that the single place that the script engines call CoCreateInstance does in fact get all the interface types right! How can I be so sure? Because the script engines would crash and die immediately if they were not.

    In your example, smart pointers would have prevented a bug that should have been caught the very first time I ran the code and it crashed. That’s not an interesting class of bug to prevent! Furthermore, the cost (ie, introducing subtle bugs in exchange for obvious ones) is too high.

    The bugs that smart pointers _cause_ are deep, insidious, hard to debug, and require detailed knowledge of both the underlying COM concepts that they are abstracting AND detailed knowledge of the smart pointer implementation.

    Like I said, I’m not smart enough to use smart pointers. IUnknown::Release I understand, and when I screw up some refcounting, I know how to fix it quickly. Smart pointers work great most of the time, and when they fail, it takes me all day to track down the problem.

  7. BillJ says:

    So this is an old thread, but I actually have found a use for LoadPicture. I am implementing it as vbscript to replace an old .bat file. My boss wants me to spruce it up. Im trying to load a company logo onto a msgbox. Ah well, someday….