Хуки — это технология перехвата вызовов функций в чужих процессах. Хуки, как и любая достаточно мощная технология, могут быть использованы как в благих целях (снифферы, аудио\видеограбберы, расширения функционала закрытого ПО, логирование, багфиксинг) так и со злым умыслом (трояны, кряки, кейлоггеры). О хуках уже не раз писали и на Хабре и не на Хабре. Но вот в чём беда — почему-то каждая статья о хуках буквально со второго абзаца начинает рассказывать о «таблице виртуальных функций», «архитектуре памяти» и предлагает к изучению огромные блоки ассемблерного кода. Известно, что каждая формула в тексте снижает количество читателей вдвое, а уж такие вещи — так и вовсе вчетверо. Поэтому нужна статья, которая расскажет о хуках просто. Под катом нет ассемблера, нет сложных терминов и буквально два десятка строк очень простого кода на С++. Если вы давно хотели изучить хуки, но не знали с чего начать — начните с этой статьи.

Сигма-тип и вы

Давайте поговорим о простой, но мощной концепции в программировании — сигма-типах.

Сигма-тип (тип-сумма, меченное объединение) может содержать значения одного и только одного из нескольких типов. Например, рассмотрим настройки в INI-подобном файле конфигурации. Пусть каждая настройка может быть строкой, целым или булевым значением. Если бы мы хотели сделать свою библиотеку на C++, мы бы написали что-то вроде этого:

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

Данная статья посвящена оптимизациям компилятора Visual C++. Я собираюсь обсудить наиболее важные техники оптимизаций и решения, которые приходится применить компилятору, чтобы правильно их применить. Моя цель не в том, чтобы рассказать вам как вручную оптимизировать код, а в том, чтобы показать, почему стоит доверять компилятору оптимизировать ваш код самостоятельно.

— Папа, я бежал за троллейбусом и сэкономил пять копеек!
— Сынок, бежал бы за такси — сэкономил бы пять рублей!


Сегодня я хочу рассказать вам, как сэкономить 10 тысяч долларов. А заодно, что гораздо менее интересно – научить перехватывать вызовы Win32 API функций, и не только. Хотя, в первую очередь – конечно, именно их.

Эта статья посвящена программированию GUI на базе фреймворка Qt от Nokia. Мы рассмотрим способы разработки интерфейсов для нативного отображения на платформах Windows, Linux и Mac OS X.

Презентацию^[1] вёл Йенс Бач-Вииг (Jens Bache-Wiig) — разработчик Qt (с 2005 года), занимающийся интерфейсами (look and feel).

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

Итак, приступим. Каждое графическое окружение имеет свой свод правил (User Interface Guidelines, UIG) по созданию интерфейсов, предназначенных для этих окружений. Из основных можно отметить такие руководства как Windows User Experience Interaction Guideline, Apple Human Interface Guideline, KDE User Interface Guideline и GNOME HID. Каждое из этих руководств «определяет положение кнопочек и рюшечек» конкретного окружения. Фреймворк Qt, в свою очередь, осуществляет поддержку всех этих руководств, предоставляя разработчику возможность создавать программы с использованием виджетов, «подстраивающихся» под окружение.

Недавно, работая над новой версией SObjectizer-а, довелось столкнуться задачей контроля в компайл-тайм действий разработчика. Суть была в том, что ранее программист мог делать вызовы вида:

receive(from(ch).empty_timeout(150ms), ...);
receive(from(ch).handle_n(2).no_wait_on_empty(), ...);
receive(from(ch).empty_timeout(2s).extract_n(20).stop_on(...), ...);
receive(from(ch).no_wait_on_empty().stop_on(...), ...);

Операция receive() требовала набор параметров, для указания которых использовались цепочки методов, вроде показанных выше from(ch).empty_timeout(150ms) или from(ch).handle_n(2).no_wait_on_empty(). При этом вызов методов handle_n()/extract_n(), ограничивающих количество извлекаемых/обрабатываемых сообщений, был необязательным. Поэтому все показанные выше цепочки были корректными.

