Разработка под Windows *

Как язык Visual Basic .NET отлично помогает решать рутинные инженерные задачи, связанные с Word и Excel.

ProxiFyre — это Open Source инструмент, функционирующий как "соксификатор" для приложений, не имеющих встроенной поддержки работы через SOCKS прокси-серверы. Программа является улучшенным вариантом одного из демонстрационных примеров для Windows Packet Filter. В отличие от базовой версии, ProxiFyre обеспечивает поддержку протокола UDP и предлагает функцию одновременного использования нескольких экземпляров SOCKS5 прокси, что существенно расширяет ее функциональные возможности. Приложение в схожем виде существует уже пару лет, но я опубликовал его всего лишь пару недель назад после небольшого ревью. Поводом для публикации стали несколько последовательных запросов на дополнительные функциональные возможности (в частности поддержку UDP), а также скромная надежда на то, что те, кто просит об этих улучшениях, примут посильное участие в дальнейшем развитии проекта.

Как известно, интерпретируемые и компилируемые языки имеют преимущества и недостатки относительно друг друга. Одним из таких преимуществ/недостатков является сохранение связи имени переменной из исходного текста с соответствующим объектом программы во время выполнения.

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

В случае же компилируемых языков, имена переменных из исходного текста уже были использованы на этапе компиляции и обычно на этапе выполнения недоступны и кажутся ненужными.

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

В SIEM-системах есть множество написанных экспертами правил, которые помогут отследить подозрительное поведение. Однако существует много сценариев атак, которые нельзя описать строгими правилами, а значит, эффективно отслеживать.

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

О том, как правильно использовать «магию» машинного обучения, какой алгоритм фактически самостоятельно «понимает» функциональные обязанности каждого пользователя и предназначение конкретной программы и при чем здесь рекомендации товаров в интернет-магазине, рассказываем в посте.

Позапрошлую заметку я начинал словами «вот уже 10 лет прошло…», а эту можно было бы начать «вот уже 20 лет прошло…». Хотя там речь шла лишь о выравнивании стека, а здесь – о целой организации взаимодействия программы с WinAPI. Помнится, здесь недавно в комментариях кто-то наивно удивлялся: зачем вы приводите устаревший и никому не интересный способ программирования через WinAPI? А как же иначе программа вообще может взаимодействовать со средой Windows, как не через вызовы ее стандартных функций? Через имеющиеся надстройки над WinAPI не все можно сделать.

Конечно, было бы прекрасно все время оставаться в рамках парадигмы используемого языка программирования и чтобы «на фотографии не торчали уши фотографа», т.е. чтобы в исходных текстах никак не проявлялись бы особенности взаимодействия со средой. Например, в большинстве языков есть понятие файла. Чтобы открыть файл не обязательно явно описывать стандартную функцию из WinAPI CreateFile или OpenFile, поскольку компилятор переведет встроенный в язык оператор открытия или прямо к обращению к этой функции или к вызову системной библиотеки, которая где-то внутри себя и вызовет требуемую функцию. В любом случае программист не обязан знать, как именно это реализовано в Windows.

В системной библиотеке языка PL/1-KT, который я использую, имеется обращение лишь к 28 функциям WinAPI и это вполне покрывает «обычные» возможности языка и можно было бы не заботиться о явных вызовах. Но увы, часто этого мало. И хотя нормальные люди ходят в двери, а не в окна (ах, какая свежая, искрометная шутка!), приходится в программах явно обращаться к функциям типа CreateWindow или CloseWindow. А это уже ну никак не входит в понятия языка.

Недавно мне для личных целей понадобилось написать читалку FB2. И сразу я столкнулась с тем, что информации по теме минимум. Палочка-выручалочка под названием ChatGPT выдал что-то невразумительное в ответ на довольно подробный запрос. К тому же, никаких готовых библиотек, чтобы по-быстренькому наваять ридер, я также не смогла обнаружить. Хотя искала долго и упорно, как Чубакка расческу.

Все это привело меня к закономерному выводу, что сначала нужно изучить формат FB2. А потом подумать, как прочитать его стандартными способами и вывести на экран. После того, как я немного разобралась со структурой FB2, начала догадываться, почему нет готовых библиотек. Дело в том, что этот формат довольно простой, и нет особой необходимости писать для него отдельную библиотеку. Можно довольно быстро наваять свой код, который будет читать практически все файлы FB2. И вы сможете убедиться в этом, если дочитаете статью до конца.

