Вывод текста в окно, как способ визуализации результатов работы приложения, является одной из основных задач в любом языке программирования. На пути изучения программирования на языке Ассемблера под Windows, очередным шагом является освоение принципов работы со строковой информацией в рамках использования объектов графического интерфейса (окон). В последние десятилетия человечество заметно изменило механизмы взаимодействия пользователя с операционной системой в сторону использования графики, постепенно нивелируя роль текстовых режимов работы, объясняя это банальным удобством. Тем не менее, в области использования современных графических интерфейсов, мы так и не отошли от основной формы выражения языка - письменности, потому как текст был и остается одним из превалирующих типов информации. А начиналось всё со старого-доброго *nix'а, где текстовая консоль выполняла основную задачу по взаимодействию с пользователем. Да и не смотря на тотальное засилие графики во основных пользовательских операционных системах (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-устройств.
STOP 0x000000F4
Критическая ошибка STOP 000000F4, символическое имя: CRITICAL_OBJECT_TERMINATION. Данная критическая ошибка говорит нам о том, что произошла ситуация, в которой объект (процесс/поток), критичный для функционирования операционной системы, был неожиданно завершен или прерван.
Параметры ошибки:
Нижеследующие параметры можно наблюдать на диагностическом "синем экране смерти" (BSOD), либо в полях дампа памяти.
| Параметр | Описание |
|---|---|
| 1 | Тип завершившегося объекта: 0x3: Процесс 0x6: Поток |
| 2 | Завершившийся объект |
| 3 | Имя файла образа процесса |
| 4 | Указатель на ASCII строку, содержащую поясняющее сообщение |
Не устанавливаются приложения, тормозит станция
Сегодня я хотел бы обсудить довольно специфическую проблему, которая долгое время не давала покоя техническому отделу, скажем так условного корпоративного клиента. Не то что бы она была какой-то уж чрезвычайно сложной, скорее просто никому не интересной (как в том анекдоте про Джо) :), и решалась местным персоналом при помощи полной "перезаливки" станции пользователя. Кстати, к слову сказать, проблема, которая будет описана в данной статье, мне уже встречалась, но всё никак не появлялось возможности детального её изучения. Благо, не так давно возникший аналогичный инцидент явился отправной точкой для написания этой заметки. Надо заметить, что для детального описания сбоев, в будущем хотелось бы все же разработать какой-нибудь единый диагностический шаблон, то есть собрать с проблемной станции именно ту информацию, которая представляла бы собой наиболее точное описание всех необходимых конфигураций и однозначно идентифицировала проблему, что бы пользователи могли находить решения по проблемам со схожими симптомам.
Установка Internet Explorer не закончена
На тему установки новых версий браузера Internet Explorer, и возникающих по этому случаю ошибок, в Сети уже опубликовано достаточно большое количество разнообразного материала. Лишний раз комментировать глобальные причины возникновения подобных ситуаций как-то не очень хочется, а то и так градус обсуждения порой слишком уж завышен, да и споры на предмет архитектуры того или иного системного компонента Windows не являются темой данной заметки, и без того некоторые специалисты, я думаю, уже имели достаточно времени сделать собственные выводы. Сегодня же мы поговорим о группе проблем, которые заключаются в следующем: на протяжении существования Windows 7 и выхода 9, 10, 11 версий браузера Internet Explorer (IE9, IE10, IE11), при попытке обновления браузера на более свежую (позднюю, последнюю) версию, иногда возникают не совсем понятные ошибки, одним из случаев которых является возникновение ошибки Установка Internet Explorer не закончена:
Больше информации по ошибке Установка Internet Explorer не закончена
Черный экран смерти
Проблемы различных этапов загрузки операционной системы Windows довольно широко распространены и определенно достойны собственного раздела. Данное явление нашло своё выражение в большом количестве разнообразных ошибок, возникающих при выполнении кода из секторов MBR/PBR, модулей Bootmgr, Winload, Ntoskrnl, SMSS, Csrss, Winlogon, Userinit и некоторых других, одним словом, всех тех компонентов, которые участвуют в процессе загрузки операционной системы. Не так давно в своей практике я очередной раз столкнулся с одной из подобных проблем и решил написать себе небольшую шпаргалку, поскольку всегда хотел как-то систематизировать подобного рода ошибки, и с чего то надо было определенно начинать. Из всего множества сбоев, возникающих на этапе загрузки Windows, хотелось бы отдельно отметить ошибки, называемые пользователями Черным экраном смерти.
Изучая материалы в Сети я сделал вывод, что проблема широко распространена, однако жестко не закреплена за каким то одним этапом загрузки и включает в себя довольно большой спектр разнородных ошибок, возникающих на разных стадиях. К черному экрану смерти зачастую относят еще и проблемы, возникающие во время работы операционной системы, источником которых являются аппаратные сбои, однако мы их рассматривать не будет в виду их немногочисленности.
