Обсуждение:Компонентная объектная модель

JavaScript против JScript

«Другие библиотеки и языки, поддерживающие COM, включают Microsoft Foundation Classes, VBScript, Visual Basic, ECMAScript (JavaScript) и Delphi».

JScript технически более точен, чем Javascript, поскольку COM использует реализацию и расширение ECMAScript от Microsoft, а не от Netscape.

COM-лайт

Есть также «более легкий» способ использования COM. Согласно спецификации COM (черновая версия 0.9 от октября 1995 года, которая, похоже, больше не доступна от Microsoft, но вы можете получить ее на этой странице archive.org), объекты COM не обязательно должны быть экземплярами классов COM или CoClasses (см. главу 3.6 спецификации COM). Пока объект поддерживает хотя бы один интерфейс COM, его можно назвать объектом COM. Его класс не обязательно должен быть общедоступным для создания экземпляров. Поэтому интерфейсы COM можно использовать как эффективное средство связи с любыми приложениями или библиотеками DLL. Он объектно-ориентированный, в отличие от простых функций API DLL. Многие приложения используют интерфейсы COM внутри. Знаете ли вы, что интерфейсы объектов Borland Delphi по умолчанию совместимы с COM, даже если вы не утруждаете себя работой с CoWhatever? Интерфейсы COM — это простая, но очень мощная концепция.

Visual Basic делает то же самое; он реализует интерфейсы на основе IDispatch для всех ваших объектов, даже тех, которые вы не экспортируете. Возможно, VB использует для них закрытый, внутренний ClassFactory, но, скорее всего, нет. Shinobu 04:26, 27 июня 2007 (UTC) [ ответить ]

Это все хорошо и здорово — перенаправлять из OCX в COM, но нигде в этой статье не говорится, что такое OCX-файл на самом деле? DLL, которая реализует какие-то интерфейсы?

Элемент управления OCX или пользовательский элемент управления OLE по сути является соклассом, реализующим интерфейсы, необходимые для того, чтобы приложения, которые могут встраивать элементы управления через эти интерфейсы, могли встраивать объекты этого класса в качестве видимого интерактивного элемента управления. Обычно их реализация размещается в динамической библиотеке с расширением .ocx. Shinobu 04:26, 27 июня 2007 (UTC) [ ответить ]

Где находятся списки стандартных библиотек COM, чтобы их можно было использовать для разработки?

Я рассматривал возможность написания HTA ​​(HTML-приложений). По сути, это приложения, созданные путем локального запуска веб-страницы со скриптом, полностью за пределами изолированной программной среды безопасности.

Это классный способ программирования, потому что, как обнаружили программисты PHP, нет более простого способа сгенерировать пользовательский интерфейс, чем выдать HTML. А DHTML — это классный способ написать скрипт пользовательского интерфейса.

Но поскольку в JavaScript нет библиотек для доступа к системе, вам необходимо ссылаться на библиотеки COM во время выполнения для каждой не связанной с Интернетом задачи, которую вы хотите выполнить.

Это должно быть легко, поскольку Microsoft поставляла библиотеки COM для всего, и так было всегда.

Но попробуйте найти документацию о том, КАКИЕ существуют библиотеки COM, какие у них интерфейсы, какие версии поставляются с какой версией Windows. ДОКУМЕНТАЦИИ НЕТ!

Добавьте к этому тот факт, что у COM-объектов нет отражения, и вы получите безумную ситуацию.

Это как быть сантехником, за исключением того, что вы можете заказывать фитинги только по номеру, и вам не разрешено видеть каталог. Ах да, и номера каталогов имеют длину 64 бита. -- неверно: на самом деле они имеют длину 128 бит

Кто-нибудь может мне помочь?

CafeAlpha@nightstudies.net

Может быть, вы можете установить Platform SDK? Это тяжелая загрузка, но она содержит все, что вы когда-либо хотели знать о программировании для Windows. Shinobu 04:18, 27 июня 2007 (UTC) [ ответить ]

На самом деле, немного неточно говорить, что .NET — это замена COM. .NET не только делает гораздо больше, чем COM, COM+ все еще жив и здоров, и Microsoft все еще поощряет его использование в корпоративных приложениях. Написание объектов COM+ в .NET — это распространенный способ сделать это, так что эти две технологии скорее дополняют друг друга, чем конкурируют. ShaneKing 12:42, 3 февраля 2004 (UTC)

