Блог GunSmoker-а

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

2011-09-08T02:59:00.000+04:00

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

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

Потому что ловушки работали иначе в 16-битных Windows.

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

Но что там с описателем? Он был нужен, чтобы увеличить счётчик загрузок модуля, чтобы модуль не выгрузился бы в то время, пока установлена и работает ловушка. Когда ловушка удалялась, то счётчик ссылок уменьшался.

И даже в 32-битных Windows оконному менеджеру всё ещё нужен описатель. Зачем? Чтобы сконвертировать адрес функции в DLL в RVA (прим.пер.: относительное смещение) - чтобы эту функцию можно было потом найти в DLL, когда она будет загружена в другой процесс (прим.пер.: и по другому адресу). Так что если бы вы передавали имя фала вместо описателя, то оконному менеджеру всё равно пришлось бы вызывать GetModuleHandle для получения описателя. Поскольку большинство программ хранит описатели, а не имена, то выбор параметра-описателя был естественным выбором (не говоря уже о сохранении совместимости с 16-битными Windows - а это очень важный критерий, когда ты пытаешься убедить людей писать программы под Win32).

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

2011-09-07T02:55:00.000+04:00

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

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

Самый частый способ использования этой информации во зло заключается в снятии ловушки неверным способом. Вместо вызова функции UnhookWindowsHook снова вызывалась SetWindowsHook! Более конкретно: текущая ловушка удалялась установкой на вершину цепочки предыдущей ловушки:

var
  g_hhkPrev: HHOOK;

// Установка ловушки
g_hhkPrev := SetWindowsHook(WH_KEYBOARD, MyHookProc);
...

// Безумие! Удаление ловушки установкой предыдущей ловушки "обратно"
SetWindowsHook(WH_KEYBOARD, g_hhkPrev);

Несмотря на это вопиюще неверное поведение, код работал; это вроде как две неверные вещи при сложении дали почти правильное. Если никто не трогал цепочку ловушек между установкой и таким "снятием" ловушки, то переустановка старой ловушки в вершину списка восстанавливала список ловушек в то же состояние, в которое он приходит при правильном удалении ловушки.

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

Я до сих пор понятия не имею, почему кому-то взбрело в голову удалять ловушку именно таким способом вместо правильного - они ничего не сэкономили, а просто заменили одну строчку на другую:

UnhookWindowsHook(WH_KEYBOARD, MyHookProc);

Windows 3.1 ввела модель с SetWindowsHookEx/CallNextHookEx, которая не использовала технику внешнего связанного списка, а хранила список сама, внутренне. Это защитило цепочку ловушек от программ, которые портили её неверным управлением списком, но это также означало, что теперь все эти сумасшедшие программы, которые пытались удалить ловушку повторной установкой старой ловушки, теперь будут просто портить внутренний список ловушек. Нам пришлось написать специальный код, который определял такие случаи и заменял их на корректные вызовы.

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

2011-09-06T02:55:00.000+04:00

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

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

При этом использовались функции SetWindowsHook, UnhookWindowsHook и DefHookProc. Первые две функции существуют даже сегодня, но третья заменена простым макросом:

// 16-битный прототип
DWORD WINAPI DefHookProc(int nCode, WPARAM wParam,
                         LPARAM lParam, HHOOK FAR *phk);

// 32-битный макрос
#define DefHookProc(nCode, wParam, lParam, phhk)\
        CallNextHookEx(*phhk, nCode, wParam, lParam)

Предупреждение: весь код реконструируется по памяти. Его дух не тронут, но точные детали могут быть указаны не верно.

Чтобы установить ловушку в 16-битных Windows, вы сначала вызываете SetWindowsHook:

var
  g_hhkPrev: HHOOK;
...
  g_hhkPrev := SetWindowsHook(WH_WHATEVER, MyHookProc);

Возвращаемое значение от SetWindowsHook должно быть сохранено в глобальной переменной, которой мы дали несколько провокационное имя g_hhkPrev. Процедура ловушки выглядела вот так:

// В Win16 процедура ловушки возвращала DWORD, а не LRESULT
function MyHookProc(nCode: Integer; wParam: WinTypes.WPARAM; lParam: WinTypes.LPARAM): DWord;
begin
  if nCode >= 0 then
  begin
    ...
  end;
  Result := DefHookProc(nCode, wParam, lParam, g_hhkPrev);
end;

А когда вы заканчивали работу, то вы удаляли ловушку вызовом UnhookWindowsHook:

UnhookWindowsHook(WH_WHATEVER, MyhookProc);
g_hhkPrev := 0;

Внутренне, цепочка функций ловушек управлялась как связанный список, но вместо использования для хранения списка каких-то внутренних структур, связанный список управлялся через сами переменные HHOOK.

Внутренняя реализация SetWindowsHook была довольно простой:

// Этот массив инициализирован процедурами вида "ничего не делай"
var
  g_rgHook: array[0..NUMHOOKS - 1] of HOOKPROC;

function SetWindowsHook(nType: Integer; pfnHookProc: HOOKPROC): HHOOK; 
var
  hhkPrev: HHOOK;
begin
  hhkPrev := HHOOK(g_rgHook[nType]);
  g_rgHook[nType] := pfnHookProc;
  Result := hhkPrev;
end;

Установка ловушки просто записывала вашу процедуру ловушки в заголовок списка (цепочки ловушек), и возвращала предыдущее начало списка. Вызов ловушки заключался просто в вызове первой ловушки (головы списка):

function CallHook(nType, nCode: Integer; wParam: WinTypes.WPARAM; lParam: WinTypes.LPARAM): DWORD;
begin
  Result := g_rgHook[nType](nCode, wParam, lParam);
end;

Каждая процедура ловушки сначала выполняла свою работу, а затем передавала управление следующему элементу в цепочке, вызывая DefHookProc и передавая ему HHOOK:

function DefHookProc(nCode: Integer; wParam: WinTypes.WPARAM; lParam: WinTypes.LPARAM; var phk: HHOOK): DWord;
var
  pfnNext: HOOKPROC;
begin
  pfnNext := HOOKPROC(phk);
  if nCode >=0 then
  begin 
    Result := pfnNext(nCode, wParam, lParam);
    Exit;
  end;
  ... ещё код ...
end;

Как вы можете видеть, это чрезвычайно примитивно: вызов ловушки вызывает первую процедуру в списке, которая затем вызывает DefHookProc, которая знает, что HHOOK - это просто HOOKPROC, и она просто перенаправляет вызов вниз по списку, прямо вызывая эту самую функцию.

А волшебство здесь заключается в последнем шаге, когда вы снимаете ловушку. Вспомните, что правило вызова ловушек таково, что отрицательные коды должны передаваться в DefHookProc (или, по современному: CallNextHookEx) напрямую. Это соглашение позволяет подсистеме ловушек использовать отрицательные коды для ведения учёта. В данном случае мы использовали -1 как код "снять эту ловушку":

function UnhookWindowsHook(nType: Integer; pfnHookProc: HOOKPROC): BOOL;
begin
  Result := DefHookProc(-1, 0, LPARAM(pfnHookProc), HHOOK(g_rgHook[nType]));
end;

А затем начинается магия:

function DefHookProc(nCode: Integer; wParam: WinTypes.WPARAM; lParam: WinTypes.LPARAM; var phk: HHOOK): DWord;
var
  pfnNext: HOOKPROC;
