Delphi *

Выкладываю данную инструкцию, т.к. самому пришлось искать необходимую информацию по крупинкам. Инструкция рассчитана на людей, имеющих мало опыта в web технологиях и web разработке. Все программные комплексы настроены на выделенном под программистские нужды «сервере» под управлением Windows 7 Pro 32 bit.
Что имеем:

• Visual SVN Server 2.6.0 (Apache Subversion 1.8.0 + Apache HTTP Server 2.2.25)
• доступ к SVN уже настроен через ssl на порт 8443
• Jira 6.0 с установленным плагином JIRA Subversion plugin
• осуществлена базовая настройка JIRA Subversion plugin (в задачах отображаются соответствующие коммиты со списками файлов)
• на SVN хранятся в том числе исходные коды, написанные на Delphi 7 с кодировкой CP1251

Что хотим получить:

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

Привет хабровцы.
Я думаю не только у меня большой плейлист на vk.com. Совсем недавно я озадачился тем, как бы выкачать музыку, чтобы слушать её оффлайн. Вскоре я нашел удобный сервис SaveFrom.net. И все бы ничего, да только выкачивать сразу всю музыку он не умеет. Он предлагает нам варинаты:
1. Дать нам кучу url, чтобы мы вставили все это дело в менеджер загрузок, типа DownloadManager
2. Сохранить плейлист в m3u/pls, которые играют по урл

В первом случае у нас имена файлов будут вида 3ee56ab0933e.mp3. ID3 tag будет на месте (UPD оказывается не для всех композиций есть корректный ID3Tag), но согласитесь, это неудобно, открывать каждую композицию чтобы посмотреть что это
Во втором случае — у нас чисто url-ы в плейлистах, но зато title песни есть сразу.

Поскольку наблюдать файлы вида 3ee56ab0933e.mp3 мне не хотелось, а так же не хотелось вручную все это именовать — я набросал на коленке тулзу, которая умеет читать pls плейлисты, и скачивать музыку в 10 коннектов.

Бинарник + исходник

Откомпилированный экзешник + исходный код (на Delphi) лежит тут

Нам часто задают вопросы, а есть ли реальные проекты, реализованные на FireMonkey. Поговорим об этом с Артёмом Бойковым. Он использует Delphi, а сегодня расскажет о своих проектах на FireMonkey.
Артем Бойков – индивидуальный разработчик, сайт его компании www.oilsoft-service.com. Специализируется на разработке ПО под заказчика, также есть проекты для широкого круга пользователей.



Embarcadero: Мы знаем, что ты недавно выпустил первые свои коммерческие проекты, сделанные в Delphi и FireMonkey. Расскажи, что это за проекты.

Артём: первый проект – это приложение по настройке забойной телесистемы (ЗТС) применяемой во время бурения нефтяных скважин. Прибор подключается по USB к программе и осуществляет его настройку. Второй – система для администрирования базы отдыха. Позволяет резервировать домики и наглядно отображать размещение клиентов. Более подробная информация на сайте.

E: А ты работаешь в команде? Или ты – индивидуальный разработчик?

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

E: Какой у тебя вообще опыт использования Delphi?

А: Программированием увлекся еще с детства. Примерно в пятом классе родители купили компьютер «Дельта-с». Многие наверно помнят, что это за аппараты, когда программы писались на магнитную ленту. Там был реализован Basic. Он мне нравился. Я все мечтал сделать на нем 3D-изображение с вращением. Я только познавал мир программирования. Я с детства мечтал быть программистом. Когда поступил в институт на программиста, столкнулся первый раз с Pascal. После непродолжительного изучения я начал осознавать, что Delphi — очень удобен и понятен.

Начал сравнивать его с С++. Да простят меня «Сишники», этот язык показался мне слишком синтезированным и сложным в изучении. Дипломный проект был написан на Delphi. В 2006 примерно я перешел на должность программиста, до этого был геологом и геофизиком. А потом подумал что на этом можно зарабатывать и неплохие деньги. После чего открыл свое дело.

Всем привет!
Сегодня я расcкажу вам о своем опыте написания ORM для Delphi с использованием RTTI под влиянием практик работы с Doctrine и Java EE.

Зачем?

