Блог GunSmoker-а (переводы)

Принцип имён в API: если объект не указан явно, то действие относится к исходному объекту

2024-07-25T14:09:00.001+03:00

Это перевод API naming principle: If there is no direct object, then the direct object is the source object. Автор: Реймонд Чен.

Обычно имена методов начинаются с глагола: widget.Toggle, widget.SetColor, widget.GetAssociatedDoodad.

Часто за глаголом следует объект: widget.SetColor, widget.GetAssociatedDoodad. Такой объект, указываемый явно — это то, над чем глагол работает, или что он создает. В примере выше: SetColor устанавливает (set) цвет (color), а GetAssociatedDoodad возвращает (get) ассоциированный doodad (associated doodad).

Иногда за глаголом вообще не следует название объекта. Например, метод widget.Toggle выше. В этом случае объект указывается неявно: это исходный объект. В приведенном выше примере widget.Toggle переключает (toggle) виджет (widget).

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

Например, одна команда разработчиков предложила создать API с объектом WidgetNotification и методом widgetNotification.Delete. Если трактовать это предложение, как было указано выше, то можно подумать, что предложенный метод удалит сам объект уведомления виджета, но они хотели, чтобы этот метод удалял бы прослушиватель (listener) уведомлений. По правилам выше, методы для создания и удаления прослушивателей должны быть названы как-то вроде widgetNotification.CreateListener и widgetNotification.DeleteListener.

В качестве другого примера: имя метода ApplicationDataManager.CreateForPackageFamily не говорит о том, что именно он создаёт, поэтому можно решить, что он создаёт ApplicationDataManager. Но это не так. На самом деле, он создаёт объект ApplicationData. Более правильное название для такого метода могло бы быть ApplicationDataManager.CreateDataForPackageFamily.

Исключением из этого правила являются фабрики объектов. Целью объектов-фабрик является создание других объектов, поэтому предполагается, что метод WidgetFactory.Create создаст widget. Но я не стану жаловаться, если бы вы назвали свой метод WidgetFactory.CreateWidget, просто чтобы внести ясность.

Что такое указатель статической цепочки в контексте соглашения о вызовах ABI?

2023-12-04T21:10:00.002+03:00

Это перевод What is a static chain pointer in the context of calling convention ABI? Автор: Реймонд Чен.

Глубоко в руководстве Application Binary Interface из System V для архитектуры AMD64 есть сноска на странице 24, в которой говорится: "%r10 используется для передачи указателя статической цепочки функции". Что такое "указатель статической цепочки"?

Некоторые языки (например, Паскаль/Delphi) поддерживают вложенные функции. Вложенной функции может быть разрешен доступ к переменным родительской функции. Например:

function Outer(n: Integer): Integer;
var
  i: Integer;

  procedure Inner(m: Integer);
  begin
    i := i + m;
  end;

// Тут начинаяется функция Outer
begin
  i := 0;
  Inner(n);
  Result := i;
end;

Функция Outer не делает ничего полезного, но она не делает это ничего интересным образом.

Она начинается с объявления локальной переменной i, а затем определяет локальную функцию Inner, которая добавляет свой параметр m к внешней переменной i. Затем идёт код самой функции Outer, который начинается с инициализации i нулём, вызывает Inner(n) (которая добавляет n к i), а затем возвращает изменённое значение i.

По сути, функция Outer просто возвращает свой аргумент, но она делает это с помощью внутренней функции.

Это работает так: функция Inner получает скрытый параметр, который сообщает ей, где находятся локальные переменные процедуры Outer.

На практике передается указатель на кадр стека внешней функции.

А если внешняя функция сама по себе является вложенной, вы можете использовать родительский фрейм для доступа к локальным переменным "дедушки":

function Outer(n: Integer): Integer;
var
  i: Integer;

  procedure Inner(m: Integer);
  
    procedure MoreInner;    
    begin              
      i := i + m;
    end;
    
  begin
    MoreInner;
  end;

// Тут начинаяется функция Outer
begin
  i := 0;
  Inner(n);
  Result := i;
end;

В этом примере функция MoreInner получает скрытый указатель на кадр стека функции Inner, что позволяет ей получить доступ к параметру m из Inner. Но Inner сама по себе является вложенной процедурой - и поэтому она тоже получила указатель на кадр стека родителя (в данном случае - Outer). Следовательно, MoreInner может использовать этот указатель для доступа к локальной переменной i функции Outer.

Вот как это выглядит:

MoreInner		Inner		Outer
указатель цепочки	➝	указатель цепочки	➝	`n`
		`m`		`i`

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

function Outer(n: Integer): Integer;
var
  i: Integer;

  procedure Update(j: Integer);
  begin
    i := i + j;
  end;

  procedure Inner(m: Integer);

    procedure MoreInner;
    begin
      Update(m);
    end;

  // Тело функции Inner
  begin
    MoreInner;
  end;

// Тут начинается функция Outer
begin
  i := 0;
  Inner(n);
  Result := i;
end;

Эта версия еще более бесполезна, чем предыдущая: MoreInner не обновляет i напрямую, а вместо этого просит Update (функцию-"дядю") сделать это.

В тот момент, когда функция MoreInner вызывает Update, она не передает свой собственный кадр стека в качестве указателя статической цепочки. Вместо этого она передает кадр стека Outer, поскольку родительским элементом Update является Outer.

Статическая цепочка не соответствует динамическому стеку вызовов: стек вызовов говорит, что вызывающий объект функции Update — функция MoreInner, но статическая цепочка говорит, что родительским объектом Update является функция Outer:

Update		MoreInner		Inner		Outer
указатель фрейма	➝	указатель фрейма	➝	указатель фрейма	➝	указатель фрейма
указатель цепочки						`n`
		указатель цепочки	➝	указатель цепочки	⭧	`i`
				`m`

Авторы руководства Application Binary Interface предполагают, что вы знакомы с тем, как реализованы вложенные функции, и просто отмечают, что соглашение о вызове вложенных функций заключается в передаче статической цепочки в регистре %r10.

Случай с загадочной ошибкой "out of bounds" из CreateUri и memmove

2023-02-21T13:28:00.000+03:00

Это перевод The case of the mysterious "out of bounds" error from CreateUri and memmove. Автор: Реймонд Чен.

Один клиент пытался понять, почему его программа вылетала с ошибкой E_BOUNDS ("out of bounds"), возбуждаемой из вызова метода CreateUri:

combase!RoOriginateErrorW+0x50
wincorlib!Platform::Details::ReCreateFromException+0x40
contoso!`__abi_translateCurrentException'::`1'::catch$0+0x10
contoso!memmove+0x217f4
contoso!Windows::Foundation::IUriRuntimeClassFactory::CreateUri+0x44
contoso!Contoso::DashboardView::DashboardView_obj1_Bindings::Update_ViewModel_Layout_Groups+0x50
contoso!Contoso::DashboardView::DashboardView_obj1_Bindings::Update_ViewModel_Layout+0xe4
contoso!Contoso::DashboardView::DashboardView_obj1_Bindings::PropertyChanged+0x1134
contoso!XamlBindingInfo::XamlBindingTrackingBase::PropertyChanged+0x30

Судя по стеку, процедура копирования памяти memmove вызывала высокоуровневое исключение RTL C++/CX E_BOUNDS — что не имеет никакого смысла. Ещё более загадочно то, что memmove была вызвана из метода CreateUri интерфейса IUriRuntimeClassFactory, но код клиента DashboardView вообще не работает с URI. Похоже, что этот стек вызовов - это просто какая-то чепуха.

Что ж, попробуем раскрутить эту чушь.

Что касается таинственного memmove: обратите внимание на смещение 0x217f4. Маловероятно, что размер примитивной функции копирования памяти превышает 100 Кб. Тогда что тут происходит? Ну, это просто какой-то код, который, вероятно, был перемещен в редко используемую кодовую страницу подальше от остального кода. Ну и так случилось, что ближайший к нему символ — memmove:

    xor     ecx,ecx
    call    contoso!__abi_translateCurrentException
    int     3       ; memmove+0x217f4

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

Хорошо, тогда почему же метод CreateUri выбрасывает исключение "out of bounds"?

Подождите, а вы уверены, что это действительно метод CreateUri?

Я посмотрел на записи выше по стеку и спросил себя: "почему код привязки данных (data binding) вызывает CreateUri?".

Код привязки данных автоматически создается компилятором XAML; он не присутствует в исходном коде программы. Вместо того, чтобы пытаться понять, как собрать и построить их проект (чтобы я мог извлечь автоматически сгенерированный файл), возможно, у меня получится разобраться по стеку и исходному коду.