begin
  pfnNext := HOOKPROC(phk);
  if nCode >=0 then
  begin 
    Result := pfnNext(nCode, wParam, lParam);
    Exit;
  end;
  case nCode of 
    -1: // пытаемся снять ловушку
    begin
      if pfnNext = HOOKPROC(lParam) then // нашли ловушку
      begin
        phk := HHOOK(pfnNext(-2, 0, 0));
        Result := Ord(True);
      end
      else
        // иначе - продолжаем искать
        Result := pfnNext(nCode, wParam, lParam);
    end;
    -2: // сообщить о следующей процедуре ловушке
      Result := DWORD(@phk);
  else
    Result := 0;
  end;
end;

Вот так - вся система оконных ловушек занимает всего несколько строк. Вам надо отдать должное Win16 за её компактный размер.

Прим.пер.: вырезан разбор примера работы.

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

В следующий раз мы посмотрим на то, как люди злоупотребляли этой простой системой.

Кандидат на звание самого непонятного сочетания клавиш: Shift+F8

2011-09-05T02:54:00.000+04:00

Это перевод Candidate for most obscure keyboard shortcut: Shift+F8. Автор: Реймонд Чен.

Так получилось, что одной из самых непонятных сочетаний клавиш является Shift+F8, которая используется в listbox для несмежного расширенного выбора. Господи, сколько же слов.

Статья KB Q301583 не очень помогает в понимании, перечисляя это сочетание в разделе "Сочетания клавиш для диалоговых окон", даже хотя это не диалоговая комбинация клавиш. Это сочетание клавиш listbox-а.

Если в listbox включен режим расширенного выделения, то вы можете использовать комбинацию Shift+F8, чтобы создать несмежное расширенное выделение с клавиатуры (с помощью мыши вы можете сделать это просто делая Ctrl+щелчок). Нажмите Shift+F8 первый раз, чтобы войти в режим расширенного выделения, затем используйте стрелочки для перемещения по списку и нажмите Ctrl+Space или Shift+Space для выделения (или снятия выделения). Когда вы закончите - нажмите Shift+F8 ещё раз (или просто переместите фокус к следующему элементу управления).

И да, конкретно этот клавиатурный интерфейс просто кошмарен. Более естественный механизм использовал бы Ctrl+Стрелка для перемещения фокуса без изменения выбора, и Ctrl+Пробел для выбора (или отмены выбора) элемента. К счастью, элемент управления listview использовал именно этот подход вместо подражания сумасшедшему сочетанию клавиш Shift+F8.

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

2011-09-04T22:10:00.000+04:00

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

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

Во-первых, теперь больше нет необходимости в функции-заглушке, потому что компилятор может сгенерировать инструкцию call [__imp__FunctionName]. Кроме того, компилятор знает, что этот адрес (адрес импортируемой функции) никогда не меняется, и, соответственно, он может оптимизировать многократное использование этого адреса, например:

    mov   ebx, [__imp__FunctionName]
    push  1
    call  ebx ; FunctionName(1)
    push  2
    call  ebx ; FunctionName(2)

(Примечание к сумасшедшим людям: подобная оптимизация означает, что у вас могут возникнуть проблемы, если вы исправляете таблицу импорта модуля после того, как код в модуле начал работу - потому что указатель на функцию может быть сохранён в регистр до того, как вы начали править импорт. Рассмотрите случай с примером выше, когда вы изменили запись в таблице __imp__FunctionName после выполнения инструкции mov ebx, [__imp__FunctionName]: ваша функция-перехватчик не будет вызвана, потому что старый указатель на функцию сохранён в регистре ebx).

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

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

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

2011-09-03T22:10:00.000+04:00

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

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

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

Давайте посмотрим, как справится с этой же ситуацией наивный 32-битный компилятор. Компилятор сгенерирует обычную инструкцию вызова функции, перекладывая разрешение адреса на компоновщик. Линкер увидит, что этот внешний символ, на самом деле, является импортируемой функций, и, ой, прямой вызов нужно переделать в косвенный. Но компоновщик не может переписать код, сгенерированный компилятором. Что же делать компоновщику?

Решение заключается во вставке ещё одно уровня косвенности (предупреждение: информация ниже не верна буквально, но она "достаточно правдоподобна". Мы копнём детали в следующих постах).

Для каждой экспортируемой функции создаётся два символа. Первый из них - запись в таблице импортируемых функций. Назовём его __imp__FunctionName. Конечно же, наивный компилятор не знает ни про какой префикс __imp__. Он просто генерирует код для инструкции call FunctionName, ожидая что компоновщик подставит нужный адрес.

Тут на сцену выходит второй символ. Он имеет имя FunctionName и является однострочной функцией, состоящей из одной-единственной инструкции: jmp [__imp__FunctionName] (генерируется компоновщиком). Эта крохотная заглушка предназначена для удовлетворения внешних ссылок на функцию FunctionName, и в свою очередь она генерирует ссылку на __imp__FunctionName, которая разрешается записью в таблице импортируемых функций.

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

Заметьте, что с наивным компилятором, если ваш код попытается взять адрес импортируемой функции, то он получит адрес заглушки, поскольку наивный компилятор оперирует с адресом функции FunctionName, не зная о том, что она импортируется из другого модуля и для неё, на самом деле, создаётся заглушка.

В следующий раз мы увидим, что с этой ситуацией сможет сделать менее наивный компилятор.

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

2011-09-02T22:09:00.000+04:00

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

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

Вспомните, что в 16-битных Windows правки для импортируемой функции размещались по всему сегменту цепочкой. Это прекрасно работало в Win16, потому что там было глобальное адресное пространство: сегменты кода разделялись глобально, так что будучи единожды загруженным, сегмент мог быть использован любым процессом. Но 32-битные Windows использовали изолированные адресные пространства. Если правки были расположены по всему сегменту, то загрузка сегмента кода с диска (вернее - страницы сегмента кода) означала его модификацию, что не давало разделять один сегмент несколькими процессами (механизм copy-on-write). Даже если бы таблица правок хранилась бы во внешнем сегменте, вам всё равно пришлось бы править сегмент кода, чтобы указать цели для переходов (если вы достаточно умны, то вы могли бы разделять страницы между процессами, если все правки были бы одинаковы для всех этих процессов; но учёт изменений для этой модели был бы полным кошмаром).

Но помимо простой неэффективности, идея применения правок импорта к сегменту кода просто невозможна. К примеру, Alpha AXP имеет инструкцию "call direct" (прямой вызов), но она ограничена функциями, которые находятся лишь на расстоянии не более 128 Кб от места вызова. Если вы хотите вызвать функцию, которая находится дальше от вас, то вы должны загрузить адрес назначения во временный регистр и вызвать функцию через этот регистр. И, как мы видели ранее, загрузка 32-битного значения в регистр на Alpha AXP является двухступенчатой операцией, которая зависит от того, установлен или очищен 15-й бит того значения, которое вы хотите загрузить. Поскольку это импортируемая функция, то на этапе компиляции или компоновки вы понятия не имеете будет ли адрес целевой функции иметь 15-й бит или нет.

И Alpha AXP была далеко не единственной архитектурой, которая ограничивала расстояние для прямых вызовов. К примеру, Intel ia64 (Itanium) мог делать прямые вызовы функций только в пределах 4 Мб, а популярные сегодня архитектуры AMD x86-64 и Intel EM64T ограничивают вас 2 Гб. Да, это не звучит как ограничение пока вы не вспомните, что это - 64-разрядные процессоры с 16 эксабайтами адресного пространства. И снова мы видим, что архитектура x86 является странной (прим.пер.: в том смысле, что на ней нет ограничения на прямые вызовы в отличие от многих других архитектур).