Под мою власть недавно попал старый проект на Delphi7 в котором ведется активная работа с базой данных под Interbase 2009. Код в этом проекте радовал, но ровно до тех пор, пока речь не заходила о самом взаимодействии с бд. Выборка данных, обновление, внесение новых записей, удаление — все это занимало немало строк в логике приложения, отчего разобраться в коде порой становилось довольно сложно (спасение в добросовестном разработчике, который круглосуточно отвечал на мои глупые вопросы). В мои руки проект был передан с целью устранения старых бед и добавления в него нового модуля, задача которого — покрыть новые таблицы БД.

Мне нравится MVC подход и очень хотелось разделить код логики с кодом модели. Да и если уж на чистоту — я не захотел для каждой новой таблицы переписывать по новой все get/set методы. Пару лет назад я познакомился с понятием ORM и мне это понравилось. Мне понравился принцип и я был в восторге, применяя его в своей работе.
В тот же момент я ринулся искать в Delphi7 хоть что-нибудь похожее на Doctrine или может генераторы Entity/Facade классов для таблиц… Ни того ни другого. Зато в поисковой выдаче нашлось несколько готовых решений. Например DORM. В целом, отличная штука и, по сути, то что нужно!

Уважаемые разработчики!

Совсем недавно мы проводили запуск RAD Studio XE4 в Москве, Минске и Киеве.

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

Посмотреть запись всех докладов можно здесь:

1 часть — youtu.be/S-qeJIFTupw — Кирилл Раннев, Стратегия компании Embarcadero и вступительное слово

2 часть — youtu.be/LTTAYAMhojQ — Всеволод Леонов, Разработка мобильных и настольных приложений на основе единой базы исходных кодов

3 часть youtu.be/ICjxcU8unHE — Ярослав Бровин, Использование FireMonkey для разработки приложений под iOS

4 часть youtu.be/hnlNvJvx-NM — Кирилл Раннев — Редакции продуктов и способы лицензирование

Привет, Хабр! Вдохновившись последними достижениями в области прикладного ИИ и личных помощников (Siri, Google Now и им подобные), я решил написать под себя помощника, пусть и не такого продвинутого как коммерческие аналоги, зато со своим блекджеком и своей изюминкой.

Зачем это нужно?

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

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

В данной мини-статье я рассмотрю одну из таких «хотелок».

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



Не красиво, почему это второй элемент с именем «101» находится не на своем месте? Ведь это число, а стало быть место ему как минимум после элемента с именем «2». Да и «New Folder (101)» явно должна быть после «New Folder (2)». Ведь в проводнике все выглядит нормально.



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

Буквально на днях ко мне обратились с вопросом.

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

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

В принципе предпосылка интересная, но…

В чем прелесть высокоуровневых языков программирования?
Программист перестает задумываться о том «как оно на самом деле фунциклирует» и выдает на гора тонну не сопровождаемого кода, который иногда даже работает, но периодически подтормаживает. Более того, частенько, он даже не собирается об этом задумываться, так как у него банально отсутствуют необходимые знания (увы, так сейчас учат).

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

А потом, выполнив очередной умный «паттерн» он начинает разбираться — где же тормозит алгоритм. Причем, если программист более настырен, он изучает реализацию VCL и иногда даже докапывается до сути, где получается так, что тормоза упираются в вызовы известных ему по документации API, пройдя к которым он со спокойной душой останавливается и закрывает тикет в багтрекере фразой: «функция ХХХ тормозит, вариантов обхода нет».

Не встречались с ситуацией?
Значит повезло…

В прошлой статье я рассмотрел пять вариантов перехвата функций включая их вариации.

Правда в ней я оставил не рассмотренными две неприятных ситуации:
1. Вызов перехваченной функции в тот момент, когда ловушка снята.
2. Одновременный вызов перехваченной функции из двух разных нитей.

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

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

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

Перехват сплайсингом через JMP NEAR OFFSET или PUSH ADDR + RET (наиболее уязвимый к данным ошибкам) рассмотрен не будет, т.к. по хорошему, без реализации дизассемблера длин, заставить данный вариант перехвата работать как нужно не получится.

Уважаемые разработчики!

