Форум StopLinux

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

Вообще я не уверен, что это так, но даже если и так - это же все равно круче, чем с нативным кодом, где я не могу этого делать никак вообще!

А при чем тут самомодифицирующийся код? В нативном коде действительно м.б. все что заблагорассудиться, и именно это усложняет жизнь, о чём и лай.

Это стало похоже на форум по вопросам программирования. А тут тем не менее конкретная задача, а именно доказать что линуксоиды проникли в мелкософт и ведут диверсионную деятельность по окрашиванию глаз хомячков в красный цвет.

А это примерно как статическая линковка. Ну и кто вам сказал, что я не могу подключить DLL в С++ с Delphi классами? Всё что надо иметь, чтобы вызвать член-функцию: 1) указатель на об'ект; 2) указатель на функцию; 3) знать calling convention
Всё чики-пуки, милорд

ты с такой проблемой сталкивался вообще? (мне лично не приходилось, я разнородный софт не юзаю - всё и так на C или С++ писано).

Это реализация вашего "поменяю класс, скомпилю, и подложу обратно", не?

Собсна, ничего. Разве что asm целевой архитектуры знать надо.

Спадарам модераторам я предлагал перенести несколькими страницами ранее этот оффтоп в соответствующий форум. А так с их молчаливого согласия продолжаем банкет.

Редактировался whoknows (30-07-10 00:27:50)

1) Какие квесты? Я из Synaptica могу себе любую библиотеку найти и поставить. И процесс этот будет куда меньше,как по времени,так и по количеству других действий.
2) Я дал вам дельный совет, чтоб сохранить ваше здоровье и больше прожить, а вы мне смерти желаете. А потом еще говорят, что это линуксоиды злые и неадекватные.

Ну вот у фортрана все переменные в процедурах, на самом деле, передаются ссылками. Интересное со строками.

Внимание (!) фокус-покус:
Например, если есть
procedure mypro(string), то тк.к. строки в фортране задаются в виде: массив чаров + инт - длинна, то в длл такая функция будет выглядеть
mypro_(char *, int*).
Ладно там про подчеркивание (которое зависит от компилятора) - можно посмотреть имена функций в самом длл.
Самое интересное тут с int*. Если у тебя есть строка и еще переменные в фотрановской функции, например:
procedure mypro(string, string), то в зависимости от флага компилятора можно делать, чтобы инты с длинной шли за своими char* либо в конце списка переменных. Т.е. на выходе, в зависимости от флага будет:
mypro_(char *, int*, char *, int*)
либо
mypro_(char *, char *, int*, int*)

Ну вот. Дальше если у тебя есть процедура на фортране procedure mypro(string, int). Даже если у тебя есть документация по функции и dll. Если ты не знаешь, с каким флагом это компилировалось, то имея
mypro_( char *, int*,  int*) - ты не сможешь определить кто из этих интов - параметр, а кто- длинна строки))

Не, после устроенного ими dll hell-а они тут очень тщательно сделали работу с версиями сборок.
Зырь:
https://msdn.microsoft.com/en-us/library … 71%29.aspx
И просто про сборки
https://msdn.microsoft.com/en-us/library … 71%29.aspx

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

[Serialisable]
public int Property...

Так и стоят. А еще добавляется
[ConfigItem(default="bla nla", description = "la la lo")]

Т.е. с точки зрения кода ничего не меняется, а дело решается механизмом атрибутов. Я же писал - сильная штука. И все чинно. А что подписывать надо - так по-любому если ты ожидаешь такого поведения от объектов, то должен это как-то решать. А .нет опять же, предоставляет механизмы. Ту же работу с графами)

Редактировался Tiphon (30-07-10 02:33:44)

Канечна. Хочешь, на стадии дизайна:
https://blogs.msdn.com/b/abhinaba/archiv … 98278.aspx

А хочешь, на стадии исполнения (ссылку лень искать, но если попросишь - найду. Там элментарно через отражения).

Ну это очень оптимистично)) На практике такого нет. И это только один из примеров с фортраном (с только одним языком). Но пример хорош тем, что на фортране писали с 78 года и до сих пор много чего работает. Причем в каких местах! В ПО защиты на АЭС, например. Никто там хедеров не делал, я тебя умоляю.
Я не говорю, что что-то - невозможно. Я говорю: Ну ладно уж лукавить, что все так чикипуки и получается, милорд) Получается чики-трах-трах-трах-ояя!-пуки.

По поводу сериализации, есть на то и встроенные средства:
https://msdn.microsoft.com/en-us/library … 80%29.aspx
Но еще ты можешь реализовать через вот так
https://msdn.microsoft.com/en-us/library … zable.aspx