Оба момента выше сделали правки импорта в сегменте кода нежелательными (и невозможными). Вместо этого правки импорта пришлось применять к данным. Вместо того, чтобы применять правку к каждому месту, где вызывается импортируемая функция, применяется всего одна правка в таблице указателей на функции. Это означает, что вызовы импортируемых функций на самом деле являются косвенными вызовами через указатель. К примеру, на x86 это означает, что вместо call ImportedFunction генерируется код, который говорит call [__imp__ImportedFunction], где __imp__ImportedFunction - это имя переменной (места в таблице), которая содержит указатель на эту импортируемую функцию.

Это означает, что правки импортируемых функций заключаются в простом поиске целевых адресов и их записи в таблицу импортируемых адресов (прим.пер.: хранимую в сегменте данных). Код не изменяется; он просто читает указатель на функцию в run-time и вызывает функцию через указатель.

С этой информацией мы теперь вооружены для более глубокого погружения в кое-какие последствия этого дизайна - что мы и сделаем в следующий раз.

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

2011-09-01T22:09:00.000+04:00

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

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

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

Forwarder выглядит как обычная экспортируемая функция, за исключением того что запись в таблице экспорта по номерам говорит "Ох, на самом деле, я не функция в этой DLL. На самом деле - я функция вон в той DLL". К примеру, если вы сделаете

link /dump /exports kernel32.dll

То вы увидите что-то такое:

151   EnterCriticalSection (forwarded to NTDLL.RtlEnterCriticalSection)

Это означает, что если программа связана с KERNEL32.EnterCriticalSection, то загрузчик ОС молчаливо перенаправит функцию на NTDLL.RtlEnterCriticalSection. Forwarder-ы являются удобным способом сохранить внешний интерфейс, изменив функциональность выносом в отдельные DLL. Старая DLL продолжает экспортировать функцию, но сама функция была перемещена в новую DLL.

Трюк с forwarder - это лучше, чем иметь пустую функцию-заглушку в старой DLL, которая просто вызывает функцию в новой DLL: потому что функция заглушка создаёт зависимость между новой и старой DLL (в конце концов, старую DLL нужно связать с новой DLL, чтобы была возможность вызвать функцию!). А при использовании forwarder новая DLL не будет загружаться, если только кто-то не попросит перенаправленную функцию из старой DLL. В результате вы не платите за загрузку новой DLL пока кто-то её явно не попросит.

Okей, как мы увидели, с введением forwarder Win32 отошла от 16-битных Windows, но как только мы посмотрим на импорт, то увидим, что тут изменилось вообще всё. Мы посмотрим на эту историю в следующий раз.

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

2011-08-31T22:08:00.000+04:00

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

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

В отличие от главной 16-битной таблицы экспорта, 32-битная таблица не является разрежённой. Иными словами, если ваша DLL экспортирует две функции с номерами 10 и 1000 - у вас будет таблица экспорта на 991 записей, состоящая из двух функций и кучи нулей. Поэтому вам не следует назначать номера функциям с большими пробелами в нумерации - иначе вы будете зря тратить пространство в таблице экспорта.

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

Как и в 16-битных Windows, каждому имени присваивается номер. Если программист не указывает номер, то его назначает компоновщик, и, как и в 16-битных Windows, автоматически присваиваемые значения могут отличаться в сборках. Однако тут есть существенное отличие в моделях использования: вспомните, что в 16-битных Windows импорт по имени не поощрялся (по соображениям производительности), и в результате обычно каждой экспортируемой функции явно присваивался номер, что и было предпочтительным способом связывания функций. С другой стороны, именованный импорт в Win32 является нормой, а явное присваивание номеров функций ушло в прошлое. Это означает, что номера в таблице экспорта не фиксированы. К примеру, посмотрите на номера, присваиваемые функции LocalAlloc из kernel32 за эти годы:

Windows NT 3.1	314
Windows NT 3.5	372
Windows 95	501
Windows NT 4.0	407

Но некоторые люди имеют привычку "взламывать" (reverse-engineer) библиотеки импорта - вероятно потому, что им лень качать Platform SDK чтобы получить официальные библиотеки импорта. Проблема с генерацией библиотеки импорта заключается в том, что вы не можете сказать, был ли номер, скажем, функции LoadLibrary присвоен явно программистом (и, значит, будет постоянен) или же был назначен автоматически компоновщиком (и в этом случае он будет меняться). Утилиты генерации библиотек импорта могут просто перестраховаться и всегда использовать именованный импорт, но по какой-то причине они часто предпочитают импорт по номерам (вероятно, это остаток из времён 16-битных Windows, где такой способ импорта был предпочитаемым).

Этот неудачный выбор части утилит по генерации библиотек импорта жить опасной жизнью создал проблемы совместимости команде DirectX (я не знаю, почему именно DirectX оказался под ударом больше остальных. Возможно, потому что у разработчиков игр нет времени учить детали Win32; они просто хотят писать их игры). Как только кто-то использовал такую утилиту, он оказался привязанным к функциям DirectX вроде DirectDrawCreate по номеру, а не по имени. А когда вышла следующая версия DirectX и этому имени был присвоен другой номер компоновщиком, их программы стали вылетать. Команде DirectX пришлось поднять из архива старые DLL, тщательно выписать все номера функций (присвоенные случайным образом компоновщиком) и в точности повторить это присвоение вручную, так чтобы эти номера более не менялись бы в будущем.

Есть и другие причины, почему вы не можете сгенерировать библиотеку импорта по DLL; я подниму эти причины в следующий раз, когда буду обсуждать импорт из DLL.

В следующий раз - переходники.

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

2011-08-30T22:08:00.000+04:00

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

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

Каждый раз, когда сегмент загружается с диска в память, сначала читается raw-содержимое сегмента с диска, а затем применяются relocation-правки. Правка для импортируемой функции состоит из имени целевой DLL, целевой функции (либо её имени, либо номера), и позиции первого места в сегменте, где нужно произвести правку. Все импортируемые адреса являются far-адресами, поскольку они ссылаются на другой сегмент (почему? если бы они были в том же сегменте, то это означало бы, что они расположены в той же DLL, так что это получился бы импорт функции из самого себя!). На 16-битных Windows дальний указатель занимает 4 байта (двухбайтовый селектор и двухбайтовое смещение), а поскольку точный адрес функции не известен в момент компиляции DLL, то эти 4 байта являются просто заглушками - они помещаются в файл с тем, чтобы быть заполненными настоящими значениями в run-time, когда будет получен адрес импортируемой функции. И эти байты заглушек служат двойной цели.

Все вызовы сегмента одной и той же импортируемой функции связываются в список; запись в relocation таблице ссылается только на первый элемент этого списка. А что насчёт остальных вызовов? На них указывают заглушки! К примеру, предположим, что у нас есть сегмент, который требует две правки для функции GetPrivateProfileInt, которая является функцией ядра с номером 127. Тогда в relocation таблице будет создана одна запись, которая говорит: "этот сегмент требует функцию номер 127 из KERNEL; начало по смещению 01D1". Копия сегмента на диске может выглядеть так:

...
`01D0`	`9A`
`01D1`	`FE`
`01D2`	`01`
`01D3`	`00`
`01D0`	`00`
...
`01FD`	`9A`
`01FE`	`FF`
`01FF`	`FF`
`0200`	`00`
`0201`	`00`
...

