Тут вот одна мысль посетила — жалко что менеджер InprocServer-ов (DLL с COM-объектами) не поддерживает явную инициализацию и деинициализацию загруженных DLL.
Можно, конечно, выполнять инициализацию/деинициализацию в DllMain. Но в DllMain нельзя запускать и останавливать потоки.
А если бы были явные функции (DllInitialize, DllShutdown), то проблем с потоками не было бы.
Странно что за прошедшие 20 лет в Microsoft такая идея не появилась.
Вроде в Windows 8 они COM достаточно хорошо перетряхнули, а эту вещь не придумали
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
КД>Странно что за прошедшие 20 лет в Microsoft такая идея не появилась. КД>Вроде в Windows 8 они COM достаточно хорошо перетряхнули, а эту вещь не придумали
Дык делаете глобальный референс каунт, считающий инстансы всех объектов, созданных внутри длл, и получается свой DllShutdown при достижении его нуля
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
КД>>Странно что за прошедшие 20 лет в Microsoft такая идея не появилась. КД>>Вроде в Windows 8 они COM достаточно хорошо перетряхнули, а эту вещь не придумали O>Дык делаете глобальный референс каунт, считающий инстансы всех объектов, созданных внутри длл, и получается свой DllShutdown при достижении его нуля
У меня так и сделано прямо сейчас.
Я хочу чтобы потоки продолжали существовать (в пуле) после освобождения последнего COM-объекта.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
O>>Дык делаете глобальный референс каунт, считающий инстансы всех объектов, созданных внутри длл, и получается свой DllShutdown при достижении его нуля
КД>У меня так и сделано прямо сейчас.
КД>Я хочу чтобы потоки продолжали существовать (в пуле) после освобождения последнего COM-объекта.
Imho жизнь потока можно продлить до вызова DllCanUnloadNow. Если DllCanUnloadNow возвращает S_OK, то нужно готовиться к выгрузке и прекращать фоновые работы, а если S_FALSE, то продолжаем делать полезную фоновую работу.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Странно что за прошедшие 20 лет в Microsoft такая идея не появилась. КД>Вроде в Windows 8 они COM достаточно хорошо перетряхнули, а эту вещь не придумали
Я вот в COM более-менее конкретно полез только сейчас, и неимоверно удивился тому, что еще 20 лет в MS не появилась идея сделать хелпер для регистрации/удаления COM-серверов. Они ж везде в документации талдычат: "не лезьте руками в общесистемные ключи реестра, используйте спецфункции". А функции для ключей COM-сервера так и не родили — предлагают использовать общие функции реестра.
Для DirectShow есть костыль в виде AMovieDLLRegisterServer[2], но и он сделан через задницу — регистрирует только фильтры, написанные на их фреймворке Base Classes. Для фильтров, реализующих нужные интерфейсы самостоятельно — пожалте копать реестр вручную.
Ну не дебилизм ли? Интересно, у скольких юзеров такие регистраторы, написанные с ошибками, испортили систему?
Здравствуйте, Евгений Музыченко, Вы писали:
КД>>Странно что за прошедшие 20 лет в Microsoft такая идея не появилась. КД>>Вроде в Windows 8 они COM достаточно хорошо перетряхнули, а эту вещь не придумали
ЕМ>Я вот в COM более-менее конкретно полез только сейчас, и неимоверно удивился тому, что еще 20 лет в MS не появилась идея сделать хелпер для регистрации/удаления COM-серверов. Они ж везде в документации талдычат: "не лезьте руками в общесистемные ключи реестра, используйте спецфункции". А функции для ключей COM-сервера так и не родили — предлагают использовать общие функции реестра.
Лично я дорос до понимания, что саморегистрация COM-объектов это зло
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>саморегистрация COM-объектов это зло КД>Это должен делать инсталлятор.
Да хоть бы и инсталлятор, но не MSI ж единым жив виндовый софт. А на заре COM MSI еще не было. Так что, учитывая обширность COM, MS обязана была предложить соответствующий хелпер еще в 90-х. Для гораздо более мелких и менее критичных вещей хелперы есть, а тут такая засада...
Здравствуйте, Евгений Музыченко, Вы писали:
КД>>саморегистрация COM-объектов это зло КД>>Это должен делать инсталлятор.
ЕМ>Да хоть бы и инсталлятор, но не MSI ж единым жив виндовый софт. А на заре COM MSI еще не было. Так что, учитывая обширность COM, MS обязана была предложить соответствующий хелпер еще в 90-х. Для гораздо более мелких и менее критичных вещей хелперы есть, а тут такая засада...
На заре COM у меня была книжка "Основы COM" Роджерсона. Там был код регистратора, которым я долгое время пользовался. Там работы-то — на 15 минут...
Потом написал свой, более извращенный, на базе XML-правил.
В ATL (не пользуюсь) на 146% тоже есть готовый регистратор.
По мне, поддержка со стороны винды даром не сдалась.
В MS, видимо, подумали так же
Но — если я все правильно помню, они предоставляли компоненты для управления категориями COM-объектов. Про это также было написано в книжке "Основы COM".
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>На заре COM у меня была книжка "Основы COM" Роджерсона. Там был код регистратора, которым я долгое время пользовался. Там работы-то — на 15 минут...
Да не во времени реализации дело, и даже не в сложности. А в том, что всем, кому не лень, предлагается руками (которые не всегда чистые) копаться в общей, и достаточно большой базе. При этом нет никаких технических ограничений на уровень вложенности: одно неверное движение — и ты отец удалена вся ветка CLSID.
КД>В ATL (не пользуюсь) на 146% тоже есть готовый регистратор.
А где в документации по COM предложение использовать ATL? Ну и ATL — это таки парадигма, а должен быть именно независимый хелпер, который можно использовать откуда угодно.
КД>По мне, поддержка со стороны винды даром не сдалась.
Тогда и установка, например, служб или драйверов тоже даром не сдалась — там действия ненемного сложнее. Пусть бы каждый установщик создавал нужные ключи вручную, делов-то...
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Я вот в COM более-менее конкретно полез только сейчас, и неимоверно удивился тому, что еще 20 лет в MS не появилась идея сделать хелпер для регистрации/удаления COM-серверов. Они ж везде в документации талдычат: "не лезьте руками в общесистемные ключи реестра, используйте спецфункции". А функции для ключей COM-сервера так и не родили — предлагают использовать общие функции реестра.
Для реализации COM-сервера обычно использовали ATL или подобные библиотеки где все эти хелперы есть.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, AndrewJD, Вы писали:
AJD>Для реализации COM-сервера обычно использовали ATL или подобные библиотеки где все эти хелперы есть.
Это тоже идеологически неправильно — надежность реализации общих решений не должна зависеть от используемого фреймворка. Ну и документация MS по COM нигде явно не предлагает использовать ATL — напротив, явно предлагает все делать руками.
Здравствуйте, Евгений Музыченко, Вы писали:
КД>>На заре COM у меня была книжка "Основы COM" Роджерсона. Там был код регистратора, которым я долгое время пользовался. Там работы-то — на 15 минут...
ЕМ>Да не во времени реализации дело, и даже не в сложности.
Мысль я понял.
Просто заметил, оглядываясь назад, что это не критично.
"Лучше уж никак, вместо как нибудь" (с) забыл, как его ...
Кстати, хотел вот всё сказать — если юзать "Registration Free COM", то в реестр вообще ничего писать не надо
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Ну и документация MS по COM нигде явно не предлагает использовать ATL — напротив, явно предлагает все делать руками.
Наверное потому что COM — общая технология, не зависимая от языка. А вот ATL — это лишь решение для C++, причём не единственное:
The Active Template Library (ATL) is a set of template-based C++ classes developed by Microsoft, intended to simplify the programming of Component Object Model (COM) objects.
COM objects can also be created with Microsoft Foundation Classes (MFC)
И это не говоря про Borland C++ Builder, например.
Они ж везде в документации талдычат: "не лезьте руками в общесистемные ключи реестра, используйте спецфункции". А функции для ключей COM-сервера так и не родили — предлагают использовать общие функции реестра.