Одно из основных предположений о коде в целом состоит в том, что люди, которые пишут код — не садисты. Это означает, что имена функций обычно описывают то, что они делают, имена переменных обычно описывают то, что они представляют, и так далее. Поэтому, когда я вижу класс с именем DashboardView_obj1_Bindings, я предполагаю, что этот класс предназначен для работы с привязками некоторого объекта внутри DashboardView, и поскольку у него есть метод с именем Update_ViewModel_Layout_Groups, он, вероятно, как-то связан с обновлением привязки чего-то с именем, включающим в себя слова ViewModel, Layout и Groups.

Я просмотрел DashboardView.xaml в исходном коде программы и, действительно, нашёл там слово ViewModel в элементах, которые, как оказалось, связаны с привязкой данных:

<ContentControl
    Grid.Row="0"
    x:Name="TogglesGroup"
    IsTabStop="False"
    Width="360"
    Content="{x:Bind ViewModel.Layout.Groups[0], Mode=OneWay}"
    ContentTemplateSelector="{StaticResource DashboardGroupTemplateSelector}"/>

Это было не первое использование x:Bind в разметке XAML, что не соответствует obj1, но другие части совпадают (Layout и Groups), поэтому я списал это на "возможно, компилятор XAML создаёт привязки в порядке, отличном от порядка их появления в разметке».

Как эта привязка могла вызвать исключение "out of bounds"? Ну, тут записана операция с индексом 0, так что, возможно, коллекция Groups была пуста?

Я посмотрел на метод Update_ViewModel_Layout_Groups, чтобы убедиться, что эта теория соответствует действительности:

; Update_ViewModel_Layout_Groups:
    test    rdx,rdx
    je      ...
    mov     qword ptr [rsp+8],rbx
    mov     qword ptr [rsp+18h],rbp

    push    rsi
    push    rdi
    push    r14
    sub     rsp,20h
    mov     rbp,rdx
    mov     rsi,rcx
    test    r8d,0C0000001h
    je      ...

    xor     edx,edx
    mov     rcx,rbp
    call    contoso!Windows::Foundation::IUriRuntimeClassFactory::CreateUri

Функция начинается с раннего завершения (без формирования стекового фрейма), если первый параметр равен нулю (это код метода C++, поэтому RCX содержит Self, а RDX содержит первый "настоящий" параметр метода). Я понятия не имею, как работает связывание, поэтому предположим, что это часть его логики.

А если параметр не равен нулю, то мы создаем правильный фрейм стека, проверяем некоторые биты в третьем параметре и, если они установлены, мы вызываем... простите, что? CreateUri с nil? Это же бессмысленно. XAML не запрашивает URI, зачем ему пытаться создать URI из пустой строки?

Опытный разработчик сообразит, что клиент (снова) был обманут оптимизатором.

Параметр Self для вызова CreateUri должен быть IUriRuntimeClassFactory, но это не то, что мы передаем: мы передаем первый формальный параметр (который не является IUriRuntimeClassFactory). Это значит, что перед нами вовсе не вызов CreateUri.

На самом деле, это — вызов метода GetAt интерфейса IVector, а параметр метода равен нулю, потому что нам нужен объект с нулевым индексом. Методы GetAt и CreateUri были свёрнуты оптимизатором (что означает, что они занимают одно и то же место в машинном коде), потому что они побайтно идентичны! Они оба реализуют логику "вызови метод с одним параметром по индексу 6 из VMT объекта". Для IUriRuntimeClassFactory этим методом будет CreateUri со строковым параметром, а для IVector этот метод — GetAt, а параметр — индекс.

Благодаря этому объяснению клиент понял, что у него действительно была нерешенная проблема, которая гласила: "Если наш файл настроек поврежден, то у нас не будет групп", а это исключение просто являлось альтернативным проявлением этой проблемы.

Почему x86-64 функции Windows НЕ начинаются с бессмысленной инструкции MOV EDI, EDI?

2022-11-10T13:10:00.001+03:00

Это перевод Why don’t Windows functions begin with a pointless MOV EDI,EDI instruction on x86-64? Автор: Реймонд Чен.

Когда-то мы обсуждали, почему все функции Windows начинаются с бессмысленной инструкции MOV EDI, EDI. Ответ заключался в том, что эта инструкция использовалась как двухбайтовый NOP, что позволяло безопасно заменить её на инструкцию перехода JMP $-5, что позволяло применять различные исправления к работающей системе (такой метод не подходит для тех исправлений, которые изменяют структуры данных или включают взаимодействие между процессами).

Но вы могли заметить, что в 64-битной Windows эти бессмысленные инструкции исчезли. Значит ли это, что метод мёртв?

Нет, этот способ всё ещё применяется. Но в 64-битной Windows точка для внедрения реализована иначе.

Идея состоит в том, что нам не нужно вставлять в каждую функцию бессмысленную двухбайтовую инструкцию NOP, если первая (настоящая) инструкция функции уже является двухбайтовой инструкцией (или длиннее). В этом случае эта инструкция сама по себе может служить точкой для внедрения.

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

`PUSH R`	`LEAVE`	`CWDE`	`INT 3`
`POP R`	`RET`	`CDQ`	`NOP`

где R — 64-битная версия одного из восьми именованных (не пронумерованных) регистров.

Некоторые из этих инструкций не могут стоять в начале функции:

LEAVE не имеет смысла, потому что она изменяет регистр, который мы (как вызываемый) должны сохранять.
CWDE и CDQ не имеют смысла, потому что они используют RAX в качестве входного регистра, но этот регистр не определен при входе в функцию.
NOP можно просто опустить.
Начало функции с POP запрещено Win32 ABI: адрес возврата должен оставаться в стеке.

Остаётся всего пара инструкций, которые можно обойти:

PUSH: если функция вносит в стек какие-либо регистры R8 или выше, компилятор может поставить эти инструкции в начало функции, поскольку внос в стек регистра с верхним номером является двухбайтовой инструкцией. Либо же компилятор может перекодировать инструкцию с избыточным префиксом REX 0x48. Наконец, в качестве альтернативы компилятор может сохранить регистр в домашнем пространстве (home space), для чего используется многобайтовая инструкция MOV [RSP+n], R.
RET: это происходит, если функция пуста и не возвращает значения. Тогда компилятор может изменить её на 3-байтовый RET 0 или 2-байтовый REPZ RET.

Последняя оставшаяся инструкция — INT 3 (программная точка останова).

Один из вариантов — использовать альтернативную двухбайтовую кодировку CD 03 (INT nn, где nn = 3). Однако код, который установил INT 3, может полагаться на то, что это именно однобайтовая инструкция, потому что он намеревается исправить её с помощью однобайтового NOP, или он намеревается обработать исключение "точка останова", перешагнув код инструкции путём увеличения указателя инструкции на 1.

Вместо этого компилятор перестраховывается и начинает функцию с двухбайтового NOP, который закодирован как XCHG AX, AX - и, действительно, отладчик Microsoft именно так его и дизассемблирует.

Бессмысленная инструкция MOV EDI, EDI исчезла. И в большинстве случаев компилятор может жонглировать командами так, что вы даже не заметите, что он устроил так, чтобы первая инструкция вашей функции была многобайтовой инструкцией. Единственный случай, когда компилятор терпит неудачу, это если первой инструкцией вашей функции является INT 3, но тогда компилятор вставляет бессмысленную инструкцию XCHG AX, AX, также известную как двухбайтная команда NOP.

Почему все функции Windows начинаются с бессмысленной инструкции MOV EDI, EDI?

2022-11-10T12:29:00.001+03:00

Это перевод Why do Windows functions all begin with a pointless MOV EDI, EDI instruction? Автор: Реймонд Чен.

Если вы посмотрите на ассемблерный код функций внутри DLL Windows, вы обнаружите, что они начинаются с бессмысленной инструкции MOV EDI, EDI. Эта инструкция копирует регистр в самого себя и не обновляет флаги, что совершенно не имеет смысла. Тогда зачем она там?

Это точка для внедрения кода.

Инструкция MOV EDI, EDI представляет собой двухбайтовый NOP (операция, которая ничего не делает). Двух байт как раз достаточно для вставки инструкции перехода, чтобы функцию можно было обновить на лету. Предполагается, что инструкция MOV EDI, EDI будет заменена двухбайтовой инструкцией JMP $-5 (перейти по адресу, записанному на пять байт выше) для передачи управления на пять байтов из так называемого "patch space" (места для патчей), которое вставляется непосредственно перед началом функции. Пять байтов достаточно для полной инструкции перехода, которая может передать управление на любую функцию где-то ещё в адресном пространстве.

Хотя пять байтов из места для патчей до начала функции состоят из пяти однобайтовых инструкций NOP, точка входа функции использует одну двухбайтовую NOP.

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

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

Почему бы просто не использовать две инструкции NOP в точке входа?

