1. Получите файл includes.zip (находится в архиве wasm_files.zip: files/recovered/1005002/includes.zip)

2. Распакуйте его и поместите файлы @struct.inc и windows.inc в папку включаемых файлов пакета MS DevStudio (по умолчанию - C:\Program Files\DevStudio\VC\INCLUDE).

Файл @struct.inc - это авторская отсебятина, которой в принципе можно и не пользоваться, а можно и наоборот, добавить в него что-нибудь свое, полезное.

С файлом windows.inc все гораздо сложнее. Это файл заголовков API, ассемблерный аналог той тучи h-файлов, которые содержатся в пакете Visual C++ и начинаются с файла windows.h (и, возможно, не только). Поскольку Microsoft официально не поставляет файл windows.inc (в отличие от windows.h), у ассемблерного программиста в связи с этим возникает большая-пребольшая проблема. Ее можно попытаться решить несколькими путями:

• транслировать windows.inc из windows.h с помощью специальной программы-переводчика H2INC, поставляемой в составе пакета MASM 6.11+. Сразу скажем, что следует смело отправить эту надежду в мусоропровод. Продравшись сквозь частокол багов H2INC, вы обнаружите, что ее интеллекта хватает лишь на трансляцию тривиальнейших заголовочных файлов, к которым windows.h , безусловно, не относится. Вы утонете в бездне сообщений о некорректном переводе, и ваш сизифов труд по их обходу будет вознагражден получением совершенно негодного результата

• найти windows.inc (вариант - win.inc) в Интернете. Это гораздо более реально. Существует некоторое количество чудаков (возможно, это дети миллионеров, которым наплевать на необходимость зарабатывать на жизнь), которые тратят свое время на формирование и актуализацию этого файла и раздают его всем желающим. Есть мнение, что пользоваться такими файлами настоятельно не рекомендуется. Представьте себе ситуацию к концу второго месяца возни этого доброго человека с каким-нибудь пятым по уровню вложенности заголовочным файлом в пирамиде windows.h. Возьмет, да и перепутает с устатку порядок описания членов какой-нибудь структуры. Или забудет указать ее выравнивание относительно умалчиваемого. Хорошо еще, если соответствующая функция API при использовании ее вами будет вываливаться с фатальной ошибкой вроде нарушения общей защиты. А может ведь и не вываливаться. И будете вы разбираться, почему глючит ваше приложение, дольше, чем добрый дядя переводил заголовочный файл

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

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

Именно последний вариант и предлагается в качестве основного. Файл windows.inc , который мы вам предложили выше, взят из состава приложения MyCall. В нем только самая малая часть из того, что должно быть, и есть кое-что лишнее (RAS, например, в Visual C++ имеет собственный заголовочный файл). Но для старта этого достаточно.

Не забудьте только включить свой windows.inc в процедуру архивирования (надеемся, таковая у вас имеется). Будет обидно начинать все сначала после какой-нибудь очередной переинсталляции системы.

Ну вот, а теперь пора создать новый проект :

1. Запустите MS DevStudio

2. Выберите в меню: File/New

3. В появившемся диалоге выберите вкладку Projects

4. В списке типов проектов выберите Win32 Application

5. В поле Location укажите каталог, в который предполагаете поместить папку проекта

6. В поле Project Name укажите желаемое имя проекта. Учтите, что по умолчанию это имя будет присвоено исполняемому модулю и, кроме того, папке, в которой будут находиться файлы проекта на этапе его разработки. (Поле Location автоматически дополняется именем папки проекта.)

7. По остальным элементам диалога убедитесь, что DevStudio собирается создавать для вашего проекта новое рабочее пространство (Create new workspace) для платформы Win32

8. Нажмите кнопку OK

Новый проект создан.

В рамках вновь созданного проекта первым делом необходимо создать файл с исходным текстом :

1. Нажмите кнопку New Text File или создайте текстовый файл посредством диалога, вызываемого через меню File/New

2. Сохраните вновь созданный файл командой меню File/Save As. При этом дайте файлу желаемое имя с расширением .asm, например, main.asm. В принципе, расширение тоже может быть любым, но лучше не отходить от общепринятых стандартов

3. Подключите файл к проекту. Для этого, например, можно в окне Workspace на вкладке FileView щелкнуть правой кнопкой мыши по заголовку пока пустого списка файлов проекта и в появившемся контекстном меню выбрать пункт Add Files to Project. В файловом диалоге, чтобы увидеть наш новый файл, придется переключиться в режим Все Файлы.

А теперь самое важное. Файл когда-нибудь придется компилировать. Подготовиться к этому следует уже сейчас:

1. В окне Workspace на вкладке FileView щелкните правой кнопкой мыши по имени файла

2. В появившемся контекстном меню выберите пункт Settings. Появится диалог Project Settings в режиме установок для файла

3. В диалоге выберите вкладку Custom Build

4. В списке Settings for выберите пункт Win32 Debug

5. В текстовом поле Build command(s) введите новую команду:

6. В текстовом поле Output file(s) введите текст:

7. В списке Settings for выберите пункт Win32 Release

8. В поле Build command(s) введите новую команду:

9. В поле Output file(s) введите текст:

Файл готов к компиляции с помощью модуля ml.exe. Обратите внимание, что пункты 5 и 6 касаются компиляции asm-файла для отладочного варианта проекта, и получаемый в этом случае объектный файл содержит отладочную информацию. Пункты же 8 и 9 касаются окончательного варианта проекта, готового к дистрибуции.

Наконец, наш файл должен иметь какое-нибудь корректное содержимое. Допустим, мы разрабатываем минимальное приложение. Учитывая, что кое-что из него уже имеется в файле @struct.inc , его содержимое может быть, например, таким:

Вот теперь можно смело нажимать кнопку Compile (Ctrl+F7). Компиляция файла должна пройти без ошибок.

Обратите внимание, что имя включаемого файла windows.inc указано с полным путем. Это не случайно. В процессе разработки приложения вам придется очень часто обращаться к этому файлу, добавляя в него заголовочную информацию. В MS DevStudio это сделать очень просто, причем несколькими способами. Например, можно выделить имя файла и, щелкнув по нему правой кнопкой, выбрать пункт контекстного меню Open Document. Но удобнее все-таки подключить файл windows.inc к проекту "на постоянно", воспользовавшись правой кнопкой мыши в окне Workspace. Если вы удачно попадете по имени проекта или по какой-нибудь папке, вам станет доступна опция Add files to Project (Folder)... С ее помощью-то вы и подключите файл к проекту, и в дальнейшем простым двойным кликом сможете вызывать его на редактирование.

Теперь перейдем к сборке проекта :

1. В окне Workspace на вкладке FileView щелкните правой кнопкой мыши по заголовку списка файлов (он же имя проекта)

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

3. В диалоге выберите вкладку Link

4. В списке Settings for выберите пункт Win32 Debug

5. В списке Category выберите пункт General

6. В поле Output file name вы можете при желании указать имя создаваемого исполняемого модуля, если вас не устраивает имя по умолчанию

7. Установите флажок Ignore all default libraries. Таким образом вы откажетесь от подключения runtime-библиотеки C/C++ и сэкономите несколько десятков килобайт кода. Подробнее см. здесь и здесь.

8. В списке Category выберите пункт Output

9. В поле Entry-point symbol укажите WinMain (в данном случае) - имя функции, являющейся точкой входа для проекта

10. В списке Settings for выберите пункт Win32 Release

11. Проделайте все то же самое по п.п.6...9

Все, проект готов к сборке. Нажмите кнопку Build (F7) и убедитесь, что сборка проходит нормально. Можете также попробовать запустить полученный исполняемый модуль проекта и убедиться, что ничего не происходит: он выполняется и завершается слишком быстро и без каких-либо видимых признаков.

Выше мы обещали обеспечить удобный доступ к файлам заголовков API , чтобы можно было пользоваться ими как справочником при подготовке файла windows.inc. Для этого нам потребуется активизировать встроенное средство MS DevStudio под названием Browse Info. Работает оно очень просто. Достаточно щелкнуть по интересующему нас имени в исходном тексте программы правой клавишей мыши и выбрать пункт контекстного меню Go To Definition Of , как моментально загрузится заголовочный файл Visual C++, в котором это имя описано. В проектах на C/C++ активизация Browse Info происходит автоматически, при первой попытке выполнить указанное действие. А вот в проектах на ассемблере, к сожалению, этого нет. Но ничего страшного. Просто нужно немножко повозиться.

И наконец, маленькое замечание о зависимостях (Dependencies). Не забывайте о них. Например, файл main.asm , очевидно, зависит от windows.inc. И поскольку последний будет очень часто подвергаться изменениям, в том числе и вне текущего проекта, имеет прямой смысл эту зависимость описать. При этом в каждом случае, когда происходит изменение файла windows.inc , будет автоматически вызываться перекомпиляция файла main.asm. В MS DevStudio зависимости описываются очень просто (хотя и не очень удобно: приходится вводить имя файла вручную), гораздо проще, чем в заковыристых исторических make-файлах. Снова вызовите диалог Project Settings для файла main.asm. Найдите на вкладке Custom Build кнопку Dependencies и в появившеся диалоге укажите полное имя файла windows.inc.

Все, MS Developer Studio готово для ассемблерного программирования. Можно предъявить много всяких претензий по сервису и оформлению, но главное - это работает.

Глупая DOS загружает exe-файл, обнаруживает в его начале привычный для себя заголовок и исполняет stub-программу, ничего не зная о наличии в файле еще чего-то, кроме слов "а пошел ты туда-то и туда-то".

Умная Windows поступает более изощренно:

• по аббревиатуре MZ определяет наличие заголовка MS-DOS. Определив, продолжает процесс:

• считывает двойное слово по смещению 3ch. Здесь компоновщик заботливо записал смещение PE-заголовка.

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

Как сделать собственную stub-программу? Да очень просто! Напишите любую, сколь угодно сложную или простую DOS-программу. Только постарайтесь обойтись без извращений вроде перевода процессора в защищенный режим или показа картинок в режимах VESA: помните, что stub-программа должна сработать с флоппи-диска на 8086-й машине с текстовым монитором. Модель памяти можно использовать любую, кроме tiny - она для stub-программы не годится.

И это, к сожалению, неизбежно, как бы ни печалилась по этому поводу душа настоящего ассемблерщика. Ведь модель tiny порождает com-формат исполняемого модуля, не имеющий, как известно, никакого заголовка. А раз нет заголовка - то даже умная Windows не сможет узнать размер stub-программы и, соответственно, вычислить начало PE-заголовка. Глупая DOS ненамного легче переварит эту ситуацию. Обнаружив, что файл является исполняемым (имеет расширение exe, как положено в Windows), она выяснит также, что его фактический формат - com (отсутствует сигнатура MZ), и попытается-таки его загрузить и исполнить. Однако stub-программа сработает только в том случае, если размер исполняемого файла не превысит 64К, что для приложений Windows (даже написанных на ассемблере) - довольно редкое исключение. Скорее всего, ваш пользователь вместо цветного пожелания перейти, в конце концов, на новую ОС, получит сухое монохромное сообщение командного процессора о чрезмерном размере исполняемого модуля.

Важно! При компоновке stub-программы в командной строке компоновщика укажите недокументированную и загадочно звучащую опцию /KNOWEAS. Это опция вносит некие изменения в заголовок exe-файла. Если опцию не указать, то компоновка Windows-приложения со stub-программой окажется некорректна, о чем вы получите соответствующее предупреждение от линкера.

Подозреваем, что не все компоновщики поддерживают эту опцию. Однако link.exe из состава MS Developer Studio, конечно же, поддерживает.

Написанную stub-программу используйте на этапе компоновки своего Windows-приложения. Для этого в командную строку компоновщика добавьте опцию /STUB:"filename.exe", где filename.exe, как вы можете догадаться - это имя вашей stub-программы, при необходимости с путем. Обнаружив эту опцию, компоновщик заменит стандартную stub-программу на вашу.

Здесь настоящего ассемблерщика подстерегает серьезное разочарование. Проблема в следующем. Обычно при компоновке exe-программ для DOS в исполняемом файле резервируется довольно большое место под таблицу перемещения. Например, в порядке вещей, если таблица перемещения вольготно располагается между смещениями 1ch (конец заголовка) и 200h (начало сегмента кода). Даже если ваша stub-программа не содержит ни одного фрагмента, подлежащего перемещению, все равно 486 байт чистых нулей будет бессмысленно вбацано в нежное девственное тело вашего Windows-приложения. Задачка, стоит ли избегать такого варварского разбазаривания дискового пространства и как это сделать, предлагается для самостоятельного решения. Кое-какие идеи читайте далее.

Минимальная stub-программа. Заглянув внутрь исполняемого модуля какого-нибудь Windows-приложения, вы обнаружите, что стандартная stub-программа чаще всего занимает 128 байт. Можно ли уменьшить этот размер и до какой величины? Отвечаем: можно, до 64 байт.

Возьмите любой редактор бинарных файлов и создайте с его помощью вот такой файл:

Присвойте ему имя, например, stub.exe и используйте в качестве stub-программы.

Вот расшифровка содержимого файла stub.exe с комментариями:

Вероятно, уменьшить размер stub-программы до величины, меньшей 64 байт, невозможно. А вот интересный вопрос: возможно ли вообще изъять stub-программу из модуля? Не спешите отвечать "нет"! 16-битные компоновщики от Microsoft имели в синтаксисе def-файла конструкцию вида STUB NONE, которая, согласно документации, предназначалась для использования при сборке dll-библиотек. В 32-битных компоновщиках эта возможность пропала. А жаль...

PS:

Вот уж в самом деле, "никогда не говори "никогда"! 24 июля 2001 года, в день падения 114-летнего рекорда жары в Москве, пришло письмо:

"На вашем сайте assembler.ru в статье "Минимальная stub-программа" автором упомянуто, что создать stub короче 40h байт, вероятнее всего, невозможно.

Привожу пример stub'а длиной в 20h байт:

В отличие от примера, приведенного в статье, размер заголовка уменьшен до одного параграфа. В терминах статьи это означает, что stub-код располагается по смещению 10h от начала файла.

Очевидно, после такого "сокращения" области заголовка от 10h и выше продолжают использоваться. Но в данном случае это неважно, так как на месте 4CB4h находится initial SP, а на месте 21CDh - checksum. Ни то, ни другое роли не играют. К сожалению, stub-код ограничен в 4 байта, потому что уже следующий word - initial IP.

Далее, в файле со stub'ом в 20h байт смещение 3Ch от начала файла приходится на смещение 1Ch PE-заголовка. Здесь расположен dword, который, по-видимому, ни на что не влияет, так что можно спокойно ставить туда 00000020h:

Такую штуку вряд ли поддерживают компоновщики (мне от них этого добиться не удалось), я лично правил EXE вручную. Зато работает.

Напоследок - пример тоже рабочего stub'а длиной в 18h байт - меньше, по-моему, некуда:

Из-под DOS он выводит восклицательный знак (21h).

Ну как, размер достоин настоящего ассемблерщика?"

автор - Grief (soulinspector@chat.ru)

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

1. Когда делается попытка запустить программу из-под DOS, загрузчик, определив по сигнатуре "MZ", что это исполняемый файл, считывает по смещению 08h размер exe-заголовка, а по смещению 14h стартовое значение регистра ip, чтобы узнать, где находится исполняемый код. В предложенном Grief'ом варианте stub'а длиной 20h он таким образом выясняет, что передавать управление следует на смещение 10h (просто выход в DOS посредством функции 4Ch), а в варианте длиной 18h - на смещение 0Ch (здесь перед выходом успевает еще напечататься восклицательный знак). И неважно, что занятые исполняемым кодом байты на самом деле являются полями exe-заголовка "Максимум требуемой памяти за концом программы", "Сегментное смещение сегмента стека", "Значение регистра sp" и "Контрольная сумма исполняемого модуля". Все эти поля в данном случае не влияют работу программы.

2. Если же программа запускается из-под Windows,то загрузчик, опять же разобравшись с назначением файла, первым делом считывает двойное слово по смещению 03ch, чтобы узнать, где находится PE-заголовок. Так вот, здесь это смещение оказывается внутри самого PE-заголовка! В варианте "18h" оно попадает на поле, содержащее суммарный размер секций неинициализированных данных в образе приложения, а в варианте "20h" - на поле, содержащее размер секций кода. Использование этих полей в современных нам версиях Windows неочевидно. По одним источникам - они используются для первичного отведения памяти под приложение. По другим - не используются вообще. Во всяком случае, практическая проверка показывает, что приложения с таким stub'ом работают нормально. (Что будет дальше - пожалуй, неизвестно даже Microsoft'у.)

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

Ну и напоследок, опровергнув свои же слова что "...меньше некуда...", Grief прислал вообще шедевр - вполне работающий stub длиной всего 0Ch!!! Разобраться, как он устроен, вы сможете самостоятельно, руководствуясь уже достаточно ясной идеей: в заголовках полным-полно никому не нужных полей, которые мы можем использовать для своих целей. Итак:

• работа начинается с вынужденного объектно-ориентированного действия - громоздкой регистрации класса окна с помощью функции RegisterClassExA. Вы должны сделать это, даже если собираетесь создать всего одно окно с такими свойствами, потому что так повелел когда-то Уильям Гейтс Второй , известный в народе как просто Билл. Впрочем, вы можете избежать этой неприятной процедуры, если воспользуетесь при создании окна одним из предопределенных классов - BUTTON, COMBOBOX, EDIT, LISTBOX, MDICLIENT, SCROLLBAR, STATIC. С помощью, например, класса BUTTON вы можете сделать большую-пребольшую кнопку и нажимать ее день и ночь до умопомрачения, ожидая, пока из floppy-дисковода выскочит банан. А класс STATIC очень удобен для эмуляции забора: написанное на таком окне емкое трехбуквенное слово всегда напомнит вам о необходимости вернуться к повседневным заботам.

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

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

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

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

• потому что в вашем распоряжении теперь - оконная процедура win_procedure. Она принимает все и всяческие сообщения, адресуемые вашему окну всеми, кому не лень, и делает в ответ на них все, что вы пожелаете. В данном случае вы пожелали отправлять все эти сообщения обратно в систему, чтобы она сама делала с окном то, что повелел когда-то Билл. Единственное сообщение, на которое реагирует ваша оконная процедура - это WM_DESTROY , которое означает, что вам надоело любоваться окном, и вы нажали Alt+F4, или щелкнули по кнопочке с крестиком, или выбрали Close в системном меню. Да и поделом ему.

Дескриптор экземпляра приложения узнать очень просто:

Возвращаемое функцией GetModuleHandleA в eax значение - и есть искомый дескриптор. Будучи настоящими ассемблерщиками, мы, как видите, сохраняем его в hInstance , чтобы не пропадали даром целых четыре байта памяти. Между прочим, этот дескриптор фактически представляет собой базовый адрес памяти для размещения образа приложения (image base в терминах формата PE-файла). Для самостоятельных приложений по умолчанию он обычно равен 400000h.

Следует обратить внимание на наличие суффикса A в имени функции, говорящего о том, что мы работаем с кодировкой ANSI. Если вы предпочитаете Unicode, то суффикс должен быть W. Это, так сказать, "ручной" выбор типа кодировки приложения на этапе компиляции. Поскольку функций API, имеющих две версии, большинство, то, в принципе, может иметь смысл автоматизация этого процесса, как это сделано, например, для C++ в MS Developer Studio. Ввести некую настроечную константу и, в зависимости от нее, подключать ту или иную версию функции.

Командную строку следует получать так:

Возвращаемое в eax значение указывает на буфер в памяти, содержащий текст командной строки с завершающим нулем. Результат, правда, несколько отличается от того, который можно было бы получить из lpCmdLine , будь у нас runtime-библиотека. Функция GetCommandLineA возвращает командную строку, включая полный путь к исполняемому модулю приложения. Путь взят в кавычки, что необходимо, поскольку он может содержать пробелы. Например, командная строка может иметь такой вид:

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

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

Уникальная для каждого процесса структура STARTUPINFO заполняется вызывающим процессом, например, Проводником, перед запуском нашего приложения, при этом в нее заносится в том числе и значение параметра показа окна в виде члена wShowWindow , имеющего размер слова. С помощью этого кода мы считываем структуру STARTUPINFO, извлекаем из нее wShowWindow , приводим размер к двойному слову и записываем полученное значение в nCmdShow.

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

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

Главное - объявить эту функцию точкой входа приложения с помощью опции /entry:"my_main_function" сборщика link.exe.

Функция __WinMainCRTStartup_ , если таковая имеется, подготавливает рабочую среду для runtime-библиотеки, а также значения параметров для функции WinMain, после чего передает управление функции WinMain.

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

Прежде чем переходить к рассмотрению примеров, следует обсудить еще одно обстоятельство. Оно связано с тем, что Windows, благодаря прозорливости ее создателей, поддерживает два типа кодировки текстовых символов - архаичную восьмибитную ANSI и перспективную шестнадцатибитную Unicode. Из-за этого программистам Microsoft пришлось для всех функций API, так или иначе работающих с текстовыми символами, писать по два программных варианта. Тот, который работает с кодировкой ANSI, имеет суффикс A, например, CreateFileA. Тот, который работает с кодировкой Unicode, имеет суффикс W, например, CreateFileW.

Обычно приложение ориентируется на работу только с одной из этих двух кодировок. Выбор производится программистом на этапе компиляции путем указания значения для специальной настроечной константы. В MS Visual C++, например, это константа UNICODE. Если она определена, то вызов функции CreateFile в тексте программы при компиляции незаметно для программиста преобразуется в вызов функции CreateFileW, в противном случае - в CreateFileA.

В программах на ассемблере, конечно, можно реализовать тот же механизм. А можно, руководствуясь девизом "handmade forever", делать это вручную.

Основываясь на вышесказанном, приведем пример вызова какой-нибудь функции API. Допустим, это будет уже упоминавшаяся функция CreateFile. Вот ее описание для C++, как оно дано в Platform SDK:

Фрагмент программы для кодировки ANSI, открывающий для чтения уже существующий файл, может выглядеть, например, так:

Но многим гораздо больше понравится тот же самый фрагмент так, как он выглядит в MASM 6.1+:

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

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

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

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

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

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

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

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

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

Поговаривают, что не всегда все было так трагично. Во времена наших предков, когда "Докторская" стоила 2.20, а Билл был еще совсем бедным со своими двумя десятками гигабаксов, заработанных на DOSе, это делалось очень просто. В win16 имел смысл параметр hPrevInstance функции WinMain. Достаточно было убедиться, что он ненулевой - и приложение знало, что оно не одиноко на этом свете. Но когда разрабатывалась win32, кто-то из главных системщиков Microsoft лопухнулся, а потом, когда все всплыло, на специальном совещании было принято решение прикрыть провинившегося и объяснить все произошедшее какими-нибудь благообразными словами, вроде: "Мы так и хотели с самого начала, а hPrevInstance сохранили для совместимости снизу вверх." Так или иначе - но hPrevInstance теперь бесполезен. А следует пользоваться средствами межпроцессного взаимодействия (Interprocess Communications), которые, к чести Microsoft, реализованы в Windows великолепно.

Способов дать знать второму экземпляру о существовании первого можно придумать много. Один из них прямо дается в MSDN в статье WinMain:

hPrevInstance

Identifies the previous instance of the application. For a Win32-based application, this parameter is always NULL. If you need to detect whether another instance already exists, create a named mutex using the CreateMutex function. If the GetLastError function returns ERROR_ALREADY_EXISTS, another instance of your application exists (it created the mutex).

Идентифицирует предыдущий экземпляр приложения. Для Win32-приложений этот параметр всегда равен NULL. Если вам необходимо определить, существует ли уже экземпляр приложения, создайте именованный объект mutex, используя функцию CreateMutex function. Если функция GetLastError вернет ERROR_ALREADY_EXISTS, другой экземпляр вашего приложения существует (так как он уже создал mutex).

Вот этой самой идеей и воспользуемся, слегка модифицировав ее:

Как видим, логика работы очень проста. Первым делом пытаемся открыть mutex с заданным именем.

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

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

Ну и, конечно, при завершении работы приложения следует не забыть вызвать функцию ReleaseMutex.

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

