home *** CD-ROM | disk | FTP | other *** search
/ com!online 2001 November / COMCD1101.iso / browser / ms / ie55sp2ger / dcom95.exe / relnotes.txt < prev    next >
Encoding:
Text File  |  1999-02-12  |  31.3 KB  |  732 lines
  1. DCOM95 1.3
  2. Anmerkungen zu dieser Version
  3. Zuletzt ge?dert: 14. September 1998
  4.  
  5. DCOM95 unterst?zt das DCOM-Protokoll (Distributed Component Object
  6. Model) unter Microsoft(r) Windows(r) 95. Das DCOM-?ertragungsprotokoll 
  7. erm?licht eine zuverl?sige, sichere, effiziente und transparente 
  8. Daten?ertragung zwischen COM-Komponenten (Component Object Model) wie 
  9. ActiveX(r)-Steuerelemente, Skripts und Java-Applets, die sich in einem 
  10. LAN, einem WAN oder im Internet auf verschiedenen Computern befinden. 
  11. Mit Hilfe von DCOM k?nen die einzelnen Prozesse einer Anwendung an 
  12. unterschiedlichen Orten verteilt sein, je nachdem, wo sie in Anbetracht 
  13. ihrer jeweiligen Aufgabe am sinnvollsten eingesetzt werden.
  14.  
  15. Genauere Informationen zu DCOM finden Sie in der ?ersicht ?er DCOM unter:
  16. http://www.microsoft.com/com/.
  17.  
  18. Inhalt
  19. ======
  20. I.   Neue Funktionen
  21. II.  Behobene Probleme
  22. III. Bekannte Probleme
  23. IV.  Unterschiede zu DCOM f? Windows NT
  24. V.   Weitervertrieb
  25. VI.  Technischer Support und weitere Informationen
  26. VII. Dateiliste
  27.  
  28. I. Neue Funktionen
  29. ------------------
  30.  
  31. Ersetzen von DCOM95 durch ?tere Version nicht mehr zul?sig
  32.  
  33. Bisher konnte eine neuere Version von DCOM95 durch eine ?tere
  34. Version ersetzt werden. Ab der vorliegenden Version werden bei der
  35. Installation jedoch die Versionsnummern ?erpr?t. Eine ?tere Version
  36. kann damit nicht mehr ?er eine neuere Version installiert werden.
  37. Dadurch werden Probleme mit nicht miteinander kompatiblen DLL-Versionen
  38. vermieden.
  39.  
  40. ?erwachung von Visual Studio 6.0-Prozessen
  41.  
  42. Zur Unterst?zung von Visual Studio 6.0 stellt DCOM95
  43. ?erwachungsinformationen zur Verf?ung, so dass die Entwickler das
  44. Verhalten, die Leistung und die Struktur ihrer Anwendung besser
  45. verstehen k?nen. Wenn Sie Visual Studio Analyzer unter Windows 95
  46. verwenden, sollten Sie immer die vorliegende Version von DCOM95
  47. verwenden.
  48.  
  49. Setup-Programm erstellt neues Verzeichnis
  50.  
  51. Das Setup-Programm erstellt im Systemverzeichnis ein Unterverzeichnis
  52. mit der Bezeichnung DCOM95. Dort werden der Endbenutzer-Lizenzvertrag
  53. und weitere Dateien gespeichert. Au?rdem wird als Unterverzeichnis
  54. von DCOM95 das Verzeichnis OLDOLE erstellt, in dem eine Sicherungskopie
  55. des alten DCOM95-Programms bzw. der OLE-Bin?dateien erstellt wird.
  56.  
  57. COM Internet Services (CIS)
  58.  
  59. Mit Hilfe von COM Internet Services (CIS) k?nen Clients und Server
  60. ?er COM eine Internetverbindung aufnehmen. CIS besteht aus mehreren
  61. Komponenten:
  62. *    Einem neuen DCOM-Protokoll: Tunneled TCP
  63. *    Einem neuen Monikertyp: OBJREF-Moniker
  64. *    Einem neuen Dienstprogramm: CISCNFG
  65.  
  66. F? die CIS-Unterst?zung f? Clients unter Windows 95 m?sen Sie
  67. sowohl DCOM95 als auch DCOMCFG installieren. ─ndern Sie dann den
  68. Registrierungsschl?sel, der das Protokoll f? Remote-Prozesse angibt,
  69. mit Hilfe des CISCNFG-Tools (dieses Tool wird bei der Installation
  70. der DCOM-Konfiguration installiert). Geben Sie in der Eingabeaufforderung
  71. folgendes ein:
  72.     ciscnfg <Protokoll>
  73.  
  74. Dabei steht "<Protokoll>" f?:
  75. *    rpc - RPC wird verwendet
  76. *    http - HTTP verwendet
  77. *    tcp_http - der Client versucht zuerst, die Verbindung ?er TCP
  78.     herzustellen. Nach einem Timeout des Servers wird HTTP verwendet.
  79.  
  80. Wenn Sie den Befehl "ciscnfg" ohne Argument eingeben, werden Hinweise
  81. zum Gebrauch des Befehls angezeigt.
  82.  
  83. F? das Tunneled TCP-Protokoll werden keine SDK-Updates ben?igt.
  84.  
  85. F? OBJREF-Moniker gibt es Updates.
  86.  
  87. CreateObjrefMoniker
  88.  
  89. Hierdurch wird ein OBJREF-Moniker basierend auf einem Zeiger zu einem
  90. Objekt erstellt.
  91. WINOLEAPI CreateObjrefMoniker(
  92.     LPUNKNOWN pUnk, //Zeiger zum Objekt
  93.     LPMONIKER *ppMk //Adresse des Zeigers zum OBJREF-Moniker
  94. );
  95.  
  96. Parameter
  97.  
  98. pUnk
  99.  
  100. Zeiger zur IUnknown-Schnittstelle des Objekts, das der Moniker
  101. darstellen soll.
  102.  
  103. ppMk
  104.  
  105. Adresse eines Zeigers zur IMoniker-Schnittstelle des gerade
  106. erstellten OBJREF-Monikers.
  107.  
  108. R?kgabewerte
  109.  
  110. Diese Funktion unterst?zt die standardmΣ▀igen R?kgabewerte
  111. E_OUTOFMEMORY und E_UNEXPECTED sowie folgenden R?kgabewert:
  112.  
  113. S_OK
  114.  
  115. Die Erstellung des OBJREF-Monikers war erfolgreich.
  116.  
  117. Hinweise
  118.  
  119. Clients verwenden OBJREF-Moniker, um einen gemarshallten Zeiger auf
  120. ein ausgef?rtes Objekt im Adressraum des Servers abzurufen.
  121. Der Server erstellt meistens erst mit "CreateObjrefMoniker" einen
  122. OBJREF-Moniker, ruft "IMoniker::GetDisplayName" auf und gibt dann den
  123. Moniker frei. Der Anzeigename f? einen OBJREF-Moniker hat folgende Form:
  124.     OBJREF:nnnnnnnn
  125.  
  126. Dabei steht "nnnnnnnn" f? einen beliebig langen base-64-Code, der
  127. den Standort des Computers, den Prozess-Endpunkt und die
  128. Schnittstellenzeiger-ID (Interface Pointer ID, IPID) des ausgef?rten
  129. Objekts verkapselt.
  130.  
  131. Der Anzeigename kann anschlie?nd als Text an den Client ?ertragen
  132. werden. Hierzu wird er z. B. oft in eine HTML-Seite eingef?t, die
  133. vom Client heruntergeladen wird.
  134.  
  135. Der Client kann den Anzeigenamen an "MkParseDisplayName" weitergeben.
  136. Diese Funktion erstellt auf Basis des Anzeigenamens einen OBJREF-Moniker.
  137. Durch einen Aufruf der IMoniker::BindToObject-Methode des Monikers
  138. wird ein gemarshallter Zeiger zur ausgef?rten Version auf dem Server
  139. abgerufen. Beispielsweise kann eine serverbasierte COM-Komponente auf
  140. einer Active Server Page einen OBJREF-Moniker erstellen, seinen
  141. Anzeigenamen abrufen und diesen in die HTML-Ausgabe schreiben, die
  142. an den Client-Browser gesendet wird. ?er den Anzeigenamen kann ein
  143. clientbasiertes Skript dann auf das ausgef?rte Objekt zugreifen. Ein
  144. clientbasiertes Visual Basic-Skript k?nte den Anzeigenamen in der
  145. Variablen "strMeinName" speichern und die folgende Zeile einbinden:
  146.     objMeineVersion = GetObject(strMeinName)
  147.  
  148. Das Skriptmodul ruft intern "MkParseDisplayName" und "IMoniker::BindToObject"
  149. auf. Das Skript kann dadurch ?er "objMeineVersion" direkt auf das ausgef?rte
  150. Objekt zugreifen.
  151.  
  152. Wenn das ausgef?rte Objekt statische Schnittstellenzeiger-IDs verwendet
  153. und der Serverprozess immer auf demselben Computer an einem bekannten
  154. Endpunkt ausgef?rt wird, lautet der Anzeigename des OBJREF-Monikers
  155. immer gleich. Der Server kann den Anzeigenamen in diesem Fall speichern,
  156. statt ihn bei jeder Anforderung nach dem Objekt neu zu berechnen.
  157.  
  158. IMoniker - Implementierung des OBJREF-Monikers
  159.  
  160. OBJREF-Moniker sind Verweise auf Objekte, die auf einem lokalen oder
  161. remoten Server ausgef?rt werden, der nicht in den Prozess eingebunden
  162. ist (prozessextern). Der Moniker bezeichnet das korrekte Objekt und
  163. den Computer, auf dem das Objekt ausgef?rt wird.
  164.  
  165. Ein OBJREF-Moniker ist in vielem einem Zeigermoniker ?nlich, mit der
  166. Ausnahme, dass das ausgef?rte Objekt prozessextern ist. Bei einem
  167. OBJREF-Moniker kann jeder Client "IMoniker::BindToObject" aufrufen
  168. und mit dem dadurch erhaltenen Zeiger das ausgef?rte Objekt aufrufen,
  169. unabh?gig davon, wo sich dieses Objekt befindet.
  170.  
  171. Ein weiterer wichtiger Unterschied besteht darin, dass der Anzeigename
  172. eines OBJREF-Monikers in eine HTML-Seite eingebettet werden und das
  173. vom Moniker dargestellte ausgef?rte Objekt in ein Clientskript,
  174. Applet oder ActiveX-Steuerelement eingebunden werden kann.
  175.  
  176. Anwendungsm?lichkeiten
  177.  
  178. Ein OBJREF-Moniker wird im wesentlichen dazu verwendet, per Internet
  179. Zugriff auf ein ausgef?rtes Objekt auf einem anderen Computer zu
  180. erhalten. Eine Active Server Page oder eine andere Anwendung zum
  181. Erstellen von dynamischen HTML-Seiten f?t den Anzeigenamen eines
  182. OBJREF-Monikers in einen Parameter eines Applets oder eines
  183. ActiveX-Steuerelements ein. Dieses Applet oder Steuerelement ruft
  184. "CreateObjrefMoniker" auf, um auf Basis des Anzeigenamens einen
  185. OBJREF-Moniker zu erstellen. Mit "IMoniker::BindToObject" kann das
  186. Applet oder Steuerelement anschlie?nd auf das ausgef?rte Objekt
  187. zugreifen. Zuletzt wird dem Client der Active Server Page ein Zeiger
  188. zum ausgef?rten Objekt gemarshallt.
  189.  
  190. Hinweise
  191.  
  192. IMoniker::BindToObject. Bei OBJREF-Monikern muss der Parameter
  193. "pmkToLeft" NULL sein. Da der OBJREF-Moniker ein ausgef?rtes Objekt
  194. darstellt, gibt es keine Aktivierung. Wenn das dargestellte Objekt
  195. nicht mehr ausgef?rt wird, schl?t "BindToObject" fehl; R?kgabewert:
  196. E_UNEXPECTED.
  197.  
  198. IMoniker::BindToStorage. Diese Methode ruft einen gemarshallten Zeiger
  199. zur angeforderten Schnittstelle auf dem Speichermedium ab, auf dem
  200. sich das ausgef?rte Objekt befindet. Da der OBJREF-Moniker ein
  201. ausgef?rtes Objekt darstellt, gibt es keine Aktivierung. Wenn das
  202. dargestellte Objekt nicht mehr ausgef?rt wird, schl?t "BindToStorage"
  203. fehl; R?kgabewert: E_UNEXPECTED.
  204.  
  205. IMoniker::Reduce. Von dieser Methode wird MK_S_REDUCED_TO_SELF
  206. zur?kgegeben und derselbe Moniker zur?kgeleitet.
  207.  
  208. IMoniker::ComposeWith. Wenn "pmkRight" ein Anti-Moniker ist, ist der
  209. zur?kgegebene Moniker NULL. Wenn "pmkRight" aus mehreren Komponenten 
  210. zusammengesetzt ist und die am weitesten links stehende Komponente ein 
  211. Anti-Moniker ist, besteht der zur?kgegebene Moniker aus derselben 
  212. Zusammensetzung wie "pmkRight" mit Ausnahme des Anti-Monikers ganz links; 
  213. dieser wird entfernt. Wenn f? "pmkRight" beide Bedingungen nicht 
  214. zutreffen, wird von der IMoniker::ComposeWith-Methoder der Parameter 
  215. "fOnlyIfNotGeneric" ?erpr?t. Wenn dieser Parameter FALSE ist, werden 
  216. die beiden Moniker zusammengesetzt; wenn er TRUE ist, wird "*ppmkComposite" 
  217. auf NULL gesetzt und MK_E_NEEDGENERIC zur?kgegeben.
  218.  
  219. IMoniker::Enum. Von dieser Methode wird S_OK zur?kgegeben und
  220. "ppenumMoniker" auf NULL gesetzt.
  221.  
  222. IMoniker::IsEqual. Diese Methode gibt S_OK zur?k, falls "*pmkOther"
  223. ein OBJREF-Moniker ist und die Pfade zu den beiden Monikern
  224. ?ereinstimmen (ohne Beachtung der Gro? und Kleinschreibung).
  225. Andernfalls wird S_FALSE zur?kgegeben.
  226.  
  227. IMoniker::Hash. Diese Methode berechnet einen Hashwert f? den
  228. Moniker.
  229.  
  230. IMoniker::IsRunning. Da OBJREF-Moniker ein ausgef?rtes Objekt
  231. darstellen, gibt diese Methode fast immer TRUE zur?k. FALSE wird nur
  232. zur?kgegeben, wenn der letzte Aufruf fehlschlug und es daher bekannt
  233. ist, dass das Objekt nicht mehr ausgef?rt wird. "pmkToLeft" wird von
  234. dieser Methode nicht beachtet.
  235.  
  236. IMoniker::GetTimeOfLastChange. Diese Methode gibt E_NOTIMPL zur?k.
  237.  
  238. IMoniker::Inverse. Diese Methode gibt einen Anti-Moniker zur?k
  239. (d.h. das Ergebnis des Aufrufs "CreateAntiMoniker").
  240.  
  241. IMoniker::CommonPrefixWith. Wenn die beiden Moniker identisch sind,
  242. wird von dieser Methode MK_S_US zur?kgegeben und "*ppmkPrefix" auf
  243. NULL gesetzt. Wenn der andere Moniker kein OBJREF-Moniker ist, werden
  244. beide Moniker an die MonikerCommonPrefixWith-Funktion weitergeleitet.
  245. Diese Funktion verarbeitet die Moniker korrekt, wenn einer der beiden
  246. aus mehreren Komponenten zusammengesetzt ist.
  247.  
  248. Wenn die beiden Moniker kein identisches Pr?ix haben, wird MK_E_ 
  249. zur?kgegeben.
  250.  
  251. IMoniker::RelativePathTo. Diese Methode gibt E_NOTIMPL zur?k.
  252.  
  253. IMoniker::GetDisplayName. Diese Methode ruft den Anzeigenamen 
  254. des OBJREF-Monikers ab. Der Anzeigename ist ein 64-bit-Code, 
  255. der den Standort des Computers, den Prozess-Endpunkt und die 
  256. Schnittstellenzeiger-ID (Interface Pointer ID, IPID) des ausgef?rten 
  257. Objekts verkapselt. Aus (k?ftigen) Kompatibilit?sgr?den werden im 
  258. Anzeigenamen nur Zeichen verwendet, die als Teil eines URL angegeben 
  259. werden k?nen.
  260.  
  261. IMoniker::ParseDisplayName. Wenn "pmkToLeft" nicht NULL ist, gibt
  262. diese Methode MK_E_SYNTAX zur?k.
  263.  
  264. IMoniker::IsSystemMoniker. Von dieser Methode wird S_OK zur?kgegeben
  265. und MKSYS_OBJREFMONIKER zur?kgeleitet.
  266.  
  267. Unterst?zung f? VB6.0-Datentypen
  268.  
  269. In Visual Basic(r) 6.0 k?nen Visual Basic-Daten vom Typ Variant
  270. benutzerdefinierte Datenstrukturen enthalten. DCOM95 unterst?zt dies
  271. nun auch als Remote-Daten.
  272.  
  273. II. Behobene Probleme
  274. ---------------------
  275.  
  276. Engpass beim Entladen mehrerer Module
  277.  
  278. Beim gleichzeitigen Entladen mehrerer Module trat in fr?eren Versionen
  279. von DCOM95 ein Engpass auf. Abh?gig von der Reihenfolge, in der die
  280. Module entladen wurden, trat u. U. eine Zugriffsverletzung auf. Dies
  281. wurde in der vorliegenden Version von DCOM95 behoben.
  282.  
  283. Keine Reaktion w?rend der Verhandlung des RPC-Protokolls
  284.  
  285. Fr?ere Versionen von DCOM95 verarbeiteten keine Meldungen, w?rend
  286. die RPC-Protokolle ausgehandelt wurden. Wenn der Benutzer w?rend des
  287. Aushandelns eine andere Anwendung aufrief, schien der Computer keine
  288. Reaktion zu zeigen. Nach 30 Sekunden wurden die Meldungen wieder
  289. verarbeitet. Dieses Verhalten wurde in der neuesten Version von DCOM95
  290. ge?dert. Jetzt k?nen Anwendungen auch aufgerufen werden, w?rend die
  291. RPC-Protokolle ausgehandelt werden.
  292.  
  293. Keine Reaktion, wenn neue Anwendung aufgerufen wird
  294.  
  295. RPC erstellt im Multiple-Threaded Apartment (MTA) ein verstecktes
  296. Fenster, das DCOM zum Verarbeiten von Meldungen nicht ben?igt.
  297. Wenn der Benutzer vom Desktop aus eine neue Anwendung aufruft, sendet
  298. Windows eine Meldung an alle anderen Fensterzugriffsnummern, in der
  299. sie von dem neuen Ereignis benachrichtet werden. Windows erwartet eine
  300. Antwort auf diese Meldung. Bei den fr?eren Versionen von DCOM95
  301. antwortete das versteckte RPC-Fenster oft nicht, und Windows reagierte
  302. nicht mehr. Dies wurde in der vorliegenden Version von DCOM95 ge?dert.
  303.  
  304. Heapbesch?igung bei mehreren IP-Adressen
  305.  
  306. Wenn DCOM95 bisher auf einem Computer mit mehreren IP-Adressen
  307. ausgef?rt wurde, lief der IP-Adressenpuffer u. U. ?er, und der Heap
  308. wurde besch?igt. Dieses Problem wurde behoben.
  309.  
  310. Nur erste IP-Adresse verwendet
  311.  
  312. Wenn DCOM95 bisher auf einem Computer mit zwei Netzwerkkarten (und
  313. deshalb zwei IP-Adressen, eine pro Karte) ausgef?rt wurde, erkannte
  314. DCOM95 nur eine Netzwerkkarte. In der vorliegenden Version wird die 
  315. zweite Karte verwendet, falls die erste nicht funktioniert.
  316.  
  317. RPC verwendet jetzt auch mehrere IP-Adressen
  318.  
  319. Bei einem Aufruf einer Remote-Prozedur auf einem Computer mit mehreren
  320. IP-Adressen wird jetzt auch versucht, die Verbindung ?er die weiteren
  321. IP-Adressen aufzunehmen, falls die erste IP-Adresse nicht angenommen
  322. wurde.
  323.  
  324. Dateimoniker unterst?zen zus?zliche Pfadsyntax
  325.  
  326. Dateimoniker k?nen jetzt auch aus Argumenten der Form
  327. "<startverz><relativerpfad>" erstellt werden, z. B.
  328. "C:\bug\bug\..\..\foo.jpg". In DCOM95 1.1 waren nur entweder 
  329. relative (z. B. "..\..\foo.jpg") oder absolute Pfade 
  330. (z. B. "C:\foo.jpg") zul?sig.
  331.  
  332. Allgemeiner Schutzfehler beim Entladen von Oleaut32.dll
  333.  
  334. Bisher trat ein allgemeiner Schutzfehler auf, wenn Oleaut32.dll vor
  335. einem Aufruf von "CoUninitialize" entladen wurde. Dies trat meistens
  336. dann auf, wenn eine VB-Anwendung ein Steuerelement erstellte, das
  337. statisch mit Oleaut32.dll verkn?ft war, und das Steuerelement dann
  338. freigab, bevor "CoUninitialize" aufgerufen wurde. Dieser Vorgang l?t
  339. in dieser Version von DCOM95 keinen allgemeinen Schutzfehler mehr aus.
  340.  
  341. Marshallen und R?kg?gigmachen von Visual Basic-Datentypen
  342.  
  343. Das Marshallen und R?kg?gigmachen des Marshallens bestimmter Visual
  344. Basic-Datentypen wurde verbessert. Datenfeldparameter ?er 64 KB sind
  345. jetzt m?lich. Strukturen, die unter Verwendung von Aliasen zum Typ
  346. definiert wurden, werden jetzt korrekt gemarshallt bzw. das Marshallen
  347. wird korrekt r?kg?gig gemacht.
  348.  
  349. Zu oft gel?chte Atome in "OleUninitialize"
  350.  
  351. Dieser Fehler trat in Anwendungen auf, die "OleInitialize" und
  352. "OleUninitialize" mehrfach aufriefen. W?rend der Initialisierung
  353. f?t OLE viele Atome f? DDE RPC hinzu. Wenn diese Atome bereits von
  354. einem anderen Thread hinzugef?t wurden, werden sie nicht noch einmal
  355. hinzugef?t. W?rend der Deinstallation wurden die Atome jedoch immer
  356. gel?cht, ohne dass die Zugriffsnummern gel?cht wurden. Wenn
  357. "OleInitialize" das n?hste Mal aufgerufen wurde, waren die alten
  358. Zugriffsnummern noch vorhanden, obwohl die zugeh?igen Atome bereits
  359. gel?cht waren; OLE f?te die Atome deshalb nicht wieder hinzu. Aus
  360. diesem Grund waren alle OLE-Atome nach mehrmaligem Aufrufen von
  361. "OleInitialize" und "OleUninitialize" ung?tig. Dieses Problem wurde
  362. behoben.
  363.  
  364. ADO-Server fahren ordnungsgemΣ▀ herunter
  365.  
  366. Active Data Objects (ADOs) verwenden Zeigermoniker, um einen
  367. Serverprozess zu starten. DCOM95 z?lte bisher die Verweise auf
  368. Moniker falsch, da Z?lung bei 1 statt bei 0 begann. Der Zeigermoniker
  369. hatte deshalb immer mehr als 0 Verweise und konnte deshalb nicht
  370. freigegeben werden. Der ADO-Server konnte deshalb nicht herunterfahren,
  371. auch wenn keiner der Zeiger zum Server mehr verwendet wurde. Dieses
  372. Problem wurde behoben.
  373.  
  374. "CoCreateInstance" funktioniert mit eigenem DNS-Namen
  375.  
  376. Bisher konnte "CoCreateInstance" nicht mit dem g?tigen Namen des
  377. lokalen Computers aufgerufen werden. Dies wurde behoben, und
  378. "CoCreateInstance" funktioniert nun ordnungsgemΣ▀.
  379.  
  380. Langsame ?ertragung auf Speichersystem bei gro?r Verbunddatei
  381.  
  382. Die ?ernahmezeit auf ein im STGM_TRANSACTED-Modus ge?fnetes
  383. Stammspeichersystem war bisher sehr langsam, wenn die Verbunddatei
  384. sehr gro?war (z. B. 400 MB). Die Grenzen der internen Seitentabelle
  385. wurden erh?t, und das Problem wurde damit beseitigt.
  386.  
  387. Exportieren von Objekten von neuerstelltem MTA
  388.  
  389. Bisher konnte ein Server ein Objekt aus einem Multi-Threaded
  390. Apartment (MTA) nicht erstellen, wenn das MTA im gleichen Prozess
  391. bereits einmal erstellt worden war. Dies wurde behoben. Wenn der
  392. Server jetzt ein MTA erstellt, es l?cht und sp?er erneut erstellt,
  393. k?nen Objekte aus dem MTA exportiert werden.
  394.  
  395. Mehrere Kopien von VB4-exe-Dateien
  396.  
  397. Wenn mit DCOM95 v1.1 dieselbe mit Visual Basic 4 kompilierte Datei
  398. mehrmals aufgerufen und anschlie?nd in beliebiger (au?r umgekehrter)
  399. Reihenfolge wieder geschlossen wurde, reagierte die letzte ausf?rbare
  400. Datei nicht mehr. Dasselbe trat bei Formularen in Microsoft Exchange
  401. auf. Das Problem wurde behoben, und VB4-Dateien k?nen jetzt in
  402. beliebiger Reihenfolge geschlossen werden.
  403.  
  404. Erweiterte Zeichen in Visual Basic-Dateinamen
  405.  
  406. Visual Basic-Module oder -Klassen mit erweiterten Zeichen (einer
  407. beliebigen Sprache) im Namen konnten oft auf Computern mit anderem
  408. Gebietsschema nicht ge?fnet werden. Dies wurde behoben.
  409.  
  410. III. Bekannte Probleme
  411. ----------------------
  412.  
  413. Corel WordPerfect Suite 7: Installation verursacht ung?tige Seite
  414.  
  415. Wenn Sie Corel WordPerfect Suite 7 auf einem Windows 95-System mit
  416. DCOM95 installieren, wird u. U. w?rend der Installation ein Fehler
  417. wegen einer ung?tigen Seite in PfOd70.pfc angezeigt. Schlie?n Sie
  418. die Meldung einfach. Das Setup-Programm f?rt ohne weitere Probleme
  419. fort.
  420.  
  421. Microsoft Access 95: Datenbankreplikation funktioniert nicht
  422.  
  423. Wenn Sie auf einem Computer mit DCOM95 versuchen, in Microsoft
  424. Access 95 eine Datenbank zu replizieren, wird u. U. die folgende
  425. Fehlermeldung angezeigt:
  426.  
  427. Microsoft Access kann diesen Vorgang nicht abschlie?n, da es die
  428. DLL-Datei (Dynamic-Link Library) Msjtrclr nicht finden oder
  429. initialisieren kann.
  430.  
  431. Dieses Problem wird von Microsoft Access 95 verursacht. Sie k?nen
  432. das Problem umgehen, wenn Sie ein Programm schreiben, das statt des
  433. Replikationstools das Access-Objektmodell nutzt, oder indem Sie zur
  434. Replikation den Aktenkoffer verwenden.
  435. Dieses Problem tritt in Microsoft Access 97 nicht auf.
  436.  
  437. WordPerfect
  438.  
  439. Wenn in einem WordPerfect-Dokument eine Corel-Kalkulationstabelle
  440. einbettet ist und diese Kalkulationstabelle ein weiteres eingebettetes
  441. Objekt enth?t (z. B. eine Bitmap), wird beim Schlie?n des innersten
  442. Objekts u. U. eine Warnung mit der Meldung angezeigt, dass die
  443. Netzwerkverbindung getrennt wurde. Diese Warnung wird vier- bis
  444. f?fmal angezeigt, ist aber ohne Bedeutung. Schlie?n Sie einfach
  445. die Warnungen, und fahren Sie mit Ihrer Arbeit fort.
  446.  
  447. MTA-Clients, die BSTR-Konvertierungsroutinen verwenden, blockieren
  448. DDE-Meldungen
  449.  
  450. Automatisierte BSTR-Konvertierungsroutinen (z. B. BstrFromR4) erstellen
  451. versteckte Fenster, um die Typkonvertierung zu erleichtern. Diese Fenster
  452. werden von der Windows-Nachrichtenwarteschlange nicht bedient. Wenn ein
  453. solches Fenster von einem MTA-Client (Multiple-Threaded Apartment) aus
  454. erstellt wird, werden die DDE-Meldungen u. U. blockiert. Der Clientthread
  455. ist laut MTA-Programmierungsmodell nicht dazu verpflichtet, die
  456. Nachrichtenwarteschlange zu bedienen. Wenn die Warteschlange aber nicht
  457. bedient wird, werden globale Broadcastmeldungen von diesem Hauptebenenfenster
  458. blockiert.
  459.  
  460. Es gibt zwei M?lichkeiten, dieses Problem zu umgehen:
  461. die BSTR-Konvertierungsroutinen werden von einem STA-Client
  462. (Single-Threaded Apartment) aus aufgerufen, oder der MTA-Thread des
  463. Clients muss sich wie ein STA-Thread verhalten (ein STA-Thread bedient
  464. die Nachrichtenwarteschlange immmer). Wenn die Blockierung an einer
  465. Win32-Zugriffsnummer auftritt, muss der Thread die Funktion
  466. "MsgWaitForMultipleObjects" aufrufen, so dass die Windows-Meldungen
  467. gleichzeitig verarbeitet werden.
  468.  
  469. DLL-Pfadnamen ?er 127 Zeichen verursachen Fehler
  470.  
  471. Eine DLL mit einem Pfadnamen, der 128 oder mehr Zeichen lang ist,
  472. kann zwar registriert werden, aber beim Zugriff auf ein von dieser
  473. DLL unterst?ztes Objekt wird von "CoCreateInstance" und
  474. "CoGetClassObject" ein Fehler zur?kgegeben (REGDB_E_CLASSNOTREG).
  475.  
  476. IV. Unterschiede zu DCOM f? Windows NT
  477. ---------------------------------------
  478.  
  479. Sicherheit in DCOM95
  480.  
  481. Die wesentlichen Funktionen und die Schnittstelle (Application
  482. Programming Interface, API) von DCOM95 wird unter Windows 95 und
  483. unter Windows NT 4.0/5.0 identisch. Aufgrund der unterschiedlichen
  484. Sicherheitsstrukturen der Betriebssysteme sind jedoch einige
  485. Sicherheitsfunktionen anders. Es wird empfohlen, die vorgegebenen
  486. Sicherheitseinstellungen des Systems zu verwenden. Au?rdem muss
  487. auf Freigaben in einem Dateisystem die Sicherheit auf Benutzerebene
  488. eingestellt werden (siehe unten).
  489.  
  490. Folgende Dienste sind verf?bar. Mit ihnen k?nen auch die vorgegebenen 
  491. Sicherheitseinstellungen au?r Kraft gesetzt werden:
  492. *    CoInitializeSecurity
  493. *    CoQueryAuthenticationService
  494. *    CoQueryProxyBlanket
  495. *    CoSetProxyBlanket
  496. *    CoQueryClientBlanket
  497. *    IClientSecurity Interface
  498. *    IServerSecurity Interface
  499.  
  500. Manche Funktionen von DCOM f? Windows NT sind unter Windows 95 
  501. jedoch nicht verf?bar, da die Sicherheitsstruktur von Windows 95 
  502. anders aufgebaut ist.
  503.  
  504. Hierbei ist besonders das Fehlen von Sicherheitsfunktionen in der
  505. Win32-API zu beachten - z. B. k?nen keine Zugriffskontrolllisten
  506. (Access Control Lists, ACL) erstellt werden, und es gibt keine
  507. AccessCheck-Funktion - sowie das Fehlen eines Sicherheitskontexts
  508. f? Threads und Prozesstoken. Unter Windows 95 ist hierf? keine
  509. native Unterst?zung vorgesehen. DCOM95 unterst?zt deshalb keinen
  510. Identit?swechsel (also die Hilfsfunktionen "CoImpersonateClient"
  511. und "CoRevertToSelf" ?er die IServerSecurity-Schnittstelle), der
  512. unter Windows NT 4.0 auf Thread- und Prozesstokensicherheit beruht.
  513. Identit?swechsel werden oft bei der automatischen ?erpr?ung des
  514. Zugriffs auf Ressourcen mit eingeschr?kten Zugriffsrechten verwendet,
  515. z. B. auf das Dateisystem, andere Prozesse oder das Netzwerk. Unter
  516. Windows 95 kann der Zugriff auf diese Ressourcen nicht beschr?kt werden.
  517.  
  518. DCOM95 verf?t jedoch ?er verschiedene Hilfsobjekte f?
  519. Zugriffskontrollfunktionen, die zur ?erpr?ung des Zugriffs durch
  520. Remote-Clients auf System- oder benutzerdefinierte Ressourcen und
  521. Daten verwendet werden k?nen. Diese Hilfsobjekte werden vom
  522. Systemobjekt "CLSID_DCOMAccessControl" ausgef?rt, das die
  523. IAccessControl-Schnittstelle verwendet.
  524.  
  525. "IAccessControl" sollte immer zur Verwaltung der Sicherheitsrechte
  526. verwendet werden, wenn die Portierung zwischen Windows 95/98 und
  527. Windows NT wichtig ist. Das "CLSID_DCOMAccessControl"-Objekt ist in
  528. allen Versionen von DCOM95 sowie in Windows NT 4.0 SP2 und sp?er
  529. verf?bar. Informationen zu "IAccessControl" finden Sie in der Platform
  530. SDK-Dokumentation.
  531.  
  532. Start- und Zugriffssicherheit
  533.  
  534. Die ?erpr?ung der Startberechtigung von Servercode wird von DCOM95
  535. nicht unterst?zt, da das Starten von Servern nicht unterst?zt wird.
  536. Server und Klassen m?sen bereits ausgef?rt werden, damit
  537. Remote-Clients Verbindung zu ihnen aufnehmen und sie verwenden k?nen.
  538.  
  539. DCOM95 kann zu bereits ausgef?rten Servern und Klassen Verbindung
  540. aufnehmen. Die Zugriffssicherheit wird ?er den Registrierungsschl?sel
  541. "\APPID\{.}\AccessPermissions" unterst?zt und ?er das Tool DCOMCNFG
  542. oder w?rend der Installation oder Konfiguration des Servercodes
  543. angepasst. Nichtauthentifizierte Benutzer k?nen Server verwenden,
  544. wenn die Klasse f? die Unterst?zung nichtauthentifizierter
  545. Verbindungen konfiguriert ist (?er statische Konfigurationstools
  546. oder dynamisch ?er die CoInitializeSecurity-Funktion). Au?rdem
  547. k?nen Zugriffskontrolllisten erstellt werden, die definieren,
  548. welche Benutzer und Gruppen auf bestimmte Dienste zugreifen k?nen.
  549.  
  550. Authentifizierungsebenen
  551.  
  552. DCOM95-Clients k?nen DCOM-Aufrufe unter Verwendung jeder 
  553. beliebigen Authentifizierungsebene durchf?ren. DCOM95-Server 
  554. oder -Clients, die einen R?kruf erhalten, k?nen nur DCOM-Aufrufe 
  555. mit der Authentifizierungsebene RPC_C_AUTHN_LEVEL_NONE oder 
  556. RPC_C_AUTHN_LEVEL_CONNECT annehmen.
  557.  
  558. Transportprotokolle
  559.  
  560. DCOM95 unterst?zt nur die Verbindung ?er TCP. Wenn das
  561. TCP-IP-Protokoll nicht installiert ist, kann DCOM95 das COM-Protokoll
  562. zu einem anderen Computer nicht unterst?zen.
  563.  
  564. Registrierungseinstellungen
  565.  
  566. Von DCOM95 werden unter HKEY_LOCAL_MACHINE\Software\Microsoft\OLE 
  567. folgende Registrierungsschl?sel eingerichtet:
  568.  
  569. EnableDCOM (Standardwert: "Y"). Dieser Schl?sel aktiviert DCOM 
  570. auf diesem Computer. Wenn dieser Wert "N" lautet, kann der Computer 
  571. keine Verbindung zu Objekten auf Remote-Computern aufnehmen oder 
  572. sie aktivieren; Remote-Computer k?nen keine Verbindung zu Objekten 
  573. auf dem lokalen Computer aufnehmen. Wenn dieser "Y" lautet, ist 
  574. entweder die Client-Verbindung vom lokalen Computer zu remoten 
  575. Objekten (wenn EnableRemoteConnect='N' ist; siehe unten) oder die 
  576. volle Client/Server-Verbindung m?lich (wenn EnableRemoteConnect='Y'; 
  577. siehe unten).
  578.  
  579. EnableRemoteConnect (Standardwert: "N"). Dieser Schl?sel macht es
  580. COM-Servern m?lich, Remote-Clients zu unterst?zen. Wenn dieser Wert
  581. "Y" lautet, k?nen Verweise zu Schnittstellen lokaler Objekte zu
  582. Remote-Clients weitergegeben werden, und Remote-Clients k?nen
  583. Verbindung zu ausgef?rten Objekten aufnehmen. Wenn dieser Wert "N"
  584. lautet, kann der Computer Verbindung zu remoten Objekten aufnehmen,
  585. aber nicht als Server agieren: die Verbindung zu ausgef?rten Objekten
  586. ist nicht m?lich.
  587.  
  588. Unter HKEY_CLASSES_ROOT\CLSID wird der folgende 
  589. Registrierungsschl?sel eingerichtet:
  590.  
  591. {bdc67890-4fc0-11d0-a805-00aa006d2ea4}\InstalledVersion.
  592. Dieser Schl?sel enth?t die Versionsnummer von DCOM95 im Format
  593. "a,b,c,d". Anhand dieses Werts stellt Internet Component Download
  594. fest, ob DCOM95 installiert ist. Der Wert wird bei der Installation
  595. in die Registrierung eingef?t und sollte nicht ge?dert werden.
  596.  
  597. Windows 95 als Remote-Server
  598.  
  599. Windows 95 kann als Remote-Server agieren. Dabei ist allerdings
  600. folgendes zu beachten:
  601. *    Starten wird nicht unterst?zt. Der Serverprozess muss bereits
  602.     ausgef?rt werden, damit ein Client zu ihm Verbindung aufnehmen     
  603.     kann.
  604. *    Wenn eine sichere Verbindung ben?igt wird, muss auf dem Server         
  605.     (und f? R?krufe auch auf dem Client) die Zugriffssteuerung
  606.     auf Benutzerebene eingestellt und ein
  607.     Sicherheits-Dienstanbieter angegeben sein.
  608. *    Der Registrierungsschl?sel "EnableRemoteConnect" muss den Wert     
  609.     "Y" haben.
  610.  
  611. DCOM95 wurde in Verbindung mit dem Sicherheits-Dienstanbieter der
  612. Windows NT-Dom?e ausf?rlich getestet. Wenn Sie einen anderen
  613. Sicherheits-Dienstanbieter verwenden, treten u. U. Probleme auf.
  614.  
  615. Zum Einrichten der Zugriffssteuerung auf Benutzerebene muss Filesec.vxd
  616. installiert sein. Diese Datei wird bei der Installation der Datei- und
  617. Druckerfreigabe auf Windows 95-Systemen installiert.
  618.  
  619. ?fnen Sie zum Aktivieren der Zugriffssteuerung auf Benutzerebene das
  620. Dialogfeld "Netzwerk" in der Systemsteuerung, klicken Sie auf die
  621. Registerkarte "Zugriffssteuerung", aktivieren Sie das Kontrollk?tchen
  622. "Zugriffssteuerung auf Benutzerebene", und geben Sie den Namen der
  623. Sicherheitsdom?e ein. Unter Umst?den hat dies Auswirkungen darauf,
  624. wie Sie auf im Netzwerk freigegebene Verzeichnisse zugreifen. Weitere
  625. Informationen hierzu finden Sie in der Onlinedokumentation. Wenn es im
  626. Dialogfeld "Netzwerk" keine Registerkarte "Zugriffssteuerung" gibt,
  627. m?sen Sie einen Netzwerk-Clientservice installieren. Informationen
  628. zur Installation eines Netzwerkclients finden Sie in der Onlinehilfe
  629. unter dem Stichwort "Netzwerkclients, Einrichten".
  630.  
  631. V. Weitervertrieb
  632. -----------------
  633.  
  634. Informationen zum Weitervertrieb von DCOM95 finden Sie in den
  635. Richtlinien zum Weitervertrieb im Endbenutzer-Lizenzvertrag (license.txt).
  636.  
  637. VI. Technische Unterst?zung und weitere Informationen
  638. ------------------------------------------------------
  639.  
  640. Geb?renpflichtige Unterst?zung
  641.  
  642. Die Anwendungsentwicklung mit Hilfe von DCOM95 wird von Microsofts
  643. Technischem Support unterst?zt. Wenn Sie einen Premier Level- oder
  644. einen Priority Level-Supportvertrag abgeschlossen haben, k?nen Sie
  645. sich jederzeit an den Technischen Support wenden. Sie k?nen aber auch
  646. einzelne Priority Support-Scheine erwerben (dies entspricht im wesentlichen
  647. einer einmaligen Geb?r pro Frage). Wenn Sie Fragen zu den Angeboten
  648. der geb?renpflichtigen Unterst?zung haben, wenden Sie sich an Microsoft
  649. Support Sales: (001-800) 936 35 00, 6.00-18.00 Pacific Time (9 Stunden
  650. Zeitunterschied), Montag bis Freitag mit Ausnahme von US-Feiertagen.
  651. Die Informationen von Microsofts Technischem Support sind auch ?er das
  652. World Wide Web erh?tlich:
  653.     http://www.microsoft.com/germany/support/.
  654.  
  655.  
  656. Geb?renfreie Unterst?zung
  657.  
  658. Newsgroups sind eine erstklassige Quelle f? kostenlose technische
  659. Unterst?zung durch andere Entwickler und Interessenten. Zus?zlich
  660. besuchen die Entwickler, Programmmmanager, Kundendienstmitarbeiter
  661. und Programmierer von Microsoft die offiziellen Newsgroups so oft wie
  662. m?lich auf, um Feedback zu erhalten und Fragen zu beantworten oder
  663. Irrt?er aufzukl?en. Wenn Sie einen Artikel in einer Newsgroup
  664. ver?fentlichen, haben Sie jedoch keine Garantie darauf, dass Sie eine
  665. Antwort von Microsoft erhalten.
  666.  
  667. In folgenden Newsgroups k?nen Sie Fragen zu DCOM95 stellen:
  668. *    comp.os.ms-windows.programmer.ole
  669. *    microsoft.public.win32.programmer.ole
  670.  
  671. Die DCOM-Verteilerliste ist eine weitere gute Quelle f? kostenlose
  672. technische Unterst?zung. Einer der Vorteile von Verteilerlisten
  673. besteht darin, dass Microsoft ?er dieses Medium zu vielen Themen
  674. Vorabnachrichten ver?fentlicht. Andererseits sollte erneut betont
  675. werden, dass es sich hier nicht um den offiziellen Technischen Support
  676. von Microsoft handelt - die Mitarbeiter von Microsoft nehmen hieran
  677. zwar durchaus aktiv teil, Sie haben aber keine Garantie darauf, dass
  678. ein ver?fentlichter Beitrag auch beantwortet wird.
  679.  
  680. Weitere Informationen zur DCOM-Verteilerliste finden Sie auf
  681. folgender Seite:
  682.     http://www.microsoft.com/sitebuilder/resource/mail.asp.
  683.  
  684. Feedback
  685.  
  686. Senden Sie bitte Kommentare und Fehlerberichte an die DCOM-Verteilerliste.
  687.  
  688. Weitere Informationen
  689.  
  690. Zus?zliche Informationen zu DCOM finden Sie auf der COM-Homepage:
  691. http://www.microsoft.com/com/.
  692.  
  693. VII. Dateiliste
  694. ---------------
  695.  
  696. In der folgenden Tabelle werden die Versionsnummern der mit DCOM95
  697. ausgelieferten Dateien aufgef?rt.
  698.  
  699. oleaut32.dll     2.40.4273
  700. secur32.dll      4.10.1999
  701. compobj.dll      2.3.2
  702. ole2.dll         2.3.2
  703. ole32.dll        4.71.2900
  704. olecnv32.dll     4.71.2900
  705. olethk32.dll     4.71.2900
  706. rpcltc1.dll      4.71.2900
  707. rpcltc5.dll      4.71.2900
  708. rpcltccm.dll     4.71.2900
  709. rpclts5.dll      4.71.2900
  710. rpcltscm.dll     4.71.2900
  711. rpcns4.dll       4.71.2900
  712. rpcrt4.dll       4.71.2900
  713. rpcss.exe        4.71.2900
  714. storage.dll      2.3.2
  715. stdole2.tlb      2.40.4273
  716. stdole32.tlb     2.1
  717. imagehlp.dll     4.00
  718. dllhost.exe      4.71.2900
  719. comcat.dll       5.0
  720. iprop.dll        4.00
  721. rpcmqcl.dll      4.71.2900
  722. rpcmqsvr.dll     4.71.2900
  723. olepro32.dll     5.0.4273
  724. asycfilt.dll     2.40.4273
  725. dcom2w98.dll     2.10.35.35
  726.  
  727. In der folgenden Tabelle werden die Versionsnummern der mit DCM95CFG
  728. ausgelieferten Dateien aufgef?rt.
  729.  
  730. dcomcnfg.exe     5.00.1603.0
  731. ciscnfg.exe      4.71.2618
  732.