Так что отредактируйте статью :-) Нам нужна серьезная техническая информация - Дэвид Джерард 00:09, 4 февраля 2004 (UTC)

может кто-нибудь написать упрощенный раздел? первый абзац читается как инопланетный язык.

Я добавил "В программной инженерии " во вступление, так что после трех слов вы поймете, что это на самом деле инопланетный язык ;-) Я не вижу, как еще упростить объяснение во вступлении. Это действительно немного эзотерично для не-гиков, но я надеюсь, что "В программной инженерии" в начале - адекватное предупреждение - Дэвид Джерард 11:21, 2 октября 2004 (UTC)

АктивИкс

Я не уверен, является ли ActiveX синонимом COM. Разве он не основан на COM, как и DirectX ? -- GatesPlusPlus 11:26, 6 февраля 2005 (UTC)

Да, ActiveX — это просто еще одна технология, использующая COM, верно? Что перенаправляет ее сюда? -- minghong 08:37, 13 мая 2005 (UTC) [ ответить ]
С тех пор было исправлено. Shinobu 08:51, 2 июля 2007 (UTC) [ ответить ]

Больше вредоносных применений ActiveX по сравнению с законными?

Я где-то читал или слышал, что существует больше нехороших применений ActiveX, чем законных. Это правда? - x42bn6 8 июля 2005 04:15 (UTC)

Нет. ActiveX — это то же самое, что и Automation. Это система программных компонентов, которая широко используется вашей системой и множеством программ, которые люди используют ежедневно. ActiveX — это просто спецификация того, как программные компоненты взаимодействуют друг с другом. Это не является ни хорошим, ни плохим по своей сути. Однако плохо то, что на вашем компьютере свободно распространяется ненадежное собственное программное обеспечение. Поэтому, если ваш браузер просит вас установить элемент управления ActiveX или плагин Firefox, откажитесь. То, что можно сделать на веб-страницах с помощью элементов управления ActiveX и плагинов Firefox, обычно можно сделать с помощью Java-апплетов, и их можно должным образом изолировать, сделав их (за исключением ошибок в Java VM) полностью безопасными. Поэтому, если владелец веб-сайта решил использовать вместо этого элемент управления ActiveX или плагин Firefox, у вас есть очень веская причина быть очень подозрительным. Устанавливайте элементы управления ActiveX, плагины Firefox или любое программное обеспечение только в том случае, если вы полностью доверяете источнику. Shinobu 04:15, 27 июня 2007 (UTC) [ ответить ]

Текст ActiveX

Текст выглядит так, будто взят прямо из MS:


Что такое Active-X


Что такое ActiveX?

ActiveX — это набор технологий от Microsoft, который позволяет создавать интерактивный контент для Всемирной паутины. До появления ActiveX веб-контент представлял собой статичный двухмерный текст и графику. С ActiveX веб-сайты оживают с помощью мультимедийных эффектов, интерактивных объектов и сложных приложений, которые создают пользовательский опыт, сравнимый с высококачественными заголовочными компакт-дисками. ActiveX обеспечивает связующее звено, которое связывает воедино широкий ассортимент технологических строительных блоков для обеспечения работы этих «активных» веб-сайтов. Каковы его основные преимущества?

 * Активный веб-контент, оказывающий влияние, который будет привлекать и удерживать пользователей. * Открытая кроссплатформенная поддержка операционных систем Macintosh®, Windows® и UNIX®. * Знакомые инструменты из широкого ассортимента инструментов и поставщиков языков программирования, включая Visual Basic®, Visual C++®, Borland® Delphi®, Borland C++, Java и инструменты с поддержкой Java. Разработчики могут использовать то, что они знают, и немедленно приступить к работе. * Существующий перечень элементов управления ActiveX доступен сегодня для немедленного использования веб-производителями. * Отраслевые стандарты со встроенной поддержкой ключевых отраслевых и фактических рыночных стандартов, включая HTML, TCP/IP, Java, COM и другие.

Каковы его элементы?