Но в новой версии потребовалось заставить пользователя обязательно явно указывать количество сообщений для извлечения и/или обработки. Т.е. цепочка вида from(ch).empty_timeout(150ms) теперь становилась некорректной. Её следовало заменить на from(ch).handle_all().empty_timeout(150ms).

Причем хотелось сделать так, чтобы именно компилятор бил бы программиста по рукам, если программист забыл сделать вызов handle_all(), handle_n() или extract_n().

Может ли C++ помочь в этом?

Да. И если кому-то интересно как именно, то милости прошу под кат.

Недавно внимание автора привлекла статья на LWN о новом интерфейсе ядра для опроса (polling). В ней обсуждается новый механизм опроса в Linux AIO API (интерфейс для асинхронной работы с файлами), который добавили в ядро версии 4.18. Идея довольно интересная: автор патча предлагает использовать Linux AIO API для работы с сетью.

Но постойте! Ведь Linux AIO был создан для работы с асинхронным вводом-выводом с диска / на диск! Файлы на диске — это не то же самое, что сетевые соединения. Возможно ли вообще использовать Linux AIO API для работы с сетью?

Оказывается, да, возможно! В этой статье объясняется, как использовать сильные стороны Linux AIO API для создания более быстрых и лучших сетевых серверов.

Но давайте начнём с разъяснения, что представляет собой Linux AIO.

Два года назад я написал статью “SCADA: в поисках идеала”. Идея была проста — превратить Qt Creator в среду для разработки SCADA. Теперь хочу рассказать, какой путь проделан и что получилось.

Удалось ли достигнуть идеального результата? — Разумеется, нет. На то он и идеал, что недостижим. Зато удалось заметно к нему приблизиться.

В свое время когда я купил роутер MikroTik, передо мной кроме базовой настройки инета встала задача обеспечить работу IPTV, до того момента у меня был установленный Ростелекомом D-link. Сама базовая настройка инета на микротике заняла у меня примерно 10 минут, а вот с IPTV пришлось повозиться. Все мануалы прочитанные мной тогда не учитывали многих моментов, до которых я дошел расковыряв настройки многострадального D-link-а и без которых работать в данной схеме ТВ нормально не будет. В этой статье я хочу обозначить полученную мной универсальную инструкцию в данной ситуации.

* Ссылка на библиотеку в конце статьи. В самой статье изложены механизмы, реализованные в библиотеке, со средней детализацией. Реализация для macOS еще не закончена, но она мало чем отличается от реализации для Linux. Здесь в основном рассматривается реализация для Linux.

Гуляя по гитхабу одним субботним днем, я наткнулся на библиотеку, реализующую обновление c++ кода налету для windows. Сам я слез с windows несколько лет назад, ни капли не пожалел, и сейчас все программирование происходит либо на Linux (дома), либо на macOS (на работе). Немного погуглив, я обнаружил, что подход из библиотеки выше достаточно популярен, и msvc использует ту же технику для функции "Edit and continue" в Visual Studio. Проблема лишь в том, что я не нашел ни одной реализации под не-windows (плохо искал?). На вопрос автору библиотеки выше, будет ли он делать порт под другие платформы, ответ был отрицательный.

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

"Как так?" — подумал я, и принялся раскуривать фимиам.

Как то раз появилась следующая задача: создать локального пользователя в ОС Linux, с ограниченным доступом к папкам и файлам, включая не только редактирование, но и просмотр, а также возможность использовать только разрешенные утилиты. Предусматривается только локальный доступ, сетевого доступа нет.

Что бы не изобретать велосипед, первым делом начал копать интернет, в результате чего были найдены следующие варианты:

• ограничения доступа через сетевые службы ssh, sftp (не подошло)
• разграничение прав доступа самой операционной системой linux (не подошло, хотелось бы универсальное решение)
• использование chroot (не подошло)
• использование сторонних утилит, например SELinux (не подошло, усложняет систему).

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

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


Эта статья будет посвещена настройки хоста именно для использования в «быту», т.е. разговор пойдет о GPU PASSTHROUGH.

