Comments 17
А можно пример?
Про иду в статье исключительно как про плюсовый клиент для ком.
У меня TLB не импортировался, а ошибки никакие не выводило. Пришлось конвертить руками, заодно видно сразу, чего нет, и что есть.
По поводу тысяч — неправда. Регистрировать через шарп я как раз таки умею. А вот регистрировать из шарпа, чтобы, например, те же колбэки протаскивать из плюсов в Шарп — бедная тема. Можно об этом хотя бы один линк?
У меня TLB не импортировался, а ошибки никакие не выводилотак может стОило разобраться сначала с этим? Ну там, например, уровень логирования msbuild-а крутануть и т.д. А не «забыть как страшный сон»…
«По поводу тысяч — неправда.», да бросьте, даже в MSDN есть раздел, включающий и IDispatch (хотя ничего в нём такого нет для тех, кто когда-нибудь писал ActiveX сервера, аналогично в ATL были примеры, и даже в поставку WinSDK всё это так или иначе входило, в примерах).
Мне лично лень ворошить относительный труп (ActiveX и т.п., плюс MS тоже не рекомендует), да и вам не советую — уж сложностей в IPC с современными фреймворками типа grpc нет же, так спросите себя «оно вам надо» идти этой дорогой?
Note: вы также можете не регить com сервер в реестре, возможно вписать его через manifest (SxS манифест) файл…
Мне нужно просто пробросить плюсовый колбэк в COM out-of-process написанный на шарпе.
Общепринято функции обратного вызова в COM (события) используют интерфейс IConnectionPoint, смотрите в этом направлении. Издатель событий публикует общедоступный интерфейс, который реализуют подписчики. Затем получатели событий запрашивают у сервера экземпляр IConnectionPoint, передают туда объект, унаследованный от общедоступного интерфейса. Теперь сервер может вызывать функции общедоступного интерфейса, что равно вызову функции на стороне клиента.
В случае если клиент и сервер находятся в разных исполняемых файлах, то общедоступный интерфейс события проще унаследовать от IDispatch, чтобы не возиться с прокси‐заглушками.
1) Сделать LoadLibrary(«emu_core.dll»), затем GetProcAddress(core, «Pause») и pause()
В emu_core.dll можно был бы сделать раздел с атрибутом SHARED. Тогда все данные в этом разделе разделялись бы между процессом IDA и процессом вашего GUI. Не много примитивов синхронизации и было бы вам бесплатное счастье.
За подробностями стоит обратиться к классическому труду Джеффри Рихтера «Windows via С/С++» — глава 17
Это какой-то прикол? Во все пдфках нет 17-й главы. 16 и за ней сразу 18.
Нашлось в русской версии:). Спасибо!
Только колбэки конечно, останутся проблемой. Но дллку хотя бы можно будет использовать как shared memory.
Как подружить .NET и IDA Pro (о дружбе C# и C++)