ActiveX включает в себя как клиентские, так и серверные технологии.

 * Элементы управления ActiveX — это интерактивные объекты на веб-странице, которые предоставляют интерактивные и (UTC)управляемые пользователем функции и, таким образом, оживляют восприятие веб-сайта. * Документы ActiveX позволяют пользователям просматривать документы, отличные от HTML, такие как файлы Microsoft Excel или Word, через веб-браузер. * Активные сценарии управляют интегрированным поведением нескольких элементов управления ActiveX и/или Java-апплетов из браузера или сервера. * Виртуальная машина Java™ — это код, который позволяет любому браузеру с поддержкой ActiveX, например Internet Explorer 3.0, запускать апплеты Java и интегрировать апплеты Java с элементами управления ActiveX. * ActiveX Server Framework предоставляет ряд функций на базе веб-сервера, таких как безопасность, доступ к базе данных и другие.

Что он может сделать?

ActiveX привносит инновации и интерактивность в Интернет. Поскольку он поддерживается многими различными языками и инструментами, он позволяет разработчикам с различным опытом и опытом привносить свое творчество в Интернет. Основанный на усовершенствовании существующего стандарта COM, уже известного тысячам разработчиков, он может использовать знания и работу сообщества разработчиков без крутой кривой обучения. И поскольку это технология третьего поколения с обширной сторонней поддержкой, он предоставляет самую богатую платформу разработки как для Интернет-, так и для интранет-приложений клиент/сервер, доступных сегодня. ActiveX принимает самые творческие и инновационные усилия по разработке программного обеспечения и позволяет им бесперебойно работать вместе на веб-сайте. С тысячами этих программных компонентов, которые уже существуют, захватывающая коллекция интерактивных объектов доступна для немедленного использования веб-производителями. Почему это важно?

ActiveX позволяет разработчикам и веб-производителям быстро и легко создавать уникальные интерактивные веб-сайты, которые сделают Интернет принципиально более полезным и продуктивным. Веб-производителям не нужно начинать с нуля и вручную создавать все части своего интерактивного веб-сайта, поскольку на рынке уже доступно более 1000 повторно используемых элементов управления. И поскольку ActiveX можно использовать с широким спектром языков программирования от десятков поставщиков, разработчики и веб-мастера могут использовать свой текущий опыт для более быстрого создания привлекательного контента. Они также могут охватить широкий круг пользователей, поскольку ActiveX будет поддерживаться на нескольких платформах операционных систем. Как это соотносится с Java?

ActiveX предоставляет стандартный механизм для расширения любого языка программирования, включая Java. ActiveX расширяет возможности языка Java, позволяя разработчикам Java интегрировать свои апплеты с богатством ActiveX. ActiveX связывает апплеты Java с объектами, созданными на других языках, так что программисты Java могут напрямую ссылаться на элементы управления ActiveX из своих программ Java. По той же причине объекты, написанные на других языках программирования от разных поставщиков, могут ссылаться на апплеты Java. ActiveX является связующим звеном, которое связывает их все вместе, предоставляя самые мощные веб-технологии на открытой интегрированной платформе. Предоставляя общий способ расширения и связывания языков программирования, включая Java, ActiveX максимизирует ресурсы разработчиков для интерактивной веб-разработки. См. ActiveX и Java для получения дополнительной информации о расширении Java с помощью ActiveX. Кто поддерживает?

В настоящее время малые, средние и крупные компании-разработчики программного обеспечения создают элементы управления ActiveX, включая такие компании, как Borland, Oracle и Sybase/Powersoft. В результате их работы сегодня существует более 1000 существующих элементов управления ActiveX, доступных для использования веб-производителями. Кроме того, 14 компаний, создающих инструменты веб-дизайна и разработки, встроили поддержку ActiveX в свои продукты, что позволяет их клиентам как создавать, так и использовать элементы управления ActiveX в своих программах. Microsoft Internet Explorer поддерживает ActiveX, а Microsoft предоставляет подключаемый модуль ActiveX для Netscape® Navigator®, что позволяет самому широкому кругу пользователей Интернета просматривать веб-страницы с поддержкой ActiveX. Где это работает?

ActiveX в настоящее время поддерживается в операционной системе Windows. Microsoft работает с Metrowerks для поддержки ActiveX на платформе Macintosh, а также работает с Bristol и Mainsoft для поддержки на платформах UNIX. Разработчики, которые пишут элементы управления ActiveX и другие объекты ActiveX, смогут охватить максимально широкую аудиторию пользователей с помощью этого кроссплатформенного решения.


так что это, вероятно, copyvio и его нужно будет переработать... -- RN 07:30, 30 июля 2005 (UTC) [ ответить ]

DLL-ад