А вот Сергей AKA The Byte Reaper (http://neptunix.narod.ru) совершенно справедливо обратил наше внимане на то, что приведенный выше пример реализации второй стратегии сильно перегружен формальностями и реверансами в сторону MSDN. Полностью сохраняет ту же функциональность, но гораздо приятнее взору настоящего ассемблерщика предложенный Сергеем вот какой вариант:

Идея проста предельно. Если создаваемый mutex уже присутствует в системе, то функция GetLastError вовращает код ERROR_ALREADY_EXISTS. Кстати, функция CreateMutex возвращает при этом вполне валидный дескриптор существующего mutex'а, но нас это совершенно не должно интересовать. Мы просто заканчиваем работу приложения - и все.

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

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

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

Это полностью работающее приложение. В его основу положен шаблон оконного приложения. Содержимое файла windows.inc не приводится (то, что он должен собой представлять, показано в предыдущем примере. Недостающие элементы следует добавить самостоятельно, по аналогии, пользуясь заголовочными файлами для C/C++).

Общая идея такова:

• регистрируется класс главного окна и создается само окно с тем, чтобы вновь запускаемое приложение могло принимать и обрабатывать сообщения с помощью оконной процедуры win_procedure

• регистрируется глобальное сообщение, которое впоследствии должно использоваться для обмена информацией между экземплярами приложения

• выполняется проверка наличия уже работающего экземпляра приложения с помощью объекта mutex

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

• ответ от уже работающего экземпляра принимает оконная процедура приложения в виде такого же сообщения, но уже с параметром ANSWER_PRIME_HWND. При этом второй параметр сообщения представляет собой дескриптор окна работающего приложения.

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

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

См. также интересный, эффективный и простой вариант решения рассматриваемой задачи, предложенный Геннадием Майко.

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

Нейтрино - вообще очень интересная штучка. Есть подозрения, что на самом деле Вселенная состоит в основном-то как раз из нейтрино. На миллиард нейтрино приходится одна какая-нибудь другая ма-а-асенькая элементарная частица. И основной вклад в мировую гравитацию вносят именно они - нейтрино. И если вдруг однажды мы доживем до Большого Чпока (процесса, обратного Большому Взрыву), то именно они будут в нем виноваты, свернув своей массой Вселенную обратно в сингулярность, из которой она когда-то родилась. И тогда у Кого-то на экран выскочит синяя маска смерти с предложением нажать Ctrl+Alt+Del. Но это будет уже совсем другая история.

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

ПРАВИЛЬНАЯ ТЕОРИЯ ЛЕПТОНОВ

Лептоны - это элементарные частицы мировой информации. Они принципиально неуловимы никакими физическими приборами. Скорость света - это недостижимая для них минимальная скорость, а обычно они движутся гораздо быстрее. Лептонное поле хранит информацию о всех прошедших, настоящих и будущих событиях в любой точке пространства-времени, включительно от чиха простудившегося этим летом микроба до мановения пальца Любимого Руководителя Товарища Ким Чен Ира, указывающего Владимиру Владимировичу направление движения России в сторону окончательной победы идей Чучхе.

В указанном промежутке лежат также разработка ОС Windows, грядущее столкновение нашей Галактики с галактикой Андромеды, передача НТВ Газпрому за долги, хрущовские испытания 50-мегатонной бомбы на Новой Земле, день рождения в прошлую субботу, раскаяние в прошлое воскресенье и многие другие события, которые здесь следовало бы перечислить, но неохота.

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

Здесь мы прекратим рассмотрение теорий лептонов, потому что все, что нужно, уже выяснили, и перейдем к практике программирования.

Среди традиционных проблем ассемблерного программиста связывание занимает далеко не последнее место.

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

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

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

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

2. Команды call, содержащиеся в одних модулях, вызывают процедуры, тела которых содержатся в других модулях.

Возможен еще такой способ взаимодействия, как передача управления из одного модуля в другой командой jmp или ее условными формами (je, jb, js и пр.). Но, если только программист не пытается реализовать какую-нибудь специальную идею, применение этого способа следует считать проявлением запредельного случая неправильного стиля программирования.

В Windows существует еще один способ взаимодействия модулей: когда из одних модулей посылаются сообщения окнам, созданным в других модулях. Но об этом ниже.

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

Родной для ассемблерных программ способ связывания обеспечивается применением сладкой парочки директив PUBLIC и EXTRN (она же EXTERN). Директива PUBLIC объявляет имя переменной или процедуры доступным для обращения из других модулей. Директива EXTERN сообщает компилятору, что команды данного модуля могут обращаться к имени переменной или процедуры, описанной в другом модуле.

Например:

в модуле masha.asm содержится такой фрагмент кода:

а в модуле vasya.asm содержится такой фрагмент кода:

Здесь дан наиболее часто применяемый вариант директив PUBLIC и EXTRN. На самом деле их возможности несколько шире, но они не являются предметом этой статьи. Читайте документацию на соответствующий вашим предпочтениям ассемблер.

Обратите внимание, что переменная mashin_vozrast объявлена как двойное слово, что вполне естественно для программирования под win32, даже при том условии, что Маша вряд ли достигнет возраста 4294967296 лет, сколько бы здоровья мы ей ни желали. Настоятельно рекомендуется в подобных случаях (когда числовая переменная объявлена как одиночная, а не как массив) всегда использовать переменные размером в двойное слово, потому что обращение к таким переменным из 32-разрядного кода существенно более компактно, чем к переменным размером в слово или байт.

Как видим, Вася пытается оценить, насколько близкими могут быть его отношения с Машей, чтобы не загреметь по очень неприятной статье. Его, вероятно, ждет разочарование, но только не на этапе компиляции, потому что компилируется он программой-компилятором (например, ml.exe) в одиночку, без участия предмета своих вожделений.

Связыванием же занимается компоновщик, он же линкер, он же link.exe. Это его основная задача, откуда и произошло его название. Схватив полученные в результате двух актов компиляции объектные файлы masha.obj и vasya.obj, он обнаруживает, что Маша публично заявляет о своем возрасте (впрочем, 17-ти лет стесняться не приходится), а Вася внимательно прислушивается. Компоновщик удовлетворяет обоих, выделяя в исполняемом модуле sex.exe место под переменную размером в двойное слово, инициализирует ее числом 17, а в команду cmp, с помощью которой Вася интересуется Машиным возрастом, подставляет адрес этой переменной.

Связывание вызовов процедур выглядит ненамного сложнее:

модуль masha.asm:

модуль vasya.asm:

Обратите внимание, что процедура get_masha объявлена как ближняя. В win32, поскольку дело происходит в плоской (flat) модели памяти, все процедуры ближние.

Как видим, Вася добрался-таки до Маши. Вероятно, в какой-то момент переменная mashin_vozrast инкрементировалась, или любовь оказалась сильнее условностей. Но так или иначе связывание состоялось.

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

Есть ли у этого метода недостатки? Да до... в общем, вам по пояс будет.

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

А даже если вы и наоборот, запредельный педант, и пипифакс рвете исключительно по перфорации, и объектная ориентация для вас важнее, чем сексуальная? Тогда, вероятно, глобальных переменных в ваших программах нет совсем, а межмодульный обмен данными вы обеспечиваете с помощью специальных интерфейсных процедур, на манер публичных функций-членов классов в C++. Ну и что, намного легче вам иметь длиннющие списки директив PUBLIC и EXTRN для процедур, чем для переменных?

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

Отвечая на первый попавшийся FAQ, объясним сразу, при чем же здесь все-таки лептоны и почему стиль назван так претенциозно, если не сказать помпезно.

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

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

А на самом деле? На самом деле все ужасно сложно и долго. Драйвер мыши обнаруживает судорожное движение вашего пальца. Потом он интересуется местоположением курсора на экране. Полученные координаты он отправляет операционной системе на предмет определения окна, над которым в данный момент находится курсор. А окон открыта целая туча: всякие там кнопочки-шмопочки, документики-шмокументики, списочки-шмисочки. И все перекрываются, и каждое норовит чего-нибудь обработать. И вот операционная система перебирает их все и находит то, которое в точке курсора лежит поверх всех остальных. И отправляет ему сообщение. Методом Pоst между прочим, то есть ставя его в очередь, а не вызывая непосредственно оконную процедуру. Сообщение отправляется родительскому окну и торчит там в очереди, пока не придет пора его обработать. Кроме того, поскольку дело происходит в диалоговом окне, кнопочка еще и перерисовывается, отображая нажатое состояние. А потом еще удаляется с экрана диалоговое окно, и перерисовывается то окно, в котором находился ваш документ, а потом удаляется и оно, и перерисовываются все лежавшие под ним другие окна, при этом тоже не особенно экономя процессорное время и память. И все это сопровождается передачей такого количества сообщений, что Смольный в ночь с 24 на 25 октября (с.с.) 1917 года по сравнению с этим гвалтом покажется вам санаторием ЦК КПСС во время послеобеденного тихого часа, когда пациенты переваривают телятину по-кабардински под белым соусом в сопровождении нежных трапецеидальных импульсов стимулирующих перистальтику кремлевских таблеток. Короче, рассмотрев эту предельно упрощенную схему действий, мы понимаем, что вместо того, чтобы просто уничтожить все ваши труды, ОС сама долго и плодотворно трудится.

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

Да никогда!

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

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

Таким образом, общая идея довольно проста и даже тривиальна. И уж конечно, в той или иной степени она реализуется практически в каждой более-менее серьезной программе.

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

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

Теперь ответим на второй первый попавшийся FAQ. Тянет ли эта идея на понятие "стиль программирования"? По-нашему, тянет. Ведь что есть стиль программирования? Это более-менее стабильный набор приемов организации программы и оформления исходного текста, используемый программистом с целью облегчения ее разработки и понимания. С точки зрения этого определения то, о чем мы сейчас говорим - именно и есть стиль. Стабилен ли он? Да вы только попробуйте его хотя бы разок, и обратно уже не запроситесь. Идет ли в данном случае речь об организации программы? Безусловно: и с формальной точки зрения (отсутствие директив PUBLIC/EXTRN), и с фактической (организация специальной системы обмена сообщениями внутри программы) - это инструмент организации программы. Идет ли в данном случае речь об оформлении исходного текста? Конечно, да. Далее мы покажем, как с помощью макросов удобно и наглядно записываются запросы клиентов.

Первая реализация поддержки лептонного стиля программирования была прямо выполнена на штатных средствах обмена сообщениями Windows. До сих пор еще некоторые наши программы используют ее. Общая идея там была такова: при запуске приложения создавалось невидимое окно, называемое нами супервизором, дескриптор которого объявлялся глобальным для всего проекта. Оконная процедура супервизора, таким образом, становилась доступной из любой точки программы для передачи (SendMessage) или посылки (PostMessage) пользовательских сообщений, то есть относящихся к диапазону WM_USER (00400h...07fffh) и/или диапазону WM_APP (08fffh...0bfffh):

В каждом модуле объявлялась как PUBLIC одна-единственная процедура, названная нами диспетчером. Упрощенно система работала так:

1. если в каком-то месте программы требовалось обратиться к лептонному сервису, вызывалась функция API SendMessage (реже, при необходимости - PostMessage), при этом в качестве окна-получателя (hWnd) указывался супервизор. Сообщение (Msg) определяло смысл запроса, а два параметра (wParam и lParam) - его параметры;

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

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

4. супервизор, получив от какого-нибудь очередного модуля ответ с признаком "обработано", прекращал опрос модулей и завершал оконную процедуру, возвращая ответ в регистре eax;

5. запрашивавший модуль считывал ответ из регистра eax.

Как параметры (wParam и lParam), так и ответ (eax) могли представлять собой непосредственные данные, если они помещались в размер двойного слова, либо являться адресами (указателями) блоков памяти (структур, строк), в которые модуль-клиент и/или модуль-сервер помещали соответствующие данные. В каждом конкретном случае это определялось смыслом запроса, то есть значением сообщения (Msg).

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

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

2. очередь оконных сообщений начинает жить только после создания окна супервизора, когда заработает цикл GetMessage-TranslateMessage-DispatchMessage. А между тем, очень часто до того хочется провести некоторое количество операций по инициализации приложения. И очень хочется выполнить их тоже в лептонном стиле. Почему бы и нет?

3. два входных параметра - это, конечно, больше, чем ни одного, но заметно меньше, чем три или более. То есть маловато будет в весьма многих случаях. А ничего не поделаешь: таков формат системного сообщения Windows. Можно, конечно, дополнительно использовать регистры esi и edi, которые, как известно, сохраняются функциями API, но это откровенный паллиатив;

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

5. 48128 сообщений, зарезервированных в диапазонах WM_USER и WM_APP - это не так уж много, неправда ли? Всего каких-нибудь 20 лет работы над программой, и вы их исчерпаете. Что будете делать тогда? Куда лучше было бы иметь в запасе 232 сообщений. Тогда можно было бы более-менее спокойно работать чуть более 1784810 лет, что в большинстве случаев следует признать достаточным.

Поэтому мы не станем рассматривать здесь вариант реализации лептонного стиля на базе системы сообщений Windows, а сразу перейдем к более прогрессивному - автономному варианту. Его отличительной особенностью является применимость не только под Windows, а в любой ассемблерной программе, в том числе под DOS, Linux и пр. Если он вам понравится, вы можете использовать приведенный здесь код один к одному. Он вполне работоспособен и достаточно функционален. Но еще правильнее воспринимать его как набор идей, которые вы свободно можете развить и дополнить так, как посчитаете нужным. Или, например, перевести на другой язык программирования.

Реализация и заключительные замечания - во второй части статьи.

ЧАСТЬ ВТОРАЯ. РЕАЛИЗАЦИЯ

В реализации задействованы файлы:

• @struct.inc - файл глобальных макросов. Это макросы, с помощью которых программист улучшает свою рабочую среду. каждый может придумать их великое множество. Некоторые из используемых нами вы можете найти в проекте MyCall. Важно, что этот файл следует включать во все модули проекта.

• globals.inc - файл глобальных констант проекта. В нем вы будете вести список констант, представляющих молитвы (лептонные вызовы). Он также должен быть включен во все модули проекта, что позволит выполнять любой лептонный вызов из любой точки проекта. Впрочем, возможен вариант, когда молитвы могут быть разбиты на группы по назначению. В таком случае все группы молитв должны быть доступны только супервизору, а каждому из модулей - только те группы, молитвы из которых используются в этом модуле. Такая организация потребует от программиста дополнительных накладных расходов на администрирование. В то же время заманчивым может оказаться сокращение времени на компиляцию проекта. Ведь если файл global.inc один на всех, то при добавлении в него каждой новой молитвы (то есть довольно часто) автоматически будет вызываться полная перекомпиляция всех модулей проекта (если, конечно, вы правильно настроили MS DevStudio). Выбор - за вами. Со своей стороны скажем, что по причине врожденной лености ни разу не пытались разбивать молитвы на группы. На современном компьютере MASM работает достаточно быстро, можно и потерпеть;

• 00_main.asm - главный модуль проекта - тот, который содержит процедуру WinMain (см. также статью Минимальное приложение). У нас он теперь будет содержать еще и супервизор;

• XX_*.asm - все остальные модули проекта. Здесь XX - двухсимвольный идентификатор модуля, в котором каждый симол X может быть цифрой или буквой латинского алфавита, а * - произвольный набор символов, смысл которого нужен человеку, но не компилятору (например: 01_main_window.asm - модуль обслуживания главного окна). Каждый такой модуль, если только он собирается выступать в качестве лептонного сервера для молитв других модулей, обязан иметь в своем составе процедуру диспетчера.

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

Файл глобальных макросов @stuct.inc:

Пояснения:

1. Эквиваленты параметров молитвы используются внутри диспетчеров (см.ниже в файле XX_*.asm). Они нужны для того, чтобы у программиста не было необходимости помнить, какой параметр передается в каком регистре. Символ "@" напоминает программисту о том, что это регистры, а не адреса памяти.

2. Макрос молитвы используется для формирования лептонных вызовов из программы - молитв и бродкастов, например:

Этот текст после компиляции будет преобразован в последовательность команд:

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

3. Макрос формирования списка диспетчеров используется только один раз - при компиляции главного модуля. На основании списка идентификаторов модулей MODULES (см. ниже в файле 00_main.asm) он создает в константном сегменте приложения таблицу адресов процедур диспетчеров всех модулей. Таблица завершается нулевым значением. При каждом лептонном вызове супервизор поочередно передает управление по адресам из этой таблицы, вызывая, таким образом, диспетчеры модулей.

4. Прототип супервизора обеспечивает связывание лептонных вызовов из модулей с процедурой супервизора, описанной в главном модуле 00_main.asm.

5. Идентификатор модуля представляет собой два первых символа имени asm-файла. Можно придумать и другие варианты, но нам показался привлекательным этот. Он удобен еще и тем, что в панели Workspace рабочей среды MS Developer Studio именованные таким образом файлы располагаются в строгом порядке, так как происходит их сортировка по имени.

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

Файл глобальных констант globals.inc:

Пояснения:

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

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

3. Здесь приведены примеры некоторых часто встречающихся молитв. P_HINSTANCE - получение дескриптора экземпляра приложения. P_MAIN_WINDOW - получение дескриптора главного окна. P_GET_STRING - получение текстовой строки из единого хранилища строк (удобно в локализуемых приложениях).

4. Особо следует остановиться на организации обработки молитв, похожих на P_GET_MAIN_WINDOW_SIZE. Очевидно, что возвращаемое значение должно иметь тип RECT, то есть не помещается в регистр eax. Возможны два варианта решения этой проблемы. Либо при вызове этой молитвы в одном из ее параметров передается адрес памяти для приема значения RECT. В этом случае ответственность за выделение этой памяти несет модуль-клиент. Либо наоборот, память под переменную RECT выделяется модулем-сервером, и тогда клиенту возвращается ее адрес в регистре eax. И тот, и другой варианты имеют право на существование. Программист должен сделать свой выбор, создавая обработчик молитвы, исходя из ее назначения и условий использования.

5. Бродкасты B_START и B_STOP практически необходимы в любом сколько-нибудь развитом приложении. Как следует из их имен, они предназначены для запуска приложения (т.е. инициализации модулей-серверов) и его завершения (освобожения ресурсов, занятых серверами). B_START может вызываться, например, сразу из процедуры WinMain. А B_STOP - по команде пользователя на завершение работы приложения.

6. Для бродкаста B_START (в первую очередь для него, но иногда и для других) возникает одна интересная проблема: в какой очередности он должен обрабатываться модулями? Например, при инициализации сервера главного окна требуется, чтобы уже была доступна строка, представляющая его имя, то есть уже был проинициализирован сервер строк. В принципе, эту проблему можно было бы решить, тасуя идентификаторы в списке MODULES в файле 00_main.asm. Однако правильная последовательность не всегда очевидна, да и не обязательно должна быть одинаковой для разных бродкастов, а если она установлена таким образом, то уже останется неизменной навсегда. Поэтому следует ориентироваться на другой способ. Зависимые модули должны инициализироваться не бродкастом B_START, а тем модулем, который требует их готовности к моменту своей инициализации. Для этого можно использовать специальную молитву, например, P_START_STRINGS. На первый взгляд, описанный механизм является отступлением от лептонного стиля, который предполагает взаимную независимость модулей. Однако на практике он не вызывает проблем, так как используется в особых, крайне редких случаях, и достаточно прозрачен.

Файл главного модуля 00_main.asm:

Пояснения:

1. Здесь и далее применена транскрипция структурных директив MASM (.if, .while и пр.) с лидирующим символом "@" вместо точки. Обоснование, как и почему это сделано, можно прочитать в статье @struct.inc для MyCall.

2. Список идентификаторов модулей используется макросом @dispatchers (см. выше в файле @struct.inc) на этапе компиляции для формирования списка диспетчеров, который опрашивается супервизором при каждом лептонном вызове. Программист должен, включив в проект новый модуль, дополнить список модулей его идентификатором, иначе супервизор не сможет вызвать диспетчера этого модуля.

3. Супервизор - это очень простая процедура. Она состоит их двух независимых частей. В первой части выполняется обработка молитв (но не бродкастов!), которые по замыслу программиста должен обрабатывать главный модуль приложения. При обработке таких молитв используется только первая часть процедуры. Вторая часть - это простой цикл, сканирующий таблицу диспетчеров. Производится поочередная выборка из таблицы адресов процедур диспетчеров и передача им управления с трансляцией параметров, находящихся в регистрах esi, edi, edx, ecx.

4. Когда супервизор обслуживает молитву, цикл опроса диспетчеров продолжается до тех пор, пока какой-нибудь из них не вернет в регистре eax ненулевое значение, что является признаком "обработано". При обслуживании бродкастов такая проверка не выполняется, поэтому супервизор обязательно перебирает всех диспетчеров.

5. Следует иметь в виду, что в случае, когда какая-нибудь молитва не обработана ни одним из модулей приложения, супервизор, опросив всех диспетчеров, возвращает в регистре eax значение 0.

6. Супервизор сохраняет с помощью атрибута USES директивы PROC значения всех регистров, за исключением регистра eax.

Файл модуля XX_*.asm:

Пояснения:

1. Диспетчер - это процедура, которая содержится в каждом модуле, обрабатывающем лептонные вызовы - молитвы или бродкасты. Идея диспетчера очень проста: сравнение параметра pray со списком лептонных вызовов, обрабатываемых данным модулем. Если полученный лептонный вызов обрабатывается, то после его обработки диспетчер возвращает управление супервизору с ненулевым (полученным в результате обработки) значением в регистре eax (выполняется выход на метку ok:). В противном случае регистр eax сбрасывается в 0 (выполняется выход на метку nok:). Что касается бродкастов, то все равно, на какую метку передается управление по завершении их обработки.

2. Имя диспетчера, поскольку оно глобально в пределах исполняемого модуля, должно быть уникальным. А диспетчеров у нас - по одному на каждый модуль. Во избежание конфликтов здесь применен следующий прием. Имя @dispatcher на самом деле является вызовом макроса, описанного в файле @struct.inc (см.выше). Этот макрос формирует действительное имя процедуры вида dispatcher_XX, где XX - идентификатор модуля.

3. Входными значениями для диспетчера являются передаваемый через стек идентификатор лептонного вызова (pray) и до четырех параметров, передаваемых через регистры: @par0 (он же регистр esi), @par1 (edi), @par2 (edx), @par3 (ecx). Эквиваленты параметров определены в файле @struct.inc.

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

5. Можно придумать много различных вариантов организации диспетчера, оптимизирующих как использование памяти, так и время выполнения (если это имеет смысл). Здесь показан простейший вариант, основанный на применении директив @if-@elseif-@endif.

6. Показанное здесь разбиение процедуры диспетчера на части (обработка бродкастов и обработка молитв) условно. На самом деле очередность выполнения сравнений, конечно же, смысла не имеет.

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

В заключение несколько дополнительных замечаний:

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

• использование нулевого значения регистра eax в качестве признака "не обработано" может вызвать возражения. Как в таком случае отличить случай "не обработано" от случая, когда результат обработки равен 0? Однако на самом деле это никакая не проблема. Во-первых, именно так работают большинство функций API win32. Во-вторых, если есть необходимость, можно придумать множество разных средств для разрешения этой ситуации. Например, ввести молитву P_GET_LAST_ERROR, по принципу использования аналогичную функции GetLastError API win32. Молитва должна возвращать значение, соответствующее последней ошибочной ситуации. А уж установить это значение в случае, если супервизор безуспешно просканировал весь список диспетчеров - не проблема;

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

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

Неприятность этой мелкой мелочи мы ощутили во всем ее необозримом масштабе, когда спустя три дня по окончании гарантийного срока сдох наш любимый Sony GDM-200, и временно перекочевал под стол вместе со своими 1280х1024, а вместо него на столе оказался старенький SyncMaster 500s, с натугой выдающий 800х600. С тех пор до 80% нашего рабочего времени уходило на переключение между окнами и, чтоб он пропал совсем, скроллинг исходного текста вверх-вниз.

Существенно сократить число сгорающих в секунду нейронов нам удалось благодаря одному-единственному совсем простенькому макросу. Вот он:

И все! Как только этот макрос был включен в нашу постоянную макробиблиотеку, мы получили счастливую и давно желаемую возможность записывать в одну строчку несколько (а именно - от 2 до 8) команд.

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

А что запишем мы, ренегаты и предатели? А вот что:

Вот какие преимущества, по нашему скромному IMHO, мы получаем в результате этого маневра:

1. Про уменьшение трудозатрат на вертикальный скроллинг уже сказано

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

3. У нас появляется дополнительный стимул к хорошему комментированию исходного текста.

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

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

5. Облегчается копирование текста. Допустим, за год работы мы копируем текст с места на место 50000 раз, в среднем по 10 строк. Так вот сравните, каково: во втором случае мы копируем 50000 строк, а в первом - 500000! В десять раз больше, но за ту же зарплату!

Освоив предлагаемый метод, вы можете смело идти к своему руководителю и рекомендовать ему снизить вам зарплату в 10 раз. Гарантируем: с этого момента вы будете его любимым сотрудником.

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

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

Недостатков у предлагаемого метода только один:

1. Так вот сиди теперь и думай: чего это я, дурак, все с ассемблером вожусь? Может, на Visual Basic перейти?

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

Большинство людей, так уж сложилось, считает, что 2000-й год принадлежит 20-му веку. Одни - потому что с детства их учили считать: "раз, два, три, ...".

Настоящих ассемблерщиков чудаковатые родители учили, конечно же, так: "ноль, один, два,..., девять, а, бе, цэ, дэ, ..." и так далее, со всеми вытекшими отсюда печальными последствиями. Неспешно плыло светлое время шестидесятых, мир был наивен и добр. Печаталась цветная "Техника молодежи" про ЭВМ, про робота Сепульку, с фантастическим рассказом в каждом номере... А еще толстенькая "Наука и жизнь", и "Юный техник". За ночь глотался "Понедельник начинается в субботу". Полыхал дюзами "Непобедимый" Лема. Слово "голубой" ассоциировалось с небом. В году было 365 солнечных дней... Впрочем, это совсем другая история.

Вторые - потому что хотят стабильности. Третьи - потому что боятся будущего. Четвертым - наплевать. Пятые - решили, что так надо. Шестые - потому что верят пятым. Седьмые - потому что они посчитали, и у них так получилось. И так далее.

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

Однако, время, как каждый вечер напоминает Михаил Леонтьев. Я лично вижу в его словах два смысла. Первый означает: "Треп закончен, переходим к делу". Второй обращает наше внимание на существо рассматриваемого вопроса.

Действительно, давайте вспомним, что речь идет о времени. И не просто о времени, а о времени, прошедшем от Рождества Христова. Потому что именно так называется Наша Эра (она же Новая Эра, она же Anno Domini). Вспомнили?

А теперь давайте считать. Время, оно ведь не кирпичи. Оно не поштучное, а непрерывное. Вот так его и будем считать.

Итак. Через пять минут после рождения Христа, когда Он лежал в яслях, освещаемый падавшим сквозь прореху в крыше убогого сарая светом Вифлеемской звезды, сколько Ему было от роду?

Правильно, ноль лет и пять минут.

А через месяц, когда, насытившись от груди Марии, радостно агукал, не зная о сужденных Ему Страстях?

Правильно, ноль лет и один месяц.

А через одиннадцать месяцев тридцать дней двадцать три часа и пятьдесят девять минут, когда Мария качала Его, спящего, в колыбели, мысленно поздравляя с первым годом жизни и мечтая о том, как Он вырастет добрым, хорошим сыном, будет счастлив и станет ей опорой в старости, как мечтают все родители от Начала Времен?

Правильно, ноль лет одиннадцать месяцев тридцать дней двадцать три часа и пятьдесят девять минут.

То есть нулевой год входит в жизнь Христа (впрочем, ничем не отличаясь от нулевого года жизни любого другого человека). Следовательно, нулевой год входит и в Нашу Эру, именно с него она начинается.

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

Следовательно, первый век Нашей Эры составляли годы 00, 01, 02, 03 ... 99, поскольку в веке, по определению, 100 лет. А 100-й год относился уже, естественно, к следующему веку н.э.

Помаленьку экстраполируя, добираемся 1999 года. Кто не помнит, подсказываю: там был еще такой президент, Ельцин Борис Николаевич. Давно это было, еще в XX веке н.э. А вот 2000-й год - это уже XXI век, потому что за две тысячи лет понятие "век" ничуть не изменилось. Как было в первом веке 100 лет, с 00 по 99, так и осталось в ХХ-м c 1900 по 1999.

Делаем окончательный вывод. 2000-й год принадлежит XXI веку. Кто не понял: мы живем в новом, XXI веке н.э. Поздравим себя, дожили. А ведь могли и не дожить.

Здесь необходимо сделать маленькое пояснение. Все вышесказанное верно с формальной точки зрения. То есть если вы, допустим, настоящий ассемблерщик, и, как всякий настоящий ассемблерщик, ненавидите считать итерации в циклах while, for, do и until, потому что каждый раз нужно лезть в учебник, и все равно на 1 ошибешься, то с вашей точки зрения все сказанное - верно.

А вот если вы, допустим, раннесредневековый монах-богослов, и присутствуете в исторически поворотной точке пространства и времени, когда определяются все последующие воззрения на дату Рождества Христова, и только что вернулись со строительства монастырской стены, и собираетесь поработать с летописями, то все сказанное выше должно быть вам далеко не очевидно. Возьмете с устатку, да и назначите нулевой год жизни Христа первым. И пошло-покатилось. Вплоть до нашего 2000-го года, последнего года XX-го века.

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

Через public mail мы получаем альтернативные мнения о рассматриваемом в этой статье вопросе. Так, Sergey Chehuta из WhiteTown прислал письмо:

Это, на наш взгляд, очень интересная и перспективная версия, хоть она и отметает все сказанное выше. К сожалению, подтвердить ее или опровергнуть столь же трудно, как, скажем, Догадку Гольдбаха. Во всяком случае, при проведении многочисленных экспериментов assembler.ru даже вместе с друзьями, даже под шашлык, никогда не добирался дальше восьмого века н.э. Было бы здорово, если бы кто-нибудь из неравнодушных к науке посетителей взялся бы проверить эту версию. Спонсировать, к сожалению, не сможем, но отчет опубликуем с удовольствием. (Репортажи со свадеб и юбилеев просьба не предлагать.)

Ну и в заключение - маленькая сенсация. Основываясь на той же методике, порассуждаем не о годах, а о веках.

Первое тысячелетие составляли века: 00, 01, 02, 03, ..., 09.

Второе тысячелетие составляли века: 10, 11, 12, 13, ..., 19.

Еклмн! Братья и сестры, да мы уже сто лет, как живем в третьем тысячелетии! Во бараны, сколько денег в празднование вбухали, колеса по всему миру строили, хрустальные шары спускали, на одни фейерверки штуки три российских годовых бюджета спалили! Хорошо хоть мы, как обычно, умнее всех оказались: не стали транжириться, водкой и оливье обошлись.

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

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

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

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

Так и дошло дело до наших дней.

Вторая предыстория - продолжение первой. В 1992 году греческий писатель Апостолос Доксиадис написал роман "Дядя Петрос и Догадка Гольдбаха" (Uncle Petros and Goldbach's Conjecture by Apostolos Doxiadis)

Роман начинается так: "В каждой семье есть своя черная овца - в нашей ею был дядя Петрос". Рассказчик - любимый племянник дяди Петроса. Семейство всегда считало Петроса неудачником. В начале рассказа племянник оглядывается назад, в годы своей учебы в средней школе в Афинах. Тогда его живой детский интерес вызывал эксцентричный дядя, отшельником живший в предместье и интересовавшийся только шахматами и озеленением. Племянник знал, что дядя Петрос когда-то был талантливым математиком, долгие годы учился и преподавал в университете в Германии и немного - в Кембридже. Однажды он приходит к дяде и объявляет, что хотел бы делать карьеру математика. Дядя Петрос предлагает племяннику решить одну математическую задачку. Если решит - то это будет означать, что математика действительно является его призванием. А если не сможет - то должен дать обещание навсегда забыть о математике. Племянник принимает условие, и, так и не найдя решения, по достижении совершеннолетия все-таки отправляется в университет в США в полной неуверенности в своем будущем математика. Его случайный попутчик, оказавшийся математиком, объясняет ему, что задача, заданная ему дядей, была ничем иным, как Догадкой Гольдбаха. Оказалось, что дядя потратил всю свою жизнь в поисках ее доказательства, но так и не нашел его. Во второй части романа читатель видит рассказчика вернувшимся в Грецию и требующим у дяди объяснений: почему тот задал ему неразрешимую задачу. И тогда мы добираемся до "Истории дяди Петроса Папахристоса", которую рассказчик подает нам в третьем лице. Это очаровательная история о математике и гениальности, о гордыне и навязчивой идее, которые все вместе составили жизнь дяди Петроса. Третья часть романа переносит нас в наши дни. Петрос теперь 80-летний старик, и слегка не в себе. Племянник, все-таки начавший свою математическую карьеру, но впоследствии оставивший ее, вновь пытается получить от дяди ответ на вопрос, который не получил когда-то. И далее следует очаровательный конец повествования с великолепной кульминацией. Доксиадис - удивительный рассказчик. Он побуждает вас переворачивать страницы одну за другой, раскрывая вам историю и мир ученого-математика, всю свою жизнь целеустремленно преследовавшего единственную цель: подтверждение Догадки Гольдбаха. А это, между прочим, самая простая и самая трудная из догадок: каждое четное число, большее 2, представляет собой сумму двух простых чисел. Звучит элементарно, неправда ли? (© J.A, перевод assembler.ru)

В этом году роман, по случаю слегка переработанный автором, опубликован на английском языке сразу в США и в Великобритании, двумя издательствами - Faber and Faber Limited (Лондон) и Bloomsbury Publishing (Нью-Йорк). И для того, чтобы сделать потенциальному бестселлеру необходимую рекламу, кто-то из сотрудников того или другого издательства предложил гениальный ход: бросить челлендж ценой в пресловутый миллион баксов. Тогда казалось, что никто особо ничем не рискует (жалко будет, если человека теперь уволят), ведь над подтверждением Догадки Гольдбаха люди бьются сотни лет, и до сих пор даже не уверены, что таковое существует.

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

Так не доставайся ж ты никому! Этой публикацией я нарушаю все правила вызова, установленные издательством, но уж постараюсь сделать так, чтобы мой миллион было бы трудно присвоить кому-нибудь шустрому. Впрочем, все возможно. В правилах же не сказано, что миллион будет вручен автору. Там сказано, что миллион будет вручен выполнившему условия. Эй, резиденты США и Великобритании, для вас еще не все потеряно!

В английском языке то, что я сейчас делаю, определяется идиомой "vsju malinu obossal, gad".

Впрочем, шутки в сторону. Вот доказательство истинности Догадки Гольдбаха.

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

Примечание от 27.07.00: Еще более сухое и, возможно, более корректное (или истинное, чем черт не шутит?) доказательство Догадки прислал Тим Туманный. Читайте!.

Еще раз повторю формулировку Догадки:

"Каждое четное число, большее двух,

может быть представлено

в виде суммы двух простых чисел."

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

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

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

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

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

Идея, по-моему, достаточно очевидна. Например, делитель "2" укладывается в кладке до отметки "13" шесть раз целиком, и еще пол-кирпича торчат наружу. А вот делитель "3" - четыре раза целиком и еще кусочек. И так далее.

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

Теперь приглядимся к кладке повнимательнее. Посмотрите: все стыки в ряду "4" попадают на стыки в ряду "2"! Это значит, что если тестируемое число не попадает на стык в ряду "2", то уж на стык в ряду "4" оно точно не попадет! А мы, дураки, мучились, раствор мешали, на прораба матерились... Оказывается, ряд "4" совершенно неинтересен в смысле тестирования чисел на предмет их простоты. Убираем его нафиг. А вместе с ним и ряды "6", "8", "9", "10" и "12", так как все их стыки тоже надежно совпадают со стыками вышележащих рядов. Смотрим, что получилось.

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

Уважаемые товарищи программисты! Не загружайте процессоры бесполезной работой! При определении простоты чисел используйте в качестве делителей только простые числа! (За исключением случаев, когда вы пишете на JavaScript. Тогда вы можете на этот призыв наплевать - все равно скрипт работает на чужом компьютере. Именно так я и сделал в этом примере.)

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

Простое число есть совокупный продукт

от всех простых чисел, меньших его.

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

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

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

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

Этот рисунок уже прямо иллюстрирует Догадку и способ ее подтверждения. Для примера мы взяли число 16, которое, как мы знаем, является четным, и, если верить Гольдбаху, должно иметь два простых слагаемых. Не станем томить, таковые действительно имеются. Например, 11 и 5.

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

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

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

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

Правда, на рисунке img04 есть еще точка, отстоящая слева на 1, а справа - на 15, которой не мешает ни один стык кирпичей. Такая точка имеется у всех пар простых слагаемых, одно из которых - 3. Существование этой точки еще ждет своего объяснения, и, я думаю, кирпичная теория простых чисел способна дать его.

Видно, что желтый и голубой ряды кирпичей "2" синфазны. Их стыки совпадают. Это не удивительно, ведь число 16 кратно 2. Эти ряды будут совпадать и для любых других четных чисел. И они отсеивают половину всех потенциальных точек рандеву. Если бы фазы голубого и желтого рядов "2" не совпадали, тогда совместными усилиями они бы отсеяли все точки. Однако фазы рядов "2" не совпадают только у нечетных чисел.

А вы-то, небось, думали, что нечетное число не может быть суммой двух простых чисел, потому что сумма двух нечетных всегда четна? На самом-то деле причина в кирпичах!

А вот ситуация с желтым и голубым рядами "3" гораздо интересней. Поскольку число 16 не кратно 3, то фазы этих рядов не совпадают. В результате ряды "3" еще отнимают каждые две из трех потенциальных точек рандеву, оставшихся после разгрома, учиненного рядами "2". Очевидно, что после их совместных усилий остается вот какая доля потенциальных точек рандеву:

(1)

Следующий ряд - "5". К сожалению, на рисунке img03 ситуация не очень удачная - нет голубого ряда "5", потому что число 16 слишком маленькое. То же касается и ряда "7". Впрочем, мы уже достаточно подготовлены, чтобы забросить возню с кирпичами и обратиться-таки к абстрактным рассуждениям. Если бы исследуемое четное число было побольше, и у второго слагаемого был бы голубой ряд "5", то он бы мог быть синфазен желтому (например, для числа 20), или несинфазен (например, для числа 22). Будем ориентироваться на худший для нас второй случай. Рассуждая аналогично рядам "3", можно считать, что несинфазные ряды "5" оставят только 3 из 5 точек, оставшихся после совместного воздействия рядов "2" и "3". То есть доля оставшихся потенциальных точек рандеву будет:

(2)

Аналогично для рядов "7":

(3)

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

(4)

Здесь:

• qi - очередной (i-й) член прогрессии

• Pi - соответствующее этому члену простое число из ряда простых чисел, начиная с 2

Также очевидно, что прогрессия (4) бесконечно стремится к 0.

Сформулируем достаточное условие существования точки рандеву: "Для того, чтобы для некоторого четного числа E j существовала хотя бы одна точка рандеву, достаточно, чтобы интерполированное значение прогрессии qi при Pi близком к половине Ej было не меньше, чем значение прогрессии:

(5)

Поясним, откуда здесь что.

(Ej-2)/Ej - это максимальная доля точек, которые не должны являться точкой рандеву для того, чтобы существование точки рандеву стало возможным. Наверное, проще пояснить на примере. Смотрим рисунок img03. Здесь Ej=16. Число потенциальных точек рандеву - 16-1=15. Но существование хотя бы одной точки рандеву возможно лишь в том случае, если не-"точками рандеву" будут не более 16-2=14 из них. То есть их максимальная доля составляет 14/16.

1-(Ej-2)/Ej - это, следовательно, минимально необходимая доля действительных точек рандеву (то есть доля одной-единственной точки).

Наконец, почему Pi должно быть близко к половине Ej? Да потому, что Догадка как раз про это: про четное как сумму двух простых. И еще вот почему.

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

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

Убедились? Есть вопросы, да? Первый бросается в глаза сразу: почему в начальной части qi < ej? Ну что ж, если вы хотите проверить, что в этой части каждое четное число имеет пару простых слагаемых, просто посчитайте, это нетрудно (или поверьте предыдущим поколениям математиков). А насчет правоты достаточного условия - так оно ведь достаточное, а не необходимое. Здесь оно не работает по двум причинам. Во-первых, помните, что прогрессия (4) составлена в расчете на худший из худших случаев, когда голубых и желтых рядов - примерно поровну. Если вы учтете для первых нескольких чисел конкретные более благоприятные расклады (это выразится в замене в выражении (4) двойки на единицу в случае синфазности соответствующих рядов), весьма вероятно, все встанет на свои места. И во-вторых, на начальном участке велико влияние краевого эффекта, ведь наше достаточное условие в некотором роде - статистическое, и плохо работает на небольших выборках. Последнее утверждение, конечно же, образное. На самом же деле краевой эффект проявляется в том, что при небольшом числе младших простых чисел, определяющих слагаемые, на значение прогрессии (4) большое влияние оказывают дробные части от деления Ej на младшие простые числа (грубо говоря, части кирпичей, выступающих наружу).

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

Второй вопрос возникнет у тех, кто разберется в программе. Она составлена "наоборот": мы не задаемся четными Ej, подбирая потом подходящие Pi, а последовательно перебираем Pi и получаем из него Ej простым умножением на 2. На самом деле, никакого вопроса здесь нет: нам достаточно построить кривые, а как - это безразлично. Нам даже все равно, четные ли числа Ej.

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

Кстати, вот еще один пример, позволяющий убедиться в справедливости нашего метода. Здесь сравнивается реальное количество пар простых слагаемых для каждого четного числа (Npairs) и прогнозируемое с помощью прогрессии (4) минимальное количество точек рандеву (qi*Ej). Совершенно однозначно видно, что после преодоления краевого эффекта ожидаемое минимальное количество точек рандеву надежно меньше, чем реальное число пар, но, конечно же, больше 1. То есть наша оценка действительно учитывает вариант "хуже худшего", но показывает, что всегда имеется не менее одной пары простых слагаемых.

Итак, мы убедились, что ej стремится к 0 гораздо быстрее, чем qi. Догадка Гольдбаха верна и подтверждена.

В заключение несколько замечаний.

Первое - философское. Обратите внимание НАСКОЛЬКО ej быстрее стремится к 0. И это, учтите, при наихудших условиях! Поэтому Догадка - это ОЧЕНЬ сильный закон. И, наверное, в этой силе - пролог ее мистической истории. Вот почему она буквально бросилась в глаза Гольдбаху (а если быть точным - то еще Декарту) во времена, когда простые числа не могли иметь никакого практического приложения и интересовали разве что чудаков. Вот почему люди искали, ищут и будут искать ясное и строгое ее доказательство: им просто не верится, что у такого сильного закона может его не оказаться. А с практической точки зрения эта сила проявляется в том, что пары простых слагаемых в подавляющем большинстве случаев обнаруживаются уже в непосредственной близости от половины четного числа. Убедитесь!

Второе - конкретное. Как видим, приведенное доказательство истинности Догадки нельзя считать абсолютно строгим. А возможно ли действительно строгое доказательство? Ответ: нет! Все те люди, включая дядю Петроса, кто потратил свои жизни на поиск доказательства, на самом деле строили вечный двигатель. Дело в природе простых чисел. Каждое очередное простое число ортогонально всем предыдущим и как бы создает новый мир, в котором не действуют законы предыдущих миров. И уж тем более для всех этих миров нет единого закона. Как невозможно точно выяснить, является ли взятое наугад нечетное число простым, не перебрав все предыдущие простые числа, так невозможно строго подтвердить Догадку.

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

Начнем с общеизвестного доказанного факта: всякое нечетное число можно выразить в виде разности квадратов двух целых чисел.

Действительно, t2-(t-1)2=2t+1 - общая формула для нечетных чисел.

5=32-22

7=42-32

и т. д.

Легко заметить, что такое разложение не всегда единственно:

15=82-72=42-12

21=112-102=52-22

35=182-172=62-12

То есть видим, что всякое составное нечетное число, имеющее простой множитель p, можно выразить в виде разности квадратов:

a2-(a-p)2=a2-a2+2ap-p2=p(2a-p)

Действительно, число 2a-p - число всегда нечетное, то есть число p(2a-p) и есть некоторое составное нечетное число, имеющее множитель p. При a=p мы получаем квадрат числа p. Ясно, что если число p входит в разложение составного нечетного числа со степенью 1, произведение остальных простых сомножителей всегда имеет вид 2a-p, где a и p - взаимно простые числа. Также ясно, что a-(a-p) не равно 1.

Итак, произведение двух простых чисел p и m есть число нечетное и составное, значит оно может быть выражено в виде разности квадратов двух целых чисел

p·m=t2-c2

По формуле разности квадратов имеем p·m=(t+c)(t-c).

Если положить t=a, c=a-p то как было показано выше t-c не равно 1.

Но по основной теореме арифметики представление числа в виде простых сомножителей единственно, следовательно, если положить p>m, тогда обязательно p=t+c и m=t-c, что равносильно утверждению Теоремы 1.

Итак, мы получили, что действительно для любого целого числа t всегда найдутся два равноудаленных от него простых числа p и m. Следовательно, Теорема Гольдбаха верна.

Дополнение.

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

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

42-12=3+5+7

82-52=11+13+15 и т. д.

Ряд первых разностей представляет собой арифметическую прогрессию с разностью d=2. Сумма n членов арифметической прогрессии выражается как sn=[n(a1+an)]/2, где в данном случае n-ый член арифметической прогрессии имеет вид an=a1+(n-1)d=a1+(n-1)·2.

Итак, имеем для суммы n членов арифметической прогрессии sn=n·(a1+n-1).

Рассмотрим s3, начиная с a1=3 и далее a1=5.......

s3=3·(3+2)=15=3·5

s3=3·(5+2)=21=3·7

s3=3·(7+2)=27=3·9

То есть получаем ряд составных нечетных чисел кратных 3. То же верно и для s5:

s5=5·(3+4)=35=5·7

s5=5·(5+4)=45=5·9

составные нечетные кратные 5.

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

Итак, мы получили, что действительно для любого целого числа t всегда найдутся два равноудаленных от него простых числа p и m. Следовательно, Теорема Гольдбаха верна.

Впрочем, у серьезного и въедливого читателя может возникнуть вопрос: а не доказали ли мы теорему, обратную данной, а именно звучащую так: каковы бы ни были простые числа p и m, всегда найдется целое число t равноудаленное от них. Это доказывается тривиально. В самом деле, числа p и m - нечетные, значит числа t=(p+m)/2 и с=(p-m)/2 числа целые, откуда автоматически следует p=t+c и m=t-c. Но верно ли обратное,т. е. выполняется ли это для любого t? Обратимся снова к методу конечных разностей. Мы рассматриваем разности квадратов t2 - c2, где числа t и c разной четности. Мы уже видели, что такие разности выражаются суммой некоторого нечетного количества первых разностей и sn=n·(a1+n-1). Ясно, что всегда можно подобрать n равным некоторому простому числу m. С другой стороны, видно, что a1=(c+1)2-c2=2c+1. Тогда имеем sm=m·(2c+1+m-1)=m(2c+m). Из постулата Бертрана имеем, что на промежутке от t/2 до 2t имеется хотя бы два простых числа, одно меньшее, а другое большее t.

Пусть t-c=m простое число. Но с другой стороны t/2+b=m и t/2=c+b, откуда t/2t, значит число 2c+m лежит в промежутке от t до 2t, то есть там, где по Бертрану существует простое число p. Ясно, что разность между двумя простыми числами p и m всегда равна некоторому четному числу, следовательно всегда найдется такое c, что 2c+m=p.

Итак, имеем, что какое бы целое число t мы не взяли, всегда найдется такое c, что t2-c2 равно произведению двух простых чисел p и m. Далее все ясно.

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

a2-b2=(a+b)(a-b)=(a-k)2-(b-k)2+2k(a-b)

Тогда

(a-b)(a+b-2k)=(a-k)2-(b-k)2.

Пусть даны два простых числа p и m, тогда их произведение представимо в виде разности квадратов a2-b2=(a+b)(a-b), где m=(a-b) и p=(a+b). С другой стороны всегда существует некоторое простое число p1 равное p-2k. То есть имея два простых числа, равноудаленных от числа a, всегда можем получить два простых числа равноудаленных от другого числа a-k.

Например:

(8+5)(8-5)=3·13=72-42+2·3

3·(13-2)= 72-42

3·11=72-42

То есть зная доподлинно исходя из постулата Бертрана, что справа и слева от числа 7 имеются простые числа p<2·7 и m<7 и выбрав p=13 и m=3, получили простые числа 3 и 11 равноудаленные от числа 7.

Еще одно дополнение.

Утверждение Теоремы 1 равносильно следующему: всегда существует некое простое число p, которое при делении на целое число t>p/2 имеет ненулевой остаток с, который равен остатку с от деления числа t на простое число m. Например, остаток от деления 13 на 10 равен 3. С другой стороны остаток от деления 10 на 7 тоже равен 3. 10 - это и есть число , равноудаленное от 7 и 13. Особый случай представляет собой тройка чисел 3, 7 и 11. Скажем, остаток от деления 7 на 3 раввен 1, а 11 на 7 - равен 4. Но мы можем записать 7=2·3+1=3+4, То есть и здесь приходим к одинаковому остатку 4. Существование одинаковых остатков следует из элементарных положений теории делимости и условия m

[C] Svet(R)off

· Комментарии читателей (0)

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

С фон Нейманом американцам совсем не повезло. Они его шлепнули еще в 41-м, за одну только приставку к фамилии. А Винер отсидел по полной за увлечение лженаукой "сибирьнетикой", про которую узнал из передач радиостанции "Рука Москвы". За КВ-приемник ему, кстати, еще червонец накинули.

С другой стороны, раз Главный Папа просит - надо уважить. Значит, знает, о чем говорит. Пронзевает орлиным своим взором пространство и время, и, под руководством КПСС, видит, гений, грядущие проблемы. Значит, надо пахать.

- У вас и сейчас есть свой бизнес? В чем он заключается? - После начала моей карьеры программиста под x86 я стал тем, кого называют Independent Software Vendor, и именно этим я зарабатывал себе на жизнь, пока это было возможно с экономической точки зрения. Я все еще делаю мелкую работу от случая к случаю для старых заказчиков и друзей, но в основном теперь я живу на доход от инвестиций. Я трачу свое время на восстановление старого дома, в котором живу, потому что через некоторое время я стану слишком стар для подобной работы. Это также помогает держать себя в форме. Я стараюсь быть в курсе того, что творится в компьютерной индустрии, и если положение на рынке улучшится, и большая часть того, что нужно сделать для восстановления дома, будет выполнена, я буду работать больше, чем сейчас. - Изучив ассемблер, Вы создали пакет MASM32, который приобрел огромную популярность во всем мире. Как вам пришла мысль о его создании?

Чтобы установить MenuetOS под никсами, вам нужно сделать в консоли следующее:

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

и готово.

Достоинством данной OS является то, что не надо ничего модифицировать на своём жёстком диске, потому как всё происходит в оперативной памяти и не надо делать дополнительные партиции, ничего...

Введение в 32-х битный ассемблер

Это краткая выжимка из документации, поставляющейся с Menuet'ом, на тот случай, если вы не знаете английского или не очень хорошо понимаете его. Итак, приступим.

Краткое введение в программирование на ассемблере - 0.02

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

Есть шесть регистров, которые в Menuet можно рассматривать как переменные: eax, ebx, ecx, edx, esi, edi.

Каждый из этих регистров может хранить 32-х битное число.

Сохранить число в регистре можно следующим образом:

Как вы уже заметили, комментарии можно помещать после ";".

Также мы можем складывать и вычитать:

Также мы можем делать умножение и деление - прочтите о командах mul, div, imul, idiv в файле CMD.TXT на дискете с операционной системой (на английском).

Безусловные переходы можно делать так:

OK, у нас уже есть следующие основные функции:

• - Сохранение переменных

• - Изменение переменных

• - Безусловные переходы

• - Условные переходы

Задавать числа можно следующим образом:

В Menuet системные функции вызываются командой 'int 0x40'.

Например, кнопка на окно помещается следующим образом:

Просто, не правда ли?

Скомпилировать приложение можно выбрав menu->programing->fasm и указав имя файла с исходником на ассемблере и файла, который должен получиться.

Здесь (находится в архиве wasm_files.zip: files/recovered/appmenuet/appmenuet.asm) можно найти исходник рабочего приложения для MenuetOS с комментариями (на языке оригинала - прим.пер.)

А сколько радости, когда списал у Iczelion из урока листинг "Hello, world" и откомпилировал в экзешник величиной всего 1,5 килобайта. И он даже корректно работает. А какое счастье посещает его, когда он узнаёт, что можно всё это добро засунуть в 1 килобайт. И там ещё куча пустых нулей остаётся.

Но жизнь - штука суровая. После того, как новый адепт начинает отходить от примеров учителя, после того, как он обнаруживает, что не всегда всё идёт так, как он хочет, после того, как он неделю копает отладчиком свою программу, пытаясь найти эту дурацкую ошибку, а потом обнаруживает, что просто забыл поставить одну букву в своём исходнике (напр. "je" -> "jne"), после того, как он походил тернистыми путями Intel'а и понабивал шишки в ямах Microsoft'а, после многих перипетий адепт постепенно начинает более или менее реально воспринимать жизнь и великое искусство программирования. Но, как говорил Рей Бредбери, "Единственный способ заставить писателя не писать, это кольт 45-го калибра".

Посему писатели пишут. Проекты становятся всё более крупными и интересными. Ходить по всему листингу скролбаром, отыскивая код процедуры или место на котором закончил в последний раз; мучительно вспоминать, что ты вчера хотел реализовать; всё заново переписывать из-за того, что выбранный путь оказался неверным; просто искать способы быстро выполнять стандартные операции, всё это приводит адепта к просветлению и осознанию полезности удобной среды разработки.

В этом разделе я много писать не буду. Хорошая статья на указанную тему уже есть на WASM.RU, и там всё подробно написано. Скажу лишь, что для себя самой удобной, хотя и не совершенной средой, нахожу RadASM от KetilO. И вот почему:

• Частые операции типа assemble, build, save, debug выполняются теми клавишами, которые я настрою

• Имеется удобная настраиваемая подсветка синтаксиса

• Весь проект объединён в группу файлов

• Автоматически отслеживается версия

• Удобная навигация по файлам

• Быстрый переход на определение функции и назад

• И многое другое

Однако главное, чтобы среда была максимально удобна Вам. Ибо прилежный адепт не должен много времени отвлекаться на бытовые мелочи.

Проблемы разработки

Начинающий адепт, недавно познавший написание программ уровня "Hello, world", получив озарение свыше или задание от начальника на написание программы, сразу бросается к клавиатуре. Он стремится выплеснуть в код всё своё искусство, накопленное за эти две недели, которые он изучает ассемблер. "Сейчас я сделаю вам всем шедевр в несколько килобайт! Не пройдёт и два месяца". Клавиатура стонет и скрипит под натиском обрушивающегося на неё дождя ударов пальцами. И в то же время она радуется, что он не обезьяна, а то бы ещё и пальцами ног набирал для скорости.

Но вот каркас программы написан, а что дальше? А дальше он начинает писать одно. Что-то не получается. Переключается на другую сферу в программе. Потом делает третью часть. О, нашёл проблему в первой - возвращается к ней. На этот момент он уже забыл, каким способом хотел организовывать работу с памятью в своей программе. Приходится изобретать велосипед снова. А как удобно представить свои данные? Лучше так. А может быть по-другому? Или так? А что там было в третьей части? Да это не важно. Вот в статье он прочитал об оригинальном способе представления данных. И снова всё надо переписывать. И новые структуры появляются. "А это что за структура? Да это ведь для моего первого варианта работы с памятью два месяца назад!" Но теперь уже он не нужен.

Кроме того, он ведь не просто пишет программы. Он пишет на ассемблере! Самые быстрые программы. А как раз недавно он прочитал классную статью по оптимизации кода по скорости и размеру. Поэтому во время написания программы адепт её сразу оптимизирует. Но это оказывается БОЛЬШОЙ ошибкой.

Ваш покорный слуга, например, долго пребывал в глубокой уверенности, что в масме диалоги не работают, их нельзя создавать. Или масм у Стива кривой? В наших ошибках всегда виноват кто-нибудь другой. Но вот же есть в примерах диалоги. Дрожащими пальцами компилирую его. Всё работает. На основе этого файла начинаю собирать свой диалог. В какой-то момент он перестаёт работать. А я не заметил после чего. Приходится всё начинать сначала. Примерно через месяц или два я понял свою ошибку. Её озвучил кто-то из великих программистов: "Многие беды программирования происходят от преждевременной оптимизации". Я не сохранял всякие IF, ELSE в первоначальном виде, а переводил их в CMP и переделывал структуру диалоговой процедуры. Читая Iczelion'а, я не сразу обратил внимание, что диалоговая процедура отличается от оконной. Что она должна возвращать определённое булевское значение. В результате я возвращал неправильные значения и диалоговое окно не создавалось, так как считало, что произошла ошибка создания окна.

Зато про сегментные регистры (EBX, ESI, EDI) я прочитал и заметил сразу. Iczelion говорит, что их нельзя использовать. А если и используешь, то надо восстанавливать их значение перед возвратом в систему. Глупый! Ведь это же их надо тогда в стек складывать. А потом восстанавливать. Это ж сколько лишних байт и тактов процессора! Но я ведь умнее этого наивного Iczelion'а! Я попробовал их не восстанавливать. Всё прошло нормально в Win98SE. Ну и стал так писать везде.

А как-то злосчастным утром я попробовал свою одну прогу запустить в Win2000. А она возьми да и зависни! Как!? Пошёл домой. Проверил: всё работает. Прихожу на тот комп - прога дохнет. Причём вываливается внутри системы, а не моей программы. Я и на другой машине попробовал. Тот же результат: в двухтысячной вылетаем по GPF. Вот тут Микрософту досталось за кривую систему. "Да все они там ламера!" Как настоящий кул-хацкер, я в 2000-ой взялся за отладчик. Отыскал, где начинается проблема. В моей части кода всё ОК. Пошёл дальше в систему. А тут через несколько инструкций идёт обращение к памяти по адресу ESI. А я его в своей программе обнуляю для собственных нужд…

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

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

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

Как же действительно оптимально разрабатывать большой проект? Я не говорю здесь о проектах, которые затеваются для себя, в образовательных целях. Такие могут длиться годами, да так и не найти завершения. Меня интересуют принципы разработки проектов, которые нужны людям, которые будут кому-то полезны, у которых есть определённая "целевая аудитория". На самом деле, эти принципы известны уже давно и с успехом используются во многих софтверных компаниях. Однако большой проект - он и в Африке большой проект, и даже у одного разработчика. Поэтому давайте рассмотрим основные этапы разработки продукта. Эти этапы были позаимствованы на сайте фирмы ABBYY, которая известна нам по таким проектам как FineReader и Lingvo. Однако моей целью не было повторение этапов разработки проектов, используемых в больших компаниях, но адаптация тех принципов к ситуации, когда проектом занимаются от одного до десяти разработчиков, которые к тому же могут быть разделены расстоянием (жить в разных городах). Вот перечень этапов:

• Выработка целей и требований к предмету разработки

• Разработка предварительного (эскизного) проекта

• Разработка детального проекта

• Реализация

• Тестирование

Это и есть пункт первый - "Выработка целей и требований к предмету разработки". По большому счёту это задание должен писать конечный пользователь или заказчик программы. Желательно, вместе с программистом-разработчиком или координатором проекта.

В техническом задании на разработку программы указывается назначение программы. На этом этапе решаются следующие вопросы.

• Для чего она разрабатывается?

• Есть ли реальная потребность в такой программе?

• Какие возможности будут у разрабатываемого проекта?

• Чем он выгодно будет отличаться от конкурентов?

• Кто входит в "целевую аудиторию" программы?

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

• Как много времени потребуется на обучение пользователя эффективной работе с этой программой?

Разработка эскизного проекта

Когда техническое задание определено, наступает этап разработки предварительного проекта.

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

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

Подбираются соответствующие технологии и принципы, которые наиболее удобно позволят реализовать требования к программе и её функциональность. Определяются ориентировочные требования к компьютеру, на котором будет работать программа, в плане как аппаратного (процессор, память и др.), так и программного обеспечения (минимальная версия Windows, Internet Explorer, DirectX и т.п.). При этом, обратите внимание, мы ещё не написали ни строчки кода! Мы даже ещё не обговорили, на каком языке это всё будет написано. На данном этапе, это лишь абстрактная система. Её можно реализовать практически в любом языке.

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

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

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

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

Кодирование

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

Главным критерием при разработке кода программы является удобочитаемость и ясность исходных текстов. Именно это, а не оптимальность кода. Если вы сделали такой оптимальный код, который никто, кроме вас не поймёт, то труд ваш был напрасен. Уже через месяц отвлечения от проекта вы займёте плотные ряды тех, кто не может прочесть и понять ваш собственный код.

Теперь о любимой всеми нами оптимизации. НЕ ОПТИМИЗИРУЙТЕ ВАШИ ПРОГРАММЫ! По крайней мере, на стадии разработки. Это можно сделать потом, после того, как программа готова и протестирована. Опять же, можно в функции оставлять заметки по оптимизации и куски компактного кода, но только в комментариях.

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

В окончательной версии можно попробовать осторожно оптимизировать. За одно сразу увидите, насколько Ваша оптимизация реально приносит пользу. И когда проходите по своему исходному тексту в поисках возможностей оптимизации по скорости или размеру, не удаляйте неоптимизированный (но обычно более удобочитаемый) текст, но оставляйте его рядом в комментариях. Это позволит легко вернуть назад в случае ошибки или другой проблемы, а также поможет легче разобраться, что делает оптимизированный код. А как тяжело искать ошибки в оптимизированном коде!

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

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

Ещё одним важным аспектом кодирования является выбор языка программирования. В принципе, мы должны были с этим определиться на предыдущем этапе. И я всё это время говорил, полагая, что мы пишем на ассемблере. Однако этого ещё не достаточно. Дело в том, что есть разные ассемблеры. (Я подразумеваю masm, fasm, tasm, spasm, hla и другие, а не .8086, .286, .386, .486 и т. д.) Выбирать стоит тот ассемблер, который всем в группе разработки наиболее понятен. Все должны писать на одном ассемблере, чтобы блоки легко между собой сочетались. Могут быть группы, в которых все - ярые поклонники tasm или fasm. Я не большой специалист в разных ассемблерах, но при выборе применяю следующие критерии: ассемблер должен быть максимально удобочитаемым (желательно с высокоуровневыми директивами типа ".if .else .endif"), но при этом не должен теряться контроль над каждым байтом кода. Иначе, какой смысл писать на ассемблере? Берите уж тогда C++.

Для себя я выбрал masm. На мой взгляд, он в наибольшей степени отвечает приведённым здесь требованиям. В случаях, когда нужен простой IF, нет смысла вручную городить "CMP EAX,EDX JNE @1" и вводить новый ярлык. Пусть компилятор сделает это сам. У него лучше получается. Он впишет тот же самый код, байт в байт, только самостоятельно. А мы в листинге напишем гораздо более удобную конструкцию ".if eax==edx .endif", которая при чтении очень красноречива. Подобным образом можно организовывать и циклы. Если компилятор не добавляет в конструкцию цикла что-нибудь лишнее, то можно воспользоваться стандартным вариантом. Но если требуется особенный цикл или цикл с оптимизацией, то всегда можно реализовать его просто командами ассемблера. Однако и в этом случае стоит вписать директивы цикла и закомментировать их, чтобы не мешали, но намекали на то, что здесь по логике закодирован цикл.

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

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

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

Тестирование

Для успешного тестирования требуется составить план тестов. В такой план обычно входят следующие виды тестов:

• Тестирование соответствия возможностей программы тому, что заявлено в техническом задании.

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

• Тестирование освоения программы неподготовленным пользователем.

• Сравнительное тестирование с конкурирующими продуктами.

• Тестирование читабельности и адекватности пользовательской документации.

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

Заключение

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

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

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

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

Как вы уже, наверное, догадались, такой инструмент мы и будем создавать с помощью так называемых Alt-кодов - встроенной в интерпретатор command.com (а также cmd.exe в Windows NT и последующих) возможности набирать бинарные значения, используя правый цифровой блок клавиатуры при нажатой клавише Alt. В самом деле, мы можем использовать команду 'copy con file.bin' в сочетании с Alt-кодами, чтобы создать двоичный файл file.bin. Хотя здесь есть и проблема.

Дело в том, что не все двоичные значения можно набрать таким способом - некоторые управляющие символы вызывают непосредственную реакцию системы, а в файл не записываются. К этим значениям относятся: 0, 3, 6, 8, 10 (0Ah), 13 (0Dh), 16 (10h), 19 (13h), 26 (1Ah), 27 (1Bh), 127 (7Fh). Причем эти значения относятся к command.com DOS (соответственно, и Windows9*). Cmd.exe от линейки Windows NT в этом отношении более "либеральна" - "запрещенными" являются лишь символы 8, 13 (0Dh), 26 (1Ah) и 127 (7Fh). К тому же, размер буфера строки в команде copy ограничен 127 байтами (в Windows 2k/Xp - 510), а это неприятно осложняет создание нормально функционирующих программ. Большие файлы набирать с помощью 'copy con' можно, но придется специально обрабатывать переходы через символы конца строки (CRLF), которые будут вставляться в файл.

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

В нашем случае это будет даже не редактор, а скорее конвертор, переводящий поток ASCII-символов из стандартного ввода в поток двоичных значений в стандартный вывод. Причем все символы, не попадающие в диапазон ASCII-символов 0..9A..Fa..f, просто игнорируются. Это позволяет форматировать вводимый текст для большего удобства восприятия (добавлять пробелы между отдельными байтами, а между строками вставлять перевод строки - CRLF). Алгоритм приведен на следующем рисунке.

Нам понадобятся три переменные размером в 1 байт: для хранения обрабатываемого байта (назовем ее place), для хранения предыдущего байта (place2) и указатель того, относится ли обрабатываемый байт к первой или второй тетраде (check). В целях экономии (нам нужно уложиться в 127 байтов!) эти переменные оставим за пределами com-файла. Тем не менее, в начале программы необходимо на всякий случай проинициализировать их нулями. Команда типа 'mov byte ptr [place],0' не годится, т.к. в этом случае в код попадает непосредственное значение 0, а это недопустимый символ. Поэтому используем косвенный способ с использованием регистра:

В листинге слева приведено смещение с начала com-файла (в hex со смещения 100h), далее - машинный код, а затем с отступом - ассемблерная мнемоника для удобства восприятия. Здесь мы инициализируем сразу по 2 байта. Вместо 'nnnn' мы потом подставим действительные адреса этих переменных.

Далее нам нужно ввести 1 байт данных из стандартного ввода. Для этого используется функция 3Fh чтения из файла прерывания DOS 21h. В регистре AH должен содержаться номер функции (3Fh), в регистре BX - дескриптор файла (для стандартного ввода - 0), в регистре CX - число читаемых байтов (в нашем случае 1), DS:DX адресует буфер, куда должны читаться данные. В данном случае, нельзя использовать инструкцию 'mov cx,1', т.к. получаем код 'B9 01 00' - появляется запрещенный нулевой байт.

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

В регистре AX возвращается число прочитанных байтов. Если прочитано 0 байт, файл закончился - также выходим.

Далее загружаем сохраненный в переменной 'place' байт в регистр AH для анализа.

Логика исполнения должна быть ясна из рисунка. Небольшие ссылки вперед ("перескакивание через инструкцию") вычислены сразу; часто использующаяся ссылка назад - на ввод очередного символа, соответствующий код расположен по смещению 108h. Остальные ссылки вперед помечены метками NUMBER и FIRST (далее); они для удобства обозначены также и на рисунке. Начало следующего участка кода соответствует метке NUMBER: мы получили смещение (149h), теперь можно вычислить все ранее сделанные ссылки на этот адрес.

Этот код может показаться несколько странным. Зачем нужен nop, когда мы и так стараемся вместить код в ограниченные 127 байтов? Если вы посмотрите на сделанные ранее ссылки вперед и подсчитаете соответствующие смещения (в частности, для инструкции по адресу 13Ah), при ссылке на адрес 149h вы получите инструкцию 'EB 0D', а 0Dh у нас "запрещенный" символ. Поэтому ближайший адрес, на который мы можем ссылаться, - 14Ah, а по адресу 149h придется оставить пустую инструкцию. Далее, если введенный ASCII-символ соответствует первой тетраде выходного байта, в переменной check будет 0. Но использовать инструкцию типа 'cmp byte ptr [check],0' нельзя, поскольку в код опять попадает 0 в виде непосредственного значения. Поэтому используем косвенный метод через копирование значения в регистр BL и последующим test.

Вычисленное значение второй (в данном случае) тетрады необходимо добавить к переменной (place2), содержащей значение сохраненной первой тетрады. К несчастью, опкод инструкции add равен 0, поэтому нам придется вообще от нее отказаться, заменив ее двумя инструкциями neg и sub. Думаю, с этим разобрались.

Далее идет вывод одного байта в стандартный вывод. Используется функция 40h файлового вывода прерывания DOS 21h. В регистре AH, как обычно, должен быть номер функции (40h), в BX - дескриптор файла (на этот раз стандартный вывод, т.е. 1), в CX - число выводимых байтов (1), DS:DX адресует буфер для вывода (у нас - адрес переменной place2). Для избежания появления нулевых байтов в коде придется применить те же хитрости с регистрами и inc, которые мы использовали при вводе. В случае ошибки (установленный бит CF при возврате из функции) сразу завершаем программу, чтобы не нагородить лишнего.

Записав очередной байт, нужно указать в переменной check, что следующий вводимый байт ASCII-кода будет представлять первую тетраду выводимого байта; для этого обнуляем эту переменную. Как обычно, это делается опосредованно через регистр:

В этом месте должен размещаться код для обработки случая первой тетрады (метка FIRST). Но сюда ссылается команда по адресу 150h, и если сделать ссылку на адрес 16Dh, получится инструкция '74 1B', а 1Bh у нас тоже "запрещен". Придется сослаться на следующий адрес 16Eh, а по адресу 16Dh опять поставить nop:

Инструкция по смещению 176 делает отметку в переменной check, что следующий вводимый байт будет соответствовать второй тетраде выходного байта. Вообще-то, check представляет собой простую логическую переменную, и решение делается на основе проверки ее на предмет 0 - не 0. Можно было бы использовать инструкцию 'inc byte ptr [check]', но, к несчастью, при этом в коде появляется запрещенный символ 06. Приходится вместо inc использовать dec; в нашем случае это совершенно не играет роли. Вот и все - здесь конец программы, инструкция возврата и метка EXIT:

Программа заняла 7Dh = 125 байтов. Переменные, как мы уже говорили, можно разместить и за пределами файла, "виртуально"; т.е. можно было бы использовать адрес 17Dh. Но, как вы понимаете :), сочинение такого опуса и его подгонка заняла не один час, и для облегчения себе жизни, чтобы не пересчитывать каждый раз хотя бы адреса переменных, я отвел им места "с запасом" - для place, place2 и check соответственно 180h, 181h и 182h. Теперь можно вставить эти адреса, а также вычислить смещения и подставить их вместо 'nnnn' в инструкции. Окончательно мы получим такой код:

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

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

Затем вводятся все приведенные выше числа (десятичные), при вводе каждого числа нажимается и удерживается клавиша Alt. В случае ошибки можно просто стереть символ клавишей "Backspace" и ввести заново. Набрав все, нажимаем Ctrl+Z (или F6) и Enter - файл готов. Программа в принципе может работать и в интерактивном режиме, хотя это не очень удобно. Основное ее предназначение - использование в перенаправлениях, типа:

В качестве редактора для создания файла input.txt используется все та же внутренняя команда оболочки copy:

Только на этот раз мы набираем не Alt-коды, а нормальный текст, вернее, текстовое представление 16-ричного кода. Непременно нужно создать тестовый файл со всеми возможными 16-ричными значениями и подать его на вход нашего редактора, чтобы проверить, что все работает нормально:

Эта программа далеко не шедевр, возможно, в ней есть большие и малые ляпусы, тем не менее, она удовлетворяет главному требованию - она работает, и работает универсально. Я проверял ее для DOS 6.22, Windows 98 SE/Me/2000 Server/XP Pro/2003 Server, а также загрузочных дискет, созданных Windows 98 и Me. Во всех случаях при наборе Alt-кодов возражений со стороны интерпретатора не поступало :), а сама полученная программа успешно конвертировала тестовый файл со всеми возможными значениями в соответствующий бинарный файл. Кстати, если вы владеете слепой печатью на правом цифровом блоке, можно поспорить, каким образом программа набирается быстрее - с помощью Alt-кодов или традиционным образом, через написание исходного текста на ассемблере с последующим построением (если брать суммарное время, боюсь, сравнение окажется не в пользу ассемблера).

