Когда-то я активно работал с промышленным оборудованием. Часто мне приходило какое-то устройство, и оно общалось с внешним миром по волшебному протоколу Modbus.

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

Поэтому представляю вам мою версию Modbus терминала!

И снова здравствуйте!

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

По этому решил я эту тему продолжать. Хотя, правды ради и прохождения полиграфа для, я бы всё равно не выдержал и написал бы что-нибудь про это ещё.

Сего дня я решил, что напишу про алгоритмы структур данных. Про те, которые смогу вспомнить. И, как говорит наш дорогой шеф:

Предупреждение

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

Введение

Решение crackme это (время от времени) достаточно увлекательное занятие, позволяющее взглянуть на некоторые вещи под непривычным углом. В этой статье я расскажу о том, как можно патчить скомпилированные .NET-приложения не прибегая к перекомпиляции.

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

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

Мне кажется нельзя считать что вы до конца понимаете концепцию многопоточности (Multithreading/ Concurrency) если вы не понимаете когда (для каких задач) ее можно и/или нужно использовать на однопроцессорной машине, 2-х процессорной, N‑процессорной машине и от чего это зависит.