Почему функция SetWindowsHookEx принимает параметр HINSTANCE?

Это перевод Why does SetWindowsHookEx take an HINSTANCE parameter? Автор: Реймонд Чен.

Анонимный комментатор спросил, почему функция SetWindowsHookEx принимает параметр HINSTANCE, если она всё равно сконвертирует это значение в имя файла.

Как злоупотребляли оконными ловушками в Win16

Это перевод One way people abused hooks in 16-bit Windows. Автор: Реймонд Чен.

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

Как были реализованы оконные ловушки в 16-битных Windows?

Это перевод How were window hooks implemented in 16-bit Windows? Автор: Реймонд Чен.

Механизм отслеживания оконных ловушек был реализован существенно иначе в 16-битных Windows.

Как менее наивный компилятор вызывает импортируемую функцию

Это перевод How a less naive compiler calls an imported function. Автор: Реймонд Чен.

Если функция объявлена со спецификатором dllimport, то это указывает компилятору Visual Studio C/C++, что эта функция импортируется из другого (исполняемого) модуля, а не является обычной функцией в этом же исполняемом модуле. Имея на руках эту информацию, компилятор генерирует немного другой код, поскольку теперь он осведомлён об особенностях импортируемых функций.

Вызов импортируемой функции, наивный способ

Это перевод Calling an imported function, the naive way. Автор: Реймонд Чен.

Библиотека импорта (import library) разрешает (resolve) символы импортируемых функций, но к ней не обращаются до этапа компоновки. Давайте посмотрим на наивную реализацию, когда компилятор слепо не осведомлён о существовании импортируемых функций.

Смена дизайна импорта в 32-х битных Windows

Это перевод Rethinking the way DLL exports are resolved for 32-bit Windows. Автор: Реймонд Чен.

За последние дни мы узнали, как работает экспорт и импорт функций в 16-битных Windows, а также что экспорт функций в Win32 очень похож на экспорт функций в 16-битных Windows. Но 16-битный импорт был полностью переписан в мире 32-битных Windows.

Экспортируемые функции, являющиеся forwarder-ами

Это перевод Exported functions that are really forwarders. Автор: Реймонд Чен.

В прошлый раз мы видели как экспортируемые функции в Win32 ведут себя похоже на экспорт функций в 16-битных Windows - только сместился акцент использования с импорта по номеру на импорт по имени. Этот акцент никак не выражен в формате исполняемого файла; и 16-битные и 32-битные DLL могут экспортировать функции по номеру и имени (и обоим одновременно).

Но в Win32 появляется новый тип экспортируемых функций, известный как forwarder.

Как экспортируются DLL функции в 32-битных Windows?

Это перевод How are DLL functions exported in 32-bit Windows? Автор: Реймонд Чен.

Дизайнерам 32-битных Windows не нужно было беспокоиться о втискивании в 256 Кб памяти. Поскольку модули в Win32 построены на загрузке по запросу, то всё, что вам нужно сделать - спроецировать весь образ в память, а затем коснуться тех частей, которые вам нужны. Поэтому нет никакого различия между резидентной и не резидентной таблицами, так что имена экспортируемых функций просто записываются в исполняемый образ вместе с указателем (вернее относительным виртуальным адресом) на имя, хранимое в таблице экспорта.

Как импортировались DLL функции в 16-битных Windows?

Это перевод How were DLL functions imported in 16-bit Windows? Автор: Реймонд Чен.

В прошлый раз я рассказал о том, как экспортировались функции в 16-битных Windows. Сегодня мы посмотрим на их импорт.

Как экспортировались DLL функции в 16-битных Windows?

Это перевод How were DLL functions exported in 16-bit Windows? Автор: Реймонд Чен.

Весь смысл динамических библиотек (DLL) заключается в динамическом связывании. В то время как статические библиотеки встраиваются в конечный продукт, модуль, который использует динамическую библиотеку, просто говорит: "мне, пожалуйста, функцию X из модуля Y, спасибо". Эта техника имеет преимущества и недостатки. Одно из преимуществ - эффективное использование места на диске и в памяти, поскольку существует только одна копия модуля, вместо отдельных копий для каждого модуля. Второе преимущество - обновление DLL может быть выполнено без перекомпиляции всех программ, её использующих. С другой стороны, возможность менять функциональность также является и одним из недостатков DLL, поскольку одна программа может изменить DLL и вызвать этим каскадные эффекты в других клиентах DLL.

В любом случае, давайте начнём с того, как 16-битные Windows управляли импортом и экспортом. После этого мы посмотрим что было изменено при миграции на 32-битные Windows, а затем мы посмотрим на импорт с точки зрения компилятора.

Расширенная RTTI информация классов

Это перевод Extended Class RTTI. Автор: Hallvard Vassbotn.

Как я упоминал ранее, Delphi (начиная с версии 7) поддерживает генерацию расширенной RTTI информации о методах класса - через компиляцию класса в режиме $METHODINFO ON. Эта RTTI информация включает в себя информацию о сигнатуре public и published методов. Delphi использует её для реализации поддержки скриптинга в фреймворке WebSnap - см. модуль ObjAuto и его друзей для более подробных сведений.

