Комментарии 43
COM и тем более на ATL разве кто-то еще пишет?
пишет :)
COM-интерфейсы имеют LzmaSdk (aka 7z api), .NET Hosting API, в виде COM-компонента оформлен DirectX…
Кроме того, COM был и остается способом «по умолчанию» для универсального взаимодействия между исполнимыми модулями, написанными на разных языках, в тех случаях, когда простых экспортируемых функций становится недостаточно.
Кроме того, COM был и остается способом «по умолчанию» для универсального взаимодействия между исполнимыми модулями, написанными на разных языках, в тех случаях, когда простых экспортируемых функций становится недостаточно.
Интересно, в каких случаях может быть недостаточно простых экспортируемых функций? Они же позволяют передавать между модулями любые данные и даже код…
ИМХО, COM — классический пример оверинжениринга, заставляющий для простейших действий писать тонны маловразумительного кода. Абсолютно везде COM-архитектуру можно было бы заменить обычными DLL, вместо того чтобы городить огород с регистрацией в реестре, GUID'ами, моникерами и COM-серверами.
Если так уж хотелось классовой обёртки, чтобы через "->" можно было к функциям обращаться, то можно было бы сделать классовую обёртку непосредственно в хеадерах, тем более что там и так вся метаинформация ручками набита (спрашивается, на кой вообще придумали IDL, если всё равно инфа дублируется в хеадерах?).
Похоже на то, что COM исходно задумывался для потенциально опасного (недоверенного) кода — например, кода Internet-апплетов. Все эти подписи, GUID'ы, регистрация — очень уж напоминают движение в сторону restricted-кода, который выполняется в песочнице с жёстким контролем доступа. Но в итоге продукт получился весьма сырым и недоработанным.
ИМХО, COM — классический пример оверинжениринга, заставляющий для простейших действий писать тонны маловразумительного кода. Абсолютно везде COM-архитектуру можно было бы заменить обычными DLL, вместо того чтобы городить огород с регистрацией в реестре, GUID'ами, моникерами и COM-серверами.
Если так уж хотелось классовой обёртки, чтобы через "->" можно было к функциям обращаться, то можно было бы сделать классовую обёртку непосредственно в хеадерах, тем более что там и так вся метаинформация ручками набита (спрашивается, на кой вообще придумали IDL, если всё равно инфа дублируется в хеадерах?).
Похоже на то, что COM исходно задумывался для потенциально опасного (недоверенного) кода — например, кода Internet-апплетов. Все эти подписи, GUID'ы, регистрация — очень уж напоминают движение в сторону restricted-кода, который выполняется в песочнице с жёстким контролем доступа. Но в итоге продукт получился весьма сырым и недоработанным.
COM это в первую очередь бинарный стандарт для межплатформенного(или если выражаться прямее — межъязыкового, в плане языков программирования), межпроцессного и даже сетевого(DCOM) взаимодействия.
В JS и VB нет «хеадеров», в C# их тоже нет, и уж точно их нет в каком-нибудь Common Lisp. Модульность во всех трех реализована совершенно по-разному. Зато и там и там и в третьем, и даже в четвертом, есть более-менее похожее ООП.
Кроме того, COM это некоторая такая попытка пофиксить недостатки C++ — а именно: отсутствие ABI, управление памятью, модель ООП и отсутствие reflection.
В JS и VB нет «хеадеров», в C# их тоже нет, и уж точно их нет в каком-нибудь Common Lisp. Модульность во всех трех реализована совершенно по-разному. Зато и там и там и в третьем, и даже в четвертом, есть более-менее похожее ООП.
Кроме того, COM это некоторая такая попытка пофиксить недостатки C++ — а именно: отсутствие ABI, управление памятью, модель ООП и отсутствие reflection.
Простых экспортируемых функций недостаточно, когда продукт постоянно развивается. Через некоторое время возникнет нехороший эффект версионности. Короче — dll hell.
Интересно, в каких случаях может быть недостаточно простых экспортируемых функций? Они же позволяют передавать между модулями любые данные и даже код…
В случае сложного объектно-ориентированного API, разумеется. Я привел три примера, которые в виде простых экспортируемых функций стали бы абсолютным кошмаром.
ИМХО, COM — классический пример оверинжениринга, заставляющий для простейших действий писать тонны маловразумительного кода. Абсолютно везде COM-архитектуру можно было бы заменить обычными DLL, вместо того чтобы городить огород с регистрацией в реестре, GUID'ами, моникерами и COM-серверами.
Обязательный элемент среди вами перечисленных — GUID'ы. Возможно, вы удивитесь, но все остальное глубоко опционально.
Если так уж хотелось классовой обёртки, чтобы через "->" можно было к функциям обращаться, то можно было бы сделать классовую обёртку непосредственно в хеадерах, тем более что там и так вся метаинформация ручками набита (спрашивается, на кой вообще придумали IDL, если всё равно инфа дублируется в хеадерах?).
Затем, что C++ — это далеко не единственной язык программирования! Мне вот другое не понятно, зачем TLB придумали…
Судя по всему, вы юзаете COM. Удивительно, что вы не знаете о TLB. Впрочем, наверное, просто никогда особо не интересовались. TLB хранит информацию о типах (метаинформацию). Она нужна, например, для автоматического маршалинга, когда на основе TLB генерятся proxy & stub. TLB нужна для загрузки COM-компонента в среде, которая не имеет никакой информации о самом компоненте. Например, директива #import, которая «кушает» dll и генерит tli/tlh хидеры со всеми интерфейсами, гуидами и прочими необходимыми вещами на самом деле работает с type library, вкомпиленной в DLL. Другие языки (не С++) тоже таким образом работают с бинарными компонентами.
Все тоже самое хранится и в IDL-файле. TLB по сути — всего лишь его двоичное представление.
Да, так и есть. Я не совсем понимаю суть вашего возражения. Или это просто констатация факта? В idl вы описываете типы, потом использвуется midl, компилятор IDL, который переводит все в бинарную форму и это добро вкомпиливается в длл. Или вы считаете, что все должно храниться в текстовом виде?
Да, это машиночитаемое представление, которое в runtime используется средой исполнения COM, например, для автоматического маршалинга.
Вы глубоко удивитесь, но GUID — тоже опционально. А вот QueryInterface — обязательно :-)
Для нас COM в первую очередь — компонентная архитектура. Она позволяет достичь модульности и независимости компонентов друг от друга.
COM на самом деле тяжеловесен и громоздок, но при работе над крупным многокомпонентным проектом открывается, что это всё нужно.
Я думаю, что если бы у нас не было COM, то мы бы придумали какой-нибудь его недоработанный аналог.
CORBA в принципе тоже подошла, но тогда бы был отдельный геморрой интеграции с .NET.
COM на самом деле тяжеловесен и громоздок, но при работе над крупным многокомпонентным проектом открывается, что это всё нужно.
Я думаю, что если бы у нас не было COM, то мы бы придумали какой-нибудь его недоработанный аналог.
CORBA в принципе тоже подошла, но тогда бы был отдельный геморрой интеграции с .NET.
Windows Runtime — даже не само новое API, а новый подход к API от Microsoft — это как раз таки COM (с небольшой подтяжкой морщин типа неймспейсов, отсутствия множественного наследования и пр..).
Что до ATL — вполне нормальная библиотека (на чем же еще COM писать?). Ее связь с WRL (новой темплейтной библиотекой для работы с COM/WinRT для тех, кто не хочет использовать C++/CX) значительно менее очевидна, чем между парой COM/WinRT, но все равно чувствуется значительное влияние ATL на WRL.
Что до ATL — вполне нормальная библиотека (на чем же еще COM писать?). Ее связь с WRL (новой темплейтной библиотекой для работы с COM/WinRT для тех, кто не хочет использовать C++/CX) значительно менее очевидна, чем между парой COM/WinRT, но все равно чувствуется значительное влияние ATL на WRL.
Десять лет, десять долгих лет я ждал этой статьи…
Бррр, хочу это развидеть! Код с комом вызвал ужасные воспоминания (не как MFC конечно, но тоже мало приятного). К счастью, уже много лет не приходилось возиться с com-ом и надеюсь, что больше не придется.
Почему?
Почему что?
Почему надеетесь. Помимо того, что «computers suck» какие Ваши претензии к COM?
Уродливая технология, которая портит архитектуру даже клиентов не говоря уже о провайдерах com-компонентов. Уродливый синтаксис и конвенции, ужасная система регистраций, гуйдов и прочей фигни, плохо соответствует и ложится на принципы ООП, полностью платформо-зависимая и вообщем-то совершенно ненужная при наличии тонны других способов взаимодействия между компонентами и процессами. Да, иногда не остается выбора работая со сторонними компонентами (в основном майкрософтовскими), но внутри своей собственной архитектуры я бы ни за что в жизни эту дрянь не стал бы брать.
Другими словами, Вы сами не знаете что Вам не нравится — лучше уж «тонна других способов» (aka «зоопарк велосипедов»), чем одна стандартная, невероятная гибкая, крайне логичная (если не залазить в дебри, но подобные дебри остались бы дебрями независимо от того, на какой компонентной модели они построены), оттестированная на миллионах сценариев использования и на сотнях миллиардов пользователей (кумулятивно за последние 20 лет). Ах, да, COM кроме масштабирования «вверх» (всякие связывания-с-моникерами-на-удаленной-машине-используя-кастомные-маршалеры-и-кастомные-транстпортные-протоколы), очень хорошо масштабируется «вниз» (graceful degradation): можно сделать
с пустой реализацией AddRef и Release и это уже COM объект, который можно передавать куда угодно. Никакой регистрации. GUID — это просто 128-битное случайное число, которое гарантированно глобально-уникально. Все. Что Вам не нравится в глобально уникальных случайных идентификаторах? Синтаксис и конвенции — это где? В IDL? Расскажите больше. «Плохо соотетствует и ложится на принципы ООП» — это глупость. А «полностью платформо-зависимая» — так и вообще идиотизм.
А вообще, немного почитав Ваши комментарии/посты, «что-то» мне подсказывает, что дело вовсе даже и не в технологии (у меня есть ОГРОМНЫЕ подозрения, что Вы в ней даже и не пытались разбираться) — дело в производителе. Все, конечно, не так запущено как в случае amarao, но тенденция тоже отлично просматривается.
class MyObject: public IUnknown {
//...
}
с пустой реализацией AddRef и Release и это уже COM объект, который можно передавать куда угодно. Никакой регистрации. GUID — это просто 128-битное случайное число, которое гарантированно глобально-уникально. Все. Что Вам не нравится в глобально уникальных случайных идентификаторах? Синтаксис и конвенции — это где? В IDL? Расскажите больше. «Плохо соотетствует и ложится на принципы ООП» — это глупость. А «полностью платформо-зависимая» — так и вообще идиотизм.
А вообще, немного почитав Ваши комментарии/посты, «что-то» мне подсказывает, что дело вовсе даже и не в технологии (у меня есть ОГРОМНЫЕ подозрения, что Вы в ней даже и не пытались разбираться) — дело в производителе. Все, конечно, не так запущено как в случае amarao, но тенденция тоже отлично просматривается.
На всякий случай поправлюсь, чтоб не придирались к словам.
Это конечно же класс, а не объект. Объект можно инстанцировать («активировать» в терминах COM) любым понравившимся способом: хоть на стеке, хоть в куче, хоть в data секции и управлять его временем жизни хоть вручную, хоть отдельным самопальным счетчиком ссылок, хоть настоящим сборщиком мусора.
COM — это прежде всего QueryInterface + жесткий ABI, а весь COM рантайм с маршалерами, апартментами, моникерами, регистрацией/активацией — это просто хелперы. Они призваны УПРОЩАТЬ жизнь, если эта функциональность нужна, а не усложнять требованием обязательно реализовывать все известные человечеству интерфейсы. Простейший пример: «классический» COM, Windows Runtime и registration-free COM имеет три совершенно разных способа активации компонентов, но при это все три между собой бинарно совместмы после того, как активация произведена.
… это уже COM объект...
Это конечно же класс, а не объект. Объект можно инстанцировать («активировать» в терминах COM) любым понравившимся способом: хоть на стеке, хоть в куче, хоть в data секции и управлять его временем жизни хоть вручную, хоть отдельным самопальным счетчиком ссылок, хоть настоящим сборщиком мусора.
COM — это прежде всего QueryInterface + жесткий ABI, а весь COM рантайм с маршалерами, апартментами, моникерами, регистрацией/активацией — это просто хелперы. Они призваны УПРОЩАТЬ жизнь, если эта функциональность нужна, а не усложнять требованием обязательно реализовывать все известные человечеству интерфейсы. Простейший пример: «классический» COM, Windows Runtime и registration-free COM имеет три совершенно разных способа активации компонентов, но при это все три между собой бинарно совместмы после того, как активация произведена.
Я действительно сильно глубоко в com не копал, но работая в windows тоже волей не волей приходилось сталкиваться, и уж точно не могу сказать что это «гибкая и логичная» система, и уж точно не «стандартная» так как опять-таки привязана к конкретной платформе (потрудитесь объяснить, почему это «идиотизм»?).
>«Плохо соотетствует и ложится на принципы ООП» — это глупость
Глупость? Хехе. Видимо вы никогда не пытались объектно ориентированную архитектуру экспортировать в ком :) Наследование ком-интерфейсов — это нечто странное, но не как не стандартное «is-a» отношение. COM не умеет многих стандартных фич из ООП языков как множественное наследование от классов или интерфейсов, полиморфизм, перегрузка и т.д. Да, на ком можно легко наложить какой-нибудь простенький недокласс (данные+функции) но никак не не более — все остальное это жуткая головная боль и тонны костылей.
>дело в производителе
И у меня нет предвзятости к майкрософту, но есть предвзятость к закрытым платформо-зависимым решениям вроде COM. Просто я много писал (и пишу) кросспатформенный код и занимаюсь портированием, и не раз сталкивался, когда с ситуацией, когда портирование многократно усложнялось, из за наличия вот такой вот хрени. Единственная претензия к Майкрософту, что они любят проталкивать свои собственные костыли под видом «стандарта», после чего толпы виндузятных программистов понятия не имеют, где заканчивается стандартные фичи языков, стандартные библиотеки и начинается платформо зависимая пропраятщина, что особенно заметно в С++.
>«Плохо соотетствует и ложится на принципы ООП» — это глупость
Глупость? Хехе. Видимо вы никогда не пытались объектно ориентированную архитектуру экспортировать в ком :) Наследование ком-интерфейсов — это нечто странное, но не как не стандартное «is-a» отношение. COM не умеет многих стандартных фич из ООП языков как множественное наследование от классов или интерфейсов, полиморфизм, перегрузка и т.д. Да, на ком можно легко наложить какой-нибудь простенький недокласс (данные+функции) но никак не не более — все остальное это жуткая головная боль и тонны костылей.
>дело в производителе
И у меня нет предвзятости к майкрософту, но есть предвзятость к закрытым платформо-зависимым решениям вроде COM. Просто я много писал (и пишу) кросспатформенный код и занимаюсь портированием, и не раз сталкивался, когда с ситуацией, когда портирование многократно усложнялось, из за наличия вот такой вот хрени. Единственная претензия к Майкрософту, что они любят проталкивать свои собственные костыли под видом «стандарта», после чего толпы виндузятных программистов понятия не имеют, где заканчивается стандартные фичи языков, стандартные библиотеки и начинается платформо зависимая пропраятщина, что особенно заметно в С++.
так как опять-таки привязана к конкретной платформе (потрудитесь объяснить, почему это «идиотизм»?)
Ну даже если не принимать во внимание тот факт что существуют сторонние реализации COM рантайма под не-Windows платформы, человек должен совершенно ничего не понимать в COM, чтобы говорить, что технология как таковая привязана к конкретной платформе. Присмотритесь к эппловскому CoreFoundation или к мозиловскому nsISupports. Ничего не напоминает? Мне все еще необходимо объяcнять «почему это идиотизм»?
Видимо вы никогда не пытались объектно ориентированную архитектуру экспортировать в ком :)
Вы заблуждаетесь в двух вещах: в том, что считаете, что понимаете что такое «объектно-ориентированная архитектура» и в том, что считаете, догадываетесь что я пытался и чего не пытался делать. «Наследование» интерфейсов — неудачный термин (и деталь реализации в некоторых языках), интерфейсы РЕАЛИЗУЮТСЯ классами. Причем (сюрприз!!!), далеко не только в COM. Еще для меня загадка, с каких пор множественное наследование стало стандартной фичей ООП языков, и с каких пор COM перестал поддерживать реализацию множества интерфейсов (Вы же это имеете в виду?). Полиморфизм — э-э-э Вы точно понимаете, что такое полиморфизм? Что же до перегрузки — действительно перегрузка не поддерживается напрямую (потому что ABI остается одним и тем же и для языков, которые поддерживают перегрузку и для тех, которые не поддерживают — да-да, перегрузка — тоже не такая уж «стандартная фича ООП языков»), с другой стороны поддерживается аннотация [overload] для языков, которые перегрузку поддерживают и хотят спроецировать данный метод под перегруженным именем.
… Единственная претензия к Майкрософту, что они любят проталкивать свои собственные костыли под видом «стандарта»...
Каждый раз когда я вижу подобные утверждения мне хочется научиться бить людей по TCP/IP. Вы, похоже, сами не осознаете, но данным абзацем Вы ПОЛНОСТЬЮ подтвердили мое утверждение о том, что у Вас ABM (пусть даже и в начальной стадии).
Не вижу смысла продолжать дискуссию при ваших постоянных попытках перехода на личности, вы даже ничего не ответили по сути, кроме обвинений в том, что «я ничего не понимаю». Кстати, забавно, но все, что вы пишите, указывает на то, что вы сами являетесь ярым фанбоем, в чем почему то пытаетесь обвинить меня, хотя я я просто написал почему мне не нравится одна устаревшая кривоватая технология, а вовсе не «наезжал» на вашу любимую компанию.
Хм, я ничего не ответил? А ссылочки там для чего? По первому абзацу остались вопросы?
По множественному наследованию как стандартной фиче ООП языков. Возьмем два самых популярных ООП языка — Java и C#.
java.lang.Class содержит два аксессора:
public Class getSuperclass()
public Class[] getInterfaces()
Прошу отметить, что базовый класс всегда один, интерфейсов — несколько, и обе сущности отделены друг от друга.
System.Type содержит проперти
public abstract Type BaseType { get; }
и аксессор
public abstract Type[] GetInterfaces()
Прошу отметить, что имеем ОДИН базовый класс, несколько интерфейсов и то и другое является отдельными сущностями.
Возьмем еще один популярный OOP язык — JavaScript. Ой, там вообще классов нет, а вместо них прототипы.
Продолжать?
Реализация множества интерфейсов коклассами. Даже не знаю, зачем я должен это писать — это нужно или знать, или не рассуждать о том, чем COM является и чем не является.
Полиморфизм. QueryInterface это полиморфизм и есть. Концентрированный. Вы работаете с интерфейсом, а coclass-ы, реализующие этот интерфейс уже сами решают чего им делать.
«Проталкивание собственных костылей под видом стандартов»
Оставим в стороне Вашу личную оценку качества предлагаемых технических решений («костыль» или не «костыль» решать тем, кто хотя бы в принципе разбирается в том, что предлагается). Но ведь, как и предполагалось, Вы не понимаете, в чем Ваша ошибка. Хорошо, попробую подтолкнуть Вас к тому, чтоб Вы сами осознали. Критикуя — предлагай. Какая альтернатива: КТО не «проталкивает собственные костыли под видом стандартов» (из тех, кто делает хоть что-то)? И откуда вообще берутся эти самые «несобственный костыли»?
Ах да, Вы наезжали не на «мою любимую компанию» и даже не на мою любимую технологию — Вы просто необоснованно критиковали (и упорствуете, хотя уже сами же признали, что Вы даже и не пытались в ней толком разобраться) технологию. Мне не нравится, когда критика высказывается людьми, которые не понимают о чем говорят (вон взгляните там ниже amarao выступил — стоило оставить этот выпад неотвеченным просто для того, чтоб не быть уличенным в «любви к компании»?). В общем, я никого не хотел обидеть (и прошу прощения, если таки обидел), но стереотипы вокруг Microsoft уже настолько надоели, что начали раздражать.
По множественному наследованию как стандартной фиче ООП языков. Возьмем два самых популярных ООП языка — Java и C#.
java.lang.Class содержит два аксессора:
public Class getSuperclass()
public Class[] getInterfaces()
Прошу отметить, что базовый класс всегда один, интерфейсов — несколько, и обе сущности отделены друг от друга.
System.Type содержит проперти
public abstract Type BaseType { get; }
и аксессор
public abstract Type[] GetInterfaces()
Прошу отметить, что имеем ОДИН базовый класс, несколько интерфейсов и то и другое является отдельными сущностями.
Возьмем еще один популярный OOP язык — JavaScript. Ой, там вообще классов нет, а вместо них прототипы.
Продолжать?
Реализация множества интерфейсов коклассами. Даже не знаю, зачем я должен это писать — это нужно или знать, или не рассуждать о том, чем COM является и чем не является.
Полиморфизм. QueryInterface это полиморфизм и есть. Концентрированный. Вы работаете с интерфейсом, а coclass-ы, реализующие этот интерфейс уже сами решают чего им делать.
«Проталкивание собственных костылей под видом стандартов»
Оставим в стороне Вашу личную оценку качества предлагаемых технических решений («костыль» или не «костыль» решать тем, кто хотя бы в принципе разбирается в том, что предлагается). Но ведь, как и предполагалось, Вы не понимаете, в чем Ваша ошибка. Хорошо, попробую подтолкнуть Вас к тому, чтоб Вы сами осознали. Критикуя — предлагай. Какая альтернатива: КТО не «проталкивает собственные костыли под видом стандартов» (из тех, кто делает хоть что-то)? И откуда вообще берутся эти самые «несобственный костыли»?
Ах да, Вы наезжали не на «мою любимую компанию» и даже не на мою любимую технологию — Вы просто необоснованно критиковали (и упорствуете, хотя уже сами же признали, что Вы даже и не пытались в ней толком разобраться) технологию. Мне не нравится, когда критика высказывается людьми, которые не понимают о чем говорят (вон взгляните там ниже amarao выступил — стоило оставить этот выпад неотвеченным просто для того, чтоб не быть уличенным в «любви к компании»?). В общем, я никого не хотел обидеть (и прошу прощения, если таки обидел), но стереотипы вокруг Microsoft уже настолько надоели, что начали раздражать.
ATL? COM? Закопайте обратно. :)
Опоздали с топиком лет эдак на 10-15. Ну а че, давайте писать гайды по кодингу для DOS например =)
ActiveX? Это технология, которая работает ТОЛЬКО на Windows, ТОЛЬКО в IE и ТОЛЬКО в 32-битах?
ActiveX? Это технология, которая позволяет запускать программы с сайтов без согласия пользователя и даёт этим программам 100% доступ к всем документам и настройкам пользователя, включая пароли, куки и прочие приватные вещи?
Да вы рехнулись, батенька.
ActiveX? Это технология, которая позволяет запускать программы с сайтов без согласия пользователя и даёт этим программам 100% доступ к всем документам и настройкам пользователя, включая пароли, куки и прочие приватные вещи?
Да вы рехнулись, батенька.
Красноглазик, отаку, гик, нерд, фанат линукса, недоброжелатель майкрософта, оракла, и т.д.
Красноглазые иксперты такие искперты.
В первом же абзаце из трех утверждений — 2 фактических ошибки («ТОЛЬКО в IE и ТОЛЬКО в 32-битах») и одно утверждение верно с большими натяжками («ТОЛЬКО на Windows»). Во втором абзаце неверно вообще все.
Почему бы Вам не перестать позориться и выскакивать с заявлениями о Windows? И ведь это не первый раз, когда Вам демонстрируют, что Ваши знания о Windows… как бы это помягче сказать… далеко не исчерпывающи. Либо Вы в принципе неспособны воспринимать информацию и рефлексировать, либо Вы неспособны воспринимать информацию и рефлексировать только если дело касается Microsoft (а также Apple, Oracle и пр.).
Нет, я серьезно, либо уже перестаньте влазить в посты, посвященные Windows либо таки сделайте усилие и РАЗБЕРИТЕСЬ в вопросах, по которым у Вас уже есть Мнение. Спасибо-пожалуйста-у-меня-все.
В первом же абзаце из трех утверждений — 2 фактических ошибки («ТОЛЬКО в IE и ТОЛЬКО в 32-битах») и одно утверждение верно с большими натяжками («ТОЛЬКО на Windows»). Во втором абзаце неверно вообще все.
Почему бы Вам не перестать позориться и выскакивать с заявлениями о Windows? И ведь это не первый раз, когда Вам демонстрируют, что Ваши знания о Windows… как бы это помягче сказать… далеко не исчерпывающи. Либо Вы в принципе неспособны воспринимать информацию и рефлексировать, либо Вы неспособны воспринимать информацию и рефлексировать только если дело касается Microsoft (а также Apple, Oracle и пр.).
Нет, я серьезно, либо уже перестаньте влазить в посты, посвященные Windows либо таки сделайте усилие и РАЗБЕРИТЕСЬ в вопросах, по которым у Вас уже есть Мнение. Спасибо-пожалуйста-у-меня-все.
Жду примера ActiveX под Debian/Hurd с ARM-архитектурой. В качестве браузера… Ну, допустим, opera.
Мдя, говорю ж — не лечится.
Давайте по порядку.
«ТОЛЬКО в IE» — читаем статью: «Встраивание в приложение на Windows.Forms».
«ТОЛЬКО в 32 битах» —
«ТОЛЬКО на Windows» — здесь, как я уже сказал, с некоторыми натяжками можно согласиться. Во первых этих Windows — было три штуки разных Windows NT, Windows 9x и Windows CE (Embedded Compact). На всех трех работал ActiveX — сам по себе он от платформы не зависит. А вот и пример вполне себе ActiveX под «Debian/Hurd с ARM». Вот еще один
Что же до Вашего второго абзаца, у меня есть встречное предложение. Вы создаете простенький ActiveX и даете мне ссылку. Я по ней кликаю, далее происходит следующее: Ваша «программа» запускается без моего согласия, Вы «получаете 100% доступ ко всем моим документам, настройкам, включая пароли куки и прочие приватные вещи», думаю похищения хабракуки и комментария от моего имени «pwned, Windows suxx» будет более чем достаточно, чтоб подвердить Вашу позицию (только, пожалуйста, без мошенничества вроде неизвестной XSS на хабре или типа того — нужно провести все исключительно через ActiveX, устанавливаемый без моего согласия).
Давайте по порядку.
«ТОЛЬКО в IE» — читаем статью: «Встраивание в приложение на Windows.Forms».
«ТОЛЬКО в 32 битах» —
«ТОЛЬКО на Windows» — здесь, как я уже сказал, с некоторыми натяжками можно согласиться. Во первых этих Windows — было три штуки разных Windows NT, Windows 9x и Windows CE (Embedded Compact). На всех трех работал ActiveX — сам по себе он от платформы не зависит. А вот и пример вполне себе ActiveX под «Debian/Hurd с ARM». Вот еще один
Что же до Вашего второго абзаца, у меня есть встречное предложение. Вы создаете простенький ActiveX и даете мне ссылку. Я по ней кликаю, далее происходит следующее: Ваша «программа» запускается без моего согласия, Вы «получаете 100% доступ ко всем моим документам, настройкам, включая пароли куки и прочие приватные вещи», думаю похищения хабракуки и комментария от моего имени «pwned, Windows suxx» будет более чем достаточно, чтоб подвердить Вашу позицию (только, пожалуйста, без мошенничества вроде неизвестной XSS на хабре или типа того — нужно провести все исключительно через ActiveX, устанавливаемый без моего согласия).
Хм, вполне осознаю, что «встречное предложение» потребует неоправданно много усилий, так что давайте хотя бы так: Вы СЛОВАМИ обрисовываете план «атаки» и попутно рассказываете, почему дыра такой величины НИ РАЗУ в истории не использовалась злоумышленниками (они, лентяи, все больше на соц инженерию нажимают)?
И, пожалуйста, попробуйте не опозориться. В очередной раз.
И, пожалуйста, попробуйте не опозориться. В очередной раз.
А почему вы хидер с интерфейсами вручную делали? Удобнее будет взять хидеры, которые midl генерирует.
да ну просто чтобы читабельнее и понятнее вышло
Да, то что генерит midl лучше не читать :) Наверное, все же, стоит указать, что так в реальной жизни так обычно не делают. Еще одну штуку нашел:
>>> свойство m_bWindowOnly в TRUE — это будет означать, что наш компонент поддерживает встраивание исключительно в графические приложение.
Не совсем понятно, что вы имели в виду. Это свойство говорит о том, может ли контрол работать в windowless ркжиме, т.е. без выделенного для себя HWND: отрисовываться в контексте, который предоставляется контейнером и получать от него информацию о необходимых событиях.
>>> свойство m_bWindowOnly в TRUE — это будет означать, что наш компонент поддерживает встраивание исключительно в графические приложение.
Не совсем понятно, что вы имели в виду. Это свойство говорит о том, может ли контрол работать в windowless ркжиме, т.е. без выделенного для себя HWND: отрисовываться в контексте, который предоставляется контейнером и получать от него информацию о необходимых событиях.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Руководство по созданию ActiveX-контролов на C++ с помощью ATL