Время от времени в разделе будут появляться короткие заметки по разнообразным, зачастую необходимым на практике, фрагментам кода на языке ассемблера. В этом посте я хотел бы сохранить фрагмент кода, предназначенный для получения размеров окна приложения ассемблере и вывода их в графическое окно. Иногда у начинающих встречаются задачи, в которых необходимо получить размеры (ширина/высота) областей произвольного окна собственного приложения. Что бы не рыскать каждый раз по Сети в поисках ответов, решил сохранить код решения задачи в качестве автономной заметки на собственном блоге. Код, приведенный далее в примере, рассчитан на диалект препроцессора FASM. Исходный код небольшого приложения, выводящего в окно размеры собственного окна:
Драйвер Windows
Как мы знаем, на аппаратном уровне современный компьютер состоит из функциональных узлов, представляющих собой те или иные электронные компоненты. Широкому кругу пользователей персональных компьютеров знакомы такие функциональные блоки как: процессор, память, видеокарта, звуковая карта, жесткий диск, контроллер ввода-вывода (обеспечивающий работу клавиатуры, мыши, джойстика, USB-носителей (флешек)), принтер, сканер и некоторые другие. На физическом уровне данные устройства взаимодействуют между собой посредством специальных шин и протоколов, создавая совокупностью своего взаимодействия симбиоз операций, который, в общем случае, характеризует функционирование компьютера. Но разве компьютер представляет собой только лишь набор электронных компонентов? Конечно же нет, ведь один из основных аппаратных модулей, центральный процессор, спроектирован для выполнения машинных инструкций, из последовательностей которых, как мы знаем, состоят программы, в свете этого было бы уместно упомянуть еще об одном уровне - программном. Теперь давайте вернемся в не столько далекое прошлое; на заре компьютерной эры код программ (которые часто писались непосредственно в машинных кодах/на низкоуровневых языках) мог легко взаимодействовать с аппаратурой напрямую, поскольку аппаратная архитектура была относительно простой. Однако со временем технологии развивались, аппаратный и программный уровни эволюционировали взаимосвязано, и первый пришел к появлению большого многообразия устройств, а второй к появлению огромного разнообразия программных модулей, обусловивших, в дальнейшем, появление операционных систем. Операционная система явилась ключевой вехой в истории развития компьютерной индустрии, поскольку именно она, среди прочего, выполняла роль связующего звена, своеобразного координатора (диспетчера), обеспечившего взаимодействие между устройствами и программами: принимала запросы от программного слоя (например, пользовательских программ) на обмен данными с тем или иным устройством и наоборот, то есть фактически выполняла роль сопряжения между аппаратной и программной частями. Операционные системы тоже не стояли на месте, и если по началу взаимодействие операционной системы с аппаратурой компьютера было относительно простым, то по мере усложнения архитектуры и введения новых аппаратных возможностей, усложнялась и структура операционной системы. На протяжении всего времени развития операционных систем, разработчики пытались создать код, обеспечивающий полноценное взаимодействие с максимально возможным количеством имеющимся на рынке аппаратных устройств. Тем не менее, подобный подход, по мере усложнения архитектуры персональных компьютеров x86, привел к появлению концепции обособленного программного слоя, носящего название драйвер, ответственного за взаимодействие с тем или иным классом/типом устройств. Концепция драйвера оказалась настолько удачной, что помимо основного направления - поддержки физических устройств, была экстраполирована и на некоторые категории логических/виртуальных устройств. В данной статье мы будем рассказывать про то, что же из себя представляет драйвер Windows.
Диалоговое окно на ассемблере
Окна, как элемент графического интерфейса Windows, могут быть простыми, информационными, уведомляющими пользователя о каком-либо событии (например, об ошибке), но чаще всего они представляют собой более сложные конструкции, содержащие в собственной клиентской области множество элементов управления. Вне зависимости от внешнего вида графического окна, основное предназначение его заключается в выстраивании взаимодействия с пользователем, поскольку само понятие окна подразумевает некую область, которую приложение отрисовывает с целью предоставить (вывести) информацию или запросить (ввести) её, другими словами обеспечить ввод/вывод данных. Вывод и вывод зачастую комбинируются в пределах одного окна и могут быть организованы нетривиально, например содержать выделенные рамкой области, группирующие однотипные данные, иметь чекбоксы/радиокнопки, обеспечивающие выбор опций, поля для текстового вывода, кнопки, различного рода списки и прочие объекты. Естественно, что создавать а затем и обслуживать в окне большое количество автономных объектов не так просто как хотелось бы: мало того, что для самого окна нужно определять класс, на основании класса уже создавать непосредственно окно, далее описывать оконную процедуру, а в довершение ко всему создавать в пределах окна каждый элемент, а ведь этими элементами придется еще и управлять. Вся эта рутина превращает процесс разработки многоэлеметного окна в очень трудоемкую задачу, в которой разработчик сфокусирован более на логике создания окон и элементов, нежели на алгоритме ядра приложения. Решением данной проблемы является рекомендованный Microsoft к использованию особый класс окон, называемый диалоговыми, которые обеспечивают относительную простоту обслуживания окон, содержащих произвольное количество различных (статических и динамических) элементов управления.
Манифест приложения на ассемблере
Метки: comctl32.dll, FASM, WinSxS
Когда я, в процессе своего обучения, подошел к написанию приложений, активно использующих различные графические элементы управления, раз за разом начал обращать внимание на одну интересную проблему. Дело в том, что при запуске двоичного исполняемого файла, все элементы, находящиеся в окне, выглядели "плоско", то есть имели упрощенный стиль, а-ля Windows 95. Долгое время я как-то не мог сообразить, почему у меня каждый раз оформление окон получается каким-то упрощенным, без выпуклого объема у кнопок, теней, объемных полос прокруток, элегантных тонких линий-рамок у групп элементов, а у подавляющего большинства сторонних оконных приложений, видимых мною в Сети, тема оформления окна была "объемной"? Особенно это заметно в диалоговых окнах, где группируется большое количество разнообразных дочерних элементов управления, волей-неволей начинаешь к ним присматриваться, изучать детали.. и тут вот осознаешь, что в твоих то приложениях они получаются не такими элегантными. Оказалось, что если не предпринимать каких-либо дополнительных действий, то приложения, компилируемые FASM и использующие оконный графический интерфейс, все как на подбор получаются с упрощенной стилизацией интерфейса. Что я только не делал, уже и все стили элементов перебрал вдоль и поперек, ставя в параметры ресурсов всяческие мыслимые и немыслимые комбинации, эффект был разный, но неизменно далекий от желаемого. Как заставить приложение выглядеть в новом, современном стиле? В ходе практических изысканий, когда уже все варианты кончились, наконец-то начал думать :) Как оказалось, ответ кроется в изменившимися принципами работы с общими элементами управления, подключаемых посредством механизма под названием манифест приложения.
Сбой при загрузке aspi32.sys
Метки: ASPI, aspi32.sys, ATAPI, DllEntryPoint, ETW, SCSI, SPTI, wnaspi32.dll, WOW64, WPT
Порой случается и такое, что обращаешь внимание на сущую мелочь, безделицу, к изначальному объекту твоего внимания никакого отношения не имеющую. Однако со временем, этот безобидный, на первый взгляд, предмет твоего невольного интереса может запросто превратиться в источник различного рода проблем. Так бывает в жизни и точно таков мир операционных систем, где постоянно изменяющийся код системных компонентов может в какой-то момент кардинально преобразовать ситуацию. Иногда, так сказать по долгу "службы", приходится анализировать системные журналы Windows, представляющие собой один из многочисленных источников информации о состоянии системы. Именно в нем иной раз можно найти записи об уже существующих и даже потенциальных, так сказать предстоящих неисправностях. Так вот, в одной далекой-далекой компании, имя которой не разглашается дабы не скомпрометировать доброе имя :) и не навредить коммерческим интересам, ну а более в целях создания статейной интриги :) специалистами было отмечено, что (иногда) при анализе системных журналов встречались любопытные события. Возникавшие с завидной регулярностью, события эти сводились к ошибкам функционирования одного и того же драйвера aspi32.sys, имели коды 7026, 1060, 7000 и содержали следующее описание:
Couldn't find user-mode logger in active logger list
После запуска логирующего системного механизма трассировки событий Windows посредством утилиты xbootmgr, на различных этапах трассировки может появиться следующая ошибка:
Звучит она, соответственно, как Couldn't find user-mode logger in active logger list. Unable to stop trace. Couldn't find kernel logger in active logger list. Couldn't find user-mode logger in active logger list. При этом после появления данной ошибки у нас возникает одна неприятная проблема: не выполняется финальная сборка многочисленных объединяемых .etl-файлов данных трассировки (суффикс premerge в названии), тем самым не формируется результирующий протокол сессий (отчет).
Подробнее об ошибке couldn't find user-mode logger in active logger list
Вывод текста в окно на ассемблере
Вывод текста в окно, как способ визуализации разнообразного рода данных, является одной из основных задач в любом языке программирования. На пути изучения программирования на языке Ассемблера под Windows, очередным шагом является освоение принципов работы со строковой информацией в рамках использования объектов графического интерфейса (окон). В последние десятилетия человечество заметно изменило механизмы взаимодействия пользователя с операционной системой в сторону использования графики, постепенно нивелируя роль текстовых режимов работы, объясняя это удобством использования. Тем не менее, в области применения графических интерфейсов, мы так и не отошли от основной формы выражения языка - письменности, потому как текст был и остается одним из превалирующих типов передачи информации. Не смотря на тотальное засилие графики во основных пользовательских операционных системах (OSx/Android/Windows), текстовый режим в виде практически не потерявшей свой первоначальный вид консоли, ведущей своё начало еще от телетайпов и пишущих машинок, всё еще присутствует в составе перечисленных ОС. Если говорить о ранних этапах становления, то предшественницей системы Windows была MSDOS, в которой интерфейс командной строки функционировал в текстовом режиме. Помните, как в ней реализовывался вывод текста на ассемблере, который осуществлялся через функции прерывания 10h BIOS, либо попросту прямой записью данных в область видеопамяти (PC: сегмент B800h).
Иконка приложения на ассемблере
Затрагиваемая нами сегодня тема, пожалуй, является не такой уж и заметной в общем процессе освоения программирования на языке ассемблера под Windows. Однако возможность обеспечения разрабатываемого приложения различного рода визуальными элементами, если хотите украшательствами, заложена в саму концепцию большинства современных операционных систем с графическим интерфейсом. Сегодня мы обсудим такую несущественную деталь как иконка приложения. Согласитесь, в сущности то мелочь, а приятно посмотреть? :) В очередной раз как-то на днях увидел элегантную иконку напротив имени какой-то программы в проводнике, и.. понравилось. Эстетика, не более, никакого особенного функционала в себе иконки не несут, однако восприятие графического окна приложения как то сразу меняется. Ведь, если разобраться, в современном программировании наличие собственного значка у приложения является уже своего рода хорошим тоном, так сказать распространенной практикой. Ну, а поскольку для меня программирование под Windows является областью пока еще новой, поэтому решил разобраться, как же собственные приложения, написанные на ассемблере, оснащать иконками. Иконка приложения, о которой идет речь, видна в верхнем левом углу главного окна программы, отображается в проводнике напротив имени файла и её так же можно наблюдать в миниокне приложения на панели задач, по сути, она доступна через стандартные системные механизмы, поэтому появляется везде, где её запрашивают и выводят.
Данный объект был создан в следующей программе: Outlook
Начиная примерно с 13 июня 2017 года, в программе Outlook пакетов Office 2007/2010 перестали открываться некоторые вложения, размещенные внутри сообщений/событий календаря в виде объектов. При попытке открыть подобные "вложенные" файлы, появляется сообщение об ошибке следующего содержания: Данный объект был создан в следующей программе: Outlook. Эта программа не установлена на вашем компьютере либо не отвечает. Чтобы изменить данный объект, установите Outlook либо убедитесь, что все диалоговые окна в Outlook закрыты:
При всем этом вложенные файл свободно "перетаскиваются" (drag-and-drop) при помощи мыши (сенсора) на рабочий стол, где, в последствии, могут быть открыты ассоциированным приложением!
далее по теме данный объект был создан в следующей программе: Outlook
Оконное приложение на ассемблере
Надумал я тут написать небольшую утилиту.. и понял, что писать-то я и не умею. Смеялись всем селом!! :) Если рассматривать вопрос по существу, то сегодня мы раскроем некоторые особенности синтаксиса языка ассемблер в свете использования компилятора FASM, и приведем типовой шаблон оконного приложения на ассемблере, а так же выполним разбор структуры для дальнейшего использования в качестве базиса в различного рода проектах. Быть может, когда-то статья и станет звеном в цикле по изучению программирования на языке Ассемблер под Windows, но на данный момент она представляет собой обособленный материал.
Не смотря на то, что данная публикация представляет из себя пособие для начинающих, изучение приведенной здесь теории требует хотя бы базового уровня знаний языка Ассемблер.
Я попытался до определенной степени детализировать небольшой накопленный опыт, дабы читатель любого уровня подготовки смог увидеть весь диапазон направлений, требуемых для более глубокого изучения специфики языка Ассемблера в контексте Windows, если появится желание дальнейшего продвижения. Будут рассмотрены основные (базовые) директивы ассемблера FASM, которые позволяют существенно влиять на финальную структуру исполняемого файла программы. Некоторые из приведенных разделов вполне могли бы дорасти до размера самостоятельной статьи, однако пока подобная структура не создана, информация будет приводиться здесь. Темой данной статьи станет создание простейшего графического оконного приложения на ассемблере для Windows, потому как данная категория приложений является наиболее распространенной, соответственно и востребованной.
