La diferencia entre DLL tradicional y COM DLL

Question

Actualmente estoy estudiando COM. Descubrí que COM DLL se basa en la infraestructura DLL tradicional. Cuando construimos DLL COM, seguimos confiando en los métodos tradicionales de exportación de DLL para llevarnos a las clases internas de COM.

Si COM es para la reutilización de componentes en el nivel binario, creo que la DLL tradicional puede lograr lo mismo. Ambos exponen funciones, ambas son binarias, ¿cuál es el sentido de recurrir al enfoque COM?

Actualmente, tengo la sensación de que la DLL tradicional exponer métodos en un "plana" forma, mientras que el DLL COM exponer métodos de una "programación orientada a objetos " de manera jerarquía. Y la manera OOP parece ser un mejor enfoque. ¿Podría ser esta la razón por la cual COM prevalece?

Muchas gracias.

Answer 1

No, hay una gran diferencia. COM tiene protocolos bien definidos para crear objetos, exponer métodos, administrar memoria, publicar información de tipo, administrar el enhebrado. Prácticamente no queda lenguaje que no sea compatible con el uso de un servidor COM, independientemente del idioma en el que esté escrito.

No podrá exponer sus propias funciones directamente. Es probable que solo sea utilizable desde un programa escrito en C/C++ (para que pueda leer sus archivos de encabezado), compilado con la misma versión del compilador de C++ y sin la falta de todo tipo de problemas de interoperabilidad. Algo tan simple como exponer un objeto de clase C++ como std :: string no es seguro. Ni el diseño de la memoria está garantizado para ser compatible, ni existe ningún tipo de protocolo de propiedad de la memoria.

Podría ser más OOPy, COM no admite herencia porque OOP es tan difícil de obtener a nivel binario. Ese problema requiere soporte en tiempo de ejecución que todo el código compra en máquinas virtuales como .NET y Java.

Answer 2

Una DLL COM es simplemente una DLL con puntos de entrada específicos de Com. COM expone fábricas de clase para crear objetos com, por lo que debe haber una forma de obtener acceso a una de las fábricas de clase implementadas por un servidor COM. Eso es lo que hace DllGetClassObject. Además, las DLL COM se autoregistran: pueden notificar a Windows sobre sus clases e interfaces disponibles. El punto de entrada para tener el registro DLL en sí es DllRegisterServer.

Hay un par de otros puntos de entrada, pero están en esta línea.

Si no hubiera un punto de entrada bien definido para DllRegisterServer, los clientes no podrían provocar que las DLL se autoregistraran. Haría que la instalación de los componentes COM sea más compleja.

Si no hubiera un punto de entrada estandarizado para obtener fábricas de clase, entonces cada DLL tendría que definir su propio punto de entrada y esa información tendría que colocarse en el Registro de Windows para que la infraestructura COM supiera cómo hacerlo acceder a la fábrica de clases de cada DLL. No hay justificación para la complejidad adicional, por lo que el punto de entrada también está estandarizado.

En cuanto a dónde COM difiere de 'C', la principal diferencia es el concepto de contratos. COM alienta a los programadores a pensar en términos de interfaces abstractas entre módulos en lugar de una descomposición jerárquica descendente de la funcionalidad. Este es un tipo de 'OOP', pero ese término es demasiado flojo para ser de mucha utilidad, IMO. Las ventajas del enfoque orientado a contratos son múltiples para los lenguajes fuertemente tipados y vinculados estáticamente, como C/C++.

Answer 3

Si usted quiere aprender acerca de las razones de la introducción de COM y la filosofía detrás de él, recomiendo encarecidamente la lectura de From CPP to COM

Answer 4

Creo que al leer el primer capítulo de COM esencial que tendrá una muy buena idea de por qué usar COM

Para ser simple, COM garantiza la compatibilidad en el nivel binario, sin importar el idioma que utilizó, la versión del compilador que utilizó. No se trata de lo de "OOP", de seguro podría exponer la clase de C++ desde una DLL, pero no son "compatibles con binarios".

Answer 5

La diferencia clave es que COM permite la compatibilidad binaria.

Si agrega/quita funciones y reconstruye una DLL tradicional, entonces las aplicaciones cliente probablemente fallarán cuando intenten utilizar la DLL porque fueron compiladas con la versión anterior.

COM introdujo el concepto de interfaces, que son inmutables por lo que no deben modificarse entre compilaciones, etc. Cada objeto COM debe implementar la interfaz IUnknown que contiene el método QueryInterface que se utiliza para solicitar punteros a otras interfaces compatibles .

