Здравствуйте.
Кто что думает по поводу прав ли я? По моему dll в подавляющем большенстве случаев хуже COM. И нужно стараться всегда использовать COM. А?
Ветку, конечно, можно и в войны отправить, но хотелось бы сначала получить хотябы несколько ответов 10 авторитетных жителей этого форума.
Здравствуйте, Ellin, Вы писали:
E>Кто что думает по поводу прав ли я? По моему dll в подавляющем большенстве случаев хуже COM. И нужно стараться всегда использовать COM. А?
Все зависит от того, что вы понимаете под COM и как вы собираетесь его использовать. Я для себя разделяю на две части: идеология COM и Windows COM Runtime.
1) Идеология COM: программа разбита на объекты, поддерживающие один или несколько хорошо определенных интерфейсов, существуют правила для управления временем жизни объектов, для передачи входных и выходных параметров и т.д.
По моему мнению, идеология COM несомненно выигрывает по сравнению с DLL:
* во-первых, натурально поддерживается объектный подход;
* во-вторых, наличие четко описанных правил передачи параметров и управления временем жизни объектов сильно упрощает командную разработку и повторное использования кода, поскольку все участники хорошо знакомы с этими правилами.
Я уже долгое время строю свои приложения по такому принципу и еще ни разу не пожалел об этом.
2) Windows COM Runtime: регистрация объектов и интерфейсов, CoCreateInstance и прочие Co-функции, межпроцессное и межпоточное взаимодействие.
С регистрацией есть проблема — объекты регистрируются в системе глобально. Это значит, что если вы оформили вашу библиотеку как COM объект, зарегистрированный в системе, все приложения будут пользоваться одной и той же копией. Это затрудняет распространение приложений, поскольку приложения должны заботиться, чтобы не заменить уже существующую версию библиотеки более старой.
Если вы не собираетесь интегрироваться со сторонними продуктами или открывать свои интерфейсы для сторонних разработчиков, и все объекты находятся в одном процессе, регистрация объектов в реестре и COM runtime вам скорее всего ни к чему.
Если вы встраиваетесь в другое приложение, которое создает объекты посредством CoCreateInstance, — у вас нет выбора, надо регистрироваться.
Другое оправданное использование COM runtime — это построение интерфейса между процессами. Например, если у вас есть windows service и клиентское приложение, которое должно с ним взаимодействовать, то COM — пожалуй, один из лучших способов организовать такое взаимодействие.
Таким образом, вам нужно постараться понять, чего вы хотите достичь и каким образом COM поможет вам в этом. Использование идеологии COM почти наверняка не навредит, а вот зависимость на регистрацию объектов может доставить хлопот.
AF>С регистрацией есть проблема — объекты регистрируются в системе глобально. Это значит, что если вы оформили вашу библиотеку как COM объект, зарегистрированный в системе, все приложения будут пользоваться одной и той же копией. Это затрудняет распространение приложений, поскольку приложения должны заботиться, чтобы не заменить уже существующую версию библиотеки более старой.
Это всё легко обходится начиная с Win98 — компоненты устанавливаются в каталог с приложением, создаётся файл MyComponent.Dll.local. Справедливости ради надо отметить что это замечательно работает как с COM-овскими, так и с не-COM-овскими Dll
Ещё я бы отметил такой минус как необходимость наличия администраторских прав для регистрации COM Dll. Хотя опять же — и это обходится, хотя и с чуть большими ухищрениями (через RegOverridePredefKey).
Интерестно, но интересует следующий момент :
-пусть есть COM Server (myServ.dll)
-приложение MyApp1.exe, использующее myServ.dll текущей версии, есть файл MyApp1.exe.local
-приложение MyApp2.exe, использующее myServ.dll более ранней версии, есть файл MyApp2.exe.local
-приложение MyApp3.exe, использующее myServ.dll пофиг какой версии, нет файла MyApp3.exe.local
каждое приложение находится в своей дирректории и в дирректориях для приложений MyApp1.exe && MyApp2.exe существуют копии myServ.dll необходимых версий.
Естественно интерфейсы myServ.dll текущей и более ранней версий совпадают.
Вопрос 1 : какой myServ.dll должен быть зарегистрирован в системе? MyApp1/myServ.dll или MyApp2/myServ.dll или это пофиг?
Вопрос 2, скорее риторический : какой myServ.dll будет использоваться для MyApp3.exe? Зарегистрированный в "Вопрос 1"?
Здравствуйте, Left2, Вы писали:
L>Это всё легко обходится начиная с Win98 — компоненты устанавливаются в каталог с приложением, создаётся файл MyComponent.Dll.local. Справедливости ради надо отметить что это замечательно работает как с COM-овскими, так и с не-COM-овскими Dll
Очень ориганально! Однако не очень практично, я бы сказал что не работает. Предположим, что у нас приложение состоит из 5-ти программ, которые используют наш компонент. Получается, что надо для каждой программы сделать копию нашей библиотеки. По моему очень не удобно. Постоянно следить за каждой библиотекой в отдельности.
А как решение: не выпускать новые версии компонентов, а выпускать новые компоненты — по моему хорошо решает заданный вопрос. Как там в DirectX DirectDraw1, DirectDraw2 и т.д. и ничего переписывать не придется.
L>Ещё я бы отметил такой минус как необходимость наличия администраторских прав для регистрации COM Dll. Хотя опять же — и это обходится, хотя и с чуть большими ухищрениями (через RegOverridePredefKey).
А подробнее можно?
Здравствуйте, Left2, Вы писали:
L>Ещё я бы отметил такой минус как необходимость наличия администраторских прав для регистрации COM Dll. Хотя опять же — и это обходится, хотя и с чуть большими ухищрениями (через RegOverridePredefKey).
Здравствуйте, ssm, Вы писали:
ssm>Интерестно, но интересует следующий момент : ssm> -пусть есть COM Server (myServ.dll) ssm> -приложение MyApp1.exe, использующее myServ.dll текущей версии, есть файл MyApp1.exe.local ssm> -приложение MyApp2.exe, использующее myServ.dll более ранней версии, есть файл MyApp2.exe.local ssm> -приложение MyApp3.exe, использующее myServ.dll пофиг какой версии, нет файла MyApp3.exe.local
Я так понял что версии — не важно. Вот зарегестрирована офицально dll — ее все берут, а если лежит MyApp3.exe.local
,например, то берут dll из своей папки. Например если зарегестрирована официально ранняя версия и все берут ее, а если в папке лежит dll+MyApp3.exe.local то берут именно эту dll вне зависимости от того — еще более ранняя она, или уже гораздо более новая.
А если в папке лежит MyApp3.exe.local и нету dll, то берут официальную dll — ту, которая по дефолту.
ssm>каждое приложение находится в своей дирректории и в дирректориях для приложений MyApp1.exe && MyApp2.exe существуют копии myServ.dll необходимых версий. ssm>Естественно интерфейсы myServ.dll текущей и более ранней версий совпадают. ssm>Вопрос 1 : какой myServ.dll должен быть зарегистрирован в системе? MyApp1/myServ.dll или MyApp2/myServ.dll или это пофиг?
Да, помоему пофиг, хоть вообще третья какая-нить. ssm>Вопрос 2, скорее риторический : какой myServ.dll будет использоваться для MyApp3.exe? Зарегистрированный в "Вопрос 1"?
Официально зарегестрированный под компонент.
Если я не прав, то поправят. Но походу я правильно понял.
E>Если я не прав, то поправят. Но походу я правильно понял.
По ходу правильно.
Наличие файла local всего лишь меняет порядок просмотра каталогов для LoadLibrary — первым берётся каталог, в котором лежит .Exe который запустил процесс. В HKCR может быть зарегистрирована Dll, которая лежит где угодно, лишь бы имя самого файла было правильно указано, сам path значения не имеет.
E>Очень ориганально! Однако не очень практично, я бы сказал что не работает. Предположим, что у нас приложение состоит из 5-ти программ, которые используют наш компонент. Получается, что надо для каждой программы сделать копию нашей библиотеки. По моему очень не удобно. Постоянно следить за каждой библиотекой в отдельности.
С современными винчестерами, когда мегабайты никто не считает, это куда проще чем заботится о версиях.
E>А как решение: не выпускать новые версии компонентов, а выпускать новые компоненты — по моему хорошо решает заданный вопрос. Как там в DirectX DirectDraw1, DirectDraw2 и т.д. и ничего переписывать не придется.
Это хорошо только на бумаге. В реальности при таком подходе тестирование быстро превращается в ад.
L>>Ещё я бы отметил такой минус как необходимость наличия администраторских прав для регистрации COM Dll. Хотя опять же — и это обходится, хотя и с чуть большими ухищрениями (через RegOverridePredefKey). E>А подробнее можно?
Делаешь ключик в HKCU, и мэпишь его хоть в HKLM, хоть в HKCR.
Строго говоря, если ты можешь управлять регистрацией (DllRegisterServer пишешь ты), то даже такие ухищрения не нужны — просто пишешь не в HKCR\CLSID а в HKCU\Software\Classes\CLSID. А вот если регистрируешь чужую Dll и прав админа у тебя нет — тогда нужно подменять HKCR на HKCU\Software\Classes с помощью этой функции.
Здравствуйте, Left2, Вы писали:
L>С современными винчестерами, когда мегабайты никто не считает, это куда проще чем заботится о версиях.
Ой, да про винчестеры речи и не идет. Мой вариант тоже не сахр в этом плане. А вот когда у тебя dll местах, а про 51 давно забыл(они ведь в реестре не пишутся.(!)), а 52 и 53 вообще другие лиди копировали в директории, — то при выпуске новой версии можно просто не полностью провести обновление.
L>Это хорошо только на бумаге. В реальности при таком подходе тестирование быстро превращается в ад.
Тут я не понял. Почему? все вроде нормально должно быть, — все равно что с отдельным компонентом работаешь. Только корректно имена для интерфейсов подбирать и все.
L>Строго говоря, если ты можешь управлять регистрацией (DllRegisterServer пишешь ты), то даже такие ухищрения не нужны — просто пишешь не в HKCR\CLSID а в HKCU\Software\Classes\CLSID. А вот если регистрируешь чужую Dll и прав админа у тебя нет — тогда нужно подменять HKCR на HKCU\Software\Classes с помощью этой функции.
Да ну! Это делать врядли надо. А если я забуду в какой dll у меня глобальная регистрация, а в какой для конкретного пользователя? Как такое помнить можно. И как мне потом ее глобально регистрировать, если понадобится?
Здравствуйте, Left2, Вы писали:
L>Всё верно. Проблемы начинаются когда нужно зарегистрировать чужую COM Dll без прав администратора.
Вариант — посмотреть тем или иным образом (например, с помощью того же RegOverridePredefKey), что имеено при регистрации dll-ка пытается прописать в HKCR и руками написать .reg — файл, который пропишет то же самое, только в HKCU\Classes
E>Ой, да про винчестеры речи и не идет. Мой вариант тоже не сахр в этом плане. А вот когда у тебя dll местах, а про 51 давно забыл(они ведь в реестре не пишутся.(!)), а 52 и 53 вообще другие лиди копировали в директории, — то при выпуске новой версии можно просто не полностью провести обновление.
Не понял. Если у тебя другие люди копируют что-то в каталоги после установки программы, то можешь смело при возникновении проблем отсылать к этим людям. В конце концов, если каждый кому не лень правит каталог Program Files, работоспособность программы обеспечить очень тяжело
L>>Это хорошо только на бумаге. В реальности при таком подходе тестирование быстро превращается в ад. E>Тут я не понял. Почему? все вроде нормально должно быть, — все равно что с отдельным компонентом работаешь. Только корректно имена для интерфейсов подбирать и все.
Это я тебя неправильно понял. Я думал ты говоришь о наследовании IFoo -> IFoo2 -> IFoo3, когда обьект поддерживает все, и новые и старые, интерфейсы. Кстати, в DirectX подход ближе всё-таки к этому, а не к тому о котором говоришь ты. А не выпускать новые версии компонентов вообще — тоже не очень хорошо, ты ведь не заставишь всех пользователей твоей библиотеки пересобирать свои программы после того как ты пофиксил какой-то баг у себя.
L>>Строго говоря, если ты можешь управлять регистрацией (DllRegisterServer пишешь ты), то даже такие ухищрения не нужны — просто пишешь не в HKCR\CLSID а в HKCU\Software\Classes\CLSID. А вот если регистрируешь чужую Dll и прав админа у тебя нет — тогда нужно подменять HKCR на HKCU\Software\Classes с помощью этой функции. E>Да ну! Это делать врядли надо. А если я забуду в какой dll у меня глобальная регистрация, а в какой для конкретного пользователя? Как такое помнить можно. И как мне потом ее глобально регистрировать, если понадобится?
Ничего не понял. Что нужно помнить и, главное, зачем? Если у юзера нет админских прав — он может поставить компонент только "для себя", никто другой его не увидит пока не поставит сам.
Здравствуйте, Left2, Вы писали:
L>Подробнее тут [skipped]
Ах, какая симпатичная дырочка в защите.
Кстати, а прокомментируй твое предыдущее "...компоненты устанавливаются в каталог с приложением, создаётся файл MyComponent.Dll.local" по поводу выделенного. Вроде не срабатывает, или это для обычных DLL?
Здравствуйте, Alex Fedotov, Вы писали:
AF>1) Идеология COM: программа разбита на объекты, поддерживающие один или несколько хорошо определенных интерфейсов, существуют правила для управления временем жизни объектов, для передачи входных и выходных параметров и т.д.
AF>По моему мнению, идеология COM несомненно выигрывает по сравнению с DLL: AF>* во-первых, натурально поддерживается объектный подход; AF>* во-вторых, наличие четко описанных правил передачи параметров и управления временем жизни объектов сильно упрощает командную разработку и повторное использования кода, поскольку все участники хорошо знакомы с этими правилами.
Это несравнимые разноуровневые вещи. COM-объекты в конце концов в основном в DLL и живут Управление временем жизни объекта через счетчик ссылок — это не только в COM принято, это везде. Причем, не всегда удобная это штука, особенно когда ссылки закольцовываются. Передача параметров в пределах приложения — никаких особенных правил не требует из-за единого адресного пространства, in/out не работают. QueryInterface заставляет использовать ATL (COM без ATL — рукоблудство) и прилеплять везде uuid'ы (чтобы uuidof работал), что в пределах одного приложения где весь код "наш" не нужно, там всяческие касты будут работать будь здоров, и во время компиляции вывалится часть ошибок, которые бы вылезли только в рантайме. Множественно наследоваться от интерфейсов — идея тоже не из COM'а родилась, в COM придумали кастить к интерфейсам в рантайме через uuid'ы (что полезно только при работе с чужим кодом).
Даже не рассматриваем переносимость между платформами. Простая замена компилятора на одной платформе не всегда возможна (из-за ATL, например).
В итоге — идеология COM даже для локального применени слегонца перегружена ненужными сущностями, завязанными еще и на рантайм (пронаследовался от интерфейса и забыл включить его в интерфейс-мап — получите misbehavior). Нужно это кому или нет — думайте сами. Но уж делать все подряд с использованием этой идеологии я бы поостерегся.
А про COM-рантайм — согласен на все 100, это неизбежное зло
Ну почему же — если у тебя есть права на запись в каталог где установлена программа, то ты можешь и сам Exe-шник поправить. Так что я бы это такой уж дыркой в защите не назвал.
Vi2>Кстати, а прокомментируй твое предыдущее "...компоненты устанавливаются в каталог с приложением, создаётся файл MyComponent.Dll.local" по поводу выделенного. Вроде не срабатывает, или это для обычных DLL?
На самом деле имел в виду MyComponent.Exe.local — описАлся.
aik>Передача параметров в пределах приложения — никаких особенных правил не требует из-за единого адресного пространства,
Не совсем так. Передача, к примеру, строк в/из Dll требует серьёзных извращений (почитай как народ мучается при передаче std::string или std::vector между двумя модулями, скомпилированными с разными CRT).
Здравствуйте, Left2, Вы писали:
L>Ещё я бы отметил такой минус как необходимость наличия администраторских прав для регистрации COM Dll.
не админских, а Power User
Здравствуйте, Left2, Вы писали:
aik>>Передача параметров в пределах приложения — никаких особенных правил не требует из-за единого адресного пространства, L>Не совсем так. Передача, к примеру, строк в/из Dll требует серьёзных извращений (почитай как народ мучается при передаче std::string или std::vector между двумя модулями, скомпилированными с разными CRT).
Дискуссия пошла в сторону Во1ых, с привлечением COM'а проблема не исчезнет. COM вовсе про такие приколы не понимает. Во2ых, от CRT либо лучше сразу избавиться, либо использовать динамический CRT.
aik>Дискуссия пошла в сторону Во1ых, с привлечением COM'а проблема не исчезнет. COM вовсе про такие приколы не понимает. Во2ых, от CRT либо лучше сразу избавиться, либо использовать динамический CRT.
1. C привлечением COM строки передаются как BSTR, и об этих проблемах забывают
2. от CRT избавиться не так-то просто. Динамический CRT заставляет таскать с собой дополнительные Dll, которые к тому же никак не решают проблемы если какая-то из Dll с которыми ты взаимодействуешь линкует CRT статически
Вообще-то главная моя мысль была в том что в COM передача строк стандартизована, за что ему низкий поклон — не имеем проблем на казалось бы ровном месте.
Здравствуйте, Left2, Вы писали:
aik>>Дискуссия пошла в сторону Во1ых, с привлечением COM'а проблема не исчезнет. COM вовсе про такие приколы не понимает. Во2ых, от CRT либо лучше сразу избавиться, либо использовать динамический CRT. L>1. C привлечением COM строки передаются как BSTR, и об этих проблемах забывают
BSTR тебе никто не запрещает использовать и без COM'а.
L>2. от CRT избавиться не так-то просто. Динамический CRT заставляет таскать с собой дополнительные Dll, которые к тому же никак не решают проблемы если какая-то из Dll с которыми ты взаимодействуешь линкует CRT статически
msvcrt.dll — она много где есть. Чуть ли не c IE4 пошла. Не надо ее таскать.
L>Вообще-то главная моя мысль была в том что в COM передача строк стандартизована, за что ему низкий поклон — не имеем проблем на казалось бы ровном месте.
Да, но использование BSTR != использованию COM. Да SysAllocString — не самый лучший аллокатор, вообще говоря.
А вообще — не понимаю о чем спорим...
aik>BSTR тебе никто не запрещает использовать и без COM'а.
согласен. но пока не было COM, BSTR тоже не было
aik>msvcrt.dll — она много где есть. Чуть ли не c IE4 пошла. Не надо ее таскать.
Проблема не в отсутствии или наличии msvcrt.dll. Проблема в том что если кто-то ещё использует CRT статически (либо пользует самописный CRT) — будут проблемы.
aik>Да, но использование BSTR != использованию COM. Да SysAllocString — не самый лучший аллокатор, вообще говоря.
BSTR — часть COM, причём неотьемлимая
aik>А вообще — не понимаю о чем спорим... ?
Здравствуйте, Left2, Вы писали:
aik>>BSTR тебе никто не запрещает использовать и без COM'а. L>согласен. но пока не было COM, BSTR тоже не было
Да много чего не было. Под COM MS некоторое количество сопутствующих утилит слабал, потому что просто пришлось. BSTR, реестр и так далее.
aik>>msvcrt.dll — она много где есть. Чуть ли не c IE4 пошла. Не надо ее таскать. L>Проблема не в отсутствии или наличии msvcrt.dll. Проблема в том что если кто-то ещё использует CRT статически (либо пользует самописный CRT) — будут проблемы.
В пределах проекта разный CRT? Бить по рукам.
aik>>Да, но использование BSTR != использованию COM. Да SysAllocString — не самый лучший аллокатор, вообще говоря. L>BSTR — часть COM, причём неотьемлимая
И шо, требует CoInitialize?
aik>>А вообще — не понимаю о чем спорим... L> ?
Здравствуйте, Left2, Вы писали:
aik>>Да, но использование BSTR != использованию COM. Да SysAllocString — не самый лучший аллокатор, вообще говоря. L>BSTR — часть COM, причём неотьемлимая
Но есть же еше LPSTR, LPWSTR и VirtualAlloc, к примеру. Или GlobalAlloc — кому что больше по душе. Использовать библиотеки, в которых происходит выделение памяти посредством runtime между несколькими модулями, имхо, как-то нездраво.
Здравствуйте, aik, Вы писали:
aik>>>msvcrt.dll — она много где есть. Чуть ли не c IE4 пошла. Не надо ее таскать. L>>Проблема не в отсутствии или наличии msvcrt.dll. Проблема в том что если кто-то ещё использует CRT статически (либо пользует самописный CRT) — будут проблемы.
aik>В пределах проекта разный CRT? Бить по рукам.
Никогда не приходилось пользоваться чужими либами без исходников?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, AndrewJD, Вы писали:
aik>>>>msvcrt.dll — она много где есть. Чуть ли не c IE4 пошла. Не надо ее таскать. L>>>Проблема не в отсутствии или наличии msvcrt.dll. Проблема в том что если кто-то ещё использует CRT статически (либо пользует самописный CRT) — будут проблемы. aik>>В пределах проекта разный CRT? Бить по рукам. AJD>Никогда не приходилось пользоваться чужими либами без исходников?
Приходилось, но всегда было из чего выбрать и не пользоваться корявыми либами
Управление временем жизни объекта через счетчик ссылок — это не только в COM принято, это везде. Причем, не всегда удобная это штука, особенно когда ссылки закольцовываются. Передача параметров в пределах приложения — никаких особенных правил не требует из-за единого адресного пространства, in/out не работают. QueryInterface заставляет использовать ATL (COM без ATL — рукоблудство) и прилеплять везде uuid'ы (чтобы uuidof работал), что в пределах одного приложения где весь код "наш" не нужно, там всяческие касты будут работать будь здоров, и во время компиляции вывалится часть ошибок, которые бы вылезли только в рантайме. Множественно наследоваться от интерфейсов — идея тоже не из COM'а родилась, в COM придумали кастить к интерфейсам в рантайме через uuid'ы (что полезно только при работе с чужим кодом).
?