Еще одно замечание по поводу возможности ошибок, трудности программирования в машинных кодах и т.д. и т.п. В ходе подготовки материала я набирал этот числовой блок в Alt-кодах раз двадцать, и ни разу не сделал ни единой ошибки. Между тем в ассемблерных проектах, даже коротких, практически всегда хоть мелкая, но найдется какая-нибудь ошибка. Так что в мире программирования гуляет под видом истин множество предрассудков; развеять их могли бы люди, имеющие собственный опыт (например, создания больших проектов прямо в машинных кодах. Но у кого такой опыт есть? Ведь это считается безумием!) Но если бы мы ограничились тестированием лишь с небольшим пробным файлом, это было бы так, забавой, не более. Кто знает, может, там прячется какая-нибудь хитрая ошибка? Поэтому нужно преобразовать в ASCII-представление какой-нибудь рабочий бинарный файл, затем конвертировать его с помощью нашей утилиты и посмотреть, будет ли исходный файл работать после такого двойного преобразования. Я приведу готовый листинг утилиты, созданной с помощью MASM32, для преобразования бинарных файлов в текстовое 16-ричное представление. Не привожу полного описания, т.к. здесь нет ничего особенного; к тому же в исходном тексте есть комментарии.

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

Первой "жертвой" теста, как водится, стал calc.exe. После "двойного преобразования" он работал великолепно. Но интересно ведь попробовать какой-нибудь большой файл, этак в несколько мегов. После некоторых поисков мне удалось на своей системе найти такой файл, им оказался исполняемый модуль AcrobatReader 6.0 (AcroRd32.exe) в 7,3 Мб. Преобразованный в текстовый вид, он занял 22,8 Мб. Представляете, подать такое примитивной com-программке размером в 125 байт? Даже страшно как-то - вдруг задавит своей массой! Тем не менее, я проделал и это. Конечно, пришлось подождать пару-другую минут (что ж вы хотите :)). И полученный после такого преобразования монстр запустился! Правда, отсутствовало меню и еще что-то по мелочи. Но это я отношу уже к тому, что файл был вырван из контекста сложной системы, перенесен в какой-то новый каталог, а там была куча записей в реестре и т.п. В общем, если бы была лажа с преобразованием, файл не запустился бы вообще.