А раз все так просто, зачем я пишу эту статью? Для этого у меня есть две причины. Во-первых, это моя первая проба пера на Хабре. А во-вторых, возможно, это сэкономит кучу времени другому такому же новичку, как я. Ну, или пригодится какому-нибудь студенту, который пишет реферат.

Мне понадобилось провести несколько вводных уроков по языку программирования C++. В интернете есть много разнообразных учебных пособий для начинающих. Но почти во всех из них символьные и строковые литералы в примерах и упражнениях даются на английском языке, начиная со знаменитой первой программы «Hello, world!».

В этой статье я стараюсь показать, что действующий стандарт языка C++, современные компиляторы, редакторы кода и другие инструменты программиста позволяют писать исходный код программ, символьные и строковые литералы на разных языках, в частности на русском языке. При желании можно использовать иероглифы, эмодзи и любые другие символы из таблицы Юникода.

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

За последний год многим разработчикам пришлось осваивать работу с Linux, погружаться в тему кросс-платформенности и портирования существующих продуктов в новую инфраструктуру. Несмотря на то что часть наших продуктов написана под Linux, мы не стали исключением, и нашему RnD в прошлом году тоже пришлось значительно перестраивать свою работу.

Споры о том, под какой ОС проще кодить – бесконечны, примерно как дискуссии об Android vs iOS или PlayStation vs Xbox. Поэтому начинать мы ее не будем, хотя очень хочется.

В посте рассказываем исключительно об опыте нашей компании: на какие грабли наступили и в каких местах обожглись, работая над портированием продуктов с Windows на Linux. И все это собрали в 10 основных пунктов-болей наших разработчиков под катом. 

Джеймс Гослинг как-то сказал, что Java — это C++, из которого убрали все пистолеты, ножи и дубинки, однако практика показывает, что «ножи и дубинки» становятся классным инструментом в руках опытных разработчиков. В общем, немалая часть проклятий в адрес C++ объясняется элементарным «вы просто не умеете его готовить». Мы в «Лаборатории Касперского» умеем готовить «плюсы» и поэтому любим их. C++ — низкоуровневый язык, который позволяет работать с железом и писать быстрый код и при этом содержит массу возможностей. В экосистеме «плюсов» куча проработанных паттернов, best practices и готовых библиотек под разные задачи. Язык динамично развивается — но сохраняет обратную совместимость. 

В этом посте мы с помощью карты покажем, какие навыки и знания нужны разработчику на C++. Естественно, разбирать путь развития «плюсистов» будем на собственном примере — тем более что у нас в «Лаборатории Касперского» много очень разных проектов с отличающимися задачами. Однако наша карта по большей части универсальна и будет полезна всем, кто хочет развиваться в С++-разработке.

С помощью этого учебного материала мы научимся писать кросс-платформенный код на Си, используя системные функции популярных ОС (Windows, Linux/Android, macOS и FreeBSD): управление файлами и файловый I/O, консольный I/O, пайпы (неименованные), запуск новых процессов. Мы напишем свои небольшие вспомогательные функции поверх низкоуровневого системного АПИ (API), для того чтобы наш основной код, используя эти функции, мог работать на любой ОС без изменений. Этот учебный материал — начального уровня. Я делю сложные вещи на части, чтобы примеры кода здесь не были слишком заумными для тех, кто только что начал программировать на Си. Мы обсудим различия между системными АПИ и разберёмся, как создать кросс-платформенный программный интерфейс, который скрывает все эти различия от пользователя этого интерфейса.

Весь интернет уже готовится к выходу Windows 12. Вероятно, следующая версия будет во многом сосредоточена на поддержке работы с ИИ. На это намекает в том числе недавняя утечка от Intel, а также последние действия AMD и направление развития Bing.

В эпоху невероятной популярности ChatGPT и OpentAI все кинулись играть с их инструментами и использовать API в своих продуктах. Я был в общих рядах и сделал продукт для тех, кому затруднительно воспользоваться официальным сайтом ChatGPT. Но в этой статье речь пойдет не о восхитительных продуктах MS, а о создании интерфейса с котиками на основе этого продукта.

Итак, у нас стоит задача: создать десктопный чат с GTP3, которым будет удобно пользоваться человеку, далекому от пк.