DCOM95 1.3 Anmerkungen zu dieser Version Zuletzt geändert: 14. März 1998 DCOM95 unterstützt das DCOM-Protokoll (Distributed Component Object Model) unter Microsoft(r) Windows(r) 95. Das DCOM- Übertragungsprotokoll ermöglicht eine zuverlässige, sichere, effiziente und transparente Datenübertragung zwischen COM-Komponenten (Component Object Model) wie ActiveX(r)- Steuerelemente, Skripts und Java-Applets, die sich in einem LAN, einem WAN oder im Internet auf verschiedenen Computern befinden. Mit Hilfe von DCOM können die einzelnen Prozesse einer Anwendung an unterschiedlichen Orten verteilt sein, je nachdem, wo sie in Anbetracht ihrer jeweiligen Aufgabe am sinnvollsten eingesetzt werden. Genauere Informationen zu DCOM finden Sie in der Übersicht über DCOM unter: http://www.microsoft.com/com/. Inhalt ====== I. Neue Funktionen seit DCOM95 1.2 II. Behobene Probleme seit DCOM95 1.2 III. Bekannte Probleme IV. Unterschiede zu DCOM für Windows NT V. Weitervertrieb VI. Technischer Support und weitere Informationen VII. Dateiliste I. Neue Funktionen seit DCOM95 1.2 ---------------------------------- Unterstützung für VB6.0-Datentypen In Visual Basic(r) 6.0 können Visual Basic-Daten vom Typ Variant benutzerdefinierte Datenstrukturen enthalten. DCOM95 unterstützt dies nun auch als Remote-Daten. II. Behobene Probleme seit DCOM95 1.2 ------------------------------------- Dieser Abschnitt beschreibt in DCOM95 1.3 behobene Probleme, die sich auf Anwendungen auswirkten, die unter Windows 95 mit DCOM95 1.2 ausgeführt wurden. Dateimoniker unterstützen zusätzliche Pfadsyntax Dateimoniker können jetzt auch aus Argumenten der Form "" erstellt werden, z. B. "C:\bug\bug\..\..\foo.jpg". In DCOM95 1.1 waren nur entweder relative (z. B. "..\..\foo.jpg") oder absolute Pfade (z. B. "C:\foo.jpg") zulässig. Allgemeiner Schutzfehler beim Entladen von Oleaut32.dll Bisher trat ein allgemeiner Schutzfehler auf, wenn Oleaut32.dll vor einem Aufruf von "CoUninitialize" entladen wurde. Dies trat meistens dann auf, wenn eine VB-Anwendung ein Steuerelement erstellte, das statisch mit Oleaut32.dll verknüpft war, und das Steuerelement dann freigab, bevor "CoUninitialize" aufgerufen wurde. Dieser Vorgang löst in dieser Version von DCOM95 keinen allgemeinen Schutzfehler mehr aus. Marshallen und Rückgängigmachen von Visual Basic-Datentypen Das Marshallen und Rückgängigmachen des Marshallens bestimmter Visual Basic-Datentypen wurde verbessert. Datenfeldparameter über 64 KB sind jetzt möglich. Strukturen, die unter Verwendung von Aliasen zum Typ definiert wurden, werden jetzt korrekt gemarshallt bzw. das Marshallen wird korrekt rückgängig gemacht. Zu oft gelöschte Atome in "OleUninitialize" Dieser Fehler trat in Anwendungen auf, die "OleInitialize" und "OleUninitialize" mehrfach aufriefen. Während der Initialisierung fügt OLE viele Atome für DDE RPC hinzu. Wenn diese Atome bereits von einem anderen Thread hinzugefügt wurden, werden sie nicht noch einmal hinzugefügt. Während der Deinstallation wurden die Atome jedoch immer gelöscht, ohne dass die Zugriffsnummern gelöscht wurden. Wenn "OleInitialize" das nächste Mal aufgerufen wurde, waren die alten Zugriffsnummern noch vorhanden, obwohl die zugehörigen Atome bereits gelöscht waren; OLE fügte die Atome deshalb nicht wieder hinzu. Aus diesem Grund waren alle OLE-Atome nach mehrmaligem Aufrufen von "OleInitialize" und "OleUninitialize" ungültig. Dieses Problem wurde behoben. ADO-Server fahren ordnungsgemäß herunter Active Data Objects (ADOs) verwenden Zeigermoniker, um einen Serverprozess zu starten. DCOM95 zählte bisher die Verweise auf Moniker falsch, da Zählung bei 1 statt bei 0 begann. Der Zeigermoniker hatte deshalb immer mehr als 0 Verweise und konnte deshalb nicht freigegeben werden. Der ADO-Server konnte deshalb nicht herunterfahren, auch wenn keiner der Zeiger zum Server mehr verwendet wurde. Dieses Problem wurde behoben. "CoCreateInstance" funktioniert mit eigenem DNS-Namen Bisher konnte "CoCreateInstance" nicht mit dem gültigen Namen des lokalen Computers aufgerufen werden. Dies wurde behoben, und "CoCreateInstance" funktioniert nun ordnungsgemäß. Langsame Übertragung auf Speichersystem bei großer Verbunddatei Die Übernahmezeit auf ein im STGM_TRANSACTED-Modus geöffnetes Stammspeichersystem war bisher sehr langsam, wenn die Verbunddatei sehr groß war (z. B. 400 MB). Die Grenzen der internen Seitentabelle wurden erhöht, und das Problem wurde damit beseitigt. Exportieren von Objekten von neuerstelltem MTA Bisher konnte ein Server ein Objekt aus einem Multi-Threaded Apartment (MTA) nicht erstellen, wenn das MTA im gleichen Prozess bereits einmal erstellt worden war. Dies wurde behoben. Wenn der Server jetzt ein MTA erstellt, es löscht und später erneut erstellt, können Objekte aus dem MTA exportiert werden. Mehrere Kopien von VB4-exe-Dateien Wenn mit DCOM95 v1.1 dieselbe mit Visual Basic 4 kompilierte Datei mehrmals aufgerufen und anschließend in beliebiger (außer umgekehrter) Reihenfolge wieder geschlossen wurde, reagierte die letzte ausführbare Datei nicht mehr. Dasselbe trat bei Formularen in Microsoft Exchange auf. Das Problem wurde behoben, und VB4-Dateien können jetzt in beliebiger Reihenfolge geschlossen werden. Erweiterte Zeichen in Visual Basic-Dateinamen Visual Basic-Module oder -Klassen mit erweiterten Zeichen (einer beliebigen Sprache) im Namen konnten oft auf Computern mit anderem Gebietsschema nicht geöffnet werden. Dies wurde behoben. Speicherverlust im Heap-Speicher bei Verwendung von IDataObject/IAdviseSink Es trat ein Speicherverlust auf, wenn ein Uniform Data Transfer zwischen einem Datenobjekt auf einem lokalen Server, der die IdataObject-Schnittstelle implementiert, und einem Client, der IadviseSink implementiert, verwendet wurde. Wenn der Client das STA-Modell verwendete, trat bei jedem Anruf ein Verlust von 32 Byte auf. Dieses Problem manifestierte sich, da die Server zunehmend mehr Zeit zur Ausführung benötigten. Der Datenverlust wurde behoben. III. Bekannte Probleme ---------------------- Corel WordPerfect Suite 7: Installation verursacht ungültige Seite Wenn Sie Corel WordPerfect Suite 7 auf einem Windows 95-System mit DCOM95 installieren, wird u. U. während der Installation ein Fehler wegen einer ungültigen Seite in PfOd70.pfc angezeigt. Schließen Sie die Meldung einfach. Das Setup-Programm fährt ohne weitere Probleme fort. Microsoft Access 95: Datenbankreplikation funktioniert nicht Wenn Sie auf einem Computer mit DCOM95 versuchen, in Microsoft Access 95 eine Datenbank zu replizieren, wird u. U. die folgende Fehlermeldung angezeigt: Microsoft Access kann diesen Vorgang nicht abschließen, da es die DLL-Datei (Dynamic-Link Library) Msjtrclr nicht finden oder initialisieren kann. Dieses Problem wird von Microsoft Access 95 verursacht. Sie können das Problem umgehen, wenn Sie ein Programm schreiben, das statt des Replikationstools das Access-Objektmodell nutzt, oder indem Sie zur Replikation den Aktenkoffer verwenden. Dieses Problem tritt in Microsoft Access 97 nicht auf. WordPerfect Wenn in einem WordPerfect-Dokument eine Corel-Kalkulationstabelle einbettet ist und diese Kalkulationstabelle ein weiteres eingebettetes Objekt enthält (z. B. eine Bitmap), wird beim Schließen des innersten Objekts u. U. eine Warnung mit der Meldung angezeigt, dass die Netzwerkverbindung getrennt wurde. Diese Warnung wird vier- bis fünfmal angezeigt, ist aber ohne Bedeutung. Schließen Sie einfach die Warnungen, und fahren Sie mit Ihrer Arbeit fort. MTA-Clients, die BSTR-Konvertierungsroutinen verwenden, blockieren DDE-Meldungen Automatisierte BSTR-Konvertierungsroutinen (z. B. BstrFromR4) erstellen versteckte Fenster, um die Typkonvertierung zu erleichtern. Diese Fenster werden von der Windows-Nachrichtenwarteschlange nicht bedient. Wenn ein solches Fenster von einem MTA-Client (Multiple-Threaded Apartment) aus erstellt wird, werden die DDE-Meldungen u. U. blockiert. Der Clientthread ist laut MTA-Programmierungsmodell nicht dazu verpflichtet, die Nachrichtenwarteschlange zu bedienen. Wenn die Warteschlange aber nicht bedient wird, werden globale Broadcastmeldungen von diesem Hauptebenenfenster blockiert. Es gibt zwei Möglichkeiten, dieses Problem zu umgehen: die BSTR-Konvertierungsroutinen werden von einem STA-Client (Single-Threaded Apartment) aus aufgerufen, oder der MTA-Thread des Clients muss sich wie ein STA-Thread verhalten (ein STA-Thread bedient die Nachrichtenwarteschlange immer). Wenn die Blockierung an einer Win32-Zugriffsnummer auftritt, muss der Thread die Funktion "MsgWaitForMultipleObjects" aufrufen, so dass die Windows-Meldungen gleichzeitig verarbeitet werden. DLL-Pfadnamen über 127 Zeichen verursachen Fehler Eine DLL mit einem Pfadnamen, der 128 oder mehr Zeichen lang ist, kann zwar registriert werden, aber beim Zugriff auf ein von dieser DLL unterstütztes Objekt wird von "CoCreateInstance" und "CoGetClassObject" ein Fehler zurückgegeben (REGDB_E_CLASSNOTREG). IV. Unterschiede zu DCOM für Windows NT --------------------------------------- Sicherheit in DCOM95 Die wesentlichen Funktionen und die Schnittstelle (Application Programming Interface, API) von DCOM95 wird unter Windows 95 und unter Windows NT 4.0 identisch. Aufgrund der unterschiedlichen Sicherheitsstrukturen der Betriebssysteme sind jedoch einige Sicherheitsfunktionen anders. Es wird empfohlen, die vorgegebenen Sicherheitseinstellungen des Systems zu verwenden. Außerdem muss auf Freigaben in einem Dateisystem die Sicherheit auf Benutzerebene eingestellt werden (siehe unten). Folgende Dienste sind verfügbar. Mit ihnen können auch die vorgegebenen Sicherheitseinstellungen außer Kraft gesetzt werden: * CoInitializeSecurity * CoQueryAuthenticationService * CoQueryProxyBlanket * CoSetProxyBlanket * CoQueryClientBlanket * IClientSecurity Interface * IServerSecurity Interface Manche Funktionen von DCOM für Windows NT sind unter Windows 95 jedoch nicht verfügbar, da die Sicherheitsstruktur von Windows 95 anders aufgebaut ist. Hierbei ist besonders das Fehlen von Sicherheitsfunktionen in der Win32-API zu beachten - z. B. können keine Zugriffskontrolllisten (Access Control Lists, ACL) erstellt werden, und es gibt keine AccessCheck-Funktion - sowie das Fehlen eines Sicherheitskontexts für Threads und Prozesstoken. Unter Windows 95 ist hierfür keine native Unterstützung vorgesehen. DCOM95 unterstützt deshalb keinen Identitätswechsel (also die Hilfsfunktionen "CoImpersonateClient" und "CoRevertToSelf" über die IServerSecurity-Schnittstelle), der unter Windows NT 4.0 auf Thread- und Prozesstokensicherheit beruht. Identitätswechsel werden oft bei der automatischen Überprüfung des Zugriffs auf Ressourcen mit eingeschränkten Zugriffsrechten verwendet, z. B. auf das Dateisystem, andere Prozesse oder das Netzwerk. Unter Windows 95 kann der Zugriff auf diese Ressourcen nicht beschränkt werden. DCOM95 verfügt jedoch über verschiedene Hilfsobjekte für Zugriffskontrollfunktionen, die zur Überprüfung des Zugriffs durch Remote-Clients auf System- oder benutzerdefinierte Ressourcen und Daten verwendet werden können. Diese Hilfsobjekte werden vom Systemobjekt "CLSID_DCOMAccessControl" ausgeführt, das die IAccessControl-Schnittstelle verwendet. "IAccessControl" sollte immer zur Verwaltung der Sicherheitsrechte verwendet werden, wenn die Portierung zwischen Windows 95 und Windows NT wichtig ist. Das "CLSID_DCOMAccessControl"-Objekt ist in allen Versionen von DCOM95 sowie in Windows NT 4.0 SP2 und später verfügbar. Informationen zu "IAccessControl" finden Sie in der Platform SDK-Dokumentation. Start- und Zugriffssicherheit Die Überprüfung der Startberechtigung von Servercode wird von DCOM95 nicht unterstützt, da das Starten von Servern nicht unterstützt wird. Server und Klassen müssen bereits ausgeführt werden, damit Remote-Clients Verbindung zu ihnen aufnehmen und sie verwenden können. DCOM95 kann zu bereits ausgeführten Servern und Klassen Verbindung aufnehmen. Die Zugriffssicherheit wird über den Registrierungsschlüssel "\APPID\{.}\AccessPermissions" unterstützt und über das Tool DCOMCNFG oder während der Installation oder Konfiguration des Servercodes angepasst. Nichtauthentifizierte Benutzer können Server verwenden, wenn die Klasse für die Unterstützung nichtauthentifizierter Verbindungen konfiguriert ist (über statische Konfigurationstools oder dynamisch über die CoInitializeSecurity-Funktion). Außerdem können Zugriffskontrolllisten erstellt werden, die definieren, welche Benutzer und Gruppen auf bestimmte Dienste zugreifen können. Authentifizierungsebenen DCOM95-Clients können DCOM-Aufrufe unter Verwendung jeder beliebigen Authentifizierungsebene durchführen. DCOM95-Server oder -Clients, die einen Rückruf erhalten, können nur DCOM-Aufrufe mit der Authentifizierungsebene RPC_C_AUTHN_LEVEL_NONE oder RPC_C_AUTHN_LEVEL_CONNECT annehmen. Transportprotokolle DCOM95 unterstützt nur die Verbindung über TCP. Wenn das TCP-IP-Protokoll nicht installiert ist, kann DCOM95 das COM-Protokoll zu einem anderen Computer nicht unterstützen. Registrierungseinstellungen Von DCOM95 werden unter HKEY_LOCAL_MACHINE\Software\Microsoft\OLE folgende Registrierungsschlüssel eingerichtet: EnableDCOM (Standardwert: "Y"). Dieser Schlüssel aktiviert DCOM auf diesem Computer. Wenn dieser Wert "N" lautet, kann der Computer keine Verbindung zu Objekten auf Remote-Computern aufnehmen oder sie aktivieren; Remote-Computer können keine Verbindung zu Objekten auf dem lokalen Computer aufnehmen. Wenn dieser "Y" lautet, ist entweder die Client-Verbindung vom lokalen Computer zu remoten Objekten (wenn EnableRemoteConnect='N' ist; siehe unten) oder die volle Client/Server-Verbindung möglich (wenn EnableRemoteConnect='Y'; siehe unten). EnableRemoteConnect (Standardwert: "N"). Dieser Schlüssel macht es COM-Servern möglich, Remote-Clients zu unterstützen. Wenn dieser Wert "Y" lautet, können Verweise zu Schnittstellen lokaler Objekte zu Remote-Clients weitergegeben werden, und Remote-Clients können Verbindung zu ausgeführten Objekten aufnehmen. Wenn dieser Wert "N" lautet, kann der Computer Verbindung zu remoten Objekten aufnehmen, aber nicht als Server agieren: die Verbindung zu ausgeführten Objekten ist nicht möglich. Unter HKEY_CLASSES_ROOT\CLSID wird der folgende Registrierungsschlüssel eingerichtet: {bdc67890-4fc0-11d0-a805-00aa006d2ea4}\InstalledVersion. Dieser Schlüssel enthält die Versionsnummer von DCOM95 im Format "a,b,c,d". Anhand dieses Werts stellt Internet Component Download fest, ob DCOM95 installiert ist. Der Wert wird bei der Installation in die Registrierung eingefügt und sollte nicht geändert werden. Windows 95 als Remote-Server Windows 95 kann als Remote-Server agieren. Dabei ist allerdings folgendes zu beachten: * Starten wird nicht unterstützt. Der Serverprozess muss bereits ausgeführt werden, damit ein Client zu ihm Verbindung aufnehmen kann. * Wenn eine sichere Verbindung benötigt wird, muss auf dem Server (und für Rückrufe auch auf dem Client) die Zugriffssteuerung auf Benutzerebene eingestellt und ein Sicherheits-Dienstanbieter angegeben sein. * Der Registrierungsschlüssel "EnableRemoteConnect" muss den Wert "Y" haben. DCOM95 wurde in Verbindung mit dem Sicherheits-Dienstanbieter der Windows NT-Domäne ausführlich getestet. Wenn Sie einen anderen Sicherheits-Dienstanbieter verwenden, treten u. U. Probleme auf. Zum Einrichten der Zugriffssteuerung auf Benutzerebene muss Filesec.vxd installiert sein. Diese Datei wird bei der Installation der Datei- und Druckerfreigabe auf Windows 95-Systemen installiert. Öffnen Sie zum Aktivieren der Zugriffssteuerung auf Benutzerebene das Dialogfeld "Netzwerk" in der Systemsteuerung, klicken Sie auf die Registerkarte "Zugriffssteuerung", aktivieren Sie das Kontrollkästchen "Zugriffssteuerung auf Benutzerebene", und geben Sie den Namen der Sicherheitsdomäne ein. Unter Umständen hat dies Auswirkungen darauf, wie Sie auf im Netzwerk freigegebene Verzeichnisse zugreifen. Weitere Informationen hierzu finden Sie in der Onlinedokumentation. Wenn es im Dialogfeld "Netzwerk" keine Registerkarte "Zugriffssteuerung" gibt, müssen Sie einen Netzwerk-Clientservice installieren. Informationen zur Installation eines Netzwerkclients finden Sie in der Onlinehilfe unter dem Stichwort "Netzwerkclients, Einrichten". V. Weitervertrieb ----------------- Informationen zum Weitervertrieb von DCOM95 finden Sie in den Richtlinien zum Weitervertrieb im Endbenutzer-Lizenzvertrag (license.txt). Wenn Sie planen, DCOM95 weiter zu vertreiben, sollten Sie Ihrem Distributionsdatenträger die Dateien "DCOM95.EXE" und optional "DCM95CFG.EXE" hinzufügen. Sie sollten diese selbstextrahierenden Programmdateien über das Setup-Programm ausführen. Diese Programmdateien installieren die korrekten Dateien nur dann, wenn eine neuere Version noch nicht installiert ist. Die für DCOM95 erforderlichen korrekten Registrierungseinträge werden automatisch vorgenommen. Auf Windows NT-Systemen ist keine Installation möglich. Standardmäßig werden von DCOM95.EXE und DCM95CFG.EXE eine Lizenzvereinbarung und andere Eingabeaufforderungen für Benutzer angezeigt. DCOM95.EXE fordert den Benutzer auf, das System nach Abschluß neu zu starten. Wenn Sie eine der beiden Programmdateien über das Setup-Programm ausführen, ist es empfehlenswert, die selbstextrahierenden Dateien im Hintergrund auszuführen. Sie müssen den Benutzer dazu auffordern, das System nach Beendigung des Setups neu zu starten, wenn DCOM95 installiert wurde. Verwenden Sie zum Ausführen von DCOM95.EXE oder DCM95CFG.EXE im Hintergrund diese Befehlszeile: [Name der EXE-Datei] /r:n /q:a VI. Technische Unterstützung und weitere Informationen ------------------------------------------------------ Gebührenpflichtige Unterstützung Die Anwendungsentwicklung mit Hilfe von DCOM95 wird von Microsofts Technischem Support unterstützt. Wenn Sie einen Premier Level- oder einen Priority Level-Supportvertrag abgeschlossen haben, können Sie sich jederzeit an den Technischen Support wenden. Sie können aber auch einzelne Priority Support-Scheine erwerben (dies entspricht im wesentlichen einer einmaligen Gebühr pro Frage). Wenn Sie Fragen zu den Angeboten der gebührenpflichtigen Unterstützung haben, wenden Sie sich an Microsoft Support Sales: (001-800) 936 35 00, 6.00-18.00 Pacific Time (9 Stunden Zeitunterschied), Montag bis Freitag mit Ausnahme von US-Feiertagen. Die Informationen von Microsofts Technischem Support sind auch über das World Wide Web erhältlich: http://www.microsoft.com/germany/support/. Gebührenfreie Unterstützung Newsgroups sind eine erstklassige Quelle für kostenlose technische Unterstützung durch andere Entwickler und Interessenten. Zusätzlich besuchen die Entwickler, Programmmanager, Kundendienstmitarbeiter und Programmierer von Microsoft die offiziellen Newsgroups so oft wie möglich auf, um Feedback zu erhalten und Fragen zu beantworten oder Irrtümer aufzuklären. Wenn Sie einen Artikel in einer Newsgroup veröffentlichen, haben Sie jedoch keine Garantie darauf, dass Sie eine Antwort von Microsoft erhalten. In folgenden Newsgroups können Sie Fragen zu DCOM95 stellen: * comp.os.ms-windows.programmer.ole * microsoft.public.win32.programmer.ole Die DCOM-Verteilerliste ist eine weitere gute Quelle für kostenlose technische Unterstützung. Einer der Vorteile von Verteilerlisten besteht darin, dass Microsoft über dieses Medium zu vielen Themen Vorabnachrichten veröffentlicht. Andererseits sollte erneut betont werden, dass es sich hier nicht um den offiziellen Technischen Support von Microsoft handelt - die Mitarbeiter von Microsoft nehmen hieran zwar durchaus aktiv teil, Sie haben aber keine Garantie darauf, dass ein veröffentlichter Beitrag auch beantwortet wird. Weitere Informationen zur DCOM-Verteilerliste finden Sie auf folgender Seite: http://www.microsoft.com/sitebuilder/resource/mail.asp. Feedback Senden Sie bitte Kommentare und Fehlerberichte an die DCOM-Verteilerliste. Weitere Informationen Zusätzliche Informationen zu DCOM finden Sie auf der COM-Homepage: http://www.microsoft.com/com/. VII. Dateiliste --------------- In der folgenden Tabelle werden die Versionsnummern der mit DCOM95 ausgelieferten Dateien aufgeführt. asycfilt.dll 2.40.4275.1 comcat.dll 5.0.1601.1 compobj.dll 2.30.200.1 dcom2w98.dll 2.10.35.35 dllhost.exe 4.71.3328.0 iprop.dll 4.0.1381.6 ole2.dll 2.30.200.0 ole32.dll 4.71.3328.0 oleaut32.dll 2.40.4275.1 olecnv32.dll 4.71.3328.0 olepro32.dll 5.0.4275.1 olethk32.dll 4.71.3328.0 rpcltc1.dll 4.71.3328.0 rpcltc5.dll 4.71.3328.0 rpcltccm.dll 4.71.3328.0 rpclts5.dll 4.71.3328.0 rpcltscm.dll 4.71.3328.0 rpcmqcl.dll 4.71.3328.0 rpcmqsvr.dll 4.71.3328.0 rpcns4.dll 4.71.3328.0 rpcrt4.dll 4.71.3328.0 rpcss.exe 4.71.3328.0 secur32.dll 4.10.0.2177 stdole2.tlb 2.40.4275.1 stdole32.tlb 2.10.3027.1 storage.dll 2.30.200.0 In der folgenden Tabelle werden die Versionsnummern der mit DCM95CFG ausgelieferten Dateien aufgeführt. dcomcnfg.exe 5.00.1603.1 ciscnfg.exe 4.71.2618.0