Поэтому можно считать, что первый инструмент в борьбе за виртуальное выживание у нас уже есть. Я не думаю, что надо заучивать эти 125 байтов наизусть, как "Отче наш". Уловив общую суть, а главное, просмотрев этот путь и узнав, где какие подвохи попадаются, можно при необходимости его воспроизвести. А дальше уже дело собственных знаний. С помощью этого инструмента можно создавать все те вещи, которые создаются с помощью debug'а (и о которых я начал писать в статьях "Приложение Windows голыми руками" и "Dll в машинных кодах"). А это значит, что можно практически "с нуля" создавать любые нужные приложения (при необходимости используя наш принцип спецназа: используем простые утилиты для создания более сложных, а последние - для создания еще более сложных и т.д. - до выполнения боевой задачи). Фактически, это равносильно созданию этих утилит прямо в Alt-кодах. Более "голый" способ может быть разве что создание загрузочной дискеты с помощью самодельного электромагнита :). Лично я покопаюсь еще в этом направлении, уж больно интересные вещи можно здесь обнаружить.

1. MS ActiveSync 3.7.1

2. Microsoft .NET Framework 1.1 SDK (Nov. 2003)

- Будут ли добавлены высокоуровневые конструкции (встроенный PROC, .IF/.WHILE и т.д.) в FASM? Мне всегда хотелось держать синтаксис fasm'а очень простым и основанным на небольшом количестве директив, которые бы позволяли реализовывать другие фичи вроде макросов. И хотя директивы fasm ещё недостаточно могущественны, чтобы реализовать некоторые очень сложные высокоуровневые конструкции, в общем случае этих директив более чем достаточно, чтобы реализовать практически любую возможность, каким-либо боком относящуюся к ассемблеру. И если кому-то действительно нужно больше, я бы посоветовал использовать какой-либо компилятор с fasm в качестве постпроцессора (back-end). - Будет ли FASM добавлена оптимизация, как формальная (например, замена lea на mov, замена одних опкодов на более короткие), так и неформальная (например, перегруппировка инструкций, выкидывание ненужного кода)? Нет, на мой взгляд, даже эта формальная оптимизация слишком противоречива, чтобы помещать её в ассемблер. Тем не менее, практически для всего из вышеперечисленного можно сделать соответсвующий макрос. - Макроязык FASM нетривиален и отличается от MASM/TASM. Вы планируете добавить режим совместимости?