Чтобы применить правку, мы вызываем GetProcAddress для получения настоящего адреса функции 127. Затем мы идём к месту первой правки (это место со смещением $01D1), записываем в него адрес, а затем смотрим на значение, которое мы только что перезаписали (конечно, мы должны его сохранить перед записью). Это значение равно $01FE, поэтому мы идём к месту по смещению $01FE и снова записываем адрес. Перезаписанное значение равно $FFFF, что означает конец цепочки правок.

Но что если вызов GetProcAddress будет неудачным? (к примеру - в KERNEL нет никакой функции 127). Тогда вместо записи адреса целевой функции, загрузчик запишет адрес специальной функции-заглушки, которая вызывает фатальную ошибку "Call to Undefined Dynalink".

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

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

2011-08-29T22:07:00.000+04:00

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

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

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

16-битная DLL имела не одну, а целых три таблицы экспорта (на самом деле всё было немного сложнее, чем я описываю здесь, но я собираюсь опустить некоторые занудные детали, чтобы ваши головы не взорвались от переизбытка информации). Самая важная таблица представляла собой разрежённый массив функций, проиндексированных с 1("ordinal"). Это и есть таблица функций, которая является мастер-списком всех экспортируемых функций. Если вы запрашивали функцию по номеру (ordinal), этот номер искался именно в этой таблице. Физически таблица устроена не так просто - из-за разрежённости, но логически она выглядит так:

Номер	Адрес	прочее
1	02:0014	...
2	04:0000	...
5	02:02C8	...

Первая колонка в таблице представляет собой номер функции, а вторая описывает размещение функции (заметьте, что в этой DLL нет функций 3 и 4).

Интересные вещи начинаются, когда вы хотите получить функцию по её имени. Таблица экспортируемых имён представляет собой список имён функций с ассоциированными номерами. К примеру, секция экспортируемых имён для 16-битного оконного менеджера выглядела так:

...
`ClipCursor`	16
`GetCursorPos`	17
`SetCapture`	18
...

Если кто-то просил адрес функции "ClipCursor", то сначала проверялась таблица экспортируемых имён и из неё извлекался номер 16, после чего этот номер использовался для обращения к мастер-таблице, упомянутой выше. Хотя вы не видите этого здесь, но не существовало никакого требования, чтобы имена в таблице экспортируемых имён шли в каком-то определённом порядке или чтобы каждая функция с номером имела бы экспортируемое имя.

Подождите-ка, я сказал "таблица экспортируемых имён"? Ох, извините, это было сильное упрощение. На самом деле было две таблицы экспортируемых имён: резидентная таблица имён и не резидентная таблица имён. Как следует из их названий, имена в резидентной таблице оставались в памяти всё время, пока DLL была загружена, а имена из не резидентной таблицы загружались в память только когда кто-то вызывал GetProcAddress (или её эквивалент). Это различие появилось из-за очень жёстких ограничений на память, с которыми Windows приходилось работать в те дни. К примеру, оконный менеджер имел около шестисот экспортируемых функций; если бы все эти функции были резидентными, то они занимали бы более 10 Кб памяти. Это означает, что вы тратите 4 процента вашей памяти (машины с 256 Кб), чтобы хранить вещи, которые вам не нужны 99% процентов времени.

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

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

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

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

Pidl и моникеры делают примерно одно и то же, только по-разному

2011-08-28T22:07:00.000+04:00

Это перевод Pidls and monikers do roughly the same thing, just backwards. Автор: Реймонд Чен.

Работая с Оболочкой (Shell) Windows, вам наверняка в какой-то момент пришлось работать с указателем на список ID элементов (pointer to item ID list), известным как "pidl" (рифмуется с "middle"). С другой стороны, работая с OLE, вы могли работать с моникерами (moniker). В каком-то смысле они делают одно и то же. Они позволяют вам ссылаться на какой-то объект внутри пространства имён (с которым вы как-то работаете), они имеют иерархическую структуру, вы можете их сериализовать и т.п.

Но почему тогда команда Оболочки Windows изобрела pidl-ы, если моникеры делали ровно это же?

Фундаментальное отличие между pidl и моникерами - не в том, что они делают, а скорее в их "акценте". Моникер - это COM объект. Это означает, что они существуют в форме COM интерфейса (IMoniker), что означает, что код, стоящий за объектом, должен быть загружен и готов к работе. Вы можете сконвертировать моникер в данные, но это не то, как обычно проводят свою жизнь моникеры. Если у вас есть массив моникеров, то весь код под капотом должен быть проинициализирован.

Pidl, с другой стороны, проводит большую часть своей жизни будучи засериализован в данные. COM объект появляется только когда вы производите связывание (bind). Рассмотрите, к примеру, случай, когда вы перечисляете содержимое папки. Эта операция генерирует pidl для каждого элемента в папке, но создание и хранение этих pidl не требует выполнения кода каждого элемента. Папка с тысячей элементов создаст тысячу кусков данных, а не тысячу COM объектов. Рассмотрим, к примеру, папку с тысячей таблиц Excel. Если вы открываете эту папку, то вам бы не хотелось запускать Excel для каждой из тысячи таблиц в папке (для обслуживания элементов). На этом этапе вы пока просто говорите про файлы. И лишь когда пользователь щёлкает на файле, вы хотели бы запускать Excel.

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

Не всякий человек с не-Windows разделом является гиком

2011-08-27T22:06:00.000+04:00

Это перевод Not everybody with a non-Windows partition type is a geek. Автор: Реймонд Чен.

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

Проблема в этом плане в том, что не всякий человек с не-Windows разделом на жёстком диске обязательно является техно-гиком. Многие OEM-машины (особенно ноутбуки - прим.пер.) поставляются с диском, разбитым на два раздела. На первом стоит Windows, а второй - не-Windows раздел, который имеет небольшой размер и содержит утилиты диагностики и восстановления системы (иногда - дистрибутивный образ мастер-копии системы). Наличие этого небольшого раздела не слишком известно, поскольку он работает только в редких случаях загрузки с "system recovery CD" от поставщика машины.

Следствие из этого состоит в том, что если бы установщик Windows принял бы этот подход "человек с не-Windows разделом должен быть гиком", то в итоге мы бы пометили гиками ужасно много людей (многие из которых гиками не являются).

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

Прежде чем учиться опознавать неправильное, вам нужно узнать, что есть правильное

2011-08-26T22:06:00.000+04:00

Это перевод Before you can learn to recognize what's wrong, you must learn to recognize what's right. Автор: Реймонд Чен.

Иногда, когда я отлаживаю проблему, я могу проигнорировать какой-то поток, а кто-то спросит: "а что делает этот поток? Почему ты его игнорируешь?"

Мой ответ: "Я понятия не имею, что он делает, но что бы он ни делал, это - нормально".

Tess публикует отличную серию постов, посвящённых отладке CLR, но один из самых важных уроков - это где вы учитесь игнорировать вещи, когда отлаживаете зависание в ASP.NET.

Зависания и блокировки могут быть сложны в отладке, потому что у вас нет исключения, которое кричит: "эй, смотри на меня, вот она проблема, я - это баг!". Вместо этого программа просто замирает и вам нужно понять почему. При этом вам нужно искать что-то неординарное, необычное, но чтобы вы могли опознать это что-то - вам нужно знать, как обычно выглядят вещи в вашем процессе.

