PDF 306K

Transcription

PDF 306K

Komponentenbasierte Softwareentwicklung
27.11.2006
Thema:
COM / .Net Interop
Datum:
27.11.2006
Student:
Robert Berger (291608)
Seite 1
Robert Berger
27.11.2006
Inhaltsverzeichnis
1Einleitung........................................................................................................................................... 3
2Architektur..........................................................................................................................................4
2.1COM Runtime.............................................................................................................................4
2.2COM Objekte..............................................................................................................................4
2.3Server.......................................................................................................................................... 4
2.4Schnittstellen...............................................................................................................................6
2.5Datentypen.................................................................................................................................. 6
2.6Programme..................................................................................................................................7
3Weiterführende Themen..................................................................................................................... 7
3.1ATL.............................................................................................................................................7
4Zusammenspiel mit .NET (Interop)................................................................................................... 8
4.1Wrapper...................................................................................................................................... 8
4.2Programme..................................................................................................................................9
5Beispiele............................................................................................................................................. 9
5.1ATL Server................................................................................................................................. 9
5.2ATL Client................................................................................................................................11
5.3.NET Client...............................................................................................................................12
5.4.NET Server.............................................................................................................................. 12
5.5Überblick.................................................................................................................................. 13
6Fazit.................................................................................................................................................. 14
7Quellen............................................................................................................................................. 15
8Literatur............................................................................................................................................ 15
Seite 2
Robert Berger
27.11.2006
1 Einleitung
COM steht für „Component Object Model“ und stellt genau dies dar. Microsoft hat
versucht ein Objektmodell aufzusetzen, welches alle für die komponentenbasierte
Entwicklung notwendigen Punkte zu dieser Zeit abdeckt. Das sich aus dem OLE
entwickelte COM beherrscht verschiedene Möglichkeiten Komponenten einzubinden.
Dazu zählen drei Varianten. Die erste ist eine in den gleichen Prozessraum
ausgeführte Komponente, die zweite findet sich in einem eigenen Prozessraum wieder
und die dritte sogar auf einem anderen Host. Als Grundlage für alle drei dient die COM
und DCOM Runtime, welche sich als Dienst in der Windows Konfiguration ab
Microsoft Windows NT wiederfindet.
Wie auch das verteilte Objektmodell CORBA nutzt COM die IDL zur
Schnittstellendefinition und im Grunde ist es auch genau das was COM eigentlich
darstellt, einen Schnittstellen und Binärstandard. Die IDL ist die „Interface Definition
Language“, eine Sprache mit der es möglich ist Schnittstellen für COM in einem
Binärformat zu definieren. COM ist nur eine Definition, mit der über IDL Schnittstellen
Komponenten angesprochen werden können. Die Implementation, die hinter der IDL
Schnittstelle liegt ist laut der Spezifikation egal. Dies führt auch dazu, dass COM über
alle gängigen Sprachen angesprochen werden kann. Da zur Entwicklungszeit von
COM Ende der 90er Jahre Themen wie Reflection oder Garbage Collection nur in
vereinzelten Projekten eine Rolle spielten, ist nicht verwunderlich das de
Implementationssprache C++, welche diese Eigenschaften nicht mit sich bringt, über
„alte“ Techniken, wie „Referenz Counting“ oder „Identificationnumbers“, Probleme bei
der Implementierung löst.
Die Implementation die hinter COM oftmals liegt enthält wie angedeutet,
Referenzzähler, um die Lebenszeit von Objekten zu ermitteln, sowie
Identifikationsnummern, die UID (Unique Identifikation Number), welche mit Hilfe der
Windows Registratur die Dll und deren Inhalt identifiziert. Dabei stehen verschiedene
Identifikationsnummern für die Binärdatei, deren interne zugängliche Klassen oder
sogar für Methoden, um diese über dynamisch erfragte Listen aufzurufen, zur
Verfügung. Über vordefinierte Schnittstellen ist der Zugriff auf Inhalte einer Dll möglich.
Dabei werden Fabriken zur Generierung von Objekten genutzt, welche im Nachhinein
in die jeweiligen Schnittstellen konvertiert werden. Diese sind dann dem
Programmierer zugänglich und er kann über die in der Schnittstelle festgelegten
Methoden auf Funktionen, oder Elemente zugreifen.
COM selber gibt dem Programmierer vordefinierte Schnittstellen an die
Hand, mit denen er in der Lage ist, andere Schnittstellen zu erfragen, Elementare
Funktionen, wie das Erstellen von Zeichenketten in der COM Runtime zu ermöglichen,
oder nur Referenzzähler rauf und runter zu zählen. Es existieren Schnittstellen zum
Debuggen oder erstellen von eigenen Datentypen und deren Übersetzung
(Marshelling) während der Übertragung zur Komponente. Vordefinierte Datentypen
kapselt COM in einem einzigen Datentyp, welcher jeweils einen der definierten
Basistypen Typen enthält.
Seite 3
Robert Berger
27.11.2006
2 Architektur
2.1 COM Runtime
Die COM Runtime ist als Windows Dienst, ab der Version Windows NT installiert.
Man findet in der Liste der Dienste 3 Einträge, welche auf die COM
Laufzeitumgebung schließen lassen. Die ersten beiden, gehören zur COM+
Laufzeitumgebung, welches eine Erweiterung von COM darstellt, mit der
Enterprise Services realisiert werden können.
Der DCOM Server ist leicht an dem Namen „DCOM-Server“ zu erkennen. Die
COM Runtime läuft als elementarer Windowsteil im Hintergrund mit. Dieser sorgt
für das aufrufen und einbinden der Komponenten, in den jeweiligen Prozessraum.
Weitere Aufgaben, sind die Weiterleitung der Aufrufe, welche als RPC Aufrufe
realisiert sind und das übertragen und wandeln der Standarddatentypen kümmert.
2.2 COM Objekte
Ein COM Objekt ist eine durch eine Implementation gefüllte Schnittstelle. Dieses
COM Objekt ist in alle Schnittstellen wandelbar, die es selber kennt. Über
Standardschnittstellen kann diese Wandlung durchgeführt werden und ist von
jedem Objekt, bzw. jeder Schnittstelleninstanz möglich. COM Objekte werden in
dem jeweils nach Serverart definierten Prozessraum erstellt und nach Zugriff
referenziert. Die Persistenz dieser Objekte ist über den Mechanismus des
„Reference Counting“ gelöst. Wenn der Nutzer der Komponente keine
Verwendung mehr für diese hat und somit deren Referenzzähler zurückzählt,
zerstört sich das Objekt selber.
2.3 Server
COM stellt sich als Client Server Architektur dar und besitzt drei Arten von
Servern, InProg-, OutProg- und Remote. Der Client nutzt jeweils einen davon.
InProg-Server
Eine als InProg-Server geöffnete Variante, lädt die durch eine UID angeforderte
Komponente in den Prozessraum der anfragenden Anwendung. Dort kann sie
direkt über die Schnittstellen genutzt werden. Dies ist die schnellste der
Varianten. Die Komponente selber liegt dabei als Dll im System registriert vor und
kann daher von der
COM
Runtime
Prozessraum Calculator.exe
gefunden werden. Bei
einem Fehler der
IUnkown
ISum
Komponente besteht
Client
die
Gefahr
dass
Calculator
dieser
auf
die
Anwendung
IMultiply
überspringt und diese
beendet.
CalculatorServer.dll
Seite 4
Robert Berger
27.11.2006
OutProg-Server
Der OutProg-Server stellt sein COM Objekt aus einem anderen Prozessraum der
aufrufenden Anwendung zur Verfügung. Damit dies möglich ist und der Aufruf
sich beim Client nicht von einem normalen InProg- Aufruf unterscheidet, findet
dieser dazu in seinem Prozessraum ein Proxyobjekt, dass die gleichen
Eigenschaften, wie das Original aufweist. Der Proxy kommuniziert über die COM
Runtime mit dem zugehörigen Stub- Objekt, das auf der anderen Seite, im
Prozessraum des Servers das COM-Objekt mit den Aufrufen vom Client bedient.
Client Process
Client
Server Process
ProxyObject
StubObject
COM
Object
Interprocess-Communication (COM Runtime / Windows)
Remote-Server
Der Remote Server ist der dritte im Bunde und ermöglicht die Kommunikation
über Rechnergrenzen hinweg. Die Kommunikation erfolgt wie beim OutProgServer übe des Proxy Stub Muster. Zusätzlich jedoch überträgt der DCOM Dienst
die Daten und Aufrufe über das TCP/IP Protokoll, auf das äquivalent am anderen
Ende. Dies ist der langsamste aller Server, da er zusätzlich von der Netzwerklast
und anderen Faktoren in seiner Ausführungsgeschwindigkeit beeinflusst wird. Alle
Daten werden in einem Binärformat übertragen und erzeugen somit schon den
geringsten Aufwand in der Übertragung. Der jeweilige Port muss bei einer
Firewall freigegeben werden, da sonst keine Kommunikation möglich ist.
Client Process
Client
Server Process
ProxyObject
Interprocess-Communication
(COM Runtime / Windows)
Seite 5
StubObject
DCOM
Network Protokoll
COM
Object
Interprocess-Communication
(COM Runtime / Windows)
Robert Berger
27.11.2006
Jede für COM geschriebene Komponente kann als jede der drei Varianten
aufgerufen werden. Der Aufruf dieser erfolgt beim Client mit der Initialisierung der
COM Runtime über entsprechende Funktionen. Diesen muss mitgegeben
werden, welche Servervariante zu nutzen ist. Dies kann aber nur geschehen,
wenn die Dell in der Windows Registratur für alle drei Server registriert ist.
2.4 Schnittstellen
Jedes COM Objekt ist mit dem COM Binärformat und der Runtime bestimmten
Regeln unterworfen. Dazu zählen auch das jede definierte Schnittstelle vom
Basisinterface „IUnknown“ abgeleitet werden muss. Dieses implementiert im
Grunde den Reflection Mechanismus und regelt über zwei Methoden die
Persistenz jedes Objektes. Für die Erstellung einer Binärdatei (Dll, Exec) ist eine
weitere Schnittstelle notwendig, die eine Fabrik zur Generierung der Objekte
ermöglicht. Diese wird später über die Befehle der Runtime gesteuert. Zur
Registrierung der Binärdatei müssen aus dieser eine Anzahl vorgegebener
Funktionen exportiert werden. Die Implementation eines kleinen COM Beispiel
wäre mit diesen Anforderungen abgeschlossen.
Für eine Erweiterung der Binärdatei sind zusammen mit den vorherigen
Aufzählungen noch folgende Regeln zu erwähnen.
1. Jedes Interface muss IUnknown erweitern.
2. Jedes COM Objekt muss min. IUnknown und IClassFactory erweitern.
3. Die Definition der Schnittstellen muss mittels IDL erfolgen.
4. Die Binärdatei muss die aufgeführten Funktionen exportieren:
●
●
●
●
DLLRegisterServer
DLLUnregisterServer
DLLGetClassObject
DLLCanUnloadNow
Natürlich wird für eine volle Funktionserklärung auf einschlägige Literatur
verwiesen (Siehe Punkt 7).
2.5 Datentypen
COM besitzt fest definierte Datentypen, diese werden als UNION über den Typ
VARIANT dargestellt. Jener besitzt alle gängigen Typen, für die ein
Standardwrapper existiert. Eine Übertragung ist somit ohne das nutzen des
IMarshal Interface möglich. Die Allokierung von Speicher für jeweilige
Datentypen ermöglichen Funktionen der COM Runtime. Somit ist es leicht auf
Kosten der COM Runtime Speicher für eine Zeichenkette zu allozieren und
wieder freizugeben.
Seite 6
Robert Berger
27.11.2006
2.6 Programme
Um COM Binärdateien zu registrieren, kann das Windows Werkzeug
regsvr32.exe aufgerufen werden. Es ruft die exportierten Funktionen der Datei auf
um den Server in der Registratur zu veröffentlichen. Ein zweites Werkzeug liefert
die Visual Studio Umgebung. Die midl.exe steht für Microsoft IDL Generator dar
und erzeugt aus er IDL Datei eine Binäre Typbibliothek, sowie verschiedene
weitere Dateien zur Implementierung in die Sprache C++.
Calculator_h.h
C/C++ definitions
Calculator_i.c
GUIDs
Calculator.idl
midl.exe
Calculator_p.c
Proxy/Stub code
dlldata.c
Class loading support
Calculator.tlb
Binary descriptions
Dateien zur direkten
Implementierung des
Client, Server in C++.
Dateien für die
Implementierung in
anderen Sprachen.
C++
Python
.Net
3 Weiterführende Themen
3.1 ATL
ATL steht für Active Template Library und stellt eine Bibliothek zur Erstellung von
COM Objekten zur Verfügung. Mit Hilfe von Templates erfolgt die Nutzung, wie
man es aus der C++ Standardbibliothek gewohnt ist. Hiermit werden viele
negative Thematiken, die bei der Erstellung von COM Objekten auftreten,
vermindert, oder verschwinden in den Funktionen der Templates. Dazu zählt z.B.
die Abfrage der Rückgabewerte, welche nach jeder COM Operation abzufragen
sind. Weiter wurde mit den Templats auch der Exception Handling Mechanismus
eingeführt und vor allem eine bessere Implementation für Programmierer
ermöglicht. Die Erstellung der eines ATL Server bzw. Client gestaltet sich durch
die große Unterstützung des Visual Studio als sehr einfach. Entsprechende
Beispiele werden unter Punkt 5.1 und 5.2 aufgezeigt. Mit der ATL Bibliothek
erfolgt auch die Nutzung so genannter SmartPointer. Diese stellen Wrapper dar,
mit deren Hilfe die Arbeit mit Schnittstellen erleichtert wird. SmartPointer können
z.B direkt einem Interface zugewiesen werden, ohne dass irgendwelche Abfragen
bezüglich der Möglichkeit überprüft werden.
Seite 7
Robert Berger
27.11.2006
4 Zusammenspiel mit .NET (Interop)
Das Microsoft .NET Framework ist so gestaltet, dass eine Interaktion mit vorhandenen
COM Objekten vollständig möglich ist. Die Microsoft Bibliotheken, stellen sich bei
näherer Betrachtung selber als COM Server dar und können in jeden unmanaged C++
Client oder anderen Sprachen als COM Server genutzt werden. Zur Einbettung
vorhandener COM Server unter .NET, oder anders herum existieren Wapper, die die
Kommunikation ermöglichen. Außerdem stellt Microsoft mit dem Visual Studio noch
verschiedene Programme zur Auswahl, die bei der Integration helfen sollen.
4.1 Wrapper
Es Existieren zwei Wrapper zur Kommunikation zwischen Client und Server. Der
erste ermöglicht den Weg von unmanaged nach managed. Dies ist der RCW
Wrapper. Das Äquivalent dazu stellt der CCW Wrapper dar, der den Weg von
managed nach unmanaged offen legt.
●
RCW
Der „Runtime Callable Wrapper“ ermöglicht den Aufruf von COM-Objekten
innerhalb der .NET Runtime. Für jedes COM Objekt wird ein neuer RCW
erstellt.
verwaltet
nicht verwaltet
IUnkown
COMObjekt
IDispatch
RCW
INew
.NETClient
INew
●
Ein .NET-Client
ruft einen
COM Service auf.
CCW
Der „COM Callable Wrapper“ wird erzeugt, wenn ein COM Client einen
.NET Typ aufruft. Es Existiert für jeden .NET Typ immer nur ein einziges
Proxy Objekt, über das mehrere COM Clients zugreifen können.
verwaltet
nicht verwaltet
IUnkown
Ein COM-Client
ruft einen .NET
Service auf.
Seite 8
IDispatch
RCW
INew
.NET-Objekt
COM-Client
INew
Robert Berger
27.11.2006
4.2 Programme
Das Microsoft Visual Studio gibt dem Entwickler verschiedene Werkzeuge zur
Hand, um die Interoperabilität so einfach wie möglich zu gestalten.
●
Type Library Exporter-Tool (Tlbexp.exe)
Das Tool erstellt aus Klassen und Schnittstellen, die in einer angegebenen
Assembly liegen, eine COM-Typbibliothek. COM-Clients können damit
.NET Klassen aufrufen. Dies ist notwendig, da nur Typbibliotheken mit
einer „#import“ Anweisung in z.B. C++ referenziert werden können.
●
Assembly-Registration-Tool (Regasm.exe)
Das Tool generiert und registriert eine Typbibliothek für COM Clients.
●
.NET Service Installation-Tool (Regsvcs.exe)
Fügt verwaltete Klassen dem Windows 2000 COM Dienst hinzu. Die Daten
werden Geladen, generiert und registriert. Es vereint also die beiden
vorherigen Werkzeuge in einem.
5 Beispiele
5.1 ATL Server
1. Das neue ATL Projekt soll den Namen CalculcatorServer erhalten.
2. In der Auswahl sollte der Punkt DLL schon ausgewählt sein.
3. Folgende Übersicht sollte sich nach dem erstellen in der Klassenansicht
wiederfinden.
Seite 9
Robert Berger
27.11.2006
4. Über das Popupmenü des ersten Projektes muss es möglich sein nun eine
neue Klasse anzulegen.
5. Nach der Auswahl eines einfachen ATL Objektes.
6. Ist man in der Lage diesem einen Namen zu geben. (Calculator).
7. Im nachfolgenden Fenster stellt man noch die Aggregation auf Nein.
8. Nun ist man in der Lage dem Interface Calculator, welches mit der Klasse
erstellt wurde eine neue Methode hinzuzufügen.
9. Nach dem Ausfüllen der Übergabeparameter...
10. Kann man dann die Methodenimplementation in der Klasse ausfüllen.
STDMETHODIMP CCalculator::Sum(long value1, long value2, long* retval)
{
*retval = value1 + value2
return S_OK;
}
11. Nach erfolgreicher Kompilation steht der Server dann zur Verfügung.
Seite 10
Robert Berger
27.11.2006
5.2 ATL Client
Um einen ATL Client zu erstellen muss eine Windows Konsolenanwendung
erstellt werden. Es ist wichtig, dass diese für die Nutzung der ATL Bibliothek
markiert wird. Um nach dem Kopieren der CalculationServerCpp.tlb Datei in das
Projektverzeichnis diese in das Projekt einzubinden, fügt man der stdafx.h
folgende Einträge hinzu.
#import "CalculatorServerCpp.tlb" raw_interfaces_only
using namespace CalculatorServerCppLib;
WICHTIG:
Die TLB Datei, welches die Typbibliothek darstellt, muss der Anwendung
zugänglich sein, da dort alle Schnittstellen definiert sind. Nun kann die
ClientCpp.cpp Datei folgenden Inhalt erhalten:
int _tmain(int argc, _TCHAR* argv[])
{
printf("Press any key to connect to COM Runtime. [KEY]");
getchar();
//-- Open COM Runtime
HRESULT hr = CoInitialize(NULL);
if(SUCCEEDED(hr)) //-- Check if Runtime could be open.
{
try
{
//-- Create new Smartpointer from Type ICalculator
ICalculatorPtr pointer(__uuidof(Calculator));
//-- Use functionality
long result = pointer->Sum(10, 20);
printf("The operation was: 10 + 20 = %d
result);
getchar();
}
\n[KEY]",
}
catch(...) //-- Catch possible COM errors
{
printf("COM Error");
}
//-- Uninitialize COM
CoUninitialize();
printf("COM Runtime unloaded [KEY]");
getchar();
return 0;
}
Seite 11
Robert Berger
27.11.2006
5.3 .NET Client
Der C' Client benötigt zur Nutzung der COM Schnittstelle eine Referenz auf die
Typbibliothek des CalculatorServerCPP. Diese ist über den Punkt References
auszuwählen. Nach dem hinzufügen, kann der COM Calculator Server so genutzt
werden, wie ein normales C# Objekt.
using
using
using
using
System;
System.Collections.Generic;
System.Text;
CalculatorServerCppLib;
namespace ClientCSharp
{
class Program
{
static void Main(string[] args)
{
ICalculator pCalc = new CalculatorClass();
long result = pCalc.Sum(10, 20);
Console.WriteLine("The operation was: 10 + 20 = " +
result + " \n[KEY]");
Console.ReadKey();
}
}
}
5.4 .NET Server
Die Implementierung des C# Servers erfolgt mit der gleichen COM Struktur, wie
beim ATL Server, jedoch ist diese über die Attributierungen der Klassen und deren
Schnittstellen definiert. Das Projekt „CalculatorServerCSharp“ muss gebaut
werden. In den Post-Build-Steps liegen Befehle, die die tlbexp.exe Datei nutzen,
um eine TLB Datei zu erstellen und die Typen in der Windows Registratur zu
registrieren. Mit dem gacutil.exe Werkzeug wird die Assembly im Global Assembly
Cache publiziert. Im Anschluss kann der CSClient aufgerufen werden. Dieser stellt
einen nativen COM Client dar, der auf den .NET Server zugreift.
Seite 12
Robert Berger
27.11.2006
using System;
using System.Runtime.InteropServices;
namespace CalculatorServerCSharp
{
[ComVisible(true)]
[InterfaceType(ComInterfaceType.InterfaceIsDual)]
[Guid("C74C22CF-3B2A-481a-BA58-4D7A3BF10C0C")]
public interface ICalculatorCS
{
[DispId(1)]
int Sum(long value1, long value2, out long result);
}
[ComVisible(true)]
[ComSourceInterfaces(typeof(ICalculatorCS))]
[Guid("B0306A05-38CD-4c3c-8102-8DDA20E0A9FD")]
[ClassInterface(ClassInterfaceType.AutoDual)]
public class CalculatorCSharp : ICalculatorCS
{
public CalculatorCSharp()
{ }
public int Sum(long value1, long value2, out long result)
{
result = value1 + value2;
return 0;
}
}
}
5.5 Überblick
CalculatorServer
●
CalculatorServerCpp
COM Server (CPP)
●
CalculatorServerCSharp
COM Server (.NET C#)
●
CSClient
COM Client (CPP to .NET)
ClientCPP
Seite 13
Server Beispiele
Client Beispiele
●
ClientCPP
COM Client ( CPP[ATL] to COM [CPP] )
●
ClientCPP2
COM Client ( CPP[no ATL] to COM [CPP] )
●
ClientCSharp
COM Client ( .NET[C#] to COM [CPP] )
Robert Berger
27.11.2006
6 Fazit
COM ist ein Ausgereiftes komponentenbasiertes Objektmodell welches seit 1995 die
komponentenbasierte Entwicklung unter dem Windows Betriebssystem definiert.
Punkte die für COM sprechen sind eindeutig Performance Gründe, da das COM
Objektmodell mit seiner InProg-Server Variante äußerst schnell ist. Auch die Remote
Variante, steht in Sachen wie Geschwindigkeit sehr weit vorne, jedoch mit dem
Nachteil das dafür gewollte Verbindungen hergestellt werden müssen, da ein RemoteServer nicht durch eine aktive Firewall verbunden werden kann.
Mit der Kompatibilität zum .NET Framework ist es möglich vorhandene Software in
neue Komponenten einzubinden, sowie alte zu portieren. Vor allem mit dem
Gesichtspunkt, dass Technologien, wie ActiveX oder COM+ ja auf dem COM Modell
basieren. Für eine Migration auf das .NET Framework von COM Komponenten steht
also nichts im Weg. Ebenso wie die damit verbundene Attraktivität neue COM
Komponenten zu erstellen mit dem Wissen, dass diese auch für das .NET Framework
genutzt werden könne.
Nachteile von COM sind eindeutig sein Komplexität, sowie die schwierige Einarbeitung
in das Themengebiet. Ein erfahrenen COM Programmierer benötigt ungefähr 2 Jahre
um alle Themengebiete einmal professionell genutzt zu haben. Mit Hilfe der ATL
Technologie ist die Implementierung unter C++ wesentlich erleichtert wurden, was für
COM eine zunehmende Attraktivität darstellt.
Was die Migration von COM Komponenten nach .NET betrifft, stehe ich dieser kritisch
gegenüber, da erstens die Firmen kein Geld in Projekte stecken werden aus denen sie
nur geringfügigen nutzen ziehen. Da vor allem die Interoperabilität sich so einfach
gestaltet. Ich denke viel mehr wird man .NET Wrapper sehen, welche nur vorhandene
COM Objekte nutzen.
Seite 14
Robert Berger
27.11.2006
7 Quellen
●
GoTo COM, Peter Loos, Addison Wesley, 2001 (ISBN 3-8273-1678-2)
●
Interop:
○
Advanced COM Interoperability
(http://msdn2.microsoft.com/en-us/library/bd9cdfyx.aspx)
○
Exposing COM Components to the .NET Framework
(http://msdn2.microsoft.com/en-us/library/z6tx9dw3.aspx)
○
Exposing .NET Framework Components to COM
(http://msdn2.microsoft.com/en-us/library/zsfww439.aspx)
○
Using the .NET Framework SDK Interoperability Tools
(http://msdn2.microsoft.com/en-us/library/aa302324.aspx)
●
Microsoft ATL Reference
(http://msdn.microsoft.com/library/default.asp?url=/library/enus/vccore/html/_atl_ATL_Article_Overview.asp)
8 Literatur
In der Bibliothek vorhandene Bücher
●
Konstruktion von Verteilten Objekten, Punkt Verlag [TXG 118 125] (COM,
DCOM, CORBA, ...)
●
MFC mit Visual C++ 6.0, mitp Verlag [TXE 111 406] (COM, ATL, COM, ...)
Empfohlene Bücher zu COM
●
Internals, Brent Rector an Chris Sells
●
Inside ATL, George Shepherd and Brad King
Empfohlene Bücher zu ATL
● Inside Distributed COM, Henry and Guy Eddon
●
Essential IDL, Marin Gudgin
●
Effective COM, Don Box, Keith Brown, Tim Ewald, Chris Sells
Freie eBooks
●
Seite 15
http://www.apress.com/free/download_free.html
Robert Berger

PDF 306K

Transcription

Similar documents

Doppelbesteuerungsabkommen zwischen Deutschland und Kanada

Installation