- Will high-level constructions (built-in PROC, .IF/.WHILE etc.) be added into FASM? I always wanted to keep the fasm's syntax very simple and based on just few powerful directives that would allow implementing any other features as an custom "upper layer" for assembly language, like macroinstruction packages. And though fasm's directives might still not powerful enough to implement some very sophisticated HLL-like constructions, they seem to be generally more than enough to implement any customization that is still somewhat related to assembly language. And when someone really needs more, I might suggest using some compiler with fasm as a back-end. - Will instruction optimisation, both formal (f.e. replacing lea with mov, replacing opcodes with shorter ones) and non-formal (f.e. instruction regrouping, cutting unnecessary code), be added into FASM? No, even those formal optimisations are too controversial to put them into the assembler in my opinion. However, you can make an optimising macros for most of them. - FASM Macrolanguage is non-trivial and different from MASM/TASM. Are you planning to add compatability mode?

Сайт программы: http://www.winasm.net

AddIn- это подключаемый код, предназначенный для расширения функций редактора и размещенный в отдельной dll. Для того, чтобы WinAsm его нашел, dll нужно разместить в подкаталоге AddIns домашнего каталога WinAsm-а. Под "подключением" AddIn-а имеется ввиду загрузка и инициализация соответствующей dll. Для того, чтобы загрузить AddIn, необходимо открыть менеджер AddIn-ов (Add-Ins Manager) в меню Add-Ins. Выбрав нужный AddIn в списке, отметить чекбокс "Loaded/Unloaded" чтобы его загрузить. Также можно отметить чекбокс "Load On StartUp", тогда AddIn будет загружаться автоматически при загрузке WinAsm. Для своего функционирования AddIn должен экспортировать функции, часть из которых обязательна. WinAsm, в свою очередь, предоставляет AddIn-у указатели на внутренние структуры с важными переменными, а также выполняет ряд сервисов, обрабатывая дополнительные сообщения в оконной процедуре главного окна. Основной поток сообщений, получаемых окнами WinAsm-а, пропускается вначале через соответствующие процедуры загруженых AddIn-ов, при этом AddIn может не только выполнить свой код, получив соответствующее сообщение, но и прекратить его дальнейшую обработку, вернув TRUE в eax, полностью подменив, таким образом, некоторую встроенную функцию своим кодом.

Исходник AddIn-а представляет из себя обычный проект dll и включает в себя, как минимум:

• addin.asm - исходный текст.

• addin.def - файл, в котором определяются имена экспортируемых функций.

• WAAddin.inc- файл, в котором определены структуры, используемые в WinAsm, и ряд констант, в том числе и дополнительные сообщения, обрабатываемые контролом окна редактора CodeHi.dll.

WAAddin.inc регулярно обновляется вместе с появлением новых функций в WinAsm-е. Он обширно откомментирован и снабжен примерами использования некоторых возможностей. Чтобы быстро создать шаблон нового AddIn-а, можно вызвать мастер новых проектов Ctrl+N, и в разделе "Bare Bone" выбрать тип проекта "AddIn". Можно также использовать исходные тексты примеров или рабочих AddIn-ов, так как практически все они ими снабжены.

Также для написания AddIn-а удобно сразу же в имя результирующего бинарного файла включить путь к папке с AddIn-ами. При компиляции необходимо учитывать, что она возможна только тогда, когда AddIn выгружен. Для обхождения этого неудобства можно использовать другой AddIn - Enchanced Add-Ins Manager - улучшенный менеджер AddIn-ов (автор - Mario Vilas), который при компиляции автоматически выгружает текущий AddIn, а после нее - загружает. Однако он не всегда это делает успешно, если при компиляции произошла ошибка. При написании AddIn-а необходимо быть готовым к тому, что WinAsm из-за него рухнет, поэтому не торопитесь включать для него опцию "Load On StartUp". Если же это произошло при изменении существующего AddIn-а, который загружается вместе с WinAsm-ом и рушит его, отключить его автоматическую загрузку можно убрав строку с названием соответствующей dll из раздела [ADDINS] файла winasm.ini (расположен в домашнем каталоге WinAsm-а). WinAsm позволяет запускать себя в "защищенном от AddIn-ов" режиме при удержании F8, однако это оказалось малоэффективном при старте его из разных файловых менеджеров, которые сами обрабатывают нажатие F8. Возможно, в дальнейшем это будет исправлено. Для отладки AddIn-ов можно использовать как vkdebug, идущий в составе пакета masm32, так и любые другие отладчики, запуская под ними WinAsm, загружая AddIn и переходя к отладке. Для отладки я обычно использую следующий макрос, исключающий сообщение об ошибке при запуске WinAsm-а с AddIn-ом вне отладчика:

Возможны следующие варианты обращения к dll AddIn-а:

А. Получение сведений об AddIn-е менеджером AddIn-ов

• AddIn не загружен:

• AddIn загружен:

Б. Настройка AddIn-а из менеджера AddIn-ов

• AddIn не загружен:

• AddIn загружен:

В. Загрузка AddIn-а:

Г. Выгрузка AddIn-а:

A. DllEntry

Это стандартная процедура DllMain, она вызывается при загрузке/выгрузке динамической библиотеки. В AddIn-е используется для получения хэндла dll при загрузке.

hInst- хэндл модуля dll; reason- параметр, определяющий причину вызова данной функции, в нашем случае может принимать следующие значения: DLL_PROCESS_ATTACH- выполняется загрузка библиотеки в память процесса, DLL_PROCESS_DETACH- выполняется выгрузка библиотеки из памяти процесса; reserved1 - он и в Африке reserved1.

Процедура DllEntry присутствует в шаблоне и обычно не нуждается в модификации.

Б. GetWAAddInData

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

Наример, в AddIn.Inc записываем:

В. WAAddInLoad

Процедура, вызываемая при инициализации AddIn-а.

В качестве параметров передаются указатели на структуру с важнейшими хэндлами HANDLES(pWinAsmHandles) и на структуру с разными переменными features (содержит номер версии WinAsm-а, указатели на списки процедур загруженых AddIn-ов, на переменную с хэндлом дочернего окна редактора ресурсов и на список меток редактора ресурсов). Эти структуры подробнее описаны в WAAddIn.inc.

В этой процедуре AddIn может скопировать в свои переменные такие важные значения, как хэндл главного окна WinAsm-а (HANDLES.hMain), хэндл клиентской части главного окна (HANDLES.hClient), хэндл главного меню (HANDLES.hMenu), и многие другие. Конечно же, можно запомнить и сам указатель на структуру WinAsmHandles, однако нельзя сказать, что это удобней.

Также в этой процедуре AddIn может произвести собственную инициализацию: выделить память, добавить свои опции в меню и т.п. Значение, возвращаемое этой процедурой, свидетельствует об успешности инициализации AddIn-а, и в случае неудачи (eax=TRUE) AddIn будет выгружен.

Г. WAAddInUnload

Данная процедура не имеет параметров и вызывается при выгрузке AddIn-а. Здесь AddIn должен освободить выделенную ему память, удалить свои опции меню, и т.п. То есть, восстановить status quo.

Для использования необязательных процедур AddIn-а в WinAsm их названия необходимо вписать (или декомментировать) в разделе EXPORTS def-файла проекта.

А. WAAddInConfig

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

Б. Процедуры обработки сообщений окон:

FrameWindowProc- получает все сообщения, посылаемые главному (MDI) окну WinAsm. ChildWindowProc- получает все сообщения, посылаемые всем дочерним окнам WinAsm. ProjectExplorerProc- получает все сообщения, посылаемые окну менеджера проекта. OutWindowProc - получает все сообщения, посыламые окну вывода результатов компиляции.

все эти процедуры имеют одинаковый формат, соответствующий формату процедуре окна:

Перед тем, как процедура окна WinAsm обработает сообщение сама, это сообщение будет пропущено через все соответствующие процедуры AddIn-ов. Если какая-либо процедура AddIn-а вернула eax=TRUE, дальнейшая обработка данного сообщения прекращается. При этом следует заметить, что если два AddIn-а обрабатывают одинаковое сообщение, то первенство будет согласно загрузки, а порядок загрузки AddIn-ов пока не регламентировался. После обработки сообщения WM_COMMAND самим WinAsm-ом всем процедурам FrameWindowProc дополнительно посылается сообщение WAE_COMMANDFINISHED с теми же параметрами, что дает возможность выполнить код после обработки команды редактором (а не перед).

Вероятно, AddIn-у потребуется создать свою опцию меню. Для этого могут понадобиться либо хэндл главного меню, либо хэндл одного из существующих выпадающих меню. Их можно взять из структуры HANDLES и вложеной структуры POPUPMENUS, их соответствие понятно из названий:

Например, если мы решили создать новую опцию в выпадающем меню "Add-Ins", то его хэндл мы можем получить так (в процедуре WAAddInLoad):

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

Теперь можно создавать свою опцию меню:

При выгрузке AddIn-а (в процедуре WAAddInUnload) следует удалить свою опцию меню:

Хэндл главного окна нужно взять из структуры HANDLES. Там же можно получить и хэндл главного меню:

Иногда AddIn может обрабатывать существующие команды меню, тогда создавать свои идентификаторы не нужно. Встроенные идентификаторы перечислены в WAAddIn.inc. Обработав таким образом некоторый идентификатор и вернув в eax значене TRUE AddIn может полностью подменить соответствующую функцию WinAsm-а своей. AddIn может также заставлять WinAsm выполнять нужные функции, посылая встроенные идентификаторы главному окну WinAsm-а.

7. Создание плавающих окон (docking windows).

Для создания такого рода окон необходимо использовать внутренние сообщения главному окну WinAsm-а, описанные в разделе "Docking windows" файла WAAddIns.inc:

WAM_CREATEDOCKINGWINDOW - создать окно

WAM_GETCLIENTRECT - получить размеры клиентской области окна

WAM_DESTROYDOCKINGWINDOW - удалить окно

Также для создания такого окна необходимо будет заполнить структуру DOCKINGDATA, описанную там же. 8. Работа с окном редактора. Вероятно, AddIn-у потребуется обратиться к окну редактора для анализа/модификации редактируемого текста. Для этого вначале необходима небольшая рутинная последовательность:

Также во многих случаях желательно убедиться в том, что окно видимо при помощи функции IsWindowVisible. Теперь можно работать с окном редактора. Сообщения, которые поддерживает контрол, перечислены в WAAddIn.Inc и состоят как из ряда стандартных сообщений, так и дополнительных, которые начинаются на CHM_ (CodeHi Message). Стандартные сообщения в WAAddIn.inc закомментированы, так как они уже описаны в windows.inc. Смысл большинства сообщений понятен из названия.

Например, получим слово, находящееся под курсором:

Также в структуре CHILDDATA можно найти другие полезные данные: имя файла с полным путем, внутренний тип файла и некоторые другие. Эта структура также описана в WAAddIn.inc.

Для добавления своих клавиатурных акселераторов можно воспользоваться хэндлом таблицы акселераторов, указатель на него имеется в структуре HANDLES: HANDLES.phAcceleratorTable. Работа с таблицей акселераторов показана на примере (неидеальном, но работающем) в демонстрационном AddIn-е AccelaratorDemoAddIn.

Для настройки AddIn-а можно использовать как процедуру WAAddInConfig, так и другие методы. Преимущество первого способа заключается в том, что процедура настройки конфигурации может быть вызвана у незагруженного AddInа, или в том случае, когда у AddIn-а нет своих окон, что избавляет от необходимости создавать специальные опции меню только для настройки AddIn-а. Соблюдения порядка ради автором WinAsm-а предлагается хранить настройки AddIn-а в файле WAAddIns.ini, находящегося в каталоге AddIns вместе с AddInами. Для хранения своих настроек желательно создать свою секцию, соответствующую названию AddIn-а, где и хранить значения переменных. Запись/чтение переменных производится при помощи функций WritePrivateProfileString и GetPrivateProfileString.

На сайте WinAsm Studio меется пакет WAAddInLib, разработанный Mario Vilas (QvasiModo), в котором часть рутинного кода оформлено в виде процедур, что позволяет ускорить написание AddIn-ов. Пакет также регулярно обновляется. 12. Пожелания.

Удачи всем!

Александр Журенков (aka shoo)

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

Исходный файл с описанием изменений ничем не отличается от обыкновенной программы на ассемблере, единственное, блок кода/данных нужно заключать в макрокоманды __setorg/__mkdiff. Первая определяет положение в файле, по которому будет записан блок, а вторая определяет конец блока.

Бинарные файлы

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

Также можно использовать ассемблер и изменять значения счетчика команд.

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

В дополнение можно рассказать о нескольких особенностях использования.

Изменять небольшие участки удобно макрокомандой __mkchng, она заменят набор команд __setorg/__mkdiff если требуется изменить всего одну строку.

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

Файлы формата PE

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

И для того чтобы узнать позицию инструкции в файле(RVA) по адресу памяти(VA), нужно произвести вычисление вида:

Используя макроопределения можно достаточно реально воспроизвести ситуацию, когда при написании кода вам необходимо знать только адрес в памяти(VA), тогда как программа, используя информацию о файле, сама вычислит действительный адрес инструкции(RVA).

Используя макроопределения ситуация упрощается, устанавливать положение маркера можно по виртуальному адресу.

Все, что потребуется - это используя макродирективу __format_pe указать основные характеристики - базовый адрес загрузки и секции. Описание секции состоит из трех параметров "VA RA N". Где, VA - относительный адрес секции в памяти, RA - позиция секции в файле, N - реальный размер секции в байтах.

Узнать значения можно постмотрев заголовок файла в отладчике или специальной программомой для работы c файлами формата PE(я использовал PeID).

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

Заключение

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

Хочется поблагодарить товарища Tomasz Grysztar за отличний ассемблер, кодеров с wasm.ru и flatassembler.net/board

Исходники (находится в архиве wasm_files.zip: files/0404/patchbyfasm.zip) к статье.

Сайт автора - www.assert.i8.com.

Ещё несколько хотелось бы сказать относительно года будущего. В нём мы ~~собираемся пинать GUI~~ не собираемся останавливаться на достигнутом. Если ~~нас не заломает~~ всё сложится удачно, то в 2007 году будут реализованы остальные пункты ~~программы КПСС~~ СПРС, среди которых есть ~~захват мира и господство над человечеством~~ дальнейшее наполнение сайта контентом, усовершенствование движка и введение новых сервисов и подпроектов.

— Хотим компилировать! — восклицали третьи.

