А как насчёт BOZOSLIVEHERE и TABTHETEXTOUTFORWIMPS?

Это перевод What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? Автор: Реймонд Чен. Входит в книгу The Old New Thing.

В своём предыдущем сообщении я рассказал историю о функциях с забавными именами BEAR, BUNNY и PIGLET. Но что насчёт таких глупых имён как BOZOSLIVEHERE (здесь живут типчики) и TABTHETEXTOUTFORWIMPS (табуляция текста для обывателей)?

Для этого понадобится более глубокий урок истории.

Давным-давно, в старые-добрые времена Windows реального режима, все функции обратного вызова должны были экспортироваться. Это было необходимо из-за сложных технических причин, которые я могу попробовать рассказать, если это ещё кого-то волнует (что мне очень сомнительно). Поэтому оконные процедуры для всех стандартных классов окон (edit-ы, listbox-ы, checkbox-ы и т.п.) экспортировались из библиотеки USER. Экспортировалось и множество других callback-процедур, как, например, процедуры таймеров. И это в дополнение к обычным экспортируемым внутренним функциям, с помощью которых USER, KERNEL и GDI координировали свою работу.

Некоторые люди дисассемблеризировали все эти внутренние функции и напечатали книги о том, как они работают - в результате мы получили целую кучу программ, которые их используют. Для нас это стало неприятным сюрпризом - в конце концов, это же внутренние функции. А когда мы захотели изменить эти внутренние функции (например, добавить в неё параметр, или вообще удалить функцию целиком, потому что мы решили, что она больше нам не нужна), то обнаружили, что из-за этого перестают работать программы.

Поэтому нам пришлось вернуть все функции к старому виду, оставив им всё старое поведение. Все нововведения нам пришлось переделать, перестроить и даже, иногда, полностью убрать (если мы хотели удалить функцию, то изменение можно было оставить, но старая функция всё равно оставалась на месте вместе со своим старым поведением. С точки зрения ОС это был мёртвый код, который лежал лишним грузом на случай, если какое-то приложение вдруг решит смухлевать и обойти документированный путь работы). Но чтобы преподать таким людям урок, таким функциям часто давали идиотские имена.

Например, BOZOSLIVEHERE когда-то была оконной процедурой для edit-контрола с не слишком внятным названием EditWndProc. Тогда некоторые люди, которые хотели использовать оконную процедуру edit-контрола, решили, что писать GetWindowLong(GWL_WNDPROC) - это слишком много, и вместо этого импортировали EditWndProc напрямую. Когда Windows 2.0 (как мне кажется) избавила нас от необходимости экспортировать оконные процедуры, мы убрали их все только для того чтобы обнаружить, что программы перестают работать. Поэтому нам пришлось вернуть их все, но они получили глупые имена как способ наказать программы, которые работают неправильным образом.

В Windows 95 стало ещё хуже, когда все наши оконные процедуры были сконвертированы в 32-х разрядные версии. Проблема в том, что старые оконные процедуры были только 16-ти разрядными. Поэтому мы не могли просто взять и экспортировать новую 32-х разрядную оконную процедуру под старым именем BOZOSLIVEHERE. Нам пришлось написать функцию конвертации, которая брала некорректный вызов 16-ти разрядной оконной функции и переводила его в некорректный вызов 32-х разрядной функции.

И это только верхушка айсберга под названием "обратная совместимость". Вероятно я мог бы несколько месяцев писать только о приложениях, которые делают всевозможные плохие вещи, и о том, что нам пришлось придумать, чтобы снова заставить их работать (часто в ущерб себе). Именно поэтому лично я просто выхожу из себя, когда люди обвиняют Microsoft в злостном обхождении с приложениями во время обновлений ОС. Если какое-то приложение не запускалось на Windows 95 - я считал это упрёком лично мне. Я провёл множество бессонных ночей исправляя баги в чужих приложениях, только для того, чтобы они продолжали работать в Windows 95 (а хуже всего - это игры. Почти всегда производителя игры даже не волновало, что его игра не идёт на Windows 95!).

Читать далее: А как насчет USERSEEUSERDO и GDISEEGDIDO?