Ну, поскольку инструкция NOP использует один тактовый цикл и один конвейер, поэтому две из них будут использовать два такта и два конвейера (инструкции, скорее всего, будут парными, по одной в каждом канале, поэтому совместное выполнение займет один такт). С другой стороны, инструкция MOV EDI, EDI использует один тактовый цикл и один канал (т.е. на практике инструкция занимает один канал, а другой остается доступным для параллельного выполнения другой инструкции. Можно сказать, что инструкция выполняется за половину цикла). Как бы вы ни прикидывали, инструкция MOV EDI, EDI выполняется в два раза быстрее двух инструкций NOP.

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

Но гораздо важнее, чем подсчет циклов, является то, что использование двухбайтового NOP позволяет избежать вышеупомянутой проблемой с Detours: если в коде использовались бы две однобайтовые инструкции NOP, то есть риск, что вы установите свой патч в то же самое время когда поток завершает выполнение первого однобайтового NOP и собирается начать выполнение второго однобайтового NOP, в результате чего поток будет трактовать вторую половину вашего JMP $-5 как начало новой инструкции.

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

Читать далее: Почему x86-64 функции Windows НЕ начинаются с бессмысленной инструкции MOV EDI, EDI?

Рано или поздно особенное перестанет быть особенным

2022-07-04T14:14:00.002+03:00

Это перевод Eventually, nothing is special any more. Автор: Реймонд Чен.

Комментатор ulric предположил, что должны существовать две функции для получения "текущего" окна: одна для обычного повседневного использования и одна для "специального использования", когда вы хотите взаимодействовать с окнами вне вашего процесса.

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

Это отличный пример предложения того, что Windows уже делает! Специальная функция стала настолько не особенной, что вы даже не понимаете, что она особенная.

Изначально в 16-битной Windows функцией получения "текущего" окна была GetActiveWindow. Она получала активное окно всей системы. Однако одно из основных изменений Win32 - это введение модели асинхронного ввода, при которой окна из разных очередей ввода имеют независимый ввод. Таким образом, одна программа, которая перестала реагировать на ввод, не блокирует ввод других несвязанных окон. Поэтому Win32 изменила значение GetActiveWindow, чтобы она возвращала активное окно из текущей очереди ввода.

В 16-битной Windows была только одна входная очередь, глобальная. В 32-разрядной версии Windows каждый поток (или группа потоков, присоединенных к вводу) получает собственную очередь ввода.

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

Хорошо, давайте посмотрим, что у нас есть сейчас. GetFocus и GetActiveWindow сообщают вам статус вашей входной очереди. Другими словами, в однопоточной программе (которая в 16-битной Windows является единственным типом программ) вызов GetActiveWindow дает вам активное окно из вашей программы. Он не возвращает активное окно из другой программы.¹ Все именно так, как предложил ulric!

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

Поэтому мы сделали именно то, что рекомендовал ulric - и всё равно получился бардак. Почему?

Потому что особенное не останется особенным надолго.

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

А потом кто-то отвечает: "Да, GetActiveWindow не работает. Я обнаружил, что GetForegroundWindow работает намного лучше".

Затем следует ответ: "Вау, отлично работает! Спасибо!"

В конце концов, даже на улице говорят: "GetActiveWindow не работает. Используйте вместо неё GetForegroundWindow". Вскоре люди используют её для всего: полируют машину, успокаивают ребенка или улучшают свою сексуальную привлекательность.

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

На самом деле немодность активного окна (active window) дошла до того, что люди вообще перестали называть его активным окном! Вместо этого они называют его окном переднего плана текущего процесса (foreground window from the current process). Это всё равно, что называть наземную линию "проводным сотовым телефоном".

Требование нового флага для получения специального поведения ничего не меняет. Это та же история, только с другими именами персонажей. "GetFocalWindow² не работает, если вы не передадите флаг GFW_CROSSPROCESS". Скоро все будут передавать GFW_CROSSPROCESS не потому, что понимают, что он делает, а просто потому, что "мне так сказали делать" и "ничего не заработает, если я его не передаду".

Примечания
¹ Предполагая, что вы не пытаетесь присоединить свой поток к входной очереди какой-либо другой программы. Это довольно безопасное предположение, поскольку функция AttachThreadInput не существовала в 16-разрядной версии Windows.

² GetFocalWindow - это воображаемая функция, созданная для примера.

Теперь элемент манифеста activeCodePage можно использовать для установки не только UTF-8

2022-06-01T13:30:00.007+03:00

Это перевод The activeCodePage manifest element can be used for more than just setting UTF-8 as the active code page. Автор: Реймонд Чен.

В Windows 10 версии 1903 появилось новое свойство манифеста под названием activeCodePage, которое можно использовать для установки кодовой страницы процесса в UTF-8.

Начиная с Windows Server 2022 (и Windows 11)¹ вы также можете использовать это свойство для выбора кодовых страниц, отличных от UTF-8, в манифестах неупакованных приложений².

AppLocale наконец-то повзрослел!

Если вы указываете Legacy в activeCodePage, то этим вы говорите, что ваше приложение "активно ненавидит" UTF-8. В таком случае ему будет присвоена системная локаль по умолчанию - при условии, что она существует и не является UTF-8. В противном (исключительном) случае вы получите кодовую страницу 1252 в качестве запасного варианта.

Вы также можете указать имя локали, например en-US, ru-RU или ja-JP, и приложение получит кодовую страницу, соответствующую этой локали. Если локаль не распознается системой, вы получите UTF-8 в качестве запасного варианта.

Этот трюк наиболее полезен для целей совместимости приложений: если у вас есть какое-то устаревшее приложение, которое предполагает определенную локаль, вы можете развернуть манифест рядом с приложением, который говорит: «Мне все равно, какую локаль использует система. Дайте этому приложению языковой стандарт, который он хочет».

Вот сводная таблица, так как я знаю, что люди любят сводные таблицы.

`activeCodePage` =	`UTF-8`	имя локали	`Legacy`
Регистр важен?	Да	Нет	Да
Предпочтительный результат	UTF-8	Указанная локаль, если доступна	Системная локаль, если доступна, но не UTF-8
Запасной вариант		UTF-8	1252
Packaged-приложение	Поддерживается	Не поддерживается	Не поддерживается
Unpackaged-приложение	Поддерживается	Поддерживается	Поддерживается

¹ В частности, сборка 20348 и более поздняя версия, которая также включает HoloLens 2 - также известную как Windows Holographic версии 21H1.

² Кодовое название манифестов неупакованных приложений³ было "fusion", поэтому в документации вы можете видеть термин "fusion-манифесты".

³ В то время их не называли "манифестами неупакованных приложений", потому что, когда писался проект fusion, у нас вообще не было упакованных приложений. Их называли просто "манифестами". Позже, когда для упакованных приложений были введены манифесты, для описания fusion-манифестов был изобретен ретроним "манифесты неупакованных приложений".

Как Windows определяет, должно ли вновь созданное окно использовать ориентацию LTR или RTL?

2022-05-24T06:35:00.000+03:00

Это перевод How does Windows decide whether a newly-created window should use LTR or RTL layout? Автор: Реймонд Чен.

В Extended стилях окна можно указать, будет ли оно отображаться слева направо (Left-To-Right - LTR) или справа налево (Right To Left - RTL). Раскладка справа налево используется в языках с написанием справа налево - из которых сегодня наиболее широко используются, вероятно, арабский и иврит. Вы можете попросить Windows сделать окно с ориентацией RTL, установив Extended-стиль WS_EX_LAYOUTRTL.

Если вы не укажете Extended-стиль WS_EX_LAYOUTRTL, система всё равно может применить этот стиль автоматически на основе следующих правил:

Сценарий		Правило
Дочернее окно (child window)	Родитель не указывает `WS_EX_NOINHERITLAYOUT`	Наследует `WS_EX_LAYOUTRTL` от родителя.
Дочернее окно (child window)	Родитель указывает `WS_EX_NOINHERITLAYOUT`	Остаётся LTR.
Окно верхнего уровня (top-level window)	Есть владелец (owned)	Остаётся LTR.
Окно верхнего уровня (top-level window)	Нет владельца	Согласно `GetProcessDefaultLayout`.

В случае окна верхнего уровня без владельца Extended-стиль WS_EX_LAYOUTRTL устанавливается автоматически, если в настройках по умолчанию процесса установлен бит LAYOUT_RTL.

Как я заметил некоторое время назад, если процесс ни разу не вызывает функцию SetProcessDefaultLayout, то начальные настройки процесса определяются путём проверки свойства версии FileDescription основного исполняемого файла: если оно начинается с двух меток LRM (Left-To-Right Mark, это кодовая точка Unicode U+200E), то в настройки процесса добавляется LAYOUT_RTL.

Ранее я также отметил, что вы можете запросить у GetLocaleInfoEx свойство LOCALE_IREADINGLAYOUT, чтобы определить, является ли какой-либо конкретный язык LTR или RTL.

// Направление:
// 0 = слева направо (например, английский, русский и т.п.)
// 1 = справаналево (например, арабский)
// 2 = сверху вниз, справа налево (например, классический китайский)
// 3 = свурху вниз, слева направо (например, монгольский)