Поскольку местоположение каждого компонента хранится в системном месте (реестре Windows), может быть установлена ​​только одна версия определенного компонента. Таким образом, COM серьезно страдает от DLL hell, когда два или более приложений требуют разные версии одного и того же компонента. Неправильно. Это решение разработчика компонента, если он хочет зарегистрировать новую версию компонента под старым именем версии, и это неправильное решение, если компоненты несовместимы.

Суть в том, что «COM делает неправильные решения более разрушительными, требуя общесистемного реестра зарегистрированных компонентов».
Суть не в том, что «COM дефектен и не может быть использован для создания твердых растворов». -- tyomitch 09:20, 14 ноября 2005 (UTC) [ ответить ]

Типичная установка Windows имеет установленные MS XML 2.0, 3.0 и 4.0, которые прекрасно работают вместе. Также у COM есть функция "Component Categories" http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnesscom/html/componentcategories.asp, которая позволяет не задавать жестко используемые имена компонентов в приложении.

Кроме того, поскольку COM интенсивно использует реестр, он чувствителен к повреждению реестра. И большинство программ чувствительны к повреждению файловой системы. В чем смысл?

Я не знаю. Давай, исправь, если хочешь. -- tyomitch 09:20, 14 ноября 2005 (UTC) [ ответить ]

В COM нет DLL-ада, поскольку интерфейсы и соклассы ссылаются на них с помощью их GUID, а не имен, а сами DLL могут располагаться где угодно в системе. Таким образом, по крайней мере, утверждение статьи о том, что "поскольку местоположение каждого компонента хранится в системном месте ( реестре Windows ), может быть установлена ​​только одна версия определенного компонента", является совершенно неверным - и это единственное утверждение, которое сделано в разделе "DLL hell", поэтому я его полностью удалил. Тем не менее, он был быстро вставлен обратно. Не могли бы вы объяснить, что тогда означает "DLL hell" в отношении COM? -- int19h 07:35, 30 апреля 2007 (UTC) [ ответить ]

Легко - если у вас в системе установлен OOActiveXControl v2, то вы устанавливаете OldApp 2001, и он регистрирует OOActiveXControl v1, приложения, которые зависят от интерфейсов и классов в OOActiveXControl DLL v2, будут ломаться, когда не смогут их найти. Также есть случай плохо написанных компонентов, которые меняют поведение между версиями без увеличения имен интерфейсов и т. д. Нельзя сказать, что он неуязвим для DLL hell, но вы, вероятно, могли бы перефразировать большую часть текста, чтобы сделать его более понятным. MatthewMastracci 22:22, 30 апреля 2007 (UTC) [ ответить ]

Поломка произойдет только в том случае, если вы перезапишете DLL OOActiveXControl.2 на DLL OOActiveXControl.1. Это может произойти при установке компонентов в папку SYSTEM32, но это общепризнанно плохая практика, и COM, конечно, не навязывает ее — приложение может просто поместить DLL в свою собственную папку и зарегистрировать ее оттуда. Что касается плохо написанных компонентов, которые изменяют поведение существующих интерфейсов — ну, они не являются строго совместимыми с COM, поскольку в справочном руководстве COM прямо говорится, что это запрещено. Это никоим образом не уникально для COM — та же проблема существует в стране Java/.NET; поэтому я не думаю, что название «DLL hell» в каком-либо смысле применимо здесь. — int19h 07:28, 1 мая 2007 (UTC) [ ответить ]
Ваши доводы вполне справедливы, но взгляните на страницу DLL hell:
DLL hell, как описано выше, был очень распространенным явлением в версиях операционных систем Microsoft до Windows 2000, основной причиной которого было то, что операционная система не ограничивала установку DLL. От установщиков приложений ожидалось, что они будут добросовестными гражданами и будут проверять информацию о версии DLL перед перезаписью существующих системных DLL. Стандартные инструменты для упрощения развертывания приложений (которое всегда включает отправку зависимых DLL операционной системы) предоставлялись Microsoft и другими сторонними поставщиками инструментов. Microsoft даже требовала от поставщиков приложений использовать стандартный установщик и сертифицировать свою программу установки для корректной работы, прежде чем им будет предоставлено право использовать логотип Microsoft. Подход добросовестного установщика не смягчил проблему, поскольку рост популярности Интернета предоставил больше возможностей для получения несоответствующих приложений.
Если люди могут неправильно регистрировать или писать общие компоненты, это приводит к DLL hell. Неважно, нарушает ли это спецификации COM — если это может случиться с самым глупым пользователем и/или программистом, это может случиться. Мы не можем убрать раздел об DLL hell, но вы можете добавить смягчающие факторы, такие как нарушение спецификации COM, SxS DLL, локальная регистрация и т. д. MatthewMastracci 21:15, 2 мая 2007 (UTC) [ ответить ]