Для тех, кто не сможет посетить запуск RAD Studio XE4 в Москве, Минске или Киеве, мы предлагаем присоединиться к прямой трансляции, которая начнется 23 мая в 10 утра.

Смотреть трансляцию можно прямо с сайта мероприятия softwarepeople.ru/delphixe4.

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

Как вы, наверное, уже догадались, основной темой запуска XE4 станет кроссплатформенная разработка и, к уже привычной Windows, мы добавили MAC OS и iOS – самую монетизируемую платформу. Мы также будем обсуждать планы развития RAD Studio.

Кроме того, вы увидите много демонстраций по созданию приложений для iOS и MAC OS.

Не пропустите!

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

О чем данная статья:

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

Как это работает:

Есть два основных пути добавления данного функционала в Windows приложение.
Первый способ заключается в использовании стандартных Windows Drag-and-Drop API функций и обработке сопутствующих оконных сообщений.
Вторым методом является использование технологии OLE (COM), который предоставляет расширенные методы передачи данных между приложениями.
В данной статье будет рассмотрен первый и самый простой способ.

Краткий обзор:

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

Монитор. Отличное слово, правда, объединяющее в себе целую кучу понятий. Ну например впервые данное слово было применено в 1861 году к броненосцу «USS Monitor». Чуть позже данным словом стали называть дисплеи. Еще через некоторое в славную когорту мониторов вошли более привычные нам вещи, наподобие счетчиков производительности, а вместе с ними целая куча разнообразного ПО, основной задачей которого является наблюдение — то есть мониторинг.

Задача монитора проста — по сути он наблюдатель, хотя может выступать и в качестве управляющего, кстати один из вариантов перевода «Monitor» — наставник. Задачи его так же очевидны, отдавать набор данных, на основе которых можно произвести анализ ситуации и сделать соответствующие выводы.

В современном ПО мониторы встречаются практически повсеместно, ну для примера тот же Punto Switcher — классический пример легального монитора. Практически все антивирусы являются мониторами, профилировщики, ну и я уж не говорю об основном нашем инструментарии — отладчике, который так же является монитором.

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

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

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

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

Привет всем.

Начну с того, что на днях пришла рассылка по Delphi и RAD Studio XE4, в которой Delphi декларируется как мультиплатформенное средство для быстрой разработки для компьютеров, ноутбуков, планшетов и мобильных устройств, включая MAC, iPhone, iPAD, также у Embarcadero есть планы сделать поддержку мобильной платформы Android.

Delphi и FreePascal — это Паскаль сегодня. Один из моих любимейших языков программирования. Язык прошёл долгий путь от “игрушки для учёных” до мощнейшего универсального средства разработки, на котором сделаны великолепные проекты, например, Total Commander.

Построенное на здравых решениях, ядро языка Паскаль легко поддалось усовершенствованию и умощнению и пригодно для широчайшего класса практических задач. В России Delphi особенно популярен и всё ещё широко используется. Однако развитие языка идёт по принципу наращивания возможностей, и постепенно Delphi становится всё более громоздким, догоняя по сложности таких монстров как PL/1, C++ и Ada. С большой вероятностью мы можем предположить, что проще язык становиться не будет, ибо нужно поддерживать совместимость с накопившейся базой исходников и т.д. В конце концов такая стратегия развития неизбежно приведёт к трудностям, когда сложность уже невозможно будет контролировать.

В то же время есть язык программирования, получившийся за несколько десятилетий практического преподавания и решения различных задач путём методического и последовательного уточнения Паскаля. Это Оберон — самый красивый из всех минималистичных языков, о котором мало кто слышал. Я смело утверждаю: Паскаль сегодня — это не только Дельфи (полученный методом наращивания), но и Оберон-2 / Компонентный Паскаль (полученные методом отбрасывания, пересмотра и уточнения целесообразности тех или иных средств). Благодаря тому, что над автором языка не довлела необходимость совместимости, он особенно на эту тему и не парился. И получившийся в итоге язык — цельный, компактный, мощный, кроссплатформенный в широком смысле (включая не только современные платформы, но и Amiga, и даже Atari). На Компонентном Паскале я успешно разработал мидлет для Java micro edition, не предвижу трудностей и в разработке для Android. Кроме одной: отсутствие инфраструктуры, да и вообще о таком использовании Оберонов мало кто знает.

