Comments 15
Героическая борьба с ранним связыванием и влиятельная реализация оператора присваивания from=to.
По-настоящему здесь интересен другой вопрос: чем руководствовались программисты Microsoft, делая раннее связывание в C#? Ведь к тому времени уже был Objective C с поздним связыванием методов.
Обычно принято рассматривать раннее связывание как костыль для эффективности скомпилированного кода. Но к .Net это вроде бы как не должно иметь отношения.
Причём тут раннее и позднее связывание? Проблема-то тут не в связывании, а в том что один программист забыл предусмотреть точку расширения в коде, а другому слишком нужно в неё влезть.
Так при позднем связывании не нужно было бы заранее предусматривать точки расширения. Просто присвоить метод.
Исходя из здравого смысла, программа должна бы иметь возможность расширяться в любом месте.
Речь про правки уже скомпилированного кода.
Интересно, получается что в NET платформе не защищен сегмент кода?!
Автору статьи действительно приходится править скомпилированный код, но при позднем связывании было бы достаточно замены указателя, связанного с именем метода.
Так весь смысл статьи, что мод не сделан в виде DLL с нужными точками входа
Если бы программа была на языке с поздним связыванием (как, например, Objective C вместо C#), то не нужно было бы для этого делать DLL и предусматривать точки входа.
На хабре эта тема разбиралась, например, тут. Автор сделал хак, не имея возможности в силу ограничений языка использовать честный интроспективный method swizzling.
Если бы да кабы, но на таких языках игры почему-то редко пишут
Не так уж чтобы совсем редко - вся iOS так работает. Но в целом да, такие техники выше среднерыночного уровня программирования. Вот автор статьи даже считает это своим величайшим достижением.
Такие техники динамической диспетчеризации прижились в интерпретируемыз языках, эпловские яп - исключения, ещё и неживые за пределами инфраструктуры эппла.
Объяснение простое - фича не бесплатная по производительности и нечасто нужная.
Ну вот и появляются в результате такие хаки, как у автора статьи. Потому что кто-то посчитал, что фича нечасто нужная.
Она, может, и нечасто нужная, но без неё время от времени получается полный затык. И приходится писать хаки в машинном коде.
А через некоторое время в Microsoft слегка поменяют формат кода CIL (или включат наконец read only для сегмента кода), и все такие программы навернутся.
Если я правильно понимаю, тут патчится не столько сегмент кода, сколько "сегмент" трамплинов. Эти трамплины постоянно создаются и изменяются JIT, так что ничего удивительного в отсутствии защиты.
Чувствую какой-то обман во всём этом. Ещё лет 20 назад для выполнения такого кода нужно было выполнять крэкс-пэкс-фэкс, чтобы получить права на запись в память (доводилось тогда использовать подобный патчинг... Не горжусь этим, но на тот момент проблему решили – уже даже не помню, какую именно), а потом отказаться от них.
Статья класс! И просто радуешься, когда видишь такие красивые находки и талант!
Мой худший образец полезного кода