Диалоговое окно на ассемблере

Метки:  , ,

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

Давайте ближе познакомимся с диалоговыми окнами

Манифест приложения на ассемблере

Метки:  , ,

Когда я, в процессе своего обучения, подошел к написанию приложений, активно использующих различные графические элементы управления, раз за разом начал обращать внимание на одну интересную проблему. Дело в том, что при запуске двоичного исполняемого файла, все элементы, находящиеся в окне, выглядели "плоско", то есть имели упрощенный стиль, а-ля Windows 95. Долгое время я как-то не мог сообразить, почему у меня каждый раз оформление окон получается каким-то упрощенным, без выпуклого объема у кнопок, теней, объемных полос прокруток, элегантных тонких линий-рамок у групп элементов, а у подавляющего большинства сторонних оконных приложений, видимых мною в Сети, тема оформления окна была "объемной"? Особенно это заметно в диалоговых окнах, где группируется большое количество разнообразных дочерних элементов управления, волей-неволей начинаешь к ним присматриваться, изучать детали.. и тут вот осознаешь, что в твоих то приложениях они получаются не такими элегантными. Оказалось, что если не предпринимать каких-либо дополнительных действий, то приложения, компилируемые FASM и использующие оконный графический интерфейс, все как на подбор получаются с упрощенной стилизацией интерфейса. Что я только не делал, уже и все стили элементов перебрал вдоль и поперек, ставя в параметры ресурсов всяческие мыслимые и немыслимые комбинации, эффект был разный, но неизменно далекий от желаемого. Как заставить приложение выглядеть в новом, современном стиле? В ходе практических изысканий, когда уже все варианты кончились, наконец-то начал думать :) Как оказалось, ответ кроется в изменившимися принципами работы с общими элементами управления, подключаемых посредством механизма под названием манифест приложения.

Что же такое манифест приложения на ассемблере

Сбой при загрузке aspi32.sys

Метки:  , , , , , , , , ,

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

больше информации об сбое при загрузке aspi32.sys

Couldn't find user-mode logger in active logger list

Метки:  ,

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

kernel logger error

Звучит она, соответственно, как 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 20007/2010 перестали открываться некоторые вложения, размещенные внутри сообщений/событий календаря в виде объектов. При попытке открыть подобные "вложенные" файлы, появляется сообщение об ошибке следующего содержания: Данный объект был создан в следующей программе: Outlook. Эта программа не установлена на вашем компьютере либо не отвечает. Чтобы изменить данный объект, установите Outlook либо убедитесь, что все диалоговые окна в Outlook закрыты:

При всем этом вложенные файл свободно "перетаскиваются" (drag-and-drop) при помощи мыши (сенсора) на рабочий стол, где, в последствии, могут быть открыты ассоциированным приложением!

далее по теме данный объект был создан в следующей программе: Outlook

Оконное приложение на ассемблере

Метки:  , , , , , , , ,

Надумал я тут написать небольшую утилиту.. и понял, что писать-то я и не умею. Смеялись всем селом!! :) Если рассматривать вопрос по существу, то сегодня мы рассмотрим некоторые особенности синтаксиса языка ассемблер в свете использования компилятора FASM, и приведем типовой шаблон оконного приложения на ассемблере, а так же выполним разбор структуры для дальнейшего использования в качестве базиса в различного рода проектах. Быть может, когда-то статья и станет звеном в цикле по изучению программирования на языке Ассемблер под Windows, но на данный момент она представляет собой обособленный материал.

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

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

еще о шаблоне оконного приложения на ассемблере

Удаление обязательных обновлений

Метки:  , , ,

Название Удаление обязательных обновлений не до конца раскрывает смысл описываемого в статье, поскольку не совсем понятно, что именно имеется в вижу под термином "обязательный". Материал можно было бы озаглавить как Удаление неудаляемых обновлений, но тогда не совсем понятно, по каким причинам они вдруг стали неудаляемыми: по воле разработчика или из-за ошибок с хранилищем компонентов. Есть еще вариант обозначить как удаление обновлений, не предназначенных для удаления, но это как-то избыточно, что ли.
Совсем недавно открыл для себя одну любопытную особенность некоторых обновлений: они не удаляются стандартными средствами операционной системы. На практике возникла ситуация, в которой я никак не мог удалить из системы "битое" обновление. По мере углубления в тематику вопроса выяснилось, что в Windows существуют разные типы обновлений, и что частный случай невозможности удаления некоторых из них вовсе не является следствием какой-либо локальной ошибки, а отражает скорее особенность. Судя по всему, объясняется это архитектурными нюансами механизма обновлений. На практике сложно создать такую систему взаимосвязей обновлений, в которой каждое обновление будет полностью автономно, то есть независимо от остальных, и, соответственно, может быть удалено без каких-либо последствий. Но еще более важно то, что некоторые обновления для системы действительно критичны, поскольку достаточно глубоко в неё интегрированы. Например сам механизм обновления (стек обслуживания) обеспечивается набором модулей (инсталлятор, библиотеки и прч), которые необходимы для установки последующих обновлений и от которых зависит работоспособность механизма в целом. Соответственно, все обновления стека обслуживания, вносящие алгоритмические изменения, не могут быть просто удалены, поскольку тогда станут недоступными некоторые особенности этих алгоритмов, при помощи которых уже были установлены последующие пакеты обновлений. Удаление подобных обновлений чревато для системы серьезными последствиями, такими как разрушение хранилища компонентов, и как следствие, потенциальные проблемы с работоспособностью самой операционной системы. На самом деле так уж всё страшно, поскольку подобных обязательных (неудаляемых) обновлений, например в системе Windows 7, насчитывается всего-то около десятка :) Но знать то об этом нюансе все же стоит, так же как и иметь понимание, как именно производить удаление обязательных обновлений.

больше информации об удалении обязательных обновлений

История использования USB

Метки:  , , ,

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

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

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

Далее по теме как изучить историю использования USB