Утро в тот день началось с того, что у нас «сломались if'ы». Это выражение было когда-то придумано одним моим коллегой, который демонстрировал, как у него отладчик при пошаговом проходе по коду заходит в блок if, при том, что условие, которое if проверял, было абсолютно точно равно false. Проблема в тот раз оказалась тривиальной — он использовал релизный оптимизированный билд, а при таком сценарии доверять пошаговой отладке, конечно, нельзя. Но само выражение «сломались if'ы» прижилось и использовалось у нас с тех пор для обозначения ситуации, когда перестало работать что-то настолько фундаментальное, что в это даже с трудом верилось.

Так вот, в тот день у нас сломалась функция NtQuerySystemInformation — одна из важнейших функций ОС Windows, возвращающая информацию о процессах, потоках, системных дескрипторах и т.д. О пользе от использования данной функции я когда-то писал вот эту статью. Но оказалось, что иногда могут отказывать даже подобные краеугольные камни системы.

Итак, что же произошло.

После успешного перехода на линукс software разработчиков, выгадал момент, когда работы немного, и тоже сменил основную ОС. Опасения вызывал некроссплатформенный софт для поддержки уже имеющихся проектов. Часть софта заработало через wine. Однако оказалось, что определённый софт работать под wine'ом отказывается. Решено было запускать софт на виртуальной машине QEMU+KVM. Софт стал запускаться, но работать в нём было довольно не удобно. Программные виртуальные видеокарты не отличаются производительностью, да и поддержка 3D графики очень скромная. Пришлось расчехлять бубен и искать выход.

Привет Geektimes. Данная статья является продолжением предыдущей части, про туристическое зарядное устройство "Anker Solar 21Вт". Идея использования солнечной батареи для зарядки разных гаджетов мне показалась весьма перспективной, но конечно, 21Вт в качестве универсальной зарядки мало — хочется иметь возможность заряда не только в солнечную погоду, а для этого нужен запас по мощности. Поэтому были куплены полноценные солнечные панели и начаты эксперименты с ними.


Что из этого получилось, подробности под катом.

Что делать, когда имеется приложение с закрытым исходным кодом, которое обращается к БД не самым оптимальным образом? Как потюнить запросы, не меняя приложение, а возможно и саму БД?

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

Ну а если задавались — позвольте поделиться страданиями и опытом.

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

Среди серьезных компании, пожалуй, можно выделить облачные решения от Amazon (SQS) и Microsoft (Service Bus). Однако, несмотря на бурное развитие Public Cloud, такие решения не всегда применимы, что называется On-Premises. Иными словами, есть потребность в таких решениях, но на собственных закрытых площадках. В связи с этим, Microsoft сделали грамотный шаг, сделав доступным Service Bus в Private Cloud, или как минимум на одной машине с установленной Windows 7 и выше. В версии Service Bus 1.0 было доступно управление через PowerShell, а с релизом 1.1 появилась возможность интеграции в консоль Azure Pack.

В этой статье я постараюсь описать процесс настройки Service Bus for Windows Server максимально подробно, в картинках. Так как лучше один раз увидеть процесс полностью, чем несколько раз прочитать по частям в разных источниках.

Осторожно трафик! Под катом много картинок.

Цель, которой я задался, была весьма проста: узнать введённый в sshd пароль, используя ptrace. Конечно, это несколько искусственная задача, так как есть множество других, более эффективных, способов достичь желаемого (и с гораздо меньшей вероятностью получить SEGV), однако, мне показалось клёвым сделать именно так.

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

Мне всегда казалось, что нет более уязвимого и потерянного в реальности человека, чем первокурсник в первом своём семестре. Точнее, казалось так не всегда, а начиная со своего первого курса. Потом были сессии, аспирантура, работа преподавателем на несчастном первом курсе и мнение только укреплялось. Представьте себе: человека выдернули из школы и поместили в абсолютно другую среду со странными чертами: группа похожа на класс, те же парты и доска, учебники и злой библиотекарь, те же пары, так похожие на уроки. Но, чёрт возьми, что происходит? Я вам расскажу, что.

То же самое, но про инженеров — ниже. 1:1, пацаны