Ну так сделайте это. Запустите программу, пусть она работает, а вы остановите её в отладчике и просто посмотрите на неё. Отметьте то, что вы увидите. Это - вещи, которые происходят в вашей программе, когда всё идёт своим чередом. Так выглядит ваша программа, когда она работает в нормальном режиме. Теперь, когда вы знаете как выглядят нормальные вещи в вашей программе, вы можете опознать не нормальные.

Заметьте, что вам даже не нужно понимать, что все эти нормальные вещи значат или делают. К примеру, когда я подключаю отладчик к процессу, я часто вижу потоки, ожидающие RPC или спящие в пуле потоков ядра. Я понятия не имею, что они делают, но раз уж они тут и раньше были, то я их игнорирую.

Нет, а почему именно 160x31?

2011-08-25T22:05:00.000+04:00

Это перевод No, really, why is it 160x31? Автор: Реймонд Чен.

Когда я ранее пояснял, почему свёрнутые (минимизированные) окна имеют размер 160x31, я не пояснил, почему размером выбрано именно ровно 160 и 31.

Ширина минимизированного окна определяется полем iWidth в записи TMinimizedMetrics. Вы можете получить и изменить эту запись с помощью функции SystemParametersInfo (вас будут интересовать флаги SPI_GETMINIMIZEDMETRICS и SPI_SETMINIMIZEDMETRICS). Некоторые люди упоминают использование значение MinWidth в реестре, но они не правы. К примеру, заметьте, что исправление MinWidth требует выхода из системы, а использование SPI_SETMINIMIZEDMETRICS действует немедленно. Это потому что SPI_SETMINIMIZEDMETRICS обновляет внутреннее состояние системы, а правки реестра просто меняют значение в БД, на которую никто не смотрит (после запуска).

Что насчёт высоты? А это просто высота строки-заголовка (caption bar), которую вы можете изменить на вкладке "Оформление" апплета "Экран" панели управления (программно вы можете использовать эту же полезную функцию SystemParametersInfo, но в этот раз используя поле iCaptionHeight записи TNonClientMetrics).

Максимальный размер переменных окружения - это 32 или 64 Кб?

2011-08-24T22:04:00.000+04:00

Это перевод Is the maximum size of the environment 32K or 64K? Автор: Реймонд Чен.

Кажется, есть некоторая путаница в максимальном размере переменных окружения: 32 Кб или 64 Кб. Какое значение правильное?

Оба.

Ограничение - 32'767 Unicode символов, что есть 65'534 байт. Назовите это 32 Кб или 64 Кб - как вам угодно. Но только убедитесь, что вы включили единицу измерения в ваши утверждения, если она не следует из контекста.

Безопасность: не забывайте обнулять вещи, на которые вам наплевать

2011-08-23T22:04:00.000+04:00

Это перевод Security: Don't forget to initialize the stuff you don't care about. Автор: Реймонд Чен.

Затерянным в волнении уязвимостей повышения привилегий является простое раскрытие информации через отсутствующую инициализацию мусора (прим.пер.: понятия не имею, зачем оригинальное предложение так построено).

Сегодня каждый знаком с использованием функции SecureZeroMemory для гарантии того, что буфера, содержащие чувствительную (важную) информацию, очищены после работы с ними (*), но вы также должны очищать буфера перед их записью в другое место. Рассмотрим, к примеру, такой формат данных:

type
  TFileHeader = packed record
    dwMagic: DWORD;
    dwVersion: DWORD;
    wszComment: array[0..256-1] of WideChar;
    cbData: DWORD;
    // далее следует cbData байт данных
  end;

Код, который заполняет такие файлы, мог бы выглядеть так:

function SaveToFile(hFile: THandle; pszComment: PWideChar; cbData: DWORD; pbData: PByte): Boolean;
var
  cbWritten: DWORD;
  fh: TFileHeader;
begin
  fh.dwMagic := FILE_MAGICNUMBER;
  fh.dwVersion := FILE_CURRENTVERSION;
  fh.cbData := cbData;
  Result := SUCCEEDED(StringCchCopyW(fh.wszComment, 256, pszComment)) and
                  WriteFile(hFile, @fh, SizeOf(fh), cbWritten, nil) and
                  (cbWritten = SizeOf(fh)) and
                  WriteFile(hFile, pbData, cbData, cbWritten, nil) and
                  (cbWritten = cbData);
end;

Увидели баг безопасности?

Если комментарий к файлу будет менее 255 символов, то байты после терминирующего нуля будут содержать не инициализированный мусор со стека. Мусор со стека может содержать интересную информацию, которую вы бы не хотели выкладывать в файл. Конечно, он не будет содержать информацию, которую вы уже идентифицировали как чувствительную (вроде паролей) - потому что вы уже подчистили её; но мусор может содержать информацию, хотя и менее критическую, но всё же привлекательную для злоумышленника. К примеру, у вас может утечь имя аккаунта.

Мне рассказали, что одна сетевая программа известной компании содержала аналогичный баг. Они использовали очень продвинутый алгоритм "смены пароля", детали которого сейчас не важны. Дизайном было предусмотрено, что по сети передавались только сложно зашифрованные данные. Таким образом, если кто-то просматривал сетевые пакеты, то он не мог увидеть ничего интересного. Вот только у них был баг в их клиентской программе: когда они отправляли зашифрованный пароль на сервер, они забыли обнулить не используемые байты в пакете "смена пароля". А в этих данных была... ага, верно: не зашифрованная копия пароля.

Примечание переводчика:
(*) SecureZeroMemory практически не известна в Delphi, потому что предназначена для обхода оптимизатора C++ (видимо, по причине того, что ZeroMemory в C++ является макросом, а не функцией; поэтому её "вызов" последним действием на переменную может быть выброшен оптимизатором). Вместо неё в Delphi используется стандартная системная ZeroMemory (которая в Delphi является обычной функцией; фактически - inline-переходником к FillChar) или чисто Delphi-ёвая FillChar.

Событие с авто-сбросом - это просто глупый семафор

2011-08-22T22:03:00.000+04:00

Это перевод An auto-reset event is just a stupid semaphore. Автор: Реймонд Чен.

Когда вы создаёте событие с помощью функции CreateEvent, вы указываете, хотите ли вы создать событие с авто-сбросом (auto-reset event) или с ручным сбросом (manual-reset event).

Событие с ручным сбросом прозрачно для понимания: если событие сброшено, то вы ждёте сигнального состояния; если событие установлено (в сигнальном состоянии), то ожидания не происходит (ожидание удовлетворяется сразу). Не играет значения, сколько человек ждут события; они все обрабатываются одинаково, а состояние события не зависит от числа его ожидающих.

Событие с авто-сбросом - более запутывающая штука.

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

"Ага!" в случае событий с авто-сбросом заключается в случае, когда вы устанавливаете уже установленное событие. Поскольку у события есть только два состояния (сброшенное и сигнальное), то установка события, которое и так находится в сигнальном состоянии, не даст никакого эффекта, ничего не изменит. Если вы используете событие, чтобы контролировать ресурс в модели producer/consumer, то "установка уже установленного события" приведёт к потере токена. Рассмотрим такой шаблон:

Producer	Consumer
	Ожидание
Задать работу
`SetEvent`
	Проснуться и сбросить событие
	Работа
Задать работу
	Wait
`SetEvent`
	Проснуться и сбросить событие
	Работа
...	...

Но что если тайминг немного не совпадёт? Что если потребитель (consumer) будет медленно делать работу (либо же producer будет слишком быстро её генерировать)?

Producer	Consumer
	Ожидание
Задать работу
`SetEvent`
	Проснуться и сбросить событие
Задать работу
`SetEvent`
	Работа
