They call me "LoadPicture Lippert"

They call me "LoadPicture Lippert"

  • Comments 7

As promised, my least customer impactful bug ever. 

 

VBScript 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 2.0.

 

On 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:

 

IDispatch * pdisp;

// [... open storage and stream ...]

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

 

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

 

There's a boneheaded bug there.  I'm asking for an 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

 

Those 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.

 

But 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.

 

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

  • *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?
  • 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.
  • > 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.
  • 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 -- http://groups.google.com/groups?q=LoadPicture+JScript
  • 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?
  • 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.
  • 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....

Page 1 of 1 (7 items)