Но если спецификация разработана с конкретным намерением положить конец DLL hell, и если она эффективно предоставляет программистам средства для этого, то ошибочно рассматривать спецификацию как ВКЛАДЧИКА в эту проблему. Тот факт, что программисты сталкиваются с трудностями в соответствии со спецификациями (и признанными "лучшими практиками"), не имеет значения. Если бы люди всегда тщательно следовали спецификации (и рекомендациям по установке/регистрации), DLL Hell не было бы. Учитывая бесчисленное множество сценариев, это почти невозможно (отсюда и DLL hell), но можно было бы по крайней мере упомянуть, что она предоставляет ПУТЬ к этой цели, где необработанные DLL делали/не делают. — Предыдущий неподписанный комментарий, добавленный Powermonger666 ( talkcontribs ) 13:14, 21 января 2011 (UTC) [ ответить ]

Почти. Все заявления, относящиеся к "DLL Hell" в COM, ложны. Я подозреваю, что это было введено кем-то, кто увидел, что компоненты COM упакованы в DLL, а затем сказал: "О, боже; там, должно быть, тот же самый DLL hell". Поскольку не было никаких обоснованных заявлений в поддержку критики "DLL hell" (примечание: не подразумевая, что такого никогда не было в линейке Windows 9x с обычными DLL), эта критика кажется необоснованной. Поскольку она потенциально вредна, она теперь удалена. Userup ( обсуждение ) 06:23, 23 марта 2011 (UTC) [ ответ ]
Не все ложны, описание COM без регистрации верно. Также неважно, является ли он потенциально вредоносным, важно, является ли он верным.-- Alvin-cs 19:41, 29 марта 2011 (UTC) [ ответить ]
Эффект DLL hell происходит, даже если кто-то обновляет library.dll V1 до V2, если какой-то клиент зависит от (возможно, недокументированного) поведения старой версии. COM (с регистрацией) не делает это проще. Некоторые ситуации можно решить, всегда создавая новый интерфейс, однако иногда автору компонента нужно невинно, например, исправить ошибку и не знать, что какой-то клиент сломается. COM без регистрации решает это, изолируя такую ​​поломку в приложении, которое обновило свои DLL.-- Alvin-cs 19:41, 29 марта 2011 (UTC) [ ответить ]

Где версия этой статьи для неспециалистов?

Эта статья может быть хороша сама по себе (или нет, у меня нет опыта, чтобы это утверждать), но разве энциклопедия не должна объяснять что-то людям, которые еще не понимают предмет?

Я своего рода программист, в основном самоучка, но довольно опытный. Но я в основном из мира Unix. Я бы очень хотел, чтобы была статья в Википедии, которая бы объяснила некоторые из алфавитного супа технологий Microsoft людям, которые еще не знают большую часть из них. Я могу щелкать ссылки весь день в этих статьях Википедии, от COM до OLE, от WinFX до .NET, но все они, похоже, ссылаются друг на друга, и никто из них не объясняет это не экспертам Windows.

--Headybrew 11:05, 29 мая 2006 (UTC) [ ответить ]

Хм. Я думаю, что вступительное предложение уже описывает, что делает COM / для чего он нужен, и если вам нужны технические или исторические подробности, вы можете прочитать эти разделы. Есть ли какая-то конкретная часть статьи, которую трудно понять? Shinobu 03:53, 27 июня 2007 (UTC) [ ответить ]
Первый абзац смехотворно тупой, в нем использован излишне технический язык вместо того, чтобы дать базовое введение к статье и позволить более подробное описание в тексте статьи 90.195.27.222 ( обсуждение ) 00:41, 2 февраля 2010 (UTC) [ ответ ]

Производительность .NET

«Кроме того, компонент COM теоретически всегда должен иметь лучшую производительность, чем соответствующий управляемый компонент .NET».

Это действительно так? Теоретически .NET быстрее, так как не требует, чтобы каждый вызов функции был виртуальным, и не нужно постоянно AddRef/Release ссылок на объекты.