Задать работу
`SetEvent` (без эффекта)
	Ожидание удовлетворено сразу
	Сброс события
	Работа
	Ожидание

Заметьте, что producer создал три задания на работу, но consumer обработал только два. Третий SetEvent просто ничего не сделал, поскольку событие было уже установлено (вы увидите ту же проблему, если попытаетесь увеличить счётчик семафора за его максимум). Если вы хотите, чтобы оба числа соответствовали друг другу, то вам нужно использовать семафор с максимальным значением счётчика выше чем максимум элементов в очереди (прим.пер.: либо же consumer при выходе из ожидания может обрабатывать не один элемент, а все в очереди).

Мораль истории: знайте ваши инструменты, знайте их ограничения и используйте правильный инструмент для правильной задачи.

Одноэкземплярная программа является своим собственным отказом в обслуживании

2011-08-21T22:02:00.000+04:00

Это перевод A single-instance program is its own denial of service. Автор: Реймонд Чен.

Есть много способов, которыми программа может достичь поведения запуска в едином экземпляре; я не буду разбирать их. Но как только люди встают на путь программы с одним запущенным экземпляром, они тут же спотыкаются о другую проблему при анализе безопасности: отказ в обслуживании (denial of service attack).

Мы используем мьютекс с фиксированным именем, чтобы определить, не запущена ли уже копия программы. Но это также означает, что злоумышленник может создать мьютекс с таким именем до запуска программы, блокируя, таким образом, запуск нашей программы! Как я могу предотвратить этот тип отказа в обслуживании?

Если атакующий запущен в том же контексте безопасности, что и ваша программа (ну, или будет запущена ваша программа), то вы ничего не можете сделать с этой ситуацией. Какое бы "секретное рукопожатие" вы ни придумали бы для определения запуска второго экземпляра - атакующий всегда может просто повторить его. Поскольку он запущен в том же контексте безопасности - он может ровно столько же, сколько и ваша программа.

Но посмотрите на этот вопрос шире: одноэкземплярная программа является "своим собственным отказом в обслуживании"! В конце концов, первый экземпляр программы блокирует последующие запуски программы. Ваши требования к программе изначально являются уязвимостью в безопасности. Соответственно, вы не можете защитить себя от отказа в обслуживании, потому что вы хотите иметь отказ в обслуживании.

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

Почему нет программного способа изменить порядок элементов в меню Пуск?

2011-08-20T22:01:00.000+04:00

Это перевод Why can't you programmatically reorder the items on the Start menu? Автор: Реймонд Чен.

Классическое меню Пуск и часть "Все программы" меню Пуск в стиле Windows XP позволяют вам изменить порядок ярлыков, показываемых в них. Вы можете использовать перетаскивание для его упорядочивания, либо же просто использовать сортировку по имени. Но почему нет никакого программного интерфейса для выполнения этих операций?

Потому что эта сила может использоваться во зло чаще, чем во имя добра.

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

Разбираемся, что на самом деле значит "значимые цифры"

2011-08-19T22:01:00.000+04:00

Это перевод Understanding what significant digits really mean. Автор: Реймонд Чен.

Числа с плавающей запятой двойной точности (double-precision floating point number) содержат 15 значащих цифр. Что это значит на самом деле?

Я умножил 0,619207 на 10'000'000 и получил 6'192'069,999999991 вместо 6'192'070. Это же только шесть цифр; где мои обещанные пятнадцать?

Разговор о значащих цифрах - это просто сокращение для относительной погрешности. Это не означает, что первые пятнадцать цифр в точности совпадают с результатом (если вы проведёте больше времени в численном анализе, то услышите как люди говорят о вещах вроде "пять с половиной значащих цифр". Если бы значением "значащих цифр" было таким буквальным, то как вы могли бы иметь половину цифры?).

Относительная ошибка в данном вычислении равна 9 / 6'192'070'000'000'000 = 1,5 × 10^-15, что согласуется с точностью в пятнадцать значащих цифр.

Но даже если вы примете буквальное значение слов, то числа примера всё ещё равны друг другу до пятнадцати знаков. Вспомните, что 0,99999... = 1, и поэтому значения

6192069,999999991
6192069,999999999...

согласуются на пятнадцать значащих цифр - как и было обещано.

А если вы адепт гипер-буквального чтения и отказываетесь принимать трактовку 0,99999... = 1, то вам придётся признать, что единственными возможными значениями для числа значащих цифр являются ноль и бесконечность!

Рассмотрите пример вычислений, в результате которых получается ровно 1, а сами вычисления выполняются с точностью N значащих цифр (где N > 0). Поскольку вы не принимаете, что 0,9 согласуется с 1,0 в одной значащей цифре, то единственными значениями, которые согласуются с 1,0 хотя бы по одной значащей цифре, будут числа в форме "один, запятая, что-то". Обозначим результат вычислений через 1 + ε, где 0 ≤ ε < 1. Теперь вычтем это из 2.0, что даст 1 − ε. Этот результат тоже должен иметь N значащих цифр. И снова, поскольку вы не принимаете, что 0,9 согласуется с 1,0 по одной значащей цифре, то чтобы этот результат был бы хорош для N значащих цифр (N > 0), результат должен иметь форму "один, запятая, что-то". Обозначим результат как 1 + δ, где 0 ≤ δ < 1.

Итак, мы получили 1 − ε = 1 + δ, откуда следует ε = −δ. Поскольку и δ, и ε больше или равны нуля, то единственное решение этого уравнения: ε = δ = 0. Соответственно, единственным числом, которое равно единице до какого-то ненулевого числа значащих цифр (если вы подписались на гипер-буквальную трактовку) будет сама единица. Другими словами, единственное возможное (не нулевое) число значащих цифр - бесконечность. И я думаю, что мы все согласны в том, что если единственными значениями количества значащих цифр были бы ноль с бесконечностью, то вся концепция значимых цифр была бы глупой и бесполезной.

Вот почему значимые цифры не используют гипер-буквальное определение.

Свойства оконных классов применяются ко всем окнам этого класса

2011-08-18T22:00:00.000+04:00

Это перевод Window class properties apply to all windows that belong to the class. Автор: Реймонд Чен.

Свойства оконных классов применяются ко всем окнам этого класса. Именно поэтому они и называются классовыми свойствами. Это выглядит как очевидная вещь, когда её облекают в слова, но я видел множество "решений", которые теряют из вида этот простой факт.

Все свойства, устанавливаемые в записях TWndClass (или TWndClassEx) являются свойствами оконного класса, равно как и свойства, доступ к которым происходит через Get/SetClassWord/Long/LongPtr. Это означает, что когда вы меняете эти свойства, то это изменение затрагивает весь оконный класс. К примеру, если вы пишете:

SetClassLongPtr(hwnd, GCLP_HCURSOR, LONG_PTR(hcurNew));

то вы не просто меняете курсор окна hwnd. Вы меняете курсор всех окон того же оконного класса, что и оконный класс hwnd. К примеру, если hwnd является описателем элементом управления edit, то этим вы измените курсор во всех edit-ах!

Но что если вам нужно изменить классовое свойство только для одного окна, вместо всех окон?

Если вы хотите изменить меню, фон, курсор или значок конкретного окна, то вы можете заместить умолчания класса на уровне окна:

Свойство	Метод
Меню	`SetMenu(hwnd, hmenuNew)` + удалить старое меню
Фон	Заместить `WM_ERASEBKGND`
Курсор	Заместить `WM_SETCURSOR`
Иконка	`SendMessage(hwnd, WM_SETICON, iconSize, LPARAM(hiconNew));`

