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

Непредвиденные последствия

«Система кармы Хабра и ее влияние на пользователей» — это тема для курсовой как минимум
Тема про карму на «Пикабу»

Я мог бы начать эту статью с того, что я давно читаю Хабр, но это будет не совсем точным высказыванием. Правильный тезис звучал бы так: «я давно читаю статьи с Хабра» — но не интересовался тем, что происходит внутри сообщества, когда этой весной решил наконец-то зарегистрироваться. Это типичная ошибка человека, который приходит на Хабр из поисковика читать полезные статьи о тонкостях программирования или интересные новости из мира технологий. Пока ты видишь портал только с этой, положительной стороны, ты не задаёшься вопросами о том, что происходит под капотом. Конечно, в комментариях или статьях время от времени проскальзывали упоминания кармы — но ведь карма есть почти на всех крупных порталах (наивно полагал я), это нормально для саморегулирующихся интернет-сообществ.

Мне пришлось всерьёз задуматься об этом после того, как я неожиданно потерял возможность писать больше одного комментария в пять минут.

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

Разработка прошивок, даже если она ведется не на ассемблере для экзотических архитектур, а на C для i386/amd64 — дело весьма непростое, да и цена ошибки может быть крайне высокой, вплоть до выхода целевой аппаратной платформы из строя, поэтому использование различных техник предотвращения ошибок на самых ранних этапах разработки — необходимость.

К сожалению, о формальной верификации или использовании MISRA C в случае UEFI-прошивок остается только мечтать (с другой стороны, мало кто хочет тратить на разработку прошивки пару лет и 50% бюджета проекта), поэтому сегодня поговорим о статическом анализе, а точнее — о популярном на Хабре статическом анализаторе PVS-Studio, которым попытаемся найти ошибки в открытом коде UEFI для Intel Galileo.

За результатами проверки покорнейше прошу под кат.

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

Я обожаю читать на хабре статьи про то, как устроены системы больших интернет-компаний. Кластеры SQL-серверов, монг и редисов. Тут у нас кластер ELK собирает трейсинг, там – сборка логов, здесь балансер выдает входящим запросам traceID и можно отслеживать, как запрос ходит по всем нашим микросервисам. Класс. Но, допустим, у вас совсем маленький проект и вы можете себе позволить лишь VPS минимальной конфигурации. Реально ли на ней сделать мониторинг не хуже, чем у больших проектов? Я решил – надо попробовать.

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

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