Он делает то же самое и в 10 раз больше, просто он скрыт от программиста. Как, черт возьми, он управляет подсчетом ссылок, если не с помощью функций, похожих на AddRef/Release?
Все очень просто: он вообще не использует подсчет ссылок, а использует трассирующий, сжимающий, многопоколенческий сборщик мусора . -- int19h 18:45, 25 мая 2007 (UTC) [ ответить ]

Очистка

Эту статью нужно немного подчистить, особенно раздел «История», который имеет тенденцию повторяться довольно часто. Также я удалил строку «Кроме того, компонент COM теоретически всегда должен иметь лучшую производительность, чем соответствующий управляемый компонент .NET», потому что это спорное и необоснованное утверждение. В зависимости от того, с кем вы говорите, некоторые люди скажут, что JIT-скомпилированные языки теоретически должны быть быстрее, чем изначально скомпилированные языки, потому что язык JIT имеет возможность для машинно-специфических оптимизаций. Без какой-либо ссылки это просто шум, который на самом деле ничего не добавляет к статье.12.34.246.4 22:25, 30 ноября 2006 (UTC) [ ответить ]


COM устарел?

COM имеет грязную историю. Он оставил след технологий, который будет с нами долгие годы. Все началось, когда было решено, что было бы хорошей идеей, если бы можно было, например, встроить электронную таблицу в документ текстового процессора, чтобы обновления электронной таблицы автоматически обновляли документ. В то же время программные компоненты как решение проблемы повторного использования кода были очень многообещающими. От программистов ожидалось, что они освоят заклинания среды, создание экземпляров, проверку интерфейсов, изящную деградацию функции в случае, если последняя версия объекта недоступна, подсчет ссылок и так далее и тому подобное. После того, как все это сделано, остается еще одна мелкая деталь — убийство дракона, которого должна убить программа, которую пытаются разработать. В COM не хватает простоты размышлений, которая позволяет программисту принимать решения во время выполнения на основе того, что предлагается в библиотеке COM. Вот в чем превосходен .NET Framework и почему COM — это прошлое, а .NET Framework — настоящее и будущее.--151.200.244.58 18:38, 2 декабря 2006 (UTC) [ ответить ]

COM — это не «прошлое». Все, что обсуждает этот парень, верно (кроме «отражения», как отмечено ниже), но он предполагает среду выполнения. Со средой выполнения все проще. Без среды выполнения приходится решать перечисленные выше проблемы, и это В ОСНОВНОМ, чем и является «COM» — способом решения этих проблем для компонентов, скомпилированных машиной. Он все еще широко используется (например, DirectX). — Предыдущий неподписанный комментарий, добавленный Powermonger666 ( talkcontribs )

COM поддерживает нечто похожее на то, что мы называем "Reflection" в .NET. Это называется TypeLibraries. COM с самого начала поддерживал эту концепцию запроса "типа" объекта, при условии, что объект поддерживал интерфейсы ITypeLib/ITypeInfo. Также COM поддерживает популярный IDispatch для реализации автоматизации в компонентах, что делает их доступными в скриптовых языках. 72.78.10.98 10:03, 13 марта 2007 (UTC)Виджай Рави [ ответить ]

Apprently, .NET CLR — это объект DCOM, ссылающийся на Windows Internals пятого издания, так почему же .Net обесценивает COM? Так что COM — это не .Net не заменяет COM, это оболочка для COM .. — Предыдущий неподписанный комментарий добавлен Bibo1978 (обсуждение • contribs ) 13:27, 31 мая 2010 (UTC) [ ответить ]

В разделе ".NET" говорится: "Некоторые службы, предоставляемые COM+, были в значительной степени заменены недавними выпусками .NET. Например, пространство имен System.Transactions в .NET предоставляет класс TransactionScope, который обеспечивает управление транзакциями без обращения к COM+". Но это не так. System.Transsactions — это способ использования COM+ Enterprise Services в .NET. — Предыдущий неподписанный комментарий добавлен Powermonger666 ( talkcontribs ) 18:33, 21 января 2011 (UTC) [ ответить ]

Диаграммы объектов

При визуализации COM-объектов часто рисуют симпатичные маленькие диаграммы, например:

 ______________________ | ____________ | | | | |O-+-----|ИнтерфейсA | | | |____________| | | ________________ | | | ____________ | | | | | | | | | O-+-| ИнтерфейсB | | | | | |____________| | | | | ____________ | | | | | | | |O-+---+-|ИнтерфейсC | | | | | |____________| | | | |________________| | |______________________|