Редактировался Tiphon (30-07-10 04:03:42)

Гм. Ну разумеется, так не получится. Ибо объекты высшего уровня используются по-разному, в Delphi TObject существуенно больше (тупо, по размеру) чем аналог в C++. Если хочешь посмотреть, для данного частного случая, то тебе потребуется С++ builder, там этот объявление этого TObject занимает около 150 строк, я щас специально посмотрел.

Ты правильно написал, что нам нужен будет указатель на объект, функции его и calling convention. Но как ты поедставляешь себе это на практике? Указатели на объекты автоматически не генерятся, это невозможно, разве что на функции, причем строго те которые экспортируются, безо всяких calling convention, а также параметров. Неужели создатель будет искать своей в длл-ке указатели на класс? Разумеется, нет. А если не укажет создатель, не разберется никто кроме супер-мега хакера.
В дотнете же все это делается (указывается) само, на блюдечке. Пользуйтесь классами повторно, дорогие программисты

С проблемой сталкивался, да. У нас большая программа на Delphi, понадобилось подключить либу на С, причем не удинственный раз, потому что Delphi уже непопулярен, все наработки под С делаются.

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

Возможно, я не строю из себя гуру.
Но объектности на уровне нативного кода просто нет, уж это я понимаю. Просто потому что то, что является объектом для С++, не будет объектом для других языков, того же Delphi, к примеру. Поэтому все три пункта на уровне нативного кода смысла не имеют, поскольку объектности там нет, а они относятся именно к объектам.

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

Ну давай. Итак, задача 1. К программе на Delphi подцепить библиотеку на чистом С, называется МETIS, для разбиения графов. На вход - 2 или 3 целочисленных массива, на выход - один, тоже целочисленный. В Delphi я, понятно дело, создаю TintegerDynArray, который содержит в себе длину, а также, в зависимости от настроек компиляции, умеет ее контролировать. В чистом С этого нет, в С++ тоже нет. ( как отступление: наши коллеги в соседней комнате, пишущие на С++, используют Boost для массивов. Разумеется, массив из boost не равен TintegerDynArray.) В результате я передаю указатель на первый элемент массива, при этом в сишной либе указываю, что он именно integer, и отдельно передаю его длину. Больше вариантов нет.
В дотнете же массивы стандартизованы для любого языка. Чисто технически от этого стандарта, конечно, отступпить можно, но зато "общий знаменатель" для данных из разных источников - существенно больше.

Задача №2. Встраиваю в Delphi интерпретатор Python. Тут разнобой объектов можно наблюдать вообще во всей красе. Про Delphi вообще можно забыть, типы и для С не одинаковы даже для чисел! API Питона изобилует функциями типа Py_IntegerFromLong и обратно, преобразовывая целые числа, действительные, строки. Ну про даты вообще молчу, понятно что надо преобразовывать. А для объектов даже простые указатели не подходят, как ты говорил. Приходится делать следующую вещь:
класс TpyObject
     ... GetSelf: PpyObject
где TpyObject - объект, с которым может работать Delphi, PpyObject - указатель, с которым может работать Питон. В общем, разнобой полный.

Адрес есть, и на этом все. Сигнатуру можно получить только из исходников. Причем, а если переметром функции является объект, откуда его брать? Все, финиш. дебаг инфу люди другим как правило не предоставляют, только для себя.

Ну эта дебаг-информация там очень богата, очень. А главное - всегда есть Причем для любого языка. И для связки IronPython-F# не надо будет писать прослойку на С, как для просто Python-Ocaml. Что и требовалось доказать

Редактировался DonDublon3 (31-07-10 12:14:51)

Да, с интеграцией придётся поработать. Это человекочасы, но технических непреодолимых препятствий нет - они там же и решены.

Универсальный алгоритм (не всегда лучший):
1. убедиться, что в бинарнике в область памяти с кодом можно писать (если нет - выставить нужный флаг)
2. убедиться, что размер у функции больший, чем длина команды прямого вызова функции по абс. адресу + ret. (для интел 86-32 - 5 + 1 байтов - обычно выполняется из-за записи фреймов в стек)
3. написать модифицированную функцию в свободной области памяти кода (let it be f())
4. поменять первые байты исходной функции на
call f
ret;

дело сделано, код модифицирован. не так всё красиво, как щ с класслоадерами и прочей мутью, но работает. Плюсы: не нужна перелинковка. Минусы: не всегда применим.
Можно подкладывать нужную dll, но нужна будет перелинковка всего - это геморнее.

За сим раскланиваюсь.