La especificación COM garantiza que la interfaz IUnknown esté siempre en el mismo lugar en la DLL, por lo que incluso si un objeto se revisa para admitir más interfaces, el método QueryInterface aún se puede llamar de forma segura.

Answer 6

La mejor manera de pensar en COM es imaginarlo como un contrato entre usted y la persona que usa el objeto que usted crea.

maneja COM

1. cómo versión de su objeto a través de comunicados de
2. cómo descubrir su objeto, incluso si su objeto está en un archivo DLL que consigue renombrado o vino de una fuente diferente
3. cómo referencia y destruir su objeto (con respecto a montones)
4. cómo espera que funcione el enhebrado, y las reglas que rodean el enhebrado/bloqueo para su objeto

COM se ha convertido en un estándar porque si bien podría hacer una DLL tradicional que maneja cada uno de los elementos anteriores, tendría que articular el contrato esperado al enviar su DLL

usando las reglas de COM, esta articulación es hecho para usted

también tiene la razón de que COM expone objetos mientras que DLLS más tradicional acaba de exponer funciones. a menudo verá que los desarrolladores intentan emular los contratos encontrados en COM en línea recta, por lo general los verá clonar aspectos de COM en su DLL (por ejemplo, verá métodos que devuelven estructuras de indicadores de función) ... mi la experiencia es que si no usa COM para hacer una DLL pública está aumentando las probabilidades de perder algunos casos, especialmente cuando el versionado está en la imagen

Answer 7

La DLL tiene muchos usos en Windows. Muchos tipos de códigos de biblioteca se almacenan en DLL. Uno de estos, por ejemplo, es ensamblados .net, que es una bestia diferente.

DLL COM no es mejor que "DLL Binary PE simple" porque COM DLL es también DLL.Lo que hace DLL DLL COM está exponiendo, posiblemente además de otras cosas, ciertas exportaciones que coinciden con un determinado contrato (firma) [búsqueda de entrada IUnknown], o incluso varios tipos de interfaces canonizadas [búsqueda de entrada 'dual interface'] que no permiten solo creación de instancias de objetos específicos dentro de la DLL pero también descubrimiento automatizado de servicios, incluidos nombres de funciones y tipos de parámetros.

Las interfaces duales hacen que sea muy útil para vincular a los lenguajes de scripting (utilizados en web, scripts de shell, programas educativos, etc.) porque a los programadores de scripts no les importa el tipeo estricto. Una interfaz dual expuesta por COM DLL permite al scripting runtime consultar exactamente qué tipos espera y hacer los lanzamientos adecuados, sin interrupciones para el usuario.

Esta flexibilidad permite la construcción de una gigantesca infraestructura COM, que incluye el registro de componentes, DCOM (invocación a través de la red), etc. Hace más conveniente proporcionar interfaces COM en componentes de Windows (WMI, por ejemplo) y oficina componentes. Se implementaron muchas otras interfaces populares por encima de COM, como ADO.

Todo esto es bueno, pero COM no "prevalece" en ningún sentido. Las DLL COM son una minoría de DLL. Los archivos DLL simples y .NET son muy populares. Microsoft considera que las interfaces .net son superiores a COM. Muchos fanáticos de Unix y otros consideran que las DLL son una mala idea, ya que no ofrecen servicios de vinculación en tiempo de ejecución en el mismo sentido que los objetos compartidos de Unix. A pesar de ser un desarrollador de Windows, también creo que los SO brindan una alternativa superior, y espero tenerlos una vez.

Answer 8

Además de las respuestas ya publicadas, las interfaces COM exponen objetos de datos binarios en un lenguaje de programación independiente, que permite que la memoria para estos objetos se asigne en un espacio de direcciones de proceso y se libere en otro. Búsqueda de clasificación y desasociación.

También permite pasar cadenas sin prestar atención a los detalles de codificación para determinar dónde podría estar el terminador nulo. Las cadenas COM se cuentan cadenas UNICODE.

Agregue IDL y compile la biblioteca de tipos en la DLL, y tiene interfaces de autodescripción. Con archivos DLL simples, debe saber desde los documentos externos qué métodos tienen y los parámetros que toman.

El estándar COM también puede ser multiplataforma. Las versiones para Mac de Office admiten COM, y ha habido implementaciones para sistemas Unix y similares a Unix, aunque nunca han sido populares.