Я сумел написать свои собственные определения и подпрограммы, которые выдёргивают и сохраняют расширенную RTTI информацию классов в формат, удобный для внешнего использования. Как обычно, моё тестовое приложение будет дампить тестовый класс, воссоздавая его псевдо-объявление.

Расширенная RTTI информация интерфейсов

Это перевод Extended Interface RTTI. Автор: Hallvard Vassbotn.

Чтобы поддерживать базовые механизмы SOAP архитектуры, Delphi добавила поддержку расширенной RTTI информации для интерфейсов начиная с версии 7. Как мы видели в предыдущей статье, все интерфейсы поддерживают базовую информацию RTTI: имя интерфейса, его GUID, имя модуля с объявлением, родительский интерфейс и число методов.

Чтобы добавить к интерфейсу расширенную RTTI информацию, его нужно собрать в режиме {$M+}/{$TYPINFO ON} или {$METHODINFO ON}. Альтернативно, вы можете просто унаследовать свой интерфейс от IInvokable (определённого в модуле System с $M+). Это расширит генерируемую RTTI для интерфейса информацией по сигнатуре каждого метода.

Простая RTTI информация интерфейсов

Это перевод Simple Interface RTTI. Автор: Hallvard Vassbotn.

Delphi поддерживает получение RTTI информации для всех интерфейсов, но она не включает (не генерирует) информацию о методах для "нормальных" интерфейсов:

type
  {$M-}
  IMyMMInterface = interface
    procedure Foo;
  end;

Раскапывая детали SOAP и WebSnap

Это перевод Digging into SOAP and WebSnap. Автор: Hallvard Vassbotn.

В предыдущих статьях этого блога мы досконально разобрали внутреннюю кухню работы published методов, и предположили, что RTTI для них не включает в себя сведения о сигнатуре вызова. Затем мы разработали грязный (и довольно бесполезный) хак, который откапывал параметры published методов, сопоставляя методы с событиями с RTTI, которые ссылались на этот метод в run-time. Как я кратко упомянул в моём предыдущем посте, David Glassborow указал мне на расширенный RTTI, который появился в Delphi 6.

RTTI классов

Это перевод Class RTTI. Автор: David Glassborow.

Этот пост является продолжением моего предыдущего поста, который говорил про RTTI интерфейсов в Delphi и был вдохновлён серией постов Hallvard-а по RTTI. Этот пост рассказывает о некоторых продвинутых возможностях RTTI для классов, описания которых я больше нигде не видел.

RTTI интерфейсов

Это перевод Interface RTTI. Автор: David Glassborow.

Чтение этой статьи Hallvard-а по RTTI и её дополнения вдохновило меня собрать вместе несколько постов о двух связанных частях RTTI в Delphi. В частности, это был один из комментариев в блоге Hallvard-а по использованию RTTI для вызова методов объектов в манере позднего связывания. Этот и следующие посты покроют использование продвинутой RTTI информации, описание которого я нигде больше не видел. Этот пост опишет некоторые возможности мета-данных интерфейсов, а следующий расскажет о более богатом классовом RTTI для методов.

Детали реализации published полей

Это перевод Published fields details. Автор: Hallvard Vassbotn.

В предыдущей статье мы посмотрели на то, как published поля используются IDE и VCL, чтобы сделать простыми работу с компонентными ссылками и нахождение классовых ссылок по именам типов. Сейчас мы заглянем глубже в детали реализации published полей.

Published поля

Это перевод Published fields. Автор: Hallvard Vassbotn.

В нашей небольшой серии по обратной разработке (reverse engineering) недокументированных полей VMT классов Delphi, мы видели поле FieldTable. Это поле указывает на структуры, которые описывают published поля класса. В Delphi published поля должны быть ссылками на объекты и в основном используются формами (form) и модулями данных (datamodule) для хранения ссылок на свои компоненты в логически именованных полях для удобства доступа (потому что альтернативой к полям является использование массива Components, что включает в себя поиск и преобразования типов).

Хак №10: получение параметров published методов

Это перевод Hack #10: Getting the parameters of published methods. Автор: Hallvard Vassbotn.

Этот хак не очень полезен на практике, он был сделан под вдохновением от комментария к посту о published методах. Тогда я начал расследование, как это можно сделать. Вспомните, что компилятор сейчас не кодирует сигнатуру метода в RTTI для published методов - сохраняются только адрес и имя метода.

Так что с первого взгляда кажется, что получить эту информацию - невозможно. Но давайте сделаем шаг назад и подумаем о том, как IDE обрабатывает события и published методы в design-time. Если у вас уже объявлено несколько обработчиков событий (реализованных в нескольких published методах формы), то инспектор объектов отфильтрует их и покажет только те методы (в выпадающем списке), сигнатура которых совместима с событием. Как IDE узнаёт, какие методы нужно показывать в списке, а какие - нет?

Под капотом published методов

Это перевод Under the hood of published methods. Автор: Hallvard Vassbotn.

Теперь, когда я рассказал, что такое published методы, как IDE и VCL используют их при сохранении/загрузке .DFM и как использовать их полиморфно, мы готовы погрузиться глубже в их детали реализации под капотом языка.