Здравствуйте, Tom, Вы писали:
A>>простите, промазал по кнопке, вместо ответа сделал тему... A>>Это конечно относится к перехвату интерфейсов
Tom>Для такого дела новую тему не жалко Tom>У нас в своё время не хватило желания и сил сделать что то комерческое из нашего творения.
Спасибо, да вообще статью бы накатать, чтобы в журнал попала. Но я не уверен опубликуют ли статью если она почти без исходного кода, а только ссылка на дему...
A>Спасибо, да вообще статью бы накатать, чтобы в журнал попала. Но я не уверен опубликуют ли статью если она почти без исходного кода, а только ссылка на дему...
Ммм почему бы и нет. Но та на сабмит вопрос напиши.
A>Спасибо, да вообще статью бы накатать, чтобы в журнал попала. Но я не уверен опубликуют ли статью если она почти без исходного кода, а только ссылка на дему...
А о чем статья, инструкция по использовнаию демы, или таки полезная информация для других разработчиков подобных вещей?
Здравствуйте, Tom, Вы писали:
A>>Спасибо, да вообще статью бы накатать, чтобы в журнал попала. Но я не уверен опубликуют ли статью если она почти без исходного кода, а только ссылка на дему... Tom>Ммм почему бы и нет. Но та на сабмит вопрос напиши.
Здравствуйте, araud, Вы писали:
A>Здравствуйте, Tom, Вы писали:
A>>>Спасибо, да вообще статью бы накатать, чтобы в журнал попала. Но я не уверен опубликуют ли статью если она почти без исходного кода, а только ссылка на дему... Tom>>Ммм почему бы и нет. Но та на сабмит вопрос напиши.
A>ЭЭЭ это куда?
Кстати, совет по статье. Чтобы небыло непонятных кусков кода, желательно самостоятельно в свободное время написать рабочий пример, который наглядно описывал бы принцип функционировнаия системы. Тогда от статьи будет толк. А иначе это будет лишь самореклама, а не статья.
Здравствуйте, SPeller, Вы писали:
SP>Кстати, совет по статье. Чтобы небыло непонятных кусков кода, желательно самостоятельно в свободное время написать рабочий пример, который наглядно описывал бы принцип функционировнаия системы. Тогда от статьи будет толк. А иначе это будет лишь самореклама, а не статья.
Я написал статью на CodeProject: у меня возникли сомнения, что от советской аудитории можно будет дождаться покупок. Хакнуть демку конечно не смогут, но и покупать не станут.
A>Я написал статью на CodeProject: у меня возникли сомнения, что от советской аудитории можно будет дождаться покупок. Хакнуть демку конечно не смогут, но и покупать не станут.
А мне было бы интересно почиnать о том, как вы решали проблему. Потому что я ее решил совсем по-другому Моим основным принципом было не засорять реестр никакими регистрациями, чтобы приложение никак не зависило от того, кто и что понаписал в реестр. Лишь бы доступ в сеть был и всё. Но при этом иметь все удобства работы с DCOM.
Здравствуйте, SPeller, Вы писали:
A>>Я написал статью на CodeProject: у меня возникли сомнения, что от советской аудитории можно будет дождаться покупок. Хакнуть демку конечно не смогут, но и покупать не станут.
SP>А мне было бы интересно почиnать о том, как вы решали проблему. Потому что я ее решил совсем по-другому Моим основным принципом было не засорять реестр никакими регистрациями, чтобы приложение никак не зависило от того, кто и что понаписал в реестр. Лишь бы доступ в сеть был и всё. Но при этом иметь все удобства работы с DCOM.
я много в реестр и не пишу, только набор своих комобъектов регистрю. А еще нужны только проксистабы тех объектов с которыми собираешься работать. http://www.codeproject.com/KB/COM/ComBridge.aspx
Здравствуйте, SPeller, Вы писали:
A>>Спасибо, да вообще статью бы накатать, чтобы в журнал попала. Но я не уверен опубликуют ли статью если она почти без исходного кода, а только ссылка на дему...
SP>А о чем статья, инструкция по использовнаию демы, или таки полезная информация для других разработчиков подобных вещей?
и то и другое http://www.codeproject.com/KB/COM/ComBridge.aspx
Здравствуйте, SPeller, Вы писали:
SP>Если честно, то, имхо, статья ни о чем. Озвучена проблема и приведена демо, и всё. Никакой полезной инфы о способах и путях решения.
1. Я думаю, мало кто знал о возможности вклинится между прокси и стабом. Это не пустая информация.
2. Если люди реально займуться разработкой своего решения, они обратятся и возможно получат ответы на некоторые вопросы.
А просто выкидывать в интернет годы очень сложной работы — мне кажется не целесообразно, как ты думаешь?
Какие у тебя предложения по дополнению статьи? Если услышу хорошие идеи — я мож и дополню ее.
1. Моей задаче полтора месяца от ее постановки, через 3 дня поисков в гугле я знал всё то, что описано в статье, хотя на начало поисков я не знал вообще ничего ни про маршалинг, ни про прокси-стабы. Еще за месяц я реализовал полноценный клиент-сервер дком. До завершенного продукта ему еще предстоит пройти долгий путь, но уже сейчас он работоспособен. Фактически — это своя реализация дком, выдергивающая из системы функционал стандартного маршалинга. Правда, есть свои ограничения. Как оказалось, не маловажные, но решаемые.
2. Да, выкладывать годы работы не целесообразно. Но, как я уже писал выше — нужно сделать для статьи работоспособный пример реализации, который имел бы сильные играничения и упрощения в функционале, но показывал суть метода, которым достигнуто удаленное взаимодействие. Только тогда от статьи будет польза для общественности.
Со временем я, возможно, тоже напишу статью по изложенным выше принципам, идея такая есть, но планов таких пока нет. Идея еще не вызрела, да и достаточно времени пока не предвидится.
Здравствуйте, SPeller, Вы писали:
SP>1. Моей задаче полтора месяца от ее постановки, через 3 дня поисков в гугле я знал всё то, что описано в статье, хотя на начало поисков я не знал вообще ничего ни про маршалинг, ни про прокси-стабы. Еще за месяц я реализовал полноценный клиент-сервер дком. До завершенного продукта ему еще предстоит пройти долгий путь, но уже сейчас он работоспособен. Фактически — это своя реализация дком, выдергивающая из системы функционал стандартного маршалинга. Правда, есть свои ограничения. Как оказалось, не маловажные, но решаемые.
Интересно какие ограничения? У нас можно любой проект пересадить на ComBridge за 5 мин, не меня только 1 строчку кода на клиенте и добавляя 1 на сервере. т.е. под ComBridge не надо писать специальный код. Наши приложениея имеют переключатель DCOM\ComBridge и даже не знают через что работают. Огромная распределенная система.
SP>2. Да, выкладывать годы работы не целесообразно. Но, как я уже писал выше — нужно сделать для статьи работоспособный пример реализации, который имел бы сильные играничения и упрощения в функционале, но показывал суть метода, которым достигнуто удаленное взаимодействие. Только тогда от статьи будет польза для общественности.
Пример работы с нашей либой дан. А для того собрать работоспособный пример from scratch надо написать еще код передающей(например сокетной) подсистемы. Ты какой пример имел ввиду?
SP>Со временем я, возможно, тоже напишу статью по изложенным выше принципам, идея такая есть, но планов таких пока нет. Идея еще не вызрела, да и достаточно времени пока не предвидится.
A>Интересно какие ограничения? У нас можно любой проект пересадить на ComBridge за 5 мин, не меня только 1 строчку кода на клиенте и добавляя 1 на сервере. т.е. под ComBridge не надо писать специальный код. Наши приложениея имеют переключатель DCOM\ComBridge и даже не знают через что работают. Огромная распределенная система.
У нас готовой системы нет, поэтому можно варьировать. Одним из принципов была независимость от реестра. Использую перехват API функций, который нужно сделать до инициализации COM-RPC runtime, который запоминает адреса оригинальных функций и после этого момента перехватить то что надо не удастся. Если только не использовать правку первых байт оригинальной функции, но от этого я решил отказаться.
Кроме того, моя система одновременно работает как со стандартным DCOM, так и со своим. А ваша?
A>Пример работы с нашей либой дан. А для того собрать работоспособный пример from scratch надо написать еще код передающей(например сокетной) подсистемы. Ты какой пример имел ввиду?
И это тоже. Возможно, я мыслю дельфийскими критериями, по которым можно за 20 минут накидать простой клиент-сервер на TServerSocket и TClientSocket, не знаю сколько времени занимает такая задача на сях. Больше всего же важно как заставить маршалить интерфейсы. Циферки-буковки бегают без проблем. Так же, есть проблема вложенных вызовов, когда клиент вызывает метод сервера, а тот делает вызов клиента.
A>А времени эта штука у тебя съест немеряно.
Не сомневаюсь. Поэтому и не собираюсь за это хвататься сейчас.
Здравствуйте, SPeller, Вы писали:
A>>Интересно какие ограничения? У нас можно любой проект пересадить на ComBridge за 5 мин, не меня только 1 строчку кода на клиенте и добавляя 1 на сервере. т.е. под ComBridge не надо писать специальный код. Наши приложениея имеют переключатель DCOM\ComBridge и даже не знают через что работают. Огромная распределенная система.
SP>У нас готовой системы нет, поэтому можно варьировать. Одним из принципов была независимость от реестра. Использую перехват API функций, который нужно сделать до инициализации COM-RPC runtime, который запоминает адреса оригинальных функций и после этого момента перехватить то что надо не удастся. Если только не использовать правку первых байт оригинальной функции, но от этого я решил отказаться.
SP>Кроме того, моя система одновременно работает как со стандартным DCOM, так и со своим. А ваша?
Читай выше
A>>Пример работы с нашей либой дан. А для того собрать работоспособный пример from scratch надо написать еще код передающей(например сокетной) подсистемы. Ты какой пример имел ввиду?
SP>И это тоже. Возможно, я мыслю дельфийскими критериями, по которым можно за 20 минут накидать простой клиент-сервер на TServerSocket и TClientSocket, не знаю сколько времени занимает такая задача на сях. Больше всего же важно как заставить маршалить интерфейсы. Циферки-буковки бегают без проблем. Так же, есть проблема вложенных вызовов, когда клиент вызывает метод сервера, а тот делает вызов клиента.
A>>А времени эта штука у тебя съест немеряно.
SP>Не сомневаюсь. Поэтому и не собираюсь за это хвататься сейчас.
Если ты на делфи, читай про интерсепторы. У нас задача сложнее — надо все интерфейсы чтобы работали, а не только OLE.
Я в статье сделал простенький пример, он правда не передает данные далеко, просто показывает что вклинится реально.
A>Если ты на делфи, читай про интерсепторы. У нас задача сложнее — надо все интерфейсы чтобы работали, а не только OLE. A>Я в статье сделал простенький пример, он правда не передает данные далеко, просто показывает что вклинится реально.
Дык у нас тоже все будут работать. И то что в системе зарегано, и своё, лишь бы typelib был доступен. Система сама прокси-стабы нам изготовит для маршалинга. А вот как и где ловить этот момент для пересылки — тут уже другой разговор. Здесь-то и интереснее всего.
A>Наши приложениея имеют переключатель DCOM\ComBridge и даже не знают через что работают
Я имел ввиду можно ли с вашим переключателем работать в одном процессе одновременно со стандартным DCOM и ComBridge?
Re[2]: COMBridge DEMO
От:
Аноним
Дата:
30.05.09 03:27
Оценка:
Здравствуйте, Figaro, Вы писали:
F>а 500 убитых президентов немного ли?
Лет 5 назад я занимался этим-же, многое было сделано, но потом забросил в виду слишком сомнительных коммерческих перспектив. Не думаю, что ситуация с тех пор в этом плане улучшилась Хотя кто знает, если всерьёз займутся продвижением, то может и прорвутся, так что авторам можно только пожелать удачи
Здравствуйте, SPeller, Вы писали:
A>>Наши приложениея имеют переключатель DCOM\ComBridge и даже не знают через что работают
SP>Я имел ввиду можно ли с вашим переключателем работать в одном процессе одновременно со стандартным DCOM и ComBridge?
Да, конечно, только интерфейсы полученные прямо или косвено из ComBridge работают через него.
т.е. если создаешь объект через ComBridge то все его интерфейсы и все что из него можно получить будет на канале ComBridge с тем компом откуда получили первый объект. И при этом можно из одного процесса с любым количеством компов по ComBridge связаться. И DCOM обычный и COM можно использовать. Т.е. сядешь на тот канал на котором создал первый объект. Создал на DCOM -на нем и будешь.
Здравствуйте, SPeller, Вы писали:
A>>Если ты на делфи, читай про интерсепторы. У нас задача сложнее — надо все интерфейсы чтобы работали, а не только OLE. A>>Я в статье сделал простенький пример, он правда не передает данные далеко, просто показывает что вклинится реально.
SP>Дык у нас тоже все будут работать. И то что в системе зарегано, и своё, лишь бы typelib был доступен. Система сама прокси-стабы нам изготовит для маршалинга. А вот как и где ловить этот момент для пересылки — тут уже другой разговор. Здесь-то и интереснее всего.
я говорю, посмтори статью про интерцепторы тут на rsdn. Там уже все сделано что необходимо для Delphi.
Но вообще конечно мне не понтно желание работать с Delphi когда есть шарп. А в дотнете решена поблема транспортов.
Здравствуйте, Figaro, Вы писали:
F>а 500 убитых президентов немного ли?
Давай рассуждать так: что для Вашей конторы выгоднее, содерджать программера довольно высокого уровня несколько лет, пока он изучает все плохо документированные особенности DCOM и потом еще долго собирает все знания в соложнейший проукт, или отдать за готовое, прошедшее суровое тестирование решение всего половину его месячной зарплаты?
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Figaro, Вы писали:
F>>а 500 убитых президентов немного ли?
А>Лет 5 назад я занимался этим-же, многое было сделано, но потом забросил в виду слишком сомнительных коммерческих перспектив. Не думаю, что ситуация с тех пор в этом плане улучшилась Хотя кто знает, если всерьёз займутся продвижением, то может и прорвутся, так что авторам можно только пожелать удачи
спасибо!!! Действительно, раскрутка — дело сложное.
Здравствуйте, araud, Вы писали:
A>Здравствуйте, Figaro, Вы писали:
F>>а 500 убитых президентов немного ли? A>Давай рассуждать так: что для Вашей конторы выгоднее, содерджать программера довольно высокого уровня несколько лет, пока он изучает все плохо документированные особенности DCOM и потом еще долго собирает все знания в соложнейший проукт, или отдать за готовое, прошедшее суровое тестирование решение всего половину его месячной зарплаты?
К тому же вывести проект из локальной сети в интернет за 500$ и 1 час работы, да еще параллельно избавившись от проблем с настройками безопасности, да еще ускорив сетевой обмен данными, помоему, вполне заманчиво. Я думаю, когда пойдут продажи, мы еще повысим цену.
Здравствуйте, Figaro, Вы писали:
F>Выы принципе правы, но видимо у меня еще советско-российский менталитет
Да я прекрасно Вас понимаю. Мы написали сами кучу всего того, что можно было просто купить для наших проектов
Это зависит от политики фирмы. Кстати, потестите демку, оцените — может пригодится в Ваших проектах?
Здравствуйте, Figaro, Вы писали:
F>А почему ограничение на один порт per process?
На сервере. На клиенте можно поключатся к любому количеству серверов.
На сервере я не вижу смысла открывать несколько портов делающих одно и тоже. Нужно будет в файрволы по несколько потров прописывать, а реальной выгоды я не вижу.
Если Вы сможете привести пример, как может пригодится несколько портов у сервера, я сделаю несколько
На деле, там у нас один из компонентов — полноценный вебсервер, открыть на нем еще порт дело не хитрое. Просто пока незачем
A>я говорю, посмтори статью про интерцепторы тут на rsdn. Там уже все сделано что необходимо для Delphi. A>Но вообще конечно мне не понтно желание работать с Delphi когда есть шарп. А в дотнете решена поблема транспортов.
Что-то я не нашел ничего с дельфийскими примерами. Видел только статью про интерсептор в первой части про перехват методов COM интерфейсов, но там всё тот же си. Да и вообще, какая разница на чем писать? У каждого языка есть свои плюсы. У нас задействованы плюсы дельфей. Тем более, что 2009-я стала достаточно вкусной. Кроме того, против дотнета у нас есть свои моменты. Да и свой транспорт можно будет расширить и общаться хоть по почте, добавлять любое шифрование. Я не стал завязываться на TCP и сделал основу расширяемой. Можно пайпы задействовать для общения внутри компа, можно вообще прямые вызовы делать если в одном процессе клиент и сервер. Да, это всё смахивает на то, что уже реализовано в COM, но я делаю упор на то, что приложение не зависит от регистраций компонент в реестре. Запустил — заработало, не ругается что "интерфейс не зарегистрирован". Это во-первых, а во-вторых, у юзера не всегда могут быть права на запись в реестр. И вообще, я противник загаживания реестра
A>если создаешь объект через ComBridge то все его интерфейсы и все что из него можно получить будет на канале ComBridge с тем компом A>откуда получили первый объект
У меня так же ) Можно создавать сколько угодно серверов и клиентских соединений. Где объект создался, там и будет висеть связь с ним.
Еще вопрос — у вас потоковые модели поддерживаются все?
Если вспомнить классику, то старый любимый POP3... Порты на память не помню, но для KOI8-R и CP1251 они различались.
Хотя это все некритично, но не люблю ограничений Сегодня-завтра гляну, демку скачал...
Здравствуйте, SPeller, Вы писали:
A>>я говорю, посмтори статью про интерцепторы тут на rsdn. Там уже все сделано что необходимо для Delphi. A>>Но вообще конечно мне не понтно желание работать с Delphi когда есть шарп. А в дотнете решена поблема транспортов.
SP>Что-то я не нашел ничего с дельфийскими примерами. Видел только статью про интерсептор в первой части про перехват методов COM интерфейсов, но там всё тот же си. Да и вообще, какая разница на чем писать? У каждого языка есть свои плюсы. У нас задействованы плюсы дельфей. Тем более, что 2009-я стала достаточно вкусной. Кроме того, против дотнета у нас есть свои моменты. Да и свой транспорт можно будет расширить и общаться хоть по почте, добавлять любое шифрование. Я не стал завязываться на TCP и сделал основу расширяемой. Можно пайпы задействовать для общения внутри компа, можно вообще прямые вызовы делать если в одном процессе клиент и сервер. Да, это всё смахивает на то, что уже реализовано в COM, но я делаю упор на то, что приложение не зависит от регистраций компонент в реестре. Запустил — заработало, не ругается что "интерфейс не зарегистрирован". Это во-первых, а во-вторых, у юзера не всегда могут быть права на запись в реестр. И вообще, я противник загаживания реестра
A>>если создаешь объект через ComBridge то все его интерфейсы и все что из него можно получить будет на канале ComBridge с тем компом A>>откуда получили первый объект
SP>У меня так же ) Можно создавать сколько угодно серверов и клиентских соединений. Где объект создался, там и будет висеть связь с ним.
SP>Еще вопрос — у вас потоковые модели поддерживаются все?
Да, но основное тестирование было на малтитредет.
Здравствуйте, Figaro, Вы писали:
F>Если вспомнить классику, то старый любимый POP3... Порты на память не помню, но для KOI8-R и CP1251 они различались. F>Хотя это все некритично, но не люблю ограничений Сегодня-завтра гляну, демку скачал...
Здравствуйте, SPeller, Вы писали:
A>>несколько лет, пока он изучает все плохо документированные особенности DCOM
SP>Как показал опыт — не обязательно тратить несколько лет на это
Я думаю, задача поддержать только ole совместимые интерфейсы действительно не сложна.
А вот ВСЕ случаи DCOM-а это уже посложнее. Одни асинхронные вызовы чего стоят. Да еще добится чтобы эта схема была оптимальна с точки зрения трафика и скорости вызова. Сделать чтобы все это не блокировалось при хаотическом использовании не менее чем 900 интерфесов одновременно. Еще очень много всяких тонкостей, многие из которых не документированы вообще, но если их не реализовать, то будет очень странно глючить.
A>Я думаю, задача поддержать только ole совместимые интерфейсы действительно не сложна. A>А вот ВСЕ случаи DCOM-а это уже посложнее. Одни асинхронные вызовы чего стоят. Да еще добится чтобы эта схема была оптимальна с точки зрения трафика и скорости вызова. Сделать чтобы все это не блокировалось при хаотическом использовании не менее чем 900 интерфесов одновременно. Еще очень много всяких тонкостей, многие из которых не документированы вообще, но если их не реализовать, то будет очень странно глючить.
У меня небыло цели держать только OLE, хотя использую пока только OLE-совместимые интерфейсы. Но разве есть разница если прокси-стабы я создаю через CreateXXXXFromTypeInfo? Мне совершенно фиолетово что и как передается в параметрах, маршалингом всего этого добра занимается система. Интерфейсы в параметрах я тоже не руками вытаскиваю, а предоставляю эту заботу системе, я только отдаю ей свои данные для записи в пакет, который пойдет на другую сторону. Асинхронные вызовы... На дельфе это сделать так, как делает студия, не получится, поэтому на этом не заостряюсь, но моя система позволяет делать асинхронные запросы серверу без ожидания ответа. Можно сделать, например, чтобы функции, чье имя начинается на Async, вызывались асинхронно. Замаскироваться и действовать как система вряд ли получится, но создавать код, изначально рассчитанный на такую работу — можно. Про асинхронные вызовы читал, суть работы представляю, реализовать можно. Понадобится — можно и broadcast сделать. Вобщем, направления у нас с вами разные, конкурентами если и будем, то не сильно
Здравствуйте, SPeller, Вы писали:
A>>Я думаю, задача поддержать только ole совместимые интерфейсы действительно не сложна. A>>А вот ВСЕ случаи DCOM-а это уже посложнее. Одни асинхронные вызовы чего стоят. Да еще добится чтобы эта схема была оптимальна с точки зрения трафика и скорости вызова. Сделать чтобы все это не блокировалось при хаотическом использовании не менее чем 900 интерфесов одновременно. Еще очень много всяких тонкостей, многие из которых не документированы вообще, но если их не реализовать, то будет очень странно глючить.
SP>У меня небыло цели держать только OLE, хотя использую пока только OLE-совместимые интерфейсы. Но разве есть разница если прокси-стабы я создаю через CreateXXXXFromTypeInfo? Мне совершенно фиолетово что и как передается в параметрах, маршалингом всего этого добра занимается система. Интерфейсы в параметрах я тоже не руками вытаскиваю, а предоставляю эту заботу системе, я только отдаю ей свои данные для записи в пакет, который пойдет на другую сторону. Асинхронные вызовы... На дельфе это сделать так, как делает студия, не получится, поэтому на этом не заостряюсь, но моя система позволяет делать асинхронные запросы серверу без ожидания ответа. Можно сделать, например, чтобы функции, чье имя начинается на Async, вызывались асинхронно. Замаскироваться и действовать как система вряд ли получится, но создавать код, изначально рассчитанный на такую работу — можно. Про асинхронные вызовы читал, суть работы представляю, реализовать можно. Понадобится — можно и broadcast сделать. Вобщем, направления у нас с вами разные, конкурентами если и будем, то не сильно
CreateXXXXFromTypeInfo требует наличия TypeInfo
И можно ли пересадить на Ваш транспорт ЛЮБОЙ поект, не изменяя код, кроме кода установки соединения с сервером?
A>CreateXXXXFromTypeInfo требует наличия TypeInfo A>И можно ли пересадить на Ваш транспорт ЛЮБОЙ поект, не изменяя код, кроме кода установки соединения с сервером?
Чтобы получить TypeInfo нужна Typelib, которая нужна и стандартному DCOM-у, без этого компонента никто не сможет работать, бо иных стандартных средств описания интерфейсов, функций и параметров нет.
На мой транспорт ЛЮБОЙ проект без доработок не пересадишь, потому что мой транспорт ничего не берет из реестра со всеми вытекающими. Мой транспорт заменяет собой DCOM, а не встраивается в существующий, потому и полностью совместимым он быть не может.
Здравствуйте, SPeller, Вы писали:
A>>CreateXXXXFromTypeInfo требует наличия TypeInfo A>>И можно ли пересадить на Ваш транспорт ЛЮБОЙ поект, не изменяя код, кроме кода установки соединения с сервером?
SP>Чтобы получить TypeInfo нужна Typelib, которая нужна и стандартному DCOM-у, без этого компонента никто не сможет работать, бо иных стандартных средств описания интерфейсов, функций и параметров нет.
-- да ты чо, либо я чего то незнал, либо ты Библиотека типов не нужна не оле совместимым интерфейсам. Я вырубаю генерацию библиотеки типов во всех своих проектах и нет никаких проблем. Библиотека типов нужна только для динамического связывания.
SP>На мой транспорт ЛЮБОЙ проект без доработок не пересадишь, потому что мой транспорт ничего не берет из реестра со всеми вытекающими. Мой транспорт заменяет собой DCOM, а не встраивается в существующий, потому и полностью совместимым он быть не может.
--Ясно, оттого и сложность нашего проекта, что он ведет себя полностью как DCOM, со всеми тонкостями.
A>-- да ты чо, либо я чего то незнал, либо ты Библиотека типов не нужна не оле совместимым интерфейсам. Я вырубаю генерацию библиотеки типов во всех своих проектах и нет никаких проблем. Библиотека типов нужна только для динамического связывания.
Ты забыл что дельфя не генерит прокси-стабы как это делает студия. У вас прокси-стабы статические, а в дельфе такие стабы либо писать руками, либо генерить динамически на основе библиотеки типов. Ку?
Здравствуйте, SPeller, Вы писали:
A>>-- да ты чо, либо я чего то незнал, либо ты Библиотека типов не нужна не оле совместимым интерфейсам. Я вырубаю генерацию библиотеки типов во всех своих проектах и нет никаких проблем. Библиотека типов нужна только для динамического связывания.
SP>Ты забыл что дельфя не генерит прокси-стабы как это делает студия. У вас прокси-стабы статические, а в дельфе такие стабы либо писать руками, либо генерить динамически на основе библиотеки типов. Ку?
Действительно забыл . Я на делфе в последний раз что-то делал лет 6 назад
Хотя кто знает, если всерьёз займутся продвижением, то может и прорвутся, так что авторам можно только пожелать удачи 