Наконец, их мольбы были услышаны. Google, Microsoft, Mozilla и группа инженеров, стоящая за Webkit (Apple, как обычно, делает загадочный вид), объединились, чтобы создать стандарт, который откроет новую эпоху в области web-программирования.

Они решили назвать его WebAssembly, а сокращённо — попросту wasm.

Проблемы, которые были озвучены — сложность программирования на других языках и низкая скорость выполнения, производители браузеров пытались решить по отдельности. Mozilla разрабатывала asm.js — подмножество JavaScript, которое, с одной стороны, исполняется обычным браузером, а с другой, браузер, поддерживающий этот стандарт (Firefox), способен выполнить его гораздо быстрее, чем обычный JavaScript. Также asm.js задумывался как решение проблемы с программированием на других языках — чтобы он мог служить целью компиляции других языков. Google предложил своё решение — Native Client, в котором бы исполнялся запесоченный для безопасности скомпилированный код C и C++. Однако ни то, ни другое решение не смогло завладеть умами людей и разработчиков.

WebAssembly — это новая попытка разработать новый стандарт, который решит старые проблемы и будет принят всеми основными участниками. Объединились производители основных браузеров, поэтому есть надежда, что в этот раз она окажется успешной.

Что из себя представляет WebAssembly, главный репозиторий которого находится здесь? Это не совсем привычный нам байткод. WebAssembly имеет формат AST — абстрактного синтасического дерева, которое может быть представлено как в бинарном виде — основном для распространения, так и в текстовом, соответствующим двоичному.

Вот пример WebAssembly в человекочитаемой форме.

Лисперам должно понравиться. Конечно, компилироваться wasm будет в бинарную форму.

В первую очередь, WebAssembly рассчитан на web-платформу. Вот как определяется эта цель:

Проектируется, чтобы запускаться внутри и хорошо интегрироваться с существующей веб-платформой:

- сохранять безверсионную, протестированную и обратносовместимую историю Веб;

- запускаться в той же семантической вселенной, что и JavaScript;

- позволять синхронизированные вызовы из и в JavaScript;

- соблюдать такие же политики безопасности;

- иметь доступ к функциональности браузера через такие же Web API, которые доступны в JavaScript;

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

Однако в долгосрочной перспективе под властью wasm должны оказаться и другие платформы: сервера в датацентрах, IoT-устройства, мобильные и десктопные приложения и т. д., и т. п.

Для программистов самое интересное – это то, для генерации приложений в WebAssembly можно будет использовать не JavaScript, а другие языки. Первым, для кого делается поддержка, является C++. Ветераны указатели и шаблонов снова впереди!

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

$$\sum\limits_{k=0}^N a_k*8^k$$

В данном случае требуется не 10 цифр, а 8, от 0 до 7. Обычно, если требуется указать систему счисления, её основание записывается как нижний индекс справа от числа(основание записывается в десятичной системе счисления), например:

$$76647_{8}=78^4 + 68^3 + 68^2 + 48^1 + 7*8^0 \quad (2)$$

в свою очередь:

$$76647_{8}=32167_{10}$$

то есть сумма (1) равна суме (2).

В системе счисления с основанием n существует n цифр, например в десятичной – десять, в восьмеричной – восемь. Если же нужно использовать систему счисления с основанием большим десяти, то придётся добавлять новые цифры, например в шестнадцатеричной системе счисления 16 цифр: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F. Цифры A-F, равны 10-15 соответственно. Чтобы лучше понять рассмотрим несколько примеров:

$$

A_{16}=10_{10} \

F_{16}=15_{10} \

A3_{16}=1016^1 + 316^0=163_{10} \

F2E_{16}=1516^2 + 216^1 + 14*16^0=3886_{10}

$$

Подробнее почитать о системах счисления можно в википедии

Что касается fasm-а, то в нём числа можно записывать в 4 разных системах счисления: в двоичной, в восьмеричной, в десятичной и в шестнадцатеричной. Чтобы записать число в десятичной системе счисления можно либо не указывать систему счисления вообще, либо дописать к числу справа букву “d”, например: 32167 или 32167d. Чтобы записать в восьмеричной нужно дописать к числу справа букву “o”, например: 32167o равно числу 13431. Чтобы записать в двоичной нужно дописать справа букву “b”, например: 100110b равно числу 38. Записать число в шестнадцатеричной системе счисления можно несколькими способами: можно дописать слева последовательность “0x”, можно дописать слева “$” и можно дописать справа букву “h”, но в последнем случае число должно начинаться с одной из десятичных цифр. Пример: 0xFE=$FE=0FEh=254, запись FEh приведёт к ошибке.

Компьютер работает с числами в двоичной системе счисления. Один двоичный знак называется битом, соответственно число состоящее из n двоичных знаков называется n-битным (или n-разрядным). Например число 11010010b – 8-ми битное. Группа из 8 бит называется байтом(byte), из 2-х байт – словом(word), из 4-х байт – двойным словом(double word), из 8-и байт – счетверённым словом(quad word), и т.д.

Каждая программа (её код и данные) располагается в оперативной памяти. Оперативная память состоит из ячеек размером в 1 байт. Для того чтобы обращаться к этим ячейкам, каждой из них сопоставлено некоторое число, называемое адресом (в нашем случае — 64-битное) (см. рис. 1).

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

У виртуальной памяти есть атрибуты доступа: запись, чтение, исполнение. Например, если память не доступна для записи, то попытка записать в неё приведёт к ошибке, если она не доступна для исполнения, то попытка исполнения кода, находящегося там приведёт к ошибке, и т.д.

Ещё хотелось бы добавить, что когда говорят “указатель на что-то”, то имеется ввиду виртуальный адрес, с которого начинается что-то.

Начну с того, что коснусь структуры исполняемого файла.

Исполняемый файл Windows состоит из нескольких частей:

1. Заголовок – обязателен

2. Секции, их может быть любое количество

У каждой секции есть имя (состоит из 8 ANSI символов) и атрибуты, в них входят атрибуты доступа к памяти.

Теперь рассмотрим ~~HelloWorld~~ простейшую программу на fasm-е:

Первой строчкой указывается формат файла(в нашем случае PE64 – это 64-битный исполняемый файл Windows PE-Portable Executable) и подсистема console(это значит что при запуске нашей программы у неё будет создана консоль).

Вторая строчка entry start указывает точку входа, это — место с которого начинает исполняться код нашей программы.

include 'win64w.inc' – подключение некоторых заголовочных файлов.

Слово section обозначает начало новой секции, после него идёт имя в кавычках, а затем атрибуты.

Секцию кода мы пометили как доступную для чтения и исполнения, но не для записи, атрибут “code” указывает на то, что в данной секции находится код, он не обязателен, без него всё будет нормально работать.

Секция данных доступна для чтения и записи, атрибут “data” указывает на то, что в данной секции находятся данные, он, опять же, не обязателен. В принципе можно создавать любое количество секций(даже с одинаковыми именами) и класть код и данные в любые из них, главное, чтобы то, что предназначено для исполнения находилось в исполняемой памяти, а то, что для записи находилось в памяти доступной для записи.

В секции данных находится загадочная строка dd ?, сейчас расскажу, что она означает.

Для объявления данных существует ряд директив, изображённых в следующей таблице:

Чтобы объявить данные размером в байт нужно написать db <значение>, например для объявления байта со значением 0xAB служит строчка db 0xAB, остальные директивы предназначены для объявления данных большего размера. Если вместо значения после директивы стоит “?”, это означает, что вам безразлично, какое там будет значение. Следует так-же отметить, что директива dt не предполагает указания целых чисел, а предполагает числа с плавающей точкой. С помощью этих директив можно объявить несколько блоков данных подряд, например: db 12o,10,? объявляет 3 байта подряд: сначала со значением 12(в восьмеричной системе счисления), далее 10, далее – безразлично. Строка dd 32167,12 объявляет 2 двойных слова со значениями 32167 и 12 соответственно. Чтобы заполнить участок памяти одним значением используется слово “dup”, например строка dd 12 dup (10) объявляет 12 двойных слов со значением 10, строка dd 5 dup (3,6) объявляет 5 пар двойных слов со значениями 3 и 6 соответственно.

Что касается директив db и du, они в качестве значения могут принимать строки (в кавычках), например: строка db 'Hello world!',0 объявляет строку в формате ANSI с нулём на конце, а du 'Hello world!',0 объявляет такую-же строку только в формате юникод (UTF-16).

Директива file принимает в качестве значения имя файла (file <имя файла>), после компиляции в этом месте программы будет находиться содержимое файла <имя файла>. Чтобы в коде можно было обращаться к определённым данным нужно дать им какое-нибудь имя. Данные с именем мы будем называть переменными. Имя может состоять из латинских букв, цифр и знака подчёркивания (хотя буквы могут быть не только латинские, но и любые другие, но я настоятельно не рекомендую их использовать). Имя пишется перед директивой объявления данных, например так: qwe dd 32167, в данном случае мы объявили переменную с именем “qwe”, размером 4 байта, у которой начальное значение равно 32167.

Перед тем, как подходить к писанию кода необходимо обсудить регистры. Всего есть 16 регистров общего назначения (вообще регистров больше, но общего назначения – 16). Имена 8-и из них: rax,rcx,rdx,rbx,rsp,rbp,rsi,rdi, все остальные называются r8-r15, нижние 32 бита регистров называются: eax,ecx,edx,ebx,esp,ebp,esi,edi, остальные r8d-r15d. Нижние 16 бит называются ax,cx,dx,bx,sp,bp,si,di, остальные r8w-r15w. Нижние 8 бит называются al,cl,dl,bl,spl,bpl,sil,dil, остальные r8b-r15b. Так же можно обращаться верхним 8-и битам нижних 16 бит первых 4-х регистров по именам: ah,ch,dh,bh. Так же есть регстр – указатель инструкций rip, и регистр флагов rflags. rip всегда указывает на следующую инструкцию (которая идёт после той, которая выполняется), регистры изображены на рис. 2

Если вы скомпилируете программу приведённую выше, то обнаружите при запуске, что она ничего не делает, потому что она действительно ничего не делает! Выше я говорил про точку входа, она начиналась со строки proc start, и закончилась на endp, что представляют собой эти макросы (proc и endp), я пока говорить не буду, скажу лишь что объявив таким образом процедуру к ней можно обращаться из любого места программы. Внутри процедуры “start” трижды написана команда “nop”, так вот:

nop — команда, которая ничего не делает.

Далее я хотел бы ввести ещё одну команду:

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

Попробуйте добавить int3 перед 3-мя nop-ами в приведённой в статье программе, скомпилируйте и откройте отладчиком, вы увидите что-то вроде того, что изображено на рис. 3.

Это — точка останова внутри системного кода. Продолжите выполнение программы (в WinDbg — F5), после чего вы увидите в окне дизассемблера что-то вроде этого:

“push rbp\mov rbp,rsp” и “leave\ret” — это пролог и эпилог процедуры соответственно, позже я объясню, что это и зачем.

Нажмите несколько раз “step over” (в WinDbg – F10) или “step into” (в WinDbg – F8) и вы увидите как отладчик переходит от одной инструкции к другой.

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

В оставшемся окне “memory” — 3 колонки: адрес, значения байтов (шестнадцатеричные) по данному адресу и символы ANSI, соответствующие данным значениям байтов (ANSI — как раз однобайтовая кодировка). Можете попереключать поле “display format” и посмотреть, разные форматы отображения данных. Поле “Virtual” показывает, с какого адреса начать отображение памяти, адрес может включать и регистры, числа в этом поле считаются шестнадцатеричными.

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

Метка — это символьное имя (идентификатор) позволяющий обращаться к данной области программы.

Чтобы поставить метку в коде нужно написать её имя и поставить двоеточие, например:

В прошлой статье я показывал, как можно объявлять переменные, например: Variable dd ? Так вот, имя переменной — тоже метка, оно отличается от метки поставленной с помощью двоеточия тем, что оно предполагает, что данные, на которые она указывает будут интерпретированы как данные соответствующего размера. Так же имя метки может начинаться с точки, такая метка называется локальной. При ассемблировании к имени локальной метки добавляется слева имя ближайшей сверху нелокальной метки, например:

В данном примере полное имя метки .locLbl — “Lbl.locLbl”, любая ссылка из кода 2 и 3 на метку по имени “.locLbl”, на самом деле ссылается на “Lbl.locLbl”. Если же попытаться сослаться на эту метку из кода 1 по имени “.locLbl”, fasm будет искать метку с полным именем “start.locLbl”, не найдёт её и сообщит об ошибке. Чтобы сослаться на метку “.locLbl” из кода 1 нужно писать полное имя метки: “Lbl.locLbl”.

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

Первая инструкция, которую я бы хотел обсудить называется mov. У этой инструкции два явных операнда (операнд — это то, что подаётся на вход инструкции, явный операнд — это операнд, который вы указываете в коде). В качестве операндов у этой инструкции может выступать константа, память или регистр. Записывается как mov <op1>,<op2>, эта команда копирует данные из <op2> в <op1>,сразу замечу, что <op1> не может быть константой (не только для “mov”) и вообще большинство (не все) инструкций с двумя явными операндами кладут результат в первый операнд, рассмотрим пример:

mov rax,0x32167

данная инструкция записывает число 0×32167 в регистр rax, посмотрите в отладчике, как при исполнении этой инструкции значение в регистре rax меняется на 0×32167. Можно вместо rax поставить любой регистр, главное, чтобы количество двоичных разрядов константы справа было меньше либо равно количеству разрядов в регистре, например конструкция mov al,0x1FF приведёт к ошибке, т.к. в числе 0×1FF больше восьми бит. Стоит также обратить внимание на то, что запись в регистр размера одного байта или слова не влияет на остальную часть регистра, но если вы пишете в регистр размером в 32 бита, то верхняя часть соответствующего 64-битного регистра обнуляется. Поэкспериментируйте, а потом двигайтесь дальше.

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

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

Когда ссылаются на память, адрес заключают в квадратные скобки: []. Адрес может выглядеть следующим образом:

1. [reg1+reg2*2^n +offs32]

2. [rip+offs32]

3. [offs64]

В первом случае reg1 и reg2 — регистры общего назначения, n может принимать значения от 0 до 3, offs32 — 32-битное число со знаком. Во втором случае offs32 — тоже 32-битное со знаком, прибавляется к регистру rip, замечу, что если вы сошлётесь на глобальную переменную в своём коде по имени, то fasm закодирует адрес именно таким способом. Третий случай есть не для всех инструкций и подразумевает ссылку на память по непосредственному адресу, так можно закодировать например инструкции:

mov al,[mem]

mov ax,[mem]

mov eax,[mem]

mov rax,[mem]

mov [mem],al

mov [mem],ax

mov [mem],eax

mov [mem],rax

Правда почему-то fasm отказывается ассемблировать эти инструкции с 3-м типом адреса, в документации они есть. И последнее на счёт адреса, у каждой инструкции может быть не более одного явного операнда, ссылающегося на память.

Рассмотрим простой пример:

В этом примере значение Variable2 копируется в Variable1. Чтобы посмотреть в отладчике значения Variable1 и Variable2 скопируйте адрес из инструкции mov в дизассемблере в поле “Virtual” окна “memory” и поставьте “display format” в “long hex”.

Далее я бы хотел рассмотреть пять инструкций общего назначения, которые так же имеют 2 явных операнда, все они записывают результат в <op1>:

add <op1>,<op2> — складывает <op1> и <op2>, если результат не вмещается в <op1>, тогда старшие биты отбрасываются

and <op1>,<op2> — применяет к каждому биту операцию логическое “и”

or <op1>,<op2> — применяет к каждому биту операцию логическое “или”

sub <op1>,<op2> — вычетает из <op1> <op2>, отрицательный результат записывается в дополнительном коде

xor <op1>,<op2> — применяет к каждому биту логическое “исключающее или”

Кроме них так же полезны инструкции:

xchg <op1>,<op2> — меняет местами значения <op1> и <op2>

lea reg,[memory] — считает адрес [memory] и записывает его значение в регистр reg, обратите внимание, что данная команда не выполняет реального обращения к памяти, а просто считает адрес

not <op1> — применяет логическое “не” к <op1>

Ну, и последняя инструкция о которой я расскажу в этой статье — это nop <op1> операндом этой инструкции может быть либо регистр, либо память, она ничего не делает и в случае если операнд — память обращения к данной памяти не происходит.

Попробуйте использовать эти инструкции и посмотрите в отладчике, к каким результатам приводит их исполнение.

На этом пока всё.

Из приведённых в предыдущей статье инструкций на флаги влияют: add, and, or, sub, xor. Инструкции mov, xchg, lea не влияют на флаги. Я приведу ещё несколько инструкций влияющих на флаги:

inc <op1> — увеличивает op1 на единицу, операндом может быть как регистр, так и память.

dec <op1> — уменьшает на единицу op1, аналогично inc.

cmp <op1>,<op2> — сравнивает op1 и op2, по факту просто вычитает из op1 op2, выставляет флаги, а результат вычитания никуда не записывает.

test <op1>,<op2> — аналог and, но не записывает никуда результат операции.

У вас наверно возникает разумный вопрос: “А зачем эти флаги нужны?”, ответ таков: “Для выполнения условных инструкций.” Условные инструкции — это инструкции результат выполнения которых зависит от некоторых флагов в регистре флагов.

Первыми условными инструкциями которые мы здесь рассмотрим будут условные прыжки. Сначала рассмотрим безусловный прыжок: jmp <метка>, в коде выглядит примерно так:

после выполнения данной инструкции продолжает исполняться не тот код, который идёт после jmp, а тот, который идёт после метки. Условные прыжки выполняются только если выполнено определённое условие, в противном случае выполняется код идущий сразу после инструкции прыжка. Записываются они следующим образом: j<условие> <метка> здесь я приведу некоторые из них:

jz или je — выполняются при ZF=1

jne или jnz — выполняются при ZF=0

ja — выполняется, если CF=0 и ZF=0

jb или jc — выполняются, если CF=1

jae или jnb — выполняются, если CF=0

jbe — если CF=1 или ZF=1

jl — SF<>OF

jnl — SF=OF

jle — ZF=1 или SF<>OF

jg — ZF=0 и SF=OF

Чтобы лучше понять их значения рассмотрим несколько примеров.

В данном случае прыжок не будет выполнен, т.к. при вычитании 4 из 3 нуля не будет, а соответственно ZF=0, в общем по-этому инструкция и называется je, т.е. jump equal, прыгнуть, если равно. Если в этом примере вместо je поставить jb или jl, то прыжок будет осуществлён, потому что эти мнемоники означают прыжок, если меньше. jb отличается от jl только тем, что jb подразумевает сравнение без знаковых чисел, а jl — знаковых. В связи с этим ещё один пример:

В данном случае прыжок будет выполнен, т.к. -3 меньше, чем 4, но если вы поставите там jb, то -3 надо интерпретировать как 0xFFFFFFFD, что больше 4-х, и поэтому прыжок не будет выполнен. Для прыжков приведённых выше:

jz или je — прыгнуть если равно

jne или jnz — прыгнуть если не равно

ja — прыгнуть если больше (без знака)

jb или jc — прыгнуть если меньше (без знака)

jae или jnb — прыгнуть если больше либо равно (без знака)

jbe — прыгнуть если меньше либо равно (без знака)

jl — прыгнуть если меньше (со знаком)

jnl — прыгнуть если не меньше (со знаком)

jle — прыгнуть если меньше либо равно (со знаком)

jg — прыгнуть если больше (со знаком)

С помощью прыжков можно написать аналог оператора “if” в языках высокого уровня:

В данном примере если eax=edx выполнится код 2, если нет, то код 1.

Так же с помощью прыжков можно организовать цикл:

Здесь код будет выполняться пока eax не равно нулю, инструкция dec eax уменьшает eax на единицу, поэтому код в цикле выполнится 10 раз, замечу, что инструкцию cmp eax,0 можно убрать т.к. инструкция dec eax выставит флаг нуля, когда eax станет равно нулю.

Для иллюстрации использования прыжков рассмотрим пример:

объявим в секции данных массив: Array dd 12,32,1,0,17

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

Программа:

Для того, чтобы использовать числа со знаком нужно вместо jbe .NotGreater поставить jle .NotGreater и вначале вместо нуля положить в eax -2147483648 (наименьший dword со знаком).

Ещё один пример, который я хотел рассмотреть, это — сортировка пузырьком, здесь я приведу пример программы сортирующей по возрастанию массив Arr dd 0x45,0x65,0x85,0x12,0x432,0x65,0x21,0x09,0x860,0x52,0x46, но было бы не плохо, если бы вы попытались написать программу самостоятельно, а потом смотрели бы мою реализацию. Алгоритм такой:

1. присваиваем переменной sorted значение истина (один)

2. для каждого I от нуля до (длины массива-2) делаем шаг 3

3. если I-ый элемент массива больше (I+1)-го, то меняем эти элементы местами и присваиваем переменной sorted значение ложь (ноль)

4. если sorted=ложь, то возвращаемся к пункту 1, если истина, то заканчиваем выполнение цикла.

На этом рассмотрение прыжков я хочу закончить.

Команда set<cond> принимает в качестве единственного операнда либо однобайтовый регистр, либо один байт в памяти. Если условие выполнено, она в этот байт записывает значение 1, если — нет, то 0. Например инструкция sete al запишет в регистр al значение 1, если установлен ZF, и 0, если не установлен.

Инструкция cmov<cond> имеет 2 операнда, первый приемник — только 16, 32 или 64 разрядный регистр, второй либо регистр, либо память такого же размера. Команда записывает в первый операнд значение второго, если условие выполнено, в противном случае – ничего не делает. Например инструкция cmovge eax,[variable] запишет значение [variable] в регистр eax, если флаг SF=OF, иначе не сделает ничего.

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

Данные команды предназначены для того, чтобы работать с целыми числами больше 64 бит. Команда adc действует аналогично add, но помимо этого прибавляет к результату значение флага CF. sbb аналогична sub, но вычетает из результата значение CF. Например для вычитания 128 битных чисел можно написать:

Для сложения вместо sub и sbb — add и adc.

На этом я хотел бы закончить статью.

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

Эта команда передаёт управление по указанному адресу как и jmp, но кроме этого она ещё кладёт в стек адрес возврата, т.е. адрес следующей за call команды.

Заканчивается процедура инструкцией retn или retn imm16, где imm16 обозначает 2-х байтовое целое непосредственное значение (т.е. не регистр и не память, а значение закодированное в инструкции). Эта инструкция достаёт из стека адрес возврата и передаёт на него управление, imm16 — это количество байт, которое будет вытащено из стека помимо адреса возврата, т.е. просто увеличится значение регистра rsp.

Кроме инструкции retn также есть инструкция retf, но мы не будем её рассматривать.

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

Сразу скажу, что обращаться к стеку можно только по адресам большим текущего значения rsp, так что не рекомендуется обращаться по адресам [rsp-xx]

Удобно для обращения к локальным переменным использоватьвторой другой регистр: rbp. Это будет выглядить примерно так:

Вместо связки команд mov rsp,rbp / pop rbp можно использовать команду leave, без явных операндов.

Обращаться к переменным по адресам [rbp-xx] не очень удобно, хотелось бы обращаться к ним по именам. Для этого нам нужны несколько макросов для использования которых мы подключаем win64a.inc .

Макросы следующие:

proc

endp

ret

locals

endl

Макрос proc объявляет начало процедуры, имя после этого макроса будет именем метки начала процедуры. Например если вы напишете proc SomeProc, то обращаться к ней следует так: call SomeProc. Макрос endp объявляет конец процедуры, для каждого объявления процедуры обязательно должен присутствовать endp. ret означает возврат из процедуры, т.е. там, где в процедуре вы поставите ret fasm поставит что-то вроде mov rsp,rbp / pop rbp / retn. Обратите внимание, что endp и ret — разные вещи: первый указывает конец процедуры, а второй — только возврат, их может быть несколько, рассмотрим пример:

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

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

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

К этому моменту мы научились объявлять процедуры и их локальные переменные с помощью макросов, но помимо этого процедуры могут принемать параметры и возвращать значения. Для этого существуют соглашения о вызове. Соглашение о вызове это — способ передачи параметров в функцию и возврата из неё знпчений. В принципе, на ассемблере, вы можете изобрести какие угодно соглашения о вызове, и их использовать, но для того, чтобы вызывать процедуры из чужого кода нужно заранее договориться о способе передачи параметров и возврате значений, для этого существуют стандартные соглашения о вызове. Если погуглить, то можно выяснить, что в 32-битном режиме есть ряд соглашений о вызове: stdcall, fastcall, cdecl, и т.д. В 64-битном режиме же принято одно соглашение о вызове и заключается оно в следующем:

1. Первые 4 параметра передаются через регистры, если это — указатели или целые числа то передаются они в следующем порядке:

1-rcx, 2-rdx, 3-r8, 4-r9. Если это — числа с плавающей точкой, то они передаются через регистры xmm0-xmm3 (о них я расскажу в последующих статьях).

При этом в стеке вызывающая функция выделяет место для хранения этих параметров.

2. Следующие параметры передаются через стек.

3. После выполнения процедуры стек очищает от переметров вызывающая функция.

4. Возвращаемое значение функция записывает в rax.

5. После вызова функции должны остаться неизменными регистры: r12-r15, rdi, rsi, rbx, rbp, остальные регистры общего назначения могут после вызова измениться.

Приведу пример вызова функции SomeFunc с 6 параметрами:

В ринципе так мы больше писать не будем, потому что существуют макросы fastcall и invoke, отличаются они тем, что если в fastcall стоит инструкция call Func, то в invoke стоит call [Func]. Только что приведённый код можно переписать в следующем виде:

Для того, чтобы внутри процедуры обращаться к параметрам по именам нужно перечислить их в макросе proc после имени процедуры, например:

К параметрам можно обращаться также, как к локальным переменным – по именам.ВАЖНО: В НАЧАЛЕ ИСПОЛНЕНИЯ ПРОЦЕДУРЫ В ПЕРВЫХ 4-Х ПАРАМЕТРАХ ЛЕЖИТ МУСОР, ОБРАЩАТЬСЯ К НИМ СЛЕДУЕТ ЧЕРЕЗ РЕГИСТРЫ! Приведу пример объявления процедуры с 2-мя параметрами, в следующем коде процедура “Reverse” переворачивает массив байтов заданной длины.

Скажу ещё пару слов о выделении памяти в стеке и передаче параметров.

Если вы взгланите на код процедуры start (см. Рис.1), то увидите, что для вызова процедур постоянно выделяется и освобождается память в стеке (выделено красным), чтобы это оптимизировать нужно вызывать макросы frame и endf в начале и в конце процедуры соответственно, при их использовани память выделяется в начале процедуры и освобождается в конце, пример:

Из всего выше описанного очевидно, что использование регистра rbp не обязательно, и это можно исправить, достаточно в программе вставить следующие строки:

Они заставят использовать вместо rbp только rsp, и rbp тогда можно использовать в своих целях. ОБРАТИТЕ ВНИМАНИЕ:

1. ИСПОЛЬЗОВАТЬ ТЛЬКО RSP БУДУТ ПРОЦЕДУРЫ СТОЯЩИЕ ПОСЛЕ ЭТИХ СТРОК

2. В ЭТОМ РЕЖИМЕ НЕ НУЖНО ИСПОЛЬЗОВАТЬ frame и endf

Чтобы Вернуть обратно rbp нужно вставить строки:

На этом — всё.

Шаг первый ― уменьшение размера выравнивания сегментов У программы link.exe есть ключ /ALIGN:размер Ключ /ALIGN[MENT] указывает компоновщику на необходимость выравнивания сегментов в исполняемом файле на границу, кратную значению размер. Размер ― это число равное двум возведенное в целую степень (20=1, 21=2, 22=4, 23=8, ... до 216=65536 включительно). Если об этом ключе не упоминать, то выравнивание равно 29=512 байт. Посмотреть значение выравнивания можно при помощи редактора бинарных файлов hiew32 в заголовке программы в поле «File alignment» (Открываем наш exe программой hiew32, нажимаем F4 (Mode) и выбираем Hex, нажимаем F8 (Header) в поле «File alignment» видим число 200 hex=512 dec).

Кроме ключа /ALIGN добавим в файл makeit.bat еще некоторые ключи компиляции и линковки, которые позволят нам уменьшить количество служебной информации в asm-файлах.

• Добавление ключа компиляции /Cp ― «сохранить регистр символов во всех идентификаторах» позволяет не писать каждый раз в тексте ассемблерного файла «option casemap:none».

• Добавление ключа компиляции /I:путь ― «установить путь для включаемых файлов» позволяет нам не указывать каждый раз полный путь к inc-файлам.

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

Так выглядит содержимое файла makeit.bat до изменений:

а так после:

Содержимое файла tut_02a.asm после изменений

при компиляции получаем сообщение

размер файла tut_02a.exe меняется с 2560 на 1536 байт и, не смотря, на предупреждение image may not run файл tut_02a.exe благополучно запускается

Продолжаем эксперимент, изменяя значение /ALIGN:размер, и наблюдаем за уменьшением размера файла tut_02a.exe:

похоже, что в этом направлении мы достигли предела и от исходной программы в 2560 байт пришли к программе размером в 880 байт, но согласитесь, что и это не так уж плохо!

Шаг второй ― объединяем сегмент кода и сегмент данных

Наша прграмма использует два сегмента, сегмент кода и сегмент данных, посмотрите внимательно через hiew32 ― между этими сегментами прослойка из нулей, от которых мы и пытаемся избавится. А помните во времена DOS'а можно было создавать COM-файлы, которые в единственном сегменте содержал и код, и стек, и данные? А нельзя ли и здесь создать, что-то подобное?

Оказывается можно ― при помощи ключа /SECTION можно присвоить секции кода с атрибутами «выполнять» и «читать» атрибуты секции данных «читать» и «писать».

Вносим изменения в текст программы

изменения в файле makeit.bat

Опция командной строки компоновщика link.exe /SECTION:name,[[!]{DEKPRSW}][,ALIGN=#] позволяет принудительно назначать атрибуты секциям PE-файла. Для секции можно задать один или несколько атрибутов. Следует задавать все атрибуты, которые должна иметь секция; если какой-либо знак атрибута не указан, то его бит будет отключен. Если не указан атрибут R, W или E, то существующее состояние чтения, записи или исполнения остается неизмененным. Чтобы инвертировать атрибут, перед его символом указывают знак «!». С помощью параметра ALIGN=# можно задать значение выравнивания для конкретной секции. Значения знаков атрибутов приведены в следующей таблице.

В данном случае секции с именем «.text» (содержащей код программы) и уже имеющей атрибуты R (доступна для чтения) и E (исполнимая), устанавливается атрибут W (доступна для записи)

В результате получаем tut_02a.exe размером 848 байт.

Шаг третий ― алгоритмическая оптимизация

При старте нашего приложения в x64dbg видно, что на вершине стека лежит адрес функции kernel32.RtlExitUserThread , а именно ее вызывает функция ExitProcess для завершения приложения, поэтому возникает вопрос, а необходим ли нам в этой программе вызов функции ExitProcess? Заменяем вызов ExitProcess на команду retn , которая извлечет из стека адрес функции RtlExitUserThread и передаст на нее управление.

Шаг четвертый ― «хирургический» ― ампутируем у файла «хвост».

hiew32 показывает, что в хвосте нашего файла, сразу за строкой «user32.dll» целых шестнадцать байт содержащих нули.

А не удалить ли их нам вручную? Сказано ― сделано! В far'е нажимаем F4 (открываем файл на редактирование), нажимем Ctrl+End и переходим в конец файла. Далее, нажимая на Backspace, удаляем лишнее, жмем на F2 и сохраняем изменения в файле, нажимаем на F10 и выходим из файла ― размер tut_02a.exe стал 748 байт. Нажимаем на него и запускаем tut_02a.exe ― запускается нормально! Стоп-стоп! 768-748=20 байт, а должно быть 16! Смотрим в hiew32 ― о, боже!, мы отрезали вместе с нулями от «user32.dll» кусок «.dll», но файл-то всё равно работает! Запомним на будущее, что от DLL достаточно только названия, а точку и расширение файла система подставит сама.

Шаг пятый ― очередная алгоритмическая оптимизация

Как устроен вызов функции в Win64? Сначала формируется стековый кадр (stack frame), то есть, область памяти в стеке, через которую передаются аргументы и другие "опции", затем устанавливаются аргументы и вызывается инструкция call.

Win64 ABI требует, чтобы стековый кадр был выравнен на 16 байт. Это ключевой момент, от которого следует отталкиваться во всех последующих рассуждениях.

При входе в любую функцию значение регистра RSP не кратно 16, оно смещено на 8 байт адресом возврата, который "положила" в стек инструкция call. Если поставить точку останова на любую 64-битную функцию, то при входе в нее можно увидеть, что значение RSP всегда заканчивается на 8. Вот поэтому пролог функции в Win64 делает что-нибудь в стиле "sub rsp, 28h" ― это и есть выравнивание стека на 16. Именно так, как пишут авторы многочисленных книг, то есть, до вызова других функций и до формирования стековых кадров для них.

Но это еще не все. Все тот же Win64 ABI требует, чтобы на время вызова в стеке было зарезервировано 32 байта под нужды вызываемой функции. Эта область в разных источниках называется по-разному: "register space", "home area" и так далее. Предполагалось, что в этой памяти вызываемая функция сможет временно хранить значения регистров RCX, RDX, R8 и R9. Но нужен ли "home area" для функции MessageBox?

Меняем sub rsp,28h на sub rsp,18h и add rsp,28h на add rsp,18h (соблюдаем условие кратности 16 содержимого RSP), компилируем, линкуем, запускаем на выполнение. Программа работает и нормально завершается.

Меняем sub rsp,18h на sub rsp,8 и add rsp,18h на add rsp,8 компилируем, линкуем, запускаем на выполнение. Программа работает и нормально завершается.

Эквивалент sub rsp,8 ― команда push reg , какой из регистров при этом мы будем использовать не важно, главное, что размер команды всего один байт! Эквивалент add rsp,8 ― команда pop reg. Компилируем, линкуем, запускаем на выполнение. Программа работает и нормально завершается.

Шаг шестой ― уменьшаем DOS-stub.

Код нашей программы начинается с 220h=544-го байта. Всё, что выше ― это заголовок нашего EXE-файла ― вот бы его уменьшить! Заголовок нашего файла состоит из двух частей. От строки «MZ» до строки «PE» заголовок DOS (0C8h=200 байт) и от строки «PE» до 220h=544-го байта PE-заголовок (344 байт). Адрес строки «PE» содержится в DOS-заголовке в двойном слове по смещению 3Ch.

Начнем с уменьшения DOS-стаба. Возьмем hiew32.exe и создадим с его помощью вот такой файл

Присвоим ему имя stubby.exe, сохраним в папке bin и будем использовать в качестве stub-программы. В очередной раз внесем изменения в файл makeit.bat.

Шаг седьмой ― используем ключи /LARGEADDRESSAWARE , /BASE:адрес и 32-разрядную адресацию

Приложение, работающее в Win64 может работать с адресами размер которых свыше 2 гигабайта. В 64-разрядных компиляторах для этого используется параметр /LARGEADDRESSAWARE В 32-разрядных компиляторах включен параметр /LARGEADDRESSAWARE:NO Параметр /BASE задает базовый адрес программы, переопределяя заданное по умолчанию расположение EXE-файла (для 32-разрядных Win = 0x400000, для 64-разрядных 0x140000000) или DLL-файла (для 32-разрядных = 0x10000000). Сначала операционная система пытается загрузить программу по указанному или используемому по умолчанию базовому адресу. Если по этому адресу недостаточно места, то система перемещает программу в памяти. Для предотвращения перемещения используется параметр /FIXED.

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

Вносим изменения в файл makeit.bat

Вносим изменения в asm-файл

Вносим изменения в asm-файл

Шаг восьмой ― сократим размеры заголовка и импорта

Так как код программы и данные нам сократить не удастся ― поэтому сократим размеры заголовка и импорта PE-файла. Нам потребуется создать bin-файл, заголовок которого мы напишем самостоятельно. Для этого требуются ассемблеры, которые могут создавать бинарные файлы (NASM, FASM). За основу бинарного файла возьмем содержимое предыдущего tut_02a.exe размером 688 байта

сократим DOS-stub до 64 байт, уменьшеним таблицу разделов, по умолчанию количество разделов должно быть равным 16, нам же требуется только секция импорта. В таблице разделов секция импорта идет сразу после секции экспорта.

Что можно сократить в секции импорта? Секция импорта содержит две одинаковые таблицы (Import LookUp Table и Import Address Table), содержащие ссылки на названия импортируемых функций. Можно ли обойтись только таблицей Import Address Table? Удаляем Import LookUp Table и обнуляем ссылки на user32_table2

и как в четвертом шаге удаляем 16 нулевых байтов в конце файла и окончание ".dll".

сокращаем DOS-stub на 16 байтов (3Ah-2Eh-4=10h), смещение e_lfanew оказывается внутри PE-заголовка. Так как у программы со стабом короче 64 байт смещение от начала файла 3Ch (поле e_lfanew) попадает уже внутрь PE-заголовка, то нужно, чтобы он не попал на поле PE-заголовка имеющее критическое значение при загрузке файла. Помещаем указатель на ntHeader в поле Symbol_table_offset. При размещении в нем числа 30h получаем работоспособное приложение.

сокращаем DOS-stub еще на 16 байтов (2Eh-1Eh=10h), смещение e_lfanew оказывается в поле Size_of_code. По одним источникам ― это поле используется для первичного отведения памяти под приложение. По другим ― не используются вообще. Если поместить туда число 20h, то практическая проверка показывает, что приложение с таким stub'ом работает нормально.

сокращаем DOS-stub до 16 байт, смещение e_lfanew оказывается в поле base_of_code. При размещении в нем числа 10h получаем работоспособное приложение.

В начале секции импорта убрали байты для выравнивания.

Мы удалили таблицу, которую используют для импорта по ординалам. Внимание, вопрос ― А зачем нам в таком случае ординалы перед названием функций? Обнуляем ординалы и задаем себе следующий вопрос ― Если ординал нулевой ― нужен ли нулевой байт на конце строки? Удаляем нуль-терминаторы, а заодно и нулевые байты, которые делали адреса названий функции кратными двум, так как импортируемые функции теперь у нас заканчиваются двумя нулевыми байтами (а это расточительно!) ― помещаем в поле ординала последний символ названия функции или названия dll и нуль-терминатор

количество секций делаем равным 0, удаляем секцию '.rdata' и '.text', размещаем импорт в секции кода.

уменьшаем DOS-stub до 4 байт. смещение e_lfanew оказывается в поле file aligment. section aligment=file aligment=4 уменьшение импорта

Так путем нехитрых преобразований можно на порядок уменьшить размер ехе-файла с 2560 байт до 298 байт

* * *

© Mikl___ 2016