\nBack in the days of Windows 95 development,\none of my colleagues debugged\na line-of-business application for a major delivery service.\nThis was a program that the company gave to its top-tier\nhigh-volume customers,\nso that they could place and track their orders directly.\nAnd by directly<\/i>,\nI mean that the program\ndialed the modem\n(since that was how computers communicated with each other back then)\nto contact\nthe delivery service’s mainframe\n(it was all mainframes back then)\nand upload the new orders\nand download the status of existing orders.¹\n<\/p>\n
\nVersion 1.0 of the application had a notorious bug:\nNinety days after you installed the program,\nit stopped working.\nThey forgot to remove the beta expiration code.\nI guess that’s why they have a version 1.01.\n<\/p>\n
\nAnyway, the bug that my colleague investigated\nwas that if you entered a particular type of\norder with a particular set of options\nin a particular way,\nthen the application crashed your system.\nSetting up a copy of the application\nin order to replicate the problem\nwas itself a bit of an ordeal,\nbut that’s a whole different story.\n<\/p>\n
\nOkay, the program is set up, and yup, it crashes exactly\nas described when run on Windows 95.\nActually, it also crashes exactly as described when\nrun on Windows 3.1.\nThis is just plain an application bug.\n<\/p>\n
\nHere’s why it crashed:\nAfter the program dials up the mainframe to submit the order,\nit tries to refresh the list of orders that have yet to be delivered.\nThe code that does this assumes that the list of undelivered orders\nis the control with focus.\nBut if you ask for labels to be printed,\nthen the printing code changes focus in order to\ndisplay the “Please place the label on the package\nexactly like this” dialog,\nand as a result, the refresh code can’t find the undelivered order list\nand crashes on a null pointer.\n(I’m totally making this up, by the way.\nThe details of the scenario aren’t important to the story.)\n<\/p>\n
\nOkay, well, that’s no big deal.\nA null pointer fault should just put up the\nUnrecoverable Application Error dialog box\nand close the program.\nWhy does this particular null pointer fault crash the entire system?\n<\/p>\n
\nThe developers of the program saw that their refresh code\nsometimes crashed on a null pointer,\nand instead of fixing it by actually fixing the code so it\ncould find the list of undelivered orders even if it didn’t\nhave focus,\nor fixing it by adding a null pointer check,\nthey fixed it by adding a null pointer exception handler.\n(I wish to commend myself for\nresisting the urge to put the word fixed<\/i> in quotation marks\nin that last sentence.)\n<\/p>\n
\nNow, 16-bit Windows didn’t have structured exception handling.\nThe only type of exception handler was a global exception handler,\nand this wasn’t just global to the process.\nThis was global to the entire system.\nYour exception handler was called for every exception everywhere.\nIf you screwed it up, you screwed up the entire system.\n(I think you can see where this is going.)\n<\/p>\n
\nThe developers of the program converted their global exception handler\nto a local one by going\nto every function that had a\n“We seem to crash on a null pointer and I\ndon’t know why” bug and making these changes:\n<\/p>\n
\nextern jmp_buf caught;\nextern BOOL trapExceptions;\nvoid scaryFunction(...)\n{\n if (setjmp(&caught)) return;\n trapExceptions = TRUE;<\/font>\n ... body of function ...\n trapExceptions = FALSE;<\/font>\n}\n<\/pre>\n\nTheir global exception handler checks the trapExceptions<\/code>\nglobal variable,\nand if it is TRUE<\/code>,\nthey set it back to FALSE<\/code> and\ndo a longjmp<\/code> which sends control\nback to the start of the function,\nwhich detects that something bad must have happened and just\nreturns out of the function.\n<\/p>\n\nYes, things are kind of messed up as a result of this.\nYes, there is a memory leak.\nBut at least their application didn’t crash.\n<\/p>\n
\nOn the other hand, if the global variable is FALSE<\/code>,\nbecause their application crashed in some other function that\ndidn’t have this special protection,\nor because some other totally unrelated application crashed,\nthe global exception handler decided to exit the application\nby running around freeing all the DLLs and memory associated with their\napplication.<\/p>\n\nOkay, so far so good, for certain values of good<\/i>.\n<\/p>\n
\nThese system-wide exception handlers had to be written in assembly\ncode because they were dispatched with a very strange calling\nconvention.\nBut the developers of this application\ndidn’t write their system-wide exception handler\nin assembly language.\nTheir application was written in MFC,\nso they just went to Visual C++ (as it was then known),\nclicked through some Add a Windows hook<\/i> wizard,\nand got some generic HOOKPROC<\/code>.\n(I don’t know if Visual C++ actually had an\nAdd a Windows hook<\/i> wizard;\nthey could just have copied the code from somewhere.)\nNevermind that these system-wide exception handlers are not\nHOOKPROC<\/code>s, so the function has the wrong prototype.\nWhat’s more, the code they used marked the hook function\nas __loadds<\/code>.\nThis means that the function saves the previous value of the\nDS<\/code> register on entry,\nthen changes the register to point to the application’s data,\nand on exit, the function restores the previous value of DS<\/code>.\n<\/p>\n