Comment by larsberg
14 years ago
I also remember that there was a version of <unnamed product> that rather than sending LVM_GETITEMTEXT would just read the ansi characters corresponding to the selected item during LVN_ITEMCHANGED off of a random location in the stack frame that they had "noticed" held the value. Of course, this eventually changed to a unicode string internally and broke WinZip... so the code that fired off this event would convert the unicode string to ansi and store a pointer in the stack.
I recall being very confused when I encountered this code many years after it had been implemented and had to spend a lot of time tracking through bug databases before discovering why the listview implementation was doing that.
I found it amusing how you avoided to mention the name initially only to lapse (I'm assuming it wasn't intentional) and inadvertently say it was WinZip later on.
Whoops! Yeah, I'd had WinZip in there originally, then I couldn't remember if this particular story had already come out. I've been gone from MSFT for a long time, but it was generally considered bad form when I was there to call out specific products publicly for their bad code.
but it was generally considered bad form when I was there to call out specific products publicly for their bad code
In a way, don't you think that by not allowing customers to know just how bad the code in the software they buy is, you're encouraging more of it?
If there are advantages to producing quick-and-dirty code that violates platform programming guidelines (some would call this sort of sloppy programming "Getting Work Done"), and there are no consequences (Microsoft knows how bad the code is but Winzip's customers don't), doesn't this exert a subtle market pressure that works against good developers who take the time and make the effort to do things right?