Как работают Windows-компиляторы?
Отложим пока и компиляторы, работающие в среде MS-DOS, и поговорим о том, как работают Windows-компиляторы, создающие автономные приложения: Delphi, C++, Fortran и другие. Как ни странно, и специалисты это могут подтвердить, особой разницы в способе генерации кода по сравнению со старыми версиями компиляторов нет. Более того, программы под Windows организованы намного проще, словно разработчики заранее предвидели возможность их анализа.
С появлением Windows программы имели два основных формата заголовков – NE и PE, причем NE уже давно не применяется. Вначале программы идет штатный заголовок MZ файла, представляющий собой заглушку (stub), выводящую на экран надпись о том, что программа требует наличия Windows. Там же, по определенному смещению, указан адрес начала расширенного заголовка, который и является чудесным «паспортом» приложения. Дело в том, что в заголовке перечислены важнейшие сведения о программе: ссылки на списки импортируемых функций, адреса ресурсов, настройки программы под определенную платформу и многое другое. Как вы знаете, Windows программы не любят работать «в одиночестве»: им подавай еще целую кучу как собственных DLL библиотек, так и системных. Если с системными все более или менее ясно, то собственные библиотеки – это уже интересно!
Во-первых, можно определить их состав (но не расположение, хотя это и не проблема). Это нужно для организации утилит-«чистильщиков»: после деинсталляции эти DLL, в дальнейшем не используемые, засоряют систему. Таким образом, можно написать программу, которая составляет списки импортируемых библиотек, отсеивает из них системные и составляет перекрестную карту используемых ресурсов. Эта же возможность нужна и для того, чтобы «перетащить» приложение в другую систему, не имея его дистрибутива. Как вы знаете, при этом приложения долго «кричат» о нехватке той или иной библиотеки. В принципе, эта же технология положена в основу интеллектуальных деинсталляторов, а также программ для извлечения пакетов драйверов системы.
Во-вторых, особый «смак» доставляет возможность исправлять ресурсы приложения. В далекие времена, когда первые Windows компиляторы были попроще, ресурсы для приложения готовились отдельно. К ним относились меню, строки, окна форм и диалогов, курсоры, встроенная графика (например, логотипы окон) и т.д. В некоторых случаях ресурсы создавали прямо в MS-DOS, а графические – в программах вроде WorkShop. После этого все это компилировалось и получался RC-файл – файл ресурсов. И, что важно, он на этапе компиляции просто механически добавлялся к программе, а в заголовке лишь настраивались адреса ссылок. Эта особенность подключения привела к появлению многочисленных «рестораторов», которые могли отсоединять и изменять некоторые ресурсы. Для чего? Ну, например, для русификации меню, смены шрифтов в приложении, замены параметров отображения окон. Да мало ли чего еще…
В следующей статье мы попробуем воспользоваться этими знаниями, чтобы путем анализа исследовать какое-нибудь простенькое приложения, чтобы, к примеру, заменить в нем элементы графики и русифицировать надписи. В будущем, может, и пригодится. А пока же рекомендуем поискать описание NE и PE форматов исполняемых файлов. |