function GetLanguageReadingLayout(const ALanguageName: String): Integer;
begin
  Win32Check(Boolean(
    GetLocaleInfoEx(ALanguageName,
                    LOCALE_IREADINGLAYOUT or LOCALE_RETURN_NUMBER,
                    PWideChar(@Result),
                    SizeOf(Result) div SizeOf(Char))));
end;

function GetSystemDefaultLanguageReadingLayout: Integer;
begin
  Result := GetLanguageReadingLayout(LOCALE_NAME_SYSTEM_DEFAULT);
end;

function GetUserDefaultLanguageReadingLayout: Integer;
begin
  Result := GetLanguageReadingLayout(LOCALE_NAME_USER_DEFAULT);
end;

Но обычно вас интересует основной язык для текущего потока, так как именно он больше всего влияет на языковые ресурсы, используемые вашей программой. Вы можете использовать GetThreadPreferredUILanguages, чтобы получить все языки, применимые к текущему потоку, а затем передать первый язык в нашу вспомогательную функцию GetLanguageReadingLayout. Вызов функции GetThreadPreferredUILanguages немного разочаровывает, потому что список применимых языков может меняться асинхронно (если другой поток вызывает SetProcessPreferredUILanguages). Это вдвойне раздражает, потому что вспомогательная функция AdaptFixedSizeToAllocatedResult работает с нуль-терминированными строками и не поддерживает строки, заканчивающиеся двойным нулём, поэтому придётся писать цикл вручную:

// Возвращает строку вида
// 'ru-RU'#0'ru'#0'en-US'#0'en'#0#0
function GetThreadPreferredUILanguages(const AFlags: DWORD): String;
var
  Count, BufferSize: Integer;
  Error: Cardinal;
begin
  Count := 0;
  BufferSize := 0;
  SetLastError(0);
  Win32Check(WinAPI.Windows.GetThreadPreferredUILanguages(AFlags, @Count, nil, @BufferSize));
  repeat
    SetLength(Result, BufferSize);
    if WinAPI.Windows.GetThreadPreferredUILanguages(AFlags, @Count, PChar(Result), @BufferSize) then
      Error := 0
    else
      Error := GetLastError;
  until Error <> ERROR_INSUFFICIENT_BUFFER;
  Win32Check(Error = 0);
end;

Теперь мы можем подключить это к нашей существующей функции:

function GetDefaultThreadLanguageReadingLayout: Integer;
begin
  Result := GetLanguageReadingLayout(PChar(GetThreadPreferredUILanguages(MUI_LANGUAGE_NAME or MUI_UI_FALLBACK)));
end;

Извините, что получилось так сложно.

Бонусная болтовня: вся эта логика предполагает, что ваша программа изначально была переведена на язык RTL. Если ваша программа предназначена только для английского/русского языка, не отображайте английские/русские строки в RTL. Как я отметил в этой статье, вы можете добавлять метки в строковые ресурсы, чтобы указать в каком направлении ресурсы ожидают чтения строк.

Что означает поле SizeOfImage в структуре MODULEINFO?

2021-10-15T17:39:00.003+03:00

Это перевод What does the SizeOfImage mean in the MODULEINFO structure? Автор: Реймонд Чен.

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

Вспомните, что структура MODULEINFO формируется загрузчиком ОС, а задача загрузчика - управлять модулями, загруженными процессом. SizeOfImage в паре с lpBaseOfDll описывают диапазон виртуальных адресов, который занимает образ модуля (DLL) после загрузки с диска. Загрузчик использует эту информацию для различных целей - в том числе для ответа на флаг GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS, передаваемый в функцию GetModuleHandleEx.

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

Если вы хотите измерить объём памяти, занимаемый плагином, вам необходимо принять все эти моменты во внимание. Хотите ли вы подсчитывать данные для чтения/записи отдельно от кода, ресурсов и других данных только для чтения? Не всякий код, ресурсы и данные из виртуального адресного пространства будут в файле.

Решение о том, какие разделы считать, а какие нет - это вопрос, на который можете ответить только вы. В этом вам может помочь сам модуль, в заголовке которого будут поля SizeOfCode, SizeOfData и SizeOfUninitializedData, что избавит вас от необходимости вычислять эти значения самостоятельно. Они охватывают код, данные (любые: и для чтения и для чтения/записи) и данные с нулевой инициализацией соответственно. Эти значения могут стать отправной точкой, если вас не интересуют таблица перемещений (relocation table), ресурсы или таблицы исключений.

Почему в заголовочниках Windows полно слов типа "чувак"?

2021-08-19T13:43:00.004+03:00

Это перевод What’s with all of the references to “dude” in the accessibility header files? Автор: Реймонд Чен.

Если вы читали заголовочнй файл winuser.h, то вы могли видеть как комментарии ссылаются на объекты как на "чуваков" ("dudes"):

/*
 * For all EVENT_OBJECT events,
 *      hwnd is the dude to Send the WM_GETOBJECT message to (unless NULL,
 *          see above for system things)
 *      ...
 *          The hwnd/idObject pair gets you to the container, the dude you
 *          probably want to talk to most of the time anyway.  The idChild
 *          can then be passed into the acc properties to get the name/value
 *          of it as needed.
 *      ...
 * Now, if the app itself resizes child windows as a result of being
 * sized, USER will generate LOCATIONCHANGEs for those dudes also because
 * it doesn't know better.
 *      ....
 */

Что это ещё за "чуваки"? Автор комментариев была большим поклонником Большого Лебовски?

Насколько я знаю, тут нет никакой связи.

Термин "чувак" (dude) был своего рода "крылатой фразой" в команде диспетчера окон Windows 95 и обычно означал "вещь", "сущность", "какая-то штука". Это слово часто встречается во внутренних комментариях. Вот несколько примеров:

// Returns NULL or hMenu if top level dude

// If the dude that has focus is a button, then...

// Realloc the dude to the right size.

// Is the caller a 32-bit dude?

; lParam is the thread ID of the other dude.

Популярность термина распространилась через "перекрестное опыление" среди нескольких других команд, в первую очередь - команды оболочки, поэтому вы видите слово "чувак" и в других частях Windows 95. Но большинство из них находится в диспетчере окон.

Дополнительная болтовня: вне пределов диспетчере окон (и тесно связанных с ним команд разработчиков) тоже можно встеретить "чувака", но в других местах он используется как форма прямого обращения, а не как существительное-заполнитель:

"Party on, dude!"
"Not mine, dude!"
"No way, dude!"

Перед проведением исследования я думал, что источником "чуваков" могли бы быть фразы Барта Симпсона "Cowabunga, dude!" и "Don’t have a cow, dude!" - учитывая, что Симпсоны находились в так называемом "золотом веке" как раз во время разработки Windows 95. Однако я не смог найти ни одного примера, подтверждающего эту гипотезу.

Почему не зависящие от устройства растровые изображения перевёрнуты вверх ногами?

2021-05-26T12:19:00.004+03:00

Это перевод Why are device-independent bitmaps upside down? Автор: Реймонд Чен.

Для всех, кто в первый раз знакомится с независимыми от устройства (device-independent) растровыми изображениями Windows, становится сюрпризом тот факт, что они перевёрнуты - в том смысле, что первая строка пикселей соответствует нижней строке изображения, а последующие строки пикселей идут по изображению вверх, при этом последняя строка пикселей соответствует самой верхней строке изображения.

Ладно, не будем называть эти растровые изображения перевёрнутыми вверх ногами. Менее осуждающий термин - называть их восходящими (bottom-up) растровыми изображениями.

Итак, почему растровые изображения, не зависящие от устройства, хранятся снизу вверх?

Для совместимости с OS/2.

В OS/2 Presentation Manager начало координатного пространства графики находится в нижнем левом углу экрана, а координата Y увеличивается по мере продвижения к верхней части экрана. Такая система координат совпадает с математически правильной системой координат, что устраняет много путаницы, когда вы начинаете заниматься математикой с вашей графикой.

Я сильно подозреваю, что компьютерная графика подразумевает использование математики.

Если вы используете математическую координатную модель, тогда все математические формулы сохранятся без необходимости вводить "случайные" отрицательные знаки для учёта перевёрнутой оси Y. Углы поворота всегда будут против часовой стрелки. Матрицы преобразования координат будут работать так же, как вы изучали в классе линейной алгебры. Всё отлично получается.

Конечно, если вы не один из таких математиков, то увеличение координаты Y вверх означает, что порядок чтения противоположен порядку увеличения координат.

Что странно.

Windows 2.0 и OS/2 начинали как хорошие друзья, поэтому Windows 2.0 приняла растровый формат OS/2, чтобы способствовать взаимодействию между ними. Как мы все знаем, эта дружба со временем испортилась, но решение о формате файла сохраняется.

Почему в выводе echo командной строки с перенаправлением появляется 1? Кто вставляет эти единицы?