Поскольку они так широко используются, разве не имеет смысла привести пример в статье? Не как ужасное ASCII-искусство, конечно, а как SVG? Shinobu 03:47, 27 июня 2007 (UTC) [ ответить ]

Примечание: вы также часто видите подобные вещи, например, в документации Microsoft.

 О ______|_ | |ИнтерфейсA O--| | | |ИнтерфейсC O--| | |________|

Верхний круг представляет IUnknown. Shinobu 07:56, 4 июля 2007 (UTC) [ ответить ]

Отдельная категория для COM

Учитывая количество статей в Википедии, которые можно отнести к категории COM, как насчет создания категории «Модель компонентных объектов», подобной той, что есть в .NET? — Предыдущий неподписанный комментарий, добавленный Xpclient ( обсуждениевклад ) 09:51, 4 февраля 2008 (UTC) [ ответ ]

Неплохая идея. Просто добавьте [[Category:Component Object Model]] на соответствующие страницы и напишите аннотацию для страницы категории. Я бы сделал это сам, но ухожу на техническое обслуживание. Shinobu ( talk ) 04:46, 6 сентября 2008 (UTC) [ reply ]

Историческая информация крайне обманчива

В этой статье полностью игнорируется уровень DCE RPC, из которого развился COM. В частности, игнорирование этого факта исключает тот факт, что основные части истории COM не являются частью Microsoft. —Предыдущий неподписанный комментарий добавлен 202.160.48.164 ( обсуждение ) 20:21, 18 декабря 2008 (UTC) [ ответить ]

DCOM основан на DCE RPC (и это, безусловно, следует упомянуть), а COM — нет. — Предыдущий неподписанный комментарий добавлен 86.178.56.128 ( обсуждение ) 21:19, 9 марта 2010 (UTC) [ ответить ]

Нужна ли ссылка на каждый абзац?

Неужели действительно нужно цитировать каждый абзац? Кто-нибудь думает, что нам следует удалить большую часть этих ссылок?

КОМ+

Мне бы очень хотелось, чтобы аннотация к COM+ была более подробной и подробной. Я только что начал работать в компании с корпоративным приложением, которое в значительной степени опирается на COM+, и я надеялся уйти с лучшим пониманием того, как оно работает и почему его стоит использовать.

Chrisfeohpatti (обсуждение) 16:03, 30 марта 2009 (UTC) [ ответить ]

Тогда вам лучше спросить разработчиков приложения. Это будет быстрее, чем ползать всю дорогу самостоятельно. — Vano 08:53, 21 ноября 2009 (UTC) [ ответить ]

Отказ от COM в пользу .NET

Хотя удаленное управление/маршалинг — это распространенная проблема, которую решают как .NET, так и COM, я не вижу, как COM устарел в пользу .NET. .NET ни в коем случае не является альтернативой COM для собственной разработки, даже после введения C++/CLI (из-за зависимости от .NET Fx). —Предыдущий неподписанный комментарий добавлен 41.235.169.14 (обсуждение) 23:11, 17 июля 2009 (UTC) [ ответить ]

Да. COM устарел. Даже в 2009 году будущее было (и, что удивительно, 25 лет спустя, все еще есть) .NET. Stevebroshar ( обсуждение ) 21:26, 23 июня 2024 (UTC) [ ответить ]

Двоичный интерфейс приложения COM

Есть ли где-нибудь эта спецификация? Похоже, все знают подробности (поскольку они пишут COM-совместимые компиляторы/библиотеки), но никто ничего не говорит! Какая отвратительная... — Vano 10:30, 27 января 2010 (UTC) [ ответить ]

отвратительно? Странный выбор слова. ... Он двоичный, но также настраиваемый. Есть некоторые встроенные интерфейсы, такие как IUnknown и IDispatch (погуглите их), а затем есть пользовательские интерфейсы. Вы пишете свой собственный. COM определяет, как он работает в целом, но детали настраиваются. Итак, у COM нет ABI. Это способ определения и ABI. Stevebroshar ( обсуждение ) 21:24, 23 июня 2024 (UTC) [ ответить ]

Инстанцирование

Этот раздел начинается с "COM стандартизирует процесс инстанцирования (т.е. создания) объектов COM, требуя использования фабрик классов". Фабрики классов абсолютно НЕ требуются для создания объектов.

Пример 1: Многие системные COM-объекты создаются с помощью вызова API (например, CoGetMalloc).