Оберон-2 и Компонентный Паскаль — мультипарадигменные языки для системного и прикладного программирования, они модульные, компонентные и объектно-ориентированные. Разработанные на диалектах Оберона операционные системы, компиляторы и другие программы — часто сами по себе произведения искусства. Они красивы, неординарны, компактны и достойны всяческих похвал. Оберон популярен в академической среде как способ записи алгоритмов (пришёл на смену Фортрану) и как минимальный язык для исследований (посмотрите, например, сколько вышло публикаций по Оберону на сайте издательства SpringerLink). Он идеально подходит для обучения программированию. В России есть проект Информатика-21, популяризующий применение Оберона для подготовки будущих программистов, ибо, помимо своих технических достоинств, Оберон даёт хорошее понимание технологий программирования и не зависит от коммерческих интересов крупных корпораций. Посмотрите чего наваяла моя малолетняя племянница после недели разговоров со мной о программировании. Благодаря простоте языка энтузиасты разработали много компиляторов Оберон-диалектов для различных платформ.

Вирт всегда считал правильным конструировать процессоры под языки, а не наоборот. Но, несмотря на это, Оберон-программы хорошо конвертируются в Си, Java, работают как на нативе, так и на .NET/JVM. Разрабатывается компилятор GPCP для LLVM. Мне принадлежит идея ZXDev — среды разработки на Обероне-2 для восьмибитного процессора Z80 и компьютера ZX Spectrum. Самая новая ревизия виртовского Оберона называется Oberon-07. Он ещё меньше по размеру, чем Оберон-2, и адаптирован для ARM-процессоров и архитектур большой разрядности. Вот такое направление развития Паскаля. Малоизвестное широким массам программистов, но красивое как произведение искусства. Уже более семи лет я активно применяю Оберон-технологии с пользой для своей деятельности, и программировать на чём-то другом уже мало хочется.

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

Задавшись в свое время вопросом: «как определить наличие физического ключа?», мне пришлось немного поштудировать великолепно поданный материал за авторством Павла Агурова в книге "Интерфейс USB. Практика использования и программирования". После чего потратить время на анализ вызовов API функций из трехмегабайтного объектника, линкуемого к приложению, в котором собственно и сокрыта вся «магия» работы с ключом.

В итоге появилось достаточно простое решение данной проблемы не требующее использования оригинальных Guardant API.
Единственный минус — все это жутко недокументированно и техническая поддержка компании Актив даже не будет рассматривать ваши вопросы, связанные с таким использованием ключей Guardant.
Ну и конечно, в какой-то момент весь данный код может попросту перестать работать из-за изменений в драйверах Guardant.
Но пока что, на 27 апреля 2013 года, весь данный материал актуален и его работоспособность проверена на драйверах от версии 5.31.78, до текущей актуальной 6.00.101.

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

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

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

Вот что-то такое мы и рассмотрим, только в очень упрощенной форме.

В первой части статьи были рассмотрены некоторые нюансы работы с интегрированным отладчиком Delphi — не все конечно, но наиболее необходимые разработчику. Теперь задача выглядит несколько иначе: рассмотрим его работу изнутри на примере его исходного кода. Для того чтобы не сильно утомлять вас описанием API функций и не разжевывать все этапы отладки, описывать его работу я буду на примере класса TFWDebugerCore. Часть не особо важных моментов я опущу, при желании вы их сможете уточнить просмотрев код данного класса.

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

Если же вы ранее никогда не сталкивались с самостоятельной реализацией отладчика, но заинтересованы в ней, то как минимум вы должны начать с данной ссылки: Debugging and Error Handling
По ней вы сможете узнать об основных аспектах отладки, как-то структурной обработке исключений, работой с отладочной информацией, минидампами. Работой с образом исполняемого файла, заголовками, секциями, картой памяти процесса, что такое RVA и VA и прочее-прочее.
Но это только если захотите разобраться во всей этой кухне.

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

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

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

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

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

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

Объем статьи получился неожиданно большим, поэтому я разбил ее на три части:

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

Собственно, приступим.