2020-11-17T05:20:00.002+03:00

Это перевод Why does my command line redirection echo with an extra 1? Who’s inserting these rogue 1s everywhere? Автор: Реймонд Чен.

Если вы оставите включённым режим echo в командном файле, и командный файл выполняет команду с перенаправлением, тогда в выводе появится загадочная единичка.

C:\> copy con %TEMP%\test.cmd
dir >nul
^Z
        1 file(s) copied.

C:\> %TEMP%\test.cmd

C:\> dir  1>nul
          ⇑
          🤨

Изгой 1 оказывается чисто визуальным. В командной строке нет единички. В примере выше список каталогов относится к текущему каталогу, а не к каталогу с именем 1.

Но откуда тогда берётся эта единица?

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

По умолчанию, если поток не указан, перенаправляется поток stdout, а номер потока stdout… 1.

Так, головоломка начинает складываться.

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

Если вы не указали явный поток для перенаправления, будет распечатан поток по умолчанию (stdout = 1), потому что именно этот поток перенаправляется.

Это просто причуда. На функциональность это не влияет. Хотя это выглядит немного странно, когда вы замечаете это в первый раз.

Как можно заклинить виртуальный картридер?

2020-09-09T15:50:00.003+03:00

Это перевод How is it possible to jam a virtual card reader? Автор: Реймонд Чен.

Когда-то давно я поддерживал систему с разделением времени, известную как VM/CMS. Каждый пользователь, вошедший в систему, получал свою собственную виртуальную машину с виртуальными аппаратными устройствами: виртуальным устройством для чтения карт, виртуальным устройством для записи перфокарт и виртуальным принтером.

Хорошо, у вас есть виртуальный картридер. Как вы будете загружать виртуальные карты в свой виртуальный картридер? И зачем вообще это делать?

Во времена физических карт вы сохраняли файл, создавая для него колоду перфокарт. И чтобы передать кому-нибудь этот файл, вы передавали ему колоду карт. Затем этот человек включал свою систему и вставлял перфокарты в картридер, чтобы загрузить файл.

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

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

Команда для проверки электронной почты была Q RDR: команда Query Reader проверяла, есть ли что-нибудь в вашем виртуальном картридере. Если да - значит, вы получили почту.

Однажды мы получили отчёт об ошибке с сообщением, которое никто никогда раньше не видел: Card reader jammed (заклинивание в картридере).

Как можно заклинить виртуальный картридер? Вы скормили ему согнутую виртуальную карточку?

Я уже заканчивал свою смену и не дождался решения. Позже я узнал, что один из моих коллег нашёл решение проблемы в руководстве.

Я вот думаю: выключил ли он его виртуально и снова включил?

Бонусная болтовня: задолго до появления VM/CMS перфокарты были настоящими. Я начал программировать как раз тогда, когда перфокарты умирали, но я помню, что в жаркие летние месяцы был один глупый трюк, чтобы немного охладиться: надо было подойти к служебному окну в компьютерном зале и отдать в работу несколько десятков карт. Операторы открывали окно, чтобы забрать ваши перфокарты, и в это время вы получали короткий поток прохладного воздуха из машинного зала³.

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

² Я предполагаю, что вы могли бы считать свой файл с картридера, а затем снова немедленно отправить его себе, тем самым сбрасывая срок годности. Но это был высокорисковый манёвр, поскольку один неверный шаг мог привести к потере файлов.

³ Когда работа была закончена, операторы открывали служебное окно, чтобы вернуть колоду перфокарт вместе с распечаткой результатов работы. Однако вы не могли при этом украсть второй поток прохладного воздуха, потому что вы не знали, чью работу выдавали. Нельзя просто торчать прямо перед окном, потому что операторы подумают, что вы пытаетесь отправить задание. По соглашению, если вы ожидаете результатов задания, вы должны стоять на небольшом, но уважительном расстоянии от окна, чтобы не сбивать с толку операторов. Достаточно близко, чтобы вы могли получить небольшое количество прохладного воздуха, но не настолько близко, чтобы операторы могли подумать, что вы хотите отправить задание.

Чему может быть равно свойство Status у WMI класса Win32_ComputerSystem?

2020-09-02T16:19:00.000+03:00

Это перевод What are the possible Status values for Win32_ComputerSystem? Автор: Реймонд Чен.

Документация для WMI класса Win32_ComputerSystem содержит такое описание свойства Status:

Status
Тип данных: string
Доступ: только чтение
Квалификаторы: MaxLen (10), DisplayName (“Status”)

Текущее состояние объекта. Могут быть определены различные рабочие и нерабочие состояния. К рабочим статусам относятся: OK, Degraded и Pred Fail. Последнее значение может использоваться, к примеру, жёстким диском с поддержкой SMART, который может функционировать правильно, но прогнозирует сбой в ближайшем будущем. К нерабочим состояниям относятся: Error, Starting, Stopping и Service, которые могут применяться во время переноса зеркала диска, перезагрузки списка разрешений пользователей или другой административной работы.

Это свойство наследуется от CIM_ManagedSystemElement.

Значения могут быть следующими:
OK (“OK”)
Error (“Error”)
Degraded (“Degraded”)
Unknown (“Unknown”)
Pred Fail (“Pred Fail”)
Starting (“Starting”)
Stopping (“Stopping”)
Service (“Service”)
Stressed (“Stressed”)
NonRecover (“NonRecover”)
No Contact (“No Contact”)
Lost Comm (“Lost Comm”)

Что эта чушь пытается нам сказать? И что она говорит нам о возможных значениях свойства Status для Win32_ComputerSystem?

Хорошо, сначала я дам ответ, а потом мы его обсудим.

Ответ заключается в том, что Status для Win32_ComputerSystem всегда равен "ОК". Сама система не сообщает о каком-либо интересном для себя состоянии, хотя она сообщает о статусе других вещей, например FrontPanelResetStatus.

Тогда почему Win32_ComputerSystem вообще имеет свойство Status, если ничего интересного оно не сообщает?

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

Это свойство наследуется от CIM_ManagedSystemElement.

Win32_ComputerSystem имеет свойство Status не потому, что он хочет сообщать о своём собственном статусе, а потому, что он вынужден сообщать о своём собственном статусе из-за наследования.

Это также объясняет бессвязное описание: это описание также было унаследовано от CIM_ManagedSystemElement. Класс CIM_ManagedSystemElement должен описывать все возможные элементы системы, поэтому он имеет большое количество доступных значений для Status, а в документации делается попытка объяснить, что означают эти значения статуса, поскольку они могут применяться к произвольным производным классам.

Тут помогли бы кой-какое переформатирование и дополнительные уточняющие слова:

Текущее состояние объекта.

Могут быть определены различные рабочие и нерабочие состояния.

К рабочим статусам относятся: OK, Degraded и Pred Fail (Pred Fail может сообщать, к примеру, жёсткий диск с поддержкой SMART, который может функционировать должным образом, но прогнозирует сбой в ближайшем будущем).

К нерабочим состояниям относятся: Error, Starting, Stopping и Service (Service может возвращаться во время перенастройки зеркалирования диска, перезагрузки списка разрешений пользователей или другой административной работы. Такая работа может привести к временному отключению элемента).

Это свойство наследуется от CIM_ManagedSystemElement. Не все значения статуса, описанные здесь, могут применяться к производному классу.

Но на самом деле описание этого свойства должно быть помечено как ненаследуемое (даже если свойство унаследовано), а вместо него должно использоваться специальное описание:

Текущее состояние объекта.

Для Win32_ComputerSystem всегда равно "OK".

Это свойство наследуется от CIM_ManagedSystemElement.

И именно это документация теперь и говорит.

Существует ли кодовая страница, совпадающая с ASCII и позволяющая сделать двустороннюю конвертацию в Unicode?

2020-08-31T18:20:00.000+03:00

Это перевод Is there a code page that matches ASCII and can round trip arbitrary bytes through Unicode? Автор: Реймонд Чен.

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

Например, формат двоичных данных может быть таким: строка ASCII, за которой следует 32-разрядное целое число в формате big-endian. Вы хотите проанализировать строку ASCII, затем взять следующие четыре символа, перевернуть их (преобразовать в little-endian), а затем преобразовать всё вместе обратно в байты, чтобы можно было извлечь целое число (integer).