Пример 2: В объектной модели документа, реализованной в COM, корневой объект может иметь фабрику, но другие объекты создаются с использованием методов корня. — Предыдущий неподписанный комментарий добавлен 86.178.56.128 ( обсуждение ) 21:32, 9 марта 2010 (UTC) [ ответить ]

COM от других поставщиков.

В 1995 году Bristol Technology, Inc. разработала технологию OLE1 для использования на платформах UNIX. Однако, когда MS выпустила OLE2, Microsoft подняла сборы до уровня, на котором BT стало не по карману продолжать разработку OLE2. См. соответствующую статью на http://www.techlawjournal.com/courts/bristol/Default.htm Wheger ( talk ) 20:27, 18 марта 2010 (UTC)wheger [ reply ]

COM и DCOM

Я всегда задавался вопросом, как некоторые объекты являются допустимыми объектами DCOM (например, объекты, созданные VB6), а некоторые объекты могут использоваться только локальным COM (например, все объекты MS Office). Если бы вы могли DCOM в DAO (объект базы данных MS), вы могли бы настроить сервер сетевой базы данных DAO: Вы не можете этого сделать из-за некоторых различий в объекте. Но ничего здесь или в DCOM, чтобы объяснить, чем отличается интерфейс. 122.107.141.71 (обсуждение) 23:52, 11 октября 2010 (UTC) [ ответить ]

типы квартир

Я не добавляю их напрямую в статью, поскольку у меня нет вторичных источников.

  • Microsoft сокращает название нейтральной квартиры как NA, а не NTA.
  • Для STA это неверно: «Таким образом, среда выполнения COM обеспечивает автоматическую синхронизацию, чтобы гарантировать, что каждый вызов метода объекта всегда выполняется до завершения, прежде чем будет вызван другой». Если метод в STA вызывает другой апартамент (кроме NA), то другой метод может быть запущен в STA, пока первый метод ожидает, поэтому методы должны быть готовы к такому виду повторного входа.
  • В Windows 8 также есть Application Single-Threaded Apartment (ASTA). Потоки приложений и DirectX

85.131.104.149 (обсуждение) 06:59, 25 июня 2013 (UTC) [ ответить ]

разрядность (32 бит, 16 бит, 64 бит)

Пришел в поисках описания разницы между 32-битным COM и 64-битным COM (и возможно ли преобразование COM+) — Предыдущий неподписанный комментарий добавлен 203.206.162.148 ( обсуждение ) 05:47, 24 марта 2017 (UTC) [ ответить ]

Здравствуйте, уважаемые википедисты!

Я только что изменил одну внешнюю ссылку на Component Object Model . Пожалуйста, уделите немного времени, чтобы просмотреть мои правки. Если у вас есть какие-либо вопросы или вам нужно, чтобы бот игнорировал ссылки или страницу в целом, посетите этот простой раздел FaQ для получения дополнительной информации. Я внес следующие изменения:

  • Добавлен архив https://web.archive.org/web/20090215185257/http://innovatia.com/software/papers/com.htm на http://www.innovatia.com/software/papers/com.htm

Закончив просмотр моих изменений, вы можете следовать инструкциям в шаблоне ниже, чтобы исправить любые проблемы с URL-адресами.

Это сообщение было опубликовано до февраля 2018 года . После февраля 2018 года разделы страниц обсуждения "Внешние ссылки изменены" больше не генерируются и не отслеживаются InternetArchiveBot . Никаких специальных действий в отношении этих уведомлений страниц обсуждения не требуется, кроме регулярной проверки с использованием инструкций инструмента архивации ниже. Редакторы имеют право удалять эти разделы страниц обсуждения "Внешние ссылки изменены", если они хотят очистить страницы обсуждения от загромождения, но перед выполнением массовых систематических удалений ознакомьтесь с RfC . Это сообщение динамически обновляется через шаблон (последнее обновление: 5 июня 2024 г.) .{{source check}}

  • Если вы обнаружили URL-адреса, которые бот ошибочно посчитал неработающими, вы можете сообщить о них с помощью этого инструмента.
  • Если вы обнаружили ошибку в архивах или самих URL-адресах, вы можете исправить их с помощью этого инструмента.

Привет.— InternetArchiveBot ( Сообщить об ошибке ) 19:23, 11 августа 2017 (UTC) [ ответить ]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Component_Object_Model&oldid=1267108539"