Прим.пер.: вероятно, людей смущает тот факт, что функции Get/SetClassXYZ принимают аргументом окно, а не оконный класс.

Подводные камни вывода сглаженного текста с прозрачным фоном

2011-08-17T20:48:00.000+04:00

Это перевод Pitfalls of transparent rendering of anti-aliased fonts. Автор: Реймонд Чен.

Windows предоставляет несколько технологий рендеринга монохромного текста на цветных экранах, пользуясь преимуществами характеристик экрана для предоставления гладкого результата. Эти техники включают в себя сглаживание (grayscale anti-aliasing), а также и более продвинутую технику - ClearType. Обе техники читают фоновые пиксели, чтобы определить, что рисовать. Это означает, что рендеринг текста требует дополнительного внимания.

Если вы рисуете текст вместе с фоном (обрамляющим прямоугольником), то тут нет никаких проблем, потому что вы выводите текст вместе с фоном, так что вы получаете согласованный результат, вне зависимости от предыдущего состояния холста (canvas). Но если вы рисуете текст поверх существующего фона, то вы должны убедиться, что на фоне находится именно ожидаемое вами изображение.

К примеру, наиболее часто люди лажаются, выводя текст многократно. Я видел программы, которые рисуют всё более тёмный текст; чем дольше вы её используете - тем темнее становится текст. Давайте посмотрим на то, как это происходит, и как этого можно избежать. Создайте пустое VCL приложение с таким кодом:

type
  TForm1 = class(TForm)
    procedure FormCreate(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
    procedure FormPaint(Sender: TObject);
  private
    FAntialias: TFont;
    FClearType: TFont;
    procedure MultiPaint(const X, Y, N: Integer);
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.FormCreate(Sender: TObject);
begin
 FAntialias := TFont.Create;
 FClearType := TFont.Create;

 FAntialias.Handle := CreateFont(-20, 0, 0, 0, FW_NORMAL, 0, 0, 0, DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, ANTIALIASED_QUALITY, DEFAULT_PITCH, 'Tahoma');
 FClearType.Handle := CreateFont(-20, 0, 0, 0, FW_NORMAL, 0, 0, 0, DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, CLEARTYPE_QUALITY, DEFAULT_PITCH, 'Tahoma');
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  FreeAndNil(FClearType);
  FreeAndNil(FAntialias);
end;

procedure TForm1.FormPaint(Sender: TObject);
var
  SavedFont: TFont;
  SavedBrushStyle: TBrushStyle;
begin
  SavedFont := TFont.Create;
  try
    SavedBrushStyle := Canvas.Brush.Style;
    SavedFont.Assign(Canvas.Font);
    try
      Canvas.Brush.Style := bsClear;

      Canvas.Font := FAntialias;
      MultiPaint(10,  0, 1);
      MultiPaint(10, 20, 2);
      MultiPaint(10, 40, 3);
      MultiPaint(10, 60, 4);

      Canvas.Font := FClearType;
      MultiPaint(10,100, 1);
      MultiPaint(10,120, 2);
      MultiPaint(10,140, 3);
      MultiPaint(10,160, 4);
    finally
      Canvas.Font.Assign(SavedFont);
      Canvas.Brush.Style := SavedBrushStyle;
    end;
  finally
    FreeAndNil(SavedFont);
  end;
end;

procedure TForm1.MultiPaint(const X, Y, N: Integer);
var
  Str: String;
  I: Integer;
begin
  for I := 0 to N - 1 do
    Canvas.TextOut(X, Y, 'Съешь еще этих мягких французских булок, да выпей чаю.');
end;

Эта программа создаёт два шрифта: один вида anti-aliased, а другой - ClearType (я понятия не имею, почему люди утверждают, что не существует безопасного способа включить ClearType в одном окне. Мы только что это сделали).

Запустите эту программу и внимательно посмотрите на результаты. Заметьте, что каждый следующий ряд рисуется темнее предыдущего в обоих наборах. Чем больше мы делаем повторов вывода текста, тем темнее становится текст. В частности, заметьте, что повторный вывод текста с anti-aliased шрифтом делает результат всё уродливее и уродливее!

Что же пошло не так?

Когда мы рисуем текст первый раз, фон заполнен сплошным цветом окна. Но когда текст рисуется поверх повторно, то на фоновом изображении уже есть ранее написанный текст. Когда алгоритм решает что "Этот пиксель следует рисовать на 50% темнее", то по факту получается на 75% темнее, потому что пиксель затемняется дважды. А если вы рисуете три раза, то итоговое затемнение будет 88%.

Когда вы рисуете текст ровно один раз, он рисуется поверх планируемого вами фонового изображения. Это позволяет движкам anti-aliasing сглаживания и ClearType выполнять их работу очень аккуратно.

Те программы, которые рисуют чрезмерно тёмный текст, попались на эту проблему "печати поверх". Когда программа решает, что ей нужно обновить какое-то окно (к примеру, сместили фокус, так что фокусное выделение надо перерисовать - добавить или убрать), она "экономит время", не выполняя стирание фона, а просто рисует изображение поверх старого (текст, но с или без прямоугольника выделения). К сожалению, если вы не стираете фон, то текст будет выводиться поверх старого, приводя к затемнению.

Решение заключается в рисовании текста на правильном фоне. Если вы не знаете, что за фон сейчас на экране - то вам нужно стереть его, чтобы быть уверенным в известном его состоянии. В противном случае вы будете миксировать пиксели текста с неизвестным содержимым, что может приводить к нежелательным (и уродливым) результатам.

Если у вас орлиные глаза, то вы могли заметить и другой случай, когда люди делают эту же ошибку: когда текст в элементе управления (скажем, check box) становится темнее и темнее с каждым проходом через него по Tab. Это происходит из-за того, что люди не обращают внимание на флаги, передаваемые в записи TDrawItemStruct, передаваемой с сообщением WM_DRAWITEM. К примеру, некоторые люди просто рисуют элемент целиком, даже хотя оконный менеджер указывает флаг ODA_FOCUS, указывающий на необходимость рисования или стирания только прямоугольника фокуса. Это не будет проблемой, если рисование элемента включает в себя стирание фона. Но если вместо этого вы не стираете фон, предполагая, что его стёрло сообщение WM_ERASEBKGND, то в итоге вы повторите проблему рисования текста многократно в случае, когда вас просят исправить только прямоугольник фокуса. В этом случае элемент управления не стирается; всё, что от вам требуется - перерисовать прямоугольник фокуса. Если вы при этом ещё и рисуете текст, то вы делаете то же, что и функция MultiPaint из нашего примера выше: рисуете текст поверх текста, приводя к всё более тёмному тексту.

Блуждая в темноте и спотыкаясь о неверное решение

2011-08-16T02:00:00.000+04:00

Это перевод Fumbling around in the dark and stumbling across the wrong solution. Автор: Реймонд Чен.

Я не хотел придираться к этой серии записей, но она иллюстрирует интересный шаблон спотыкания на неверном "решении".

Эта серия пытается запустить системный триггер неактивности монитора отправкой сообщения окну рабочего стола (desktop window).

Как мы видели ранее, окно рабочего стола является очень особенным окном, и его, как правило, нужно избегать, поскольку оно не ведёт себя так же, как обычные окна приложений. В частности, в коде поста автор пытается отправить (post) сообщение окну рабочего стола. Это работало раньше в исторически открытом мире оконного менеджера, но требования безопасности и надёржности взяли приоритет над обратной совместимостью. В Windows XP SP2 окно рабочего стола не чувствительно к отключению, потому что программы продолжали неосознанно делать это, и оно блокирует отправленные ему сообщения. Я думаю, что это было сделано для противодействия shatter атакам. Да, это улучшило надёжность и стабильность, но также это сломало хак с PostMessage, на который рассчитывал код.

Начинается раунд 3, где автор ищет другие окна, которым можно было бы отправить сообщение, и в итоге он находит загадочное окно, которое, кажется, работает: HWND_TOPMOST = -1.

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

(Аналогично, я видел, как люди задают вопросы вроде "Что означает сообщение 49251?" Это обратный случай: люди увидели какое-то число и пытаются присвоить ему смысл. Номера сообщений, начинающиеся с $C000 (десятичное - 49152), являются сообщениями, регистрируемыми через RegisterWindowMessage. Числовое значение сообщения, ассоциированного с зарегистрированным сообщением, меняется от запуска к запуску, его нельзя предсказать. Единственная гарантия - это постоянство в рамках одного рабочего стола).

Если вы посмотрите более внимательно на итоговый код, вы увидите, что "решение", на самом деле, является ещё одним багом. Так получилось, что значение -1 оконного описателя подозрительно похоже на значение HWND_BROADCAST:

const
  HWND_BROADCAST = $FFFF;

Внутренне оконный менеджер принимает -1 (что есть $FFFFFFFF) за HWND_BROADCAST (объяснить, почему это так, - я оставляю вам в качестве упражнения; мы можете это сделать на основе наших предыдущих обсуждений). В результате, на самом деле, автор делает широковещательную рассылку сообщения всем окнам верхнего уровня! Как мы не раз видели ранее, широковещательная рассылка - это довольно опасное занятие, но в этом случае автору повезло в том, что все окна интерпретируют это сообщение одинаково - способом, который допускает многократную обработку сообщения, и ни одно окно не выполняет никакой особой фильтрации для этого сообщения (ещё один автор набрёл на это же неверное "решение", но не предоставил никаких деталей о процессе, в результате которого он пришёл к этому решению. И ещё один автор обнаружил некоторые проблемы, но не сложил все кусочки вместе).

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

Правильное решение - не отправлять сообщения случайным окнам. Если вы хотите, чтобы какое-то оконное сообщение прошло через системную обработку сообщений - просто создайте окно и отправьте сообщение ему. Не пытайтесь заставить другие окна в системе (в этом случае - сотни окон одновременно) делать эту работу за вас.

Помните, что происходит, когда вы делаете широковещательную рассылку

2011-08-15T02:00:00.000+04:00

Это перевод Remember what happens when you broadcast a message. Автор: Реймонд Чен.

Иногда я вижу, как люди делают вещи вроде широковещательной рассылки (broadcasting) сообщения WM_COMMAND всем окнам верхнего уровня (top-level windows). Это одна из вещей, которые настолько очевидно неправильные, что я не понимаю, как кому-то вообще может приходить в голову идея, что это будет работать.

Предположим, вы делаете такую рассылку:

SendMessage(HWND_BROADCAST, WM_COMMAND, 100, 0);

Что произойдёт?

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

#define IDC_USEDEFAULT 100
...
    AUTORADIOBUTTON "Use &default color",
                    IDC_USEDEFAULT, 14, 38, 68, 10, WS_TABSTOP

проинтерпретирует это сообщение как:

id 	= 	IDC_USEDEFAULT (100)
command 	= 	BN_CLICKED (0)
window 	= 	NULL (0) — недопустимый параметр

В зависимости от того, как написана оконная процедура, она может попытаться отправить сообщение кнопке (ей это не удастся, поскольку вы передали 0 в качестве оконного описателя), или она может обновить состояние диалога вроде отключения элементов управления (поскольку ей сказали, что пользователь щёлкнул на кнопку "User default color").

Какой-то другой диалог может иметь такой шаблон:

#define IDC_CHANGE 100
...
    PUSHBUTTON      "C&hange", IDC_CHANGE, 88, 95, 50, 14

Его диалоговая процедура проинтерпретирует сообщение как:

id 	= 	IDC_CHANGE (100)
command 	= 	BN_CLICKED (0)
window 	= 	NULL (0) — недопустимый параметр

Реакцией, вероятно, будет применение текущих изменений в диалоге.

А в это время ещё какое-то окно имеет меню, заданное так:

#define IDC_REFRESH 100
...
        MENUITEM "&Refresh", IDC_REFRESH

Оно проинтерпретирует сообщение как выбор пользователем элемента меню "Refresh".

id 	= 	IDC_REFRESH (100)
command 	= 	0 — недопустимый параметр, должно быть равно 1 для элементов меню
window 	= 	NULL (0)

Это не только будет являться не корректной командой для меню, но к тому же окно может находится в состоянии, когда программа отключила пункт "Refresh". И тем не менее вы отправили ей сообщение, как если бы пользователь выбрал пункт меню, что невозможно. Поздравляю, вы только что поставили программу в невозможную ситуацию, и она вполне может вылететь в результате этих действий. К примеру, программа могла заблокировать пункт меню потому что у неё нет объектов для обновления. Когда вы отправите ей команду обновления, она попытается обновить несуществующий объект и вылетит с разыменованием nil-указателя.

Очевидно, вы не можете делать широковещательную рассылку сообщения WM_COMMAND, потому что не существует его универсальной интерпретации в программах. Сообщение, которое означает команду "Обновить" для одного окна, вполне может означать команду "Изменить" для другого окна.

Та же логика применима почти ко всем стандартным сообщениям Windows. Вот сообщения, которые специально разработаны для широковещательной рассылки:

Если вы попытаетесь сделать широковещательную рассылку сообщения в диапазоне от WM_USER до WM_APP, то вы ещё безумнее, чем я думал. Как мы уже видели, смысл оконных сообщений в этом диапазоне определяется оконным классом или приложением, которое создало окно. Здесь уже контекстно-чувствительны не только параметры сообщения, но и само сообщение! Это означает, что отправка произвольному окну сообщения (к примеру) WM_USER + 1 приведёт к полностью случайному поведению системы (мы видели это ранее в контексте широковещательной рассылки, но это так же работает и для прямой доставки сообщения). Если это диалоговое окно, оно решит, что вы отправили ему сообщение DM_SETDEFID, и в итоге вы смените действие по умолчанию в диалоге. Если это общий диалог (common dialog), он решит, что это сообщение WM_CHOOSEFONT_GETLOGFONT, и если вам повезёт, то он вылетит при попытке доступа к TLogFont по недопустимому указателю (если вам НЕ повезёт, то параметры, которые вы передали с сообщением, позволят коду выполнится, приводя к работе кода программы над случайными данными, приводя к их порче и странному поведению программы). Если это элемент управления tooltip, то вы отправили ему TTM_ACTIVATE и, значит, что-то сделали с его состоянием активации.

Эти же предупреждения с использованием той же логики применимы и к отправке сообщений без универсального смысла окнам, с чьим оконным классом у вас нет интерфейсного контракта. К примеру, я видел как программисты отправляют сообщение PSM_PRESSBUTTON окну, которое, как они полагают без всяких на то оснований, является вкладкой свойств (property sheet).

Помните про это, когда вы собираетесь отправить сообщение в окно или окна: вам нужно быть уверенными, что окно (или окна) проинтерпретируют отправленное вами сообщение именно ожидаемым вами способом.