В современных языках программирования (типа Delphi и C#) есть много удобных средств для управления текстом, но для этого требуются строковые переменные, которые выражаются как последовательность кодов UTF16-LE. Итак, вам нужен способ конвертировать байты в коды UTF16-LE - причём так, что байты меньше 128 сопоставлялись бы с соответствующими символами ASCII, а байты 128 и выше сопоставлялись бы с чем-то обратимым.

К примеру, кодовая страница UTF-8 не подойдёт, потому что в UTF-8 существуют недопустимые последовательности байтов, которые не будут преобразованы в текст (и обратно). Другой вариант, который вы можете выбрать - это кодовая страница 1252, но она также не будет работать, потому что в ней существует несколько неопределенных кодовых позиций (#$81, #$8D, #$8F, #$90, #$9D - прим. пер.). Это означает, что эти байты будут преобразованы в #$FFFD (REPLACEMENT CHARACTER), который является специальным символом Unicode, означающим "Здесь был символ, но я не могу выразить его в Unicode". Обычно этот символ используется для представления ошибок кодирования. (Прим.пер.: или же подобные байты могут быть вообще удалены из результирующей строки Unicode.)

Хотя вы вряд ли будете пробовать, но я также замечу, что двухбайтовые кодовые страницы тоже не будут работать, потому что они берут пары байтов и преобразуют их в Unicode. Это означает, что изменение порядка символов Unicode (для нашей задачи преобразования endian) не позволит сделать обратное преобразование.

Хорошо, я перейду сразу к делу. Кодовая страница, которую я использую для такого рода вещей - это кодовая страница 437 (прим. пер.: DOSLatinUS - кодовая страница, использовавшаяся в первоначальной версии IBM PC 1981 года). Каждый байт в ней определяется и сопоставляется с уникальной кодовой точкой Unicode, и она совпадает с ASCII для первых 128 значений.

uses
  StrUtils; // для ReverseString

procedure TForm1.Button1Click(Sender: TObject);
type
  CP437String = type AnsiString(437);
var
  CP437: CP437String;
  UStr: String;
  X: Integer; // = UnicodeString
begin
  // Заполнили строку
  // (в реальной программе вы бы загружали строку из потока данных)
  SetLength(CP437, 256);
  for X := 0 to 255 do
    CP437[X + 1] := AnsiChar(X);

  // Преобразовали CP437 в Unicode
  UStr := String(CP437);

  // Меняем порядок _символов_
  UStr := ReverseString(UStr);

  // Преобразовали Unicode обратно в CP437
  CP437 := CP437String(UStr);

  // Проверяем обратное преобразование
  // Должен быть изменён порядок _байт_
  for X := 0 to 255 do
    if Ord(CP437[X + 1]) <> 255 - X then
      raise Exception.CreateFmt('Ошибка преобразования для #%d', [255 - X]);

  // Сообщение должно быть показано
  ShowMessage('Всё верно');
end;

Я взял все байты 0 до 255 и преобразовал их в строку с помощью кодовой страницы 437. Потом строка переворачивается и конвертируется обратно в байты. После чего проверяем, что результирующие байты также меняются местами.

Об использовании FILE_FLAG_WRITE_THROUGH и FILE_FLAG_NO_BUFFERING для проецируемых в память файлов

2020-08-21T14:11:00.004+03:00

Это перевод On using FILE_FLAG_WRITE_THROUGH and FILE_FLAG_NO_BUFFERING for memory-mapped files. Автор: Реймонд Чен.

Клиент хотел использовать флаги FILE_FLAG_WRITE_THROUGH и FILE_FLAG_NO_BUFFERING для проецируемого в память файла (memory-mapped file), основываясь на этом руководстве в документации для функции CreateFile:

По этой причине флаг FILE_FLAG_WRITE_THROUGH часто используется совместно с флагом FILE_FLAG_NO_BUFFERING в качестве замены для вызова функции FlushFileBuffers после каждой записи, что может привести к ненужным потерям производительности. Совместное использование этих флагов позволяет избежать штрафов.

Клиент был обеспокоен тем, повлияет ли такая комбинация флагов на согласованность данных.

На самом деле, проблемы с согласованностью данных у клиента будут ещё до того, как он начнёт беспокоиться об этих флагах.

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

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

Сохранилась ли страница 1	Сохранилась ли страница 2
Нет	Нет
Да	Нет
Нет	Да
Да	Да

Вот тебе и целостность данных.

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

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

Дополнительная болтовня: использование FILE_FLAG_NO_BUFFERING для проецируемого в память файла, на самом деле, бесполезно. Флаг "без буферизации" означает, что записи идут прямо на диск - без кэширования в памяти. Но ведь весь смысл отображаемого в память файла состоит в том, что он должен быть кэширован в памяти!

Отладка зависания: все потоки встали на WinHttpGetProxyForUrl

2020-05-23T21:19:00.000+03:00

Это перевод Diagnosing a hang: Everybody stuck in WinHttpGetProxyForUrl. Автор: Реймонд Чен.

Клиент сообщил, что их программа рано или поздно полностью встаёт, а все её потоки (750 штук) зависают при вызове WinHttpGetProxyForUrl со следующим стеком вызова:

ntdll!ZwWaitForSingleObject+0x14
KERNELBASE!WaitForSingleObjectEx+0x8f
winhttp!OutProcGetProxyForUrl+0x160
winhttp!WinHttpGetProxyForUrl+0x349
contoso!submit_web_request+0x232
ntdll!TppWorkpExecuteCallback+0x35e
ntdll!TppWorkerThread+0x474
kernel32!BaseThreadInitThunk+0x14
ntdll!RtlUserThreadStart+0x21

(я упростил стек вызова для простоты объяснения)

В программе происходит следующее: вы помещаете некоторое задание (work item) в пул потоков, и это задание вызывает WinHttpGetProxyForUrl. Эта функция является синхронной, но ей нужно делать сетевые запросы HTTP - которые являются асинхронными. Чтобы устранить это противоречие, функция WinHttpGetProxyForUrl выполняет синхронное ожидание завершения асинхронной работы.

И я предполагаю, что для этого функция WinHttpGetProxyForUrl использует пул потоков.

Происходит следующее: программа заполняет пул потоков заданиями submit_web_request. Эти задания вызывают функцию WinHttpGetProxyForUrl, которая добавляет в очередь свои собственные задания и ожидает их завершения. Но эти задания не могут быть запущены, потому что все потоки пула потоков заняты обработкой заданий submit_web_request.

Рано или поздно пул потоков может понять, что он ничего не делает, и запустит новый поток, чтобы справиться с накопившимися заданиями. Возможно, этот поток завершит задание для WinHttpGetProxyForUrl - что позволит продолжить один из потоков для submit_web_request. Как только этот новый поток пула потоков завершает задание от WinHttpGetProxyForUrl, он извлекает следующее задание из очереди - и есть вероятность, что он получит очередное задание submit_web_request, так что теперь мы вернулись к тому, с чего начали, за исключением того, что мы только что создали ещё один застрявший поток в пуле потоков.

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

По сути, вы перегружаете пул потоков, заполняя его запросами, которые сами требуют пул потоков. Все потоки пула потоков зависают на обработку ваших запросов, и ни один из них не выполняет задания, сгенерированные вашими запросами.

Это как если бы у вас было много тяжёлого оборудования, которое вам нужно перевезти, поэтому вы нанимаете для перевозки все транспортные компании в городе. Появляется компания А, и они говорят: "Хм, это слишком тяжёлое, чтобы перевезти нашими силами. Давайте мы свяжемся с компаний Б, может быть, они нам помогут". Компания Б говорит: "Извините, мы не можем сейчас вам помочь. Мы только что получили крупный заказ на перевозку". Делая заказ во всех доступных транспортных компаниях, вам удаётся помешать любой из них выполнить работу.

Я подозреваю, что эта программа работает в сетевой среде, где WPAD работает медленно. Т.е. задания от WinHttpGetProxyForUrl будут выполнять свою работу дольше, что повышает вероятность того, что задания submit_web_request будут добавляться быстрее, чем завершаться задания от WinHttpGetProxyForUrl.

Теперь, когда мы диагностировали проблему: что мы можем сделать, чтобы решить её?

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

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

Я не эксперт по WinHttp, но у других людей были некоторые идеи, как это сделать.

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

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

Другим предложением было полностью убрать вызов WinHttpGetProxyForUrl и просто передать флаг WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY в WinHttpOpen. Это переложит работу по выяснению прокси на функцию WinHttpOpen, а она сможет выполнить это как часть других своих асинхронных действий. Это кажется хорошей идеей, потому что при этом вы полностью отделяетесь от вопроса выяснения прокси, и вы по-прежнему получаете асинхронное поведение. Ну и вы также получаете удовольствие от исправления ошибки путём удаления кода.

Клиент подтвердил, что переключение на флаг WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY устранило проблему.

Дело о SHGetFolderPath(CSIDL_COMMON_DOCUMENTS), возвращающей ERROR_PATH_NOT_FOUND

2020-05-23T17:27:00.000+03:00

Это перевод The case of the SHGetFolderPath(CSIDL_COMMON_DOCUMENTS) that returned ERROR_PATH_NOT_FOUND. Автор: Реймонд Чен.

У клиента возникла проблема с функцией SHGetFolderPath. В частности, у них была программа, которая вызывала функцию так:

SHGetFolderPath(0, CSIDL_COMMON_DOCUMENTS, 0, SHGFP_TYPE_CURRENT, PChar(pathBuffer));

но вызов функции возвращал ошибку $80070003 - это HRESULT-версия для ERROR_PATH_NOT_FOUND. Ошибка возникает только при запуске из Jenkins pipeline. Если же программа запускается автономно, то функция завершается успешно и возвращает ожидаемый результат.

Трассировка от procmon показала, что приложение пыталось получить доступ к папке C:\Windows\SysWOW64\autobuild\Documents и потерпело неудачу с ошибкой NAME_NOT_FOUND. Это и была подсказка к тому, почему всё сломалось.

По умолчанию папка Common Documents имеет значение %PUBLIC%\Documents. Обычное значение переменной среды PUBLIC - это C:\Users\Public, но когда программа запускается как часть Jenkins pipeline, для переменной среды по какой-то причине задается значение autobuild.

Это означает, что когда программа вызывает SHGetFolderPath и запрашивает CSIDL_COMMON_DOCUMENTS - система ищет папку autobuild\Documents, которая не существует, поэтому возникает ошибка $80070003: "Система не может найти указанный путь".

Есть ряд переменных среды, которые имеют особое значение, и вы меняете их на свой страх и риск. Вы, вероятно, знаете о таких переменных, как windir, ProgramFiles и TEMP, но существует множество других специальных переменных среды - и PUBLIC является одной из них.

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

Печальная, но короткая история значения реестра SM_AccessoriesName

2020-03-11T20:01:00.004+03:00

Это перевод The sad but short story of the SM_AccessoriesName registry value. Автор: Реймонд Чен.

SM_AccessoriesName - ещё одна жертва программ, влезающих в недокументированные разделы реестра.

Это значение реестра никогда не было документировано, так как оно создавалось только для внутреннего использования, и в 64-разрядной версии Windows мы смогли избавиться от него в некоторых обстоятельствах.

Ну, то есть, пока команда по совместимости приложений не нашла Программу С Большим Именем, которая использовала это значение. Так что нам пришлось вернуть это значение обратно в реестр - по крайней мере, пока они не смогут найти способ поддерживать эту программу без этого значения в реестре (возможно, они смогут исправить программу регулировочной прокладкой)¹.

"Почему бы просто не сломать программу и не сказать разработчику, чтобы он исправил баг в своей программе?"

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

Такова жизнь команды совместимости приложений.

¹ Я только что проверил, что в Windows 10 значение реестра окончательно пропало. Удаление ненужного значения заняло, сколько, 10 лет?

Однажды генеральный директор компании пожаловался в Конгресс на расширения файлов Windows

2020-03-11T19:59:00.000+03:00

Это перевод That time the CEO of a company complained to Congress about Windows file extensions. Автор: Реймонд Чен.

В те времена, когда ненавидеть Microsoft было ещё более модно, чем сегодня (да, некоторые вещи никогда не выходят из моды), я помню, как генеральный директор одной технологической компании свидетельствовал перед Конгрессом, чтобы пожаловаться на файловые расширения Windows.

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

Инженерной группе Windows было предложено расследовать это обвинение, учитывая только информацию, представленную на C-SPAN (прим. пер.: Cable-Satellite Public Affairs Network - кабельная спутниковая сеть по связям с общественностью, американская сеть кабельного и спутникового телевидения, созданная в 1979 году отраслью кабельного телевидения в качестве некоммерческой государственной службы. Он транслирует многие материалы федерального правительства США, а также другие программы по связям с общественностью). Я не участвовал в расследовании, но я помню, что был сделан вывод о том, что программа компании неправильно регистрировала обработчик расширения файла, поэтому процесс обновления системы приводил к несогласованному состоянию в обработчиках файловых расширений, так что алгоритм разрешения конфликтов в конечном итоге выбирал программы с правильной регистрацией обработчика: программы Windows.

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

Поэтому я думаю, что это ещё один вариант идеи отправить жалобу сразу Биллу Гейтсу, но только она делает ещё один шаг вперёд. Вместо того, чтобы идти к генеральному директору Microsoft, вы идёте к ещё более высокому авторитету: правительству.

Вот что происходит, когда Windows имеет не 100% обратную совместимость: есть шанс быть втянутым в расследование Конгресса.

Бонусная болтовня: самое замечательное в отправке этих обвинений в Конгресс заключается в том, что нетехнические СМИ разнесут эту новость повсюду. Даже если вы неправы, это не имеет значения. Это стало правдой (что может сделать Microsoft? Выпустить пресс-релиз с объяснением ошибки? Кто-нибудь хотя бы прочитает его, тем более сообщил бы об этом?).

Прим.пер.: я тут недавно наткнулся на статью в Forbes, написанную в паническом стиле: "Microsoft снова налажала, новое обновление Windows блокирует ваш компьютер, удалите обновление немедленно", которое на самом деле говорит о "менее одного процента пользователей сталкиваются с проблемами при установке обновления".

Почему существуют тривиальные функции типа CopyRect и EqualRect?

2020-02-25T13:41:00.000+03:00

Это перевод Why are there trivial functions like CopyRect and EqualRect? Автор: Реймонд Чен.

Если вы покопаетесь внутри user32, вы увидите там некоторые, казалось бы, тривиальные функции - такие как CopyRect и EqualRect. Зачем нам вообще нужны целые функции для того, что можно сделать с помощью операторов := и =?

Краткий ответ: потому что эти операторы генерируют кучу кода.

Длинный ответ: посмотрите на код, который генерируется при использовании оператора присвоения (копирование прямоугольника):

c4 5e f0        les  bx, [bp-10]    ; es:bx -> исходный прямоугольник (source)
26 8b 07        mov  ax, es:[bx]    ; ax = source.left
c4 5e ec        les  bx, [bp-14]    ; es:bx -> целевой прямоугольник (dest)
26 89 07        mov  es:[bx], ax    ; dest.left = ax

c4 5e f0        les  bx, [bp-10]    ; es:bx -> исходный прямоугольник (source)
26 8b 47 02     mov  ax, es:[bx+2]  ; ax = source.top
c4 5e ec        les  bx, [bp-14]    ; es:bx -> целевой прямоугольник (dest)
26 89 47 02     mov  es:[bx+2], ax  ; dest.top = ax

c4 5e f0        les  bx, [bp-10]    ; es:bx -> исходный прямоугольник (source)
26 8b 47 04     mov  ax, es:[bx+4]  ; ax = source.right
c4 5e ec        les  bx, [bp-14]    ; es:bx -> целевой прямоугольник (dest)
26 89 47 04     mov  es:[bx+4], ax  ; dest.right = ax

c4 5e f0        les  bx, [bp-10]    ; es:bx -> исходный прямоугольник (source)
26 8b 47 06     mov  ax, es:[bx+6]  ; ax = source.bottom
c4 5e ec        les  bx, [bp-14]    ; es:bx -> целевой прямоугольник (dest)
26 89 47 06     mov  es:[bx+6], ax  ; dest.bottom = ax

Этот код занимает 54 байт! Он получился ужасно неэффективным, потому что процессор 8086 может использовать непрямую адресацию только через регистры bx, bp, si и di. Регистр bp зарезервирован для использования в качестве указателя фрейма, так что его можно сразу вычеркнуть. Регистры si и di используются как регистры-переменные, поэтому в них почти всегда лежит что-то нужное. Что оставляет нам единственный регистр, который можно использовать для разыменования указателей: bx.

Поскольку мы работаем с указателем 16:16 - нам также нужен регистр сегмента, а у 8086 есть только четыре сегментных регистра: cs (сегмент кода), ds (сегмент данных), ss (сегмент стека), es (дополнительный сегмент). У трёх из них уж есть предназначенные цели, поэтому остаётся только один: es. Так что даже если бы мы могли временно использовать si или di, мы всё равно оказались бы в узком месте.

Но если мы переместим код в функцию CopyRect, то мы можем сэкономить кучу байт:

c4 5e f0        les  bx, [bp-10]    ; es:bx -> исходный прямоугольник (source)
53              push bx
06              push es
c4 5e ec        les  bx, [bp-14]    ; es:bx -> целевой прямоугольник (dest)
53              push bx
06              push es
9a xx xx xx xx  call CopyRect

Всего 15 байт! Экономия почти в ЧЕТЫРЕ раза.

Это была эпоха экономии байт, поэтому любой приём, позволяющий сэкономить несколько байтов, заслуживал рассмотрения - особенно если учесть, что у вас было "всего" 256 Кб памяти¹.

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

Конечно, сегодня требуется уже не так много кода, чтобы скопировать прямоугольник вручную: весь прямоугольник помещается в один 128-битный регистр:

    mov    eax, [sourcerect]
    movups xmm0, [eax]
    mov    eax, [destrect]
    movups [eax], xmm0

¹ Слово "всего" взято в кавычки, потому что 256 Кб кажется ужасно малым размером памяти сегодня, но вспомните, что в те времена это было максимумом, который вы могли поставить в IBM PC XT! По крайней мере, не прибегая к использованию карт расширений.

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

var
  R1, R2: PRect;
  V: array[0..5] of Byte;
begin
  R1 := @V[0];
  R2 := @V[1]; // плохая идея

Хорошо, раз переключение на перемещение двух целых чисел за раз не нарушает ничего, что ещё не было сломано, давайте сделаем это:

c4 5e f0        les  bx, [bp-10]    ; es:bx -> исходный прямоугольник (source)
26 8b 07        mov  ax, es:[bx]    ; ax = source.left
26 8b 57 02     mov  dx, es:[bx+2]  ; dx = source.top
c4 5e ec        les  bx, [bp-14]    ; es:bx -> целевой прямоугольник (dest)
26 89 07        mov  es:[bx], ax    ; dest.left = ax
26 89 57 02     mov  es:[bx+2], dx  ; dest.top = dx

c4 5e f0        les  bx, [bp-10]    ; es:bx -> исходный прямоугольник (source)
26 8b 47 04     mov  ax, es:[bx+4]  ; ax = source.right
26 8b 57 06     mov  dx, es:[bx+6]  ; dx = source.bottom
c4 5e ec        les  bx, [bp-14]    ; es:bx -> целевой прямоугольник (dest)
26 89 47 04     mov  es:[bx+4], ax  ; dest.right = ax
26 89 57 06     mov  es:[bx+6], dx  ; dest.bottom = dx

Получаем 42 байта (против бывших 54). Уже лучше, но это всё равно почти в три раза больше вызова функции.

Если у нас есть одна дополнительная свободная переменная (скажем, si), то мы можем сократить этот код ещё больше:

c4 5e f0        les  bx, [bp-10]    ; es:bx -> исходный прямоугольник (source)
26 8b 07        mov  ax, es:[bx]    ; ax = source.left
26 8b 57 02     mov  dx, es:[bx+2]  ; dx = source.top
26 8b 4f 04     mov  cx, es:[bx+4]  ; cx = source.right
26 8b 77 06     mov  si, es:[bx+6]  ; si = source.bottom
c4 5e ec        les  bx, [bp-14]    ; es:bx -> целевой прямоугольник (dest)
26 89 07        mov  es:[bx], ax    ; dest.left = ax
26 89 57 02     mov  es:[bx+2], dx  ; dest.top = dx
26 89 4f 04     mov  es:[bx+4], cx  ; dest.right = cx
26 89 77 06     mov  es:[bx+6], si  ; dest.bottom = si

Всего 36 байт. Уже лучше, но всё ещё более чем в два раза больше, чем вызов функции. И это также стоило нам одного регистра.

Вот ещё один трюк: копирование прямоугольника через стек.

c4 5e f0        les  bx, [bp-10]    ; es:bx -> исходный прямоугольник (source)
26 ff 37        push es:[bx]        ; push source.left
26 ff 77 02     push es:[bx+2]      ; push source.top
26 ff 77 04     push es:[bx+4]      ; push source.right
26 8b 77 06     push es:[bx+6]      ; push source.bottom
c4 5e ec        les  bx, [bp-14]    ; es:bx -> целевой прямоугольник (dest)
26 8f 47 06     pop  es:[bx+6]      ; pop dest.bottom
26 8f 47 04     pop  es:[bx+4]      ; pop dest.right
26 8f 47 02     pop  es:[bx+2]      ; pop dest.top
26 8f 47        pop  es:[bx]        ; pop dest.left

Хм, получается столько же, сколько и с регистрами. Но хотя бы в этот раз нам не потребовался свободный регистр.

Хорошо, а если мы позаимствуем регистр ds, а также и si и di?

1e              push ds
c5 7e ec        lds  di, [bp-14]
c4 76 f0        les  si, [bp-10]
fc              cld
a5              movsw
a5              movsw
a5              movsw
a5              movsw
1f              pop  ds

Ух ты! Тринадцать байт!

Один байт = один доллар

2020-02-25T13:38:00.001+03:00

Это перевод One byte used to cost a dollar. Автор: Реймонд Чен.

В те времена, когда программное обеспечение распространялось на дискетах (помните дискеты?), для Windows было правило: один байт стоит один доллар.

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

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

Конечно же, появление компакт-дисков в качестве основного средства распространения программ изменило математику, но беспокойство по поводу размера операционной системы всё ещё оставалось. Насколько я понимаю, компакт-диск Windows Server 2003 был в основном "полным". Лично вам могло так не казаться, но вспомните, что ваш CD, вероятно, является 32-битной английской версией. Для переводов на другие языки необходимо зарезервировать дополнительное пространство. И не забывайте, что 64-разрядная версия Windows примерно в два раза больше, чем 32-разрядная версия, поскольку она должна содержать две операционные системы: родную 64-разрядную и эмулируемую 32-битную (ну не ровно в два раза, потому что некоторые файлы могут быть общими, а многие 32-битные компоненты могут быть удалены).

А потом дистрибутив перешёл на DVD, а затем и вообще стал полностью сетевым. Интересно, какова цена за байт в настоящее время. Стоимость теперь находится в полосе пропускания, но она всё ещё стоит денег.

Подводный камень: размещение окна под TopMost окном сделает окно TopMost

2020-01-17T00:13:00.001+03:00

Это перевод Nasty gotcha: Positioning your window beneath a topmost window makes it topmost. Автор: Реймонд Чен.

У функции DeferWindowPos (и, следовательно, любой функции на её основе, типа SetWindowPos) есть неприятный подводный камень: если вы укажете hwndInsertAfter, а окно insert-after будет самым верхним (TopMost), то позиционируемое окно будет размещено сразу после этого окна.

Пока всё идёт нормально.

Подводный камень заключается в том, что ваше окно будет размещено в той же зоне, что и окно insert-after (которое лежит в зоне TopMost!)

Другими словами, окно будет сделано TopMost окном - даже если раньше оно не было TopMost окном.

Это будет, вероятно, не тем, что вы ожидали.

Почему я не могу переместить FOLDERID_LocalAppData с помощью SHSetKnownFolderPath?

2020-01-17T00:02:00.002+03:00

Это перевод Why can’t I use SHSetKnownFolderPath to change the location of FOLDERID_LocalAppData? Автор: Реймонд Чен.

Заказчик заметил, что его модульный тест начал давать сбой в Windows 10 версии 1803. В частности, он не прошел здесь:

SHSetKnownFolderPath(FOLDERID_LocalAppData, 0, 0, temporaryDirectory);

с ошибкой E_INVALIDARG. Что изменилось в Windows 10 версии 1803, из-за чего этот вызов стал недействительным?

Изменение в блокировании перемещения папки LocalAppData (а также её близкого личного друга LocalAppDataLow) стало лишь подтверждением реальности: да, более ранние версии Windows позволяли перемещать эти каталоги, но в результате профиль пользователя оказывался повреждён. Вам приходилось удалять пользователя и начинать всё сначала.

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

Перемещение этих каталогов заблокировано, чтобы вы не могли выстрелить себе в ногу. Это признание того факта, что это не только не работает, но и портит профиль пользователя.

Почему последний выбранный файл появляется первым, когда я выбираю несколько файлов в диалоге открытия файла?

2020-01-16T23:37:00.000+03:00

Это перевод When I select multiple files in the File Open dialog, why does the last item come first? Автор: Реймонд Чен.

Если у вас есть диалог открытия файла, который поддерживает множественный выбор, и вы выбираете несколько файлов, вы можете заметить, что файл, выбранный последним, указывается первым. Это раздражает, если порядок файлов при выборе является важным (прим. пер.: например, при добавлении фото в альбом). Почему последний выбранный элемент становится первым в списке?

Это случай утечки абстракции.

Диалог открытия файлов показывает список выбранных элементов в том же порядке, в котором они возвращаются методом IShellView.GetItemObject расширения пространства имён:

var
  pdto: IDataObject;
begin
  ShellView.GetItemObject(SVGIO_SELECTION, IID_PPV_ARGS, pdto);

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

Хорошо, тогда почему сфокусированный предмет стоит первым?

Для того, чтобы получить лучшее контекстное меню.

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

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

Поэтому, вместо того, чтобы создавать большое количество контекстных меню и пытаться объединить их не совсем бессмысленным способом, оболочка просто выбирает один из элементов и говорит: "Окей, ты - ответственный за меню". И действия от этого файла будут действиями для всего выделения. (Также не забывайте, что у нас было аж 4 МБ памяти для работы).

Окей, мы приближаемся к ответу.

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

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

Какое-то время спустя (я не знаю когда точно), в метод IShellView.GetItemObject был добавлен флаг SVGIO_FLAG_VIEWORDER, который сообщает представлению: "Не помещай сфокусированный элемент первым. Просто верни мне всё в том же порядке, в котором они отображаются".

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

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