home *** CD-ROM | disk | FTP | other *** search
/ Chip 2000 October / CHIP Turkiye Ekim 2000.iso / prog / basic / 09 / DCOM95.EXE / relnotes.txt < prev    next >
Encoding:
Text File  |  1999-03-09  |  28.3 KB  |  708 lines
  1. DCOM95 1.3
  2. Release Notes
  3. Last Modified: September 14, 1998
  4.  
  5. DCOM95 provides Distributed COM support for Microsoft« Windows« 95.
  6. The DCOM wire protocol transparently provides support for reliable, 
  7. secure, and efficient communication between Component Object 
  8. Model (COM) components such as ActiveX« controls, scripts, and 
  9. Java applets residing on different machines in a LAN, a WAN, or on 
  10. the Internet. With DCOM, your application can be distributed across 
  11. locations that make the most sense to your customer and to the 
  12. application.
  13.  
  14. For more in-depth information, see the DCOM Technical overview 
  15. available on the Microsoft COM home page, 
  16. http://www.microsoft.com/com/.
  17.  
  18. Contents
  19. ========
  20. I.   New Features
  21. II.  Bug Fixes
  22. III. Known Issues
  23. IV.  Differences from DCOM on Windows NT
  24. V.   Redistribution
  25. VI.  Support & Resources
  26. VII. File List
  27.  
  28. I. New Features
  29. ---------------
  30.  
  31. Replacing DCOM95 with Older Version Prohibited
  32.  
  33. In previous releases of DCOM95, you could replace a newer 
  34. version of DCOM95 with an older version of DCOM95. Version 
  35. numbers are now checked on installation, and you are not 
  36. permitted to install an older version over a newer version. This 
  37. change will avoid problems with incompatible versions of DLLs.
  38.  
  39. Visual Studio 6.0 Process Monitoring Support
  40.  
  41. In support of Visual Studio 6.0, DCOM95 provides monitoring 
  42. information for developers to help them understand the behavior, 
  43. performance, and structure of their application. If you are using 
  44. Visual Studio Analyzer on a computer that is running Windows 95, 
  45. you should always use this version of DCOM95.
  46.  
  47. New Directory Created by Setup
  48.  
  49. Setup creates a directory called DCOM95 under your system 
  50. directory. The end-user license agreement and other files  are 
  51. stored there. Setup also creates a subdirectory of DCOM95 called 
  52. OLDOLE, into which the old DCOM95 or OLE binaries are backed 
  53. up. These files are restored if you later uninstall DCOM95.
  54.  
  55. COM Internet Services
  56.  
  57. The COM Internet Services (CIS) enable clients and servers to be 
  58. connected over the Internet using COM. CIS consists of 
  59. *    A new DCOM protocol, Tunneled TCP 
  60. *    A new moniker type, OBJREF moniker 
  61. *    A new CISCNFG utility
  62.  
  63. For CIS client support in Windows 95, you must install both DCOM95 
  64. and DCOMCFG. Then use the CISCNFG tool, which is installed when you 
  65. install the DCOM configuration utility, to change the registry key 
  66. that defines which protocol to use for remote processes. In the 
  67. Command Prompt window, enter:
  68.     ciscnfg <protocol>
  69.  
  70. Where <protocol> is:
  71. *    rpc to use RPC
  72. *    http to use HTTP
  73. *    tcp_http to try TCP first and then, if the server times out, 
  74.     to try HTTP.
  75.  
  76. The ciscnfg command with no argument provides usage 
  77. information.
  78.  
  79. No SDK updates are required to use the Tunneled TCP protocol. 
  80.  
  81. There are a few updates for OBJREF monikers. 
  82.  
  83. CreateObjrefMoniker
  84.  
  85. Creates an OBJREF moniker based on a pointer to an object.
  86. WINOLEAPI CreateObjrefMoniker(
  87.     LPUNKNOWN pUnk, //Pointer to the object
  88.     LPMONIKER *ppMk //Address of pointer to OBJREF moniker
  89. );
  90.  
  91. Parameters
  92.  
  93. pUnk
  94.  
  95. Pointer to the IUnknown interface on the object that the moniker 
  96. is to represent.
  97.  
  98. ppMk
  99.  
  100. Address of a pointer to the IMoniker interface on the OBJREF 
  101. moniker created.
  102.  
  103. Return Values
  104.  
  105. This function supports the standard return values 
  106. E_OUTOFMEMORY and E_UNEXPECTED, as well as the 
  107. following:
  108.  
  109. S_OK
  110.  
  111. The OBJREF moniker was successfully created.
  112.  
  113. Remarks
  114.  
  115. Clients use OBJREF monikers to obtain a marshaled pointer to a 
  116. running object in the serverÆs address space. 
  117. The server typically calls CreateObjrefMoniker to create an 
  118. OBJREF moniker and then calls IMoniker::GetDisplayName, and 
  119. finally releases the moniker. The display name for an OBJREF 
  120. moniker is of the form:
  121.     OBJREF:nnnnnnnn 
  122.  
  123. Where nnnnnnnn is an arbitrarily long base-64 encoding that 
  124. encapsulates the machine location, process endpoint, and interface 
  125. pointer ID (IPID) of the running object. 
  126.  
  127. The display name can then be transferred to the client as text. For 
  128. example, the display name can reside on an HTML page that the 
  129. client downloads. 
  130.  
  131. The client can pass the display name to MkParseDisplayName, 
  132. which creates an OBJREF moniker based on the display name. A 
  133. call to the monikerÆs IMoniker::BindToObject method then obtains 
  134. a marshaled pointer to the running instance on the server. 
  135. For example, a server-side COM component contained in an active 
  136. server page can create an OBJREF moniker, obtain its display 
  137. name, and write the display name to the HTML output that is sent to 
  138. the client browser. A script that runs on the client side can use the 
  139. display name to get access to the running object itself. A client-side
  140. Visual Basic script, for instance, could store the display name in a 
  141. variable called strMyName and include this line:
  142.     objMyInstance = GetObject(strMyName)
  143.  
  144. The script engine internally makes the calls to 
  145. MkParseDisplayName and IMoniker::BindToObject, and the 
  146. script can then use objMyInstance to refer directly to the running 
  147. object.
  148.  
  149. If the running object uses static IPIDs and the server process 
  150. always runs on the same computer at a well-known endpoint, the 
  151. display name of the OBJREF moniker will always be the same. In 
  152. that case, the server can store the display name instead of 
  153. calculating it each time it receives a request for the object. 
  154.  
  155. IMoniker - OBJREF Moniker Implementation
  156.  
  157. OBJREF monikers represent a reference to an object instance that 
  158. is running on an out-of-process server, either locally or remotely. 
  159. The moniker identifies the object instance and the computer the 
  160. object is running on. 
  161.  
  162. An OBJREF moniker is similar in many ways to a pointer moniker, 
  163. except that the running object is out-of-process. A client can call 
  164. IMoniker::BindToObject on an OBJREF moniker and use the 
  165. pointer it obtains to access the running object, regardless of its 
  166. location. 
  167.  
  168. An important distinction from a pointer moniker is that the display 
  169. name of an OBJREF moniker can be embedded in an HTML page, 
  170. and the running object represented by the moniker can be bound by 
  171. a client script, applet, or ActiveX control.
  172.  
  173. When to Use
  174.  
  175. The primary use for an OBJREF moniker is to obtain access to a 
  176. running object instance over the Internet. An active server page or 
  177. some other means of generating dynamic HTML content places the 
  178. display name of an OBJREF moniker in a parameter to an applet or 
  179. an ActiveX control. The code of the applet or control calls 
  180. CreateObjrefMoniker to create an OBJREF moniker based on the 
  181. display name, and it then calls IMoniker::BindToObject on the 
  182. resulting OBJREF moniker to get access to the running object 
  183. instance. The active server page then marshals a pointer to the 
  184. running object back to the pageÆs client. 
  185.  
  186. Remarks
  187.  
  188. IMoniker::BindToObject. For OBJREF monikers, the pmkToLeft 
  189. parameter must be NULL. Because the OBJREF moniker 
  190. represents a running object, no activation takes place. If the 
  191. represented object is no longer running, BindToObject fails with 
  192. E_UNEXPECTED. 
  193.  
  194. IMoniker::BindToStorage. This method obtains a marshaled 
  195. pointer to the requested interface on the storage that contains the 
  196. running object. Because the OBJREF moniker represents a running 
  197. object, no activation takes place. If the represented object is no 
  198. longer running, BindToStorage fails with E_UNEXPECTED. 
  199.  
  200. IMoniker::Reduce. This method returns 
  201. MK_S_REDUCED_TO_SELF and passes back the same moniker.
  202.  
  203. IMoniker::ComposeWith. If pmkRight is an anti-moniker, the 
  204. returned moniker is NULL. If pmkRight is a composite whose 
  205. leftmost component is an anti-moniker, the returned moniker is the 
  206. composite with the leftmost anti-moniker removed. If pmkRight is 
  207. neither an anti-moniker nor a composite moniker whose leftmost 
  208. component is an anti-moniker, then the method checks the 
  209. fOnlyIfNotGeneric parameter. If it is FALSE, the method combines 
  210. the two monikers into a generic composite; if it is TRUE, the method 
  211. sets *ppmkComposite to NULL and returns 
  212. MK_E_NEEDGENERIC.
  213.  
  214. IMoniker::Enum. This method returns S_OK and sets 
  215. ppenumMoniker to NULL. 
  216.  
  217. IMoniker::IsEqual. This method returns S_OK if *pmkOther is an 
  218. OBJREF moniker and the paths for both monikers are identical 
  219. (using a case-insensitive comparison). Otherwise, the method 
  220. returns S_FALSE.
  221.  
  222. IMoniker::Hash. This method calculates a hash value for the 
  223. moniker.
  224.  
  225. IMoniker::IsRunning. Because OBJREF monikers represent a 
  226. running object instance, this method returns TRUE unless the 
  227. object is known to be no longer running because a recent call failed. 
  228. The method ignores pmkToLeft.
  229.  
  230. IMoniker::GetTimeOfLastChange. This method returns 
  231. E_NOTIMPL.
  232.  
  233. IMoniker::Inverse. This method returns an anti-moniker (i.e., the 
  234. results of calling CreateAntiMoniker).
  235.  
  236. IMoniker::CommonPrefixWith. If the two monikers are equal, this 
  237. method returns MK_S_US and sets *ppmkPrefix to NULL. If the 
  238. other moniker is not an OBJREF moniker, this method passes both 
  239. monikers to the MonikerCommonPrefixWith function. This 
  240. function correctly handles the case where the other moniker is a 
  241. generic composite.
  242.  
  243. If there is no common prefix, this method returns MK_E_.
  244.  
  245. IMoniker::RelativePathTo. This method returns E_NOTIMPL. 
  246.  
  247. IMoniker::GetDisplayName. This method obtains the display 
  248. name for the OBJREF moniker. The display name is a 64-bit 
  249. encoding that encapsulates the machine location, process endpoint, 
  250. and interface pointer ID (IPID) of the running object. For future 
  251. compatibility, the display name is restricted to characters that can 
  252. be specified as part of a URL.
  253.  
  254. IMoniker::ParseDisplayName. If pmkToLeft is not NULL, this 
  255. method returns MK_E_SYNTAX.
  256.  
  257. IMoniker::IsSystemMoniker. This method returns S_OK and 
  258. passes back MKSYS_OBJREFMONIKER. 
  259.  
  260. Support for VB6.0 Data Types
  261.  
  262. Visual Basic« 6.0 allows Visual Basic variants to contain user-
  263. defined data structures. DCOM95 now supports remoting of these 
  264. variants.
  265.  
  266. II. Bug Fixes
  267. -------------
  268.  
  269. Race Condition When Unloading Multiple Modules
  270.  
  271. When multiple modules were unloaded simultaneously, a race 
  272. condition would occur in previous versions of DCOM95. Depending 
  273. upon the order in which the modules were unloaded, an access 
  274. violation could result. This has been corrected in this release of 
  275. DCOM95.
  276.  
  277. Desktop Unresponsive During RPC Protocol Negotiations
  278.  
  279. Earlier versions of DCOM95 did not dispatch messages while they were 
  280. negotiating RPC protocols. In certain cases, if the user launched 
  281. another application during the time that RPC protocols were being 
  282. negotiated, the machine would appear to be unresponsive. After 30 
  283. seconds, processing of messages would resume. This behavior has been 
  284. changed in the latest release of DCOM95, and applications can be 
  285. launched while RPC protocols are being negotiated. 
  286.  
  287. Desktop Unresponsive When New Application Launched
  288.  
  289. RPC creates a hidden window in the Multiple-Threaded Apartment (MTA),
  290. which is not required to dispatch messages per DCOM spec.
  291. When a user launches a new application from the desktop, 
  292. Windows sends a message to all other window handles, notifying 
  293. them of this event, and expecting a reply. Under earlier versions of 
  294. DCOM95, the hidden RPC window might not reply, and Windows would 
  295. hang. This version of DCOM95 fixes this problem, and the RPC window 
  296. no longer makes the desktop unresponsive when new applications are 
  297. launched. 
  298.  
  299. Multiple IP Addresses Heap Corruption
  300.  
  301. In certain situations, if you were running a previous version of 
  302. DCOM95 on a machine with more than one IP address, the IP address 
  303. buffer would be overrun and the heap would be corrupted. This has 
  304. been fixed in the latest release of DCOM95. 
  305.  
  306. Only First IP Address Used
  307.  
  308. If you were running a previous version of DCOM95 on a machine that 
  309. had two network adapter cards (and therefore two IP addresses, each 
  310. assigned to a different address card), DCOM95 would use only one 
  311. network adapter. In this release of DCOM95, if the first one tried 
  312. does not work, the second one will be used.
  313.  
  314. RPC Now Tries Multiple IP Addresses
  315.  
  316. When doing a remote procedure call to a machine with multiple IP 
  317. addresses, subsequent IP addresses will now be tried if connecting 
  318. to the first one fails.
  319.  
  320. File Monikers Support Additional Path Syntax
  321.  
  322. File monikers can now be created out of arguments of the form 
  323. <startdir><relativepath>, such as "C:\bug\bug\..\..\foo.jpg." In 
  324. DCOM95 1.1, only relative paths (e.g., "..\..\foo.jpg") or absolute 
  325. paths (e.g., "C:\foo.jpg") were permitted.
  326.  
  327. General Protection Fault When Oleaut32.dll Unloaded
  328.  
  329. In previous versions of DCOM95, a general protection fault occurred 
  330. when Oleaut32.dll was unloaded before a call to CoUninitialize. This 
  331. would most often occur when a VB application created a control 
  332. statically linked to Oleaut32.dll, and then freed the control prior
  333. to calling CoUninitialize. This no longer causes a general 
  334. protection fault in the latest release of DCOM95.
  335.  
  336. Visual Basic Type Marshaling and Unmarshaling
  337.  
  338. The marshalling and unmarshaling of certain Visual Basic data 
  339. types has been fixed. Array parameters with a size greater than 64K 
  340. are now allowed. Structures defined using aliases to the type are 
  341. now marshaled and unmarshaled correctly.
  342.  
  343. Atoms Being Deleted Too Many Times in OleUninitialize
  344.  
  345. This bug appeared in applications that call OleInitialize and 
  346. OleUninitialize multiple times. During initialization, OLE adds many 
  347. atoms for DDE RPC. If the atoms have already been added by 
  348. another thread, they are not added again. However, during 
  349. uninitialization, atoms were always deleted, and the handles were 
  350. not nullified. Therefore, the next time OleInitialize was called, the 
  351. old handles would still exist, even though the atoms were already 
  352. deleted, and OLE would not add them again. This led to all OLE 
  353. atoms being invalid after multiple calls to OleInitialize and 
  354. OleUninitialize. This problem has been fixed in this release of 
  355. DCOM95. 
  356.  
  357. ADO Servers Shut Down Properly
  358.  
  359. Active Data Objects (ADOs) use pointer monikers to start a server 
  360. process. Previous versions of DCOM95 contained a bug involving 
  361. pointer moniker reference counting, whereby pointer monikers were 
  362. created with an initial reference count of 1, rather than 0. 
  363. Therefore, the reference count of the pointer moniker would never 
  364. get to zero, and the pointer moniker would never be freed. As a 
  365. result, ADO servers were never shut down, even after the last 
  366. pointer to them had been released. This has been fixed in this 
  367. release of DCOM95.
  368.  
  369. CoCreateInstance Works with Own DNS Name
  370.  
  371. In previous versions of DCOM95, calling CoCreateInstance with the 
  372. fully qualified name of the local machine did not work. This has been fixed in 
  373. the current version of DCOM95, and CoCreateInstance now correctly 
  374. creates and instance on the local machine.
  375.  
  376. Slow Commit On Root Storage With Very Large Compound File
  377.  
  378. In previous versions of DCOM95, the commit time on a root storage 
  379. opened in STGM_TRANSACTED mode became very slow as the compound 
  380. file became very large (e.g. 400M). The internal page table 
  381. limits have been increased, and this is no longer a problem.
  382.  
  383. Exporting Objects From a Recreated MTA
  384.  
  385. In previous versions of DCOM95, a server could not export an 
  386. object from a Multi-Threaded Apartment (MTA) if this was not the 
  387. first time the MTA had been created in the process. This has been 
  388. fixed. Now, if a server creates an MTA, destroys it, and 
  389. subsequently recreates the MTA, objects will be able to be 
  390. exported from the MTA.
  391.  
  392. Multiple Instances Of Visual Basic 4 EXEs
  393.  
  394. In DCOM95 v1.1, if you started multiple instances of the same 
  395. Visual Basic 4 executable, then shut them down in any order but 
  396. LIFO (Last-In First-Out), the last exe would hang. This was also 
  397. true of E-Forms in Microsoft Exchange. This has been fixed in 
  398. the latest release of DCOM95. You may now shut down Visual 
  399. Basic 4 exes in any order.
  400.  
  401. Extended Characters in Visual Basic File Names
  402.  
  403. If you named a Visual Basic module or class using extended 
  404. characters for a given language, that file might not open on 
  405. machines configured for a different locale. This has been fixed.
  406.  
  407. III. Known Issues
  408. -----------------
  409.  
  410. Corel WordPerfect Suite 7: Installation Causes Invalid Page Fault
  411.  
  412. If you install Corel WordPerfect Suite 7 on a Windows 95 system 
  413. running DCOM95, you may get an invalid page fault in PfOd70.pfc 
  414. during installation. If this error appears, just close the error 
  415. message dialog box. Setup should continue successfully.
  416.  
  417. Microsoft Access95: Database Replication Does Not Work
  418.  
  419. If you try to replicate an Access database using Microsoft Access 
  420. 95 on machines with DCOM95 installed, you may get the following 
  421. error message: 
  422.  
  423. Microsoft Access cannot complete this operation because it 
  424. can't find or initialize the dynamic-link library Msjtrclr. 
  425.  
  426. This is a problem in Microsoft Access 95. You may work around this 
  427. issue by writing a program which uses the Access object model 
  428. rather than the replica tool, or by using the briefcase for replication. 
  429. Microsoft Access 97 is not affected by this issue. 
  430.  
  431. WordPerfect 
  432.  
  433. If you have a WordPerfect document containing an embedded 
  434. Corel spreadsheet and the spreadsheet contains another 
  435. embedded object (for example, a bitmap), you may get a warning 
  436. dialog saying youÆve lost the network connection when you close the 
  437. innermost object. There may be four or five such warnings. All 
  438. these warnings are benign. Just close them and continue.
  439.  
  440. Multiple-threaded apartment (MTA) clients that use BSTR 
  441. conversion routines may block DDE messages
  442.  
  443. Automation BSTR conversion routines (for example, BstrFromR4) 
  444. create hidden windows to facilitate the type conversion. These 
  445. windows do not service the Windows message queue. If such a 
  446. window is created from within an MTA client, DDE messages may 
  447. be blocked. The client thread has no obligation to service the 
  448. message queue under the MTA programming model. If it does not, 
  449. this top-level window causes global broadcast messages to block.
  450.  
  451. There are two ways to work around this situation. Either call the 
  452. BSTR conversion routines from within a single-threaded apartment 
  453. (STA) client, or make the clientÆs MTA thread behave like an 
  454. STA thread. (An STA thread must service the message queue.) If 
  455. the thread is blocking on a win32 handle, it must call the 
  456. MsgWaitForMultipleObjects function to simultaneously dispatch 
  457. Windows messages. 
  458.  
  459. DLL path names longer than 127 characters cause error
  460.  
  461. If you register a DLL with a path name of 128 characters or longer,
  462. the registration will succeed, but CoCreateInstance or CoGetClassObject
  463. will return an error (REGDB_E_CLASSNOTREG) when accessing an object
  464. supported by this DLL.
  465.  
  466. IV. Differences from DCOM on Windows NT
  467. ---------------------------------------
  468.  
  469. Security Capabilities of DCOM95
  470.  
  471. The core functionality and application programming interface (API) 
  472. for DCOM95 are identical in both Windows 95 and Windows NT 
  473. 4.0/5.0. However, certain capabilities related to security are different 
  474. because of the different security infrastructures of the operating 
  475. systems. Using the default security settings of the system is 
  476. recommended; it is also necessary to enable "user-level" security 
  477. on file-system shares. (See below.) 
  478.  
  479. The following services, which can be used to override default 
  480. security, are available: 
  481. *    CoInitializeSecurity 
  482. *    CoQueryAuthenticationService 
  483. *    CoQueryProxyBlanket 
  484. *    CoSetProxyBlanket 
  485. *    CoQueryClientBlanket 
  486. *    IClientSecurity Interface 
  487. *    IServerSecurity Interface 
  488.  
  489. However, certain capabilities that are part of DCOM for Windows 
  490. NT will not be available on Windows 95 because of differences 
  491. in the security infrastructure on Windows 95.
  492.  
  493. In particular, the lack of security functions in the Win32 API, such
  494. as the ability to create access control lists (ACLs), and the 
  495. AccessCheck function, as well as the lack of a security context 
  496. associated with thread and process tokens, should be taken into 
  497. account. Windows 95 do not natively support these functions or 
  498. constructs. Because of this, DCOM95 will not support impersonation
  499. (specifically, the CoImpersonateClient and CoRevertToSelf helper 
  500. functions over the IServerSecurity interface), which is based on 
  501. thread- and process-token security in Windows NT 4.0. Impersonation 
  502. is commonly used to automatically control access to restrictable 
  503. system resources such as the file system, other processes, and the 
  504. network. These resources are not restrictable on Windows 95. 
  505.  
  506. DCOM95 does, however, offer programmers various helper objects 
  507. to provide ACL and access-check functionality, which can be used 
  508. to explicitly control access by remote clients to both system and 
  509. user-defined resources or data. These helper objects are provided 
  510. by the system object CLSID_DCOMAccessControl, which implements the 
  511. IAccessControl interface.
  512.  
  513. IAccessControl should be used to manage security permissions 
  514. programmatically wherever portability between Windows 95/98 and 
  515. Windows NT is a concern. The CLSID_DCOMAccessControl object 
  516. is available in all releases of DCOM95 and in Windows NT 4.0 
  517. SP2 or later. For details about IAccessControl, see the Platform 
  518. SDK documentation.
  519.  
  520. Launch and Access Security 
  521.  
  522. Controlling who can launch server-class code is not supported in 
  523. DCOM95, because launching servers is not supported. 
  524. Servers/classes must already be running in order for remote clients 
  525. to connect to them and make use of their services. 
  526.  
  527. DCOM95 does support the ability to connect to already running 
  528. classes/servers. Access security is supported via the 
  529. \APPID\{.}\AccessPermissions registry key and adjusted via the 
  530. DCOMCNFG tool or during installation or setup of the server code. 
  531. Unauthenticated users will be able to use servers if you configure 
  532. the class to support unauthenticated connections (through static 
  533. configuration tools or dynamically via the CoInitializeSecurity 
  534. function). You can also build arbitrary ACLs to define which users 
  535. and groups can access specific services. 
  536.  
  537. Authentication Levels 
  538.  
  539. DCOM95 clients can make DCOM calls using any authentication 
  540. level. DCOM95 servers or clients receiving callbacks can accept 
  541. only DCOM calls using RPC_C_AUTHN_LEVEL_NONE or 
  542. RPC_C_AUTHN_LEVEL_CONNECT authentication levels.
  543.  
  544. Transports
  545.  
  546. DCOM95 supports only TCP connectivity. If you do not have the 
  547. TCP/IP protocol installed, DCOM95 will not be able to support 
  548. cross-machine COM. 
  549.  
  550. Registry Settings 
  551.  
  552. The following registry keys found under 
  553. HKEY_LOCAL_MACHINE\Software\Microsoft\OLE are established 
  554. by DCOM95: 
  555.  
  556. EnableDCOM (default value = "Y"). Enables DCOM on this machine. 
  557. When set to "N", the machine is prevented from connecting to or 
  558. activating objects on remote machines, and remote machines are 
  559. unable to connect to objects on the local machine. Setting this value 
  560. to "Y" enables either connectivity as a client to remote objects 
  561. (when EnableRemoteConnect='N', as explained below), or full 
  562. client/server connectivity (when EnableRemoteConnect='Y', as 
  563. explained below). 
  564.  
  565. EnableRemoteConnect (default value = "N"). Enables COM servers 
  566. to support remote clients. When this value is set to "Y", references 
  567. to interfaces on local objects can be passed to remote clients, and 
  568. remote clients are allowed to connect to running objects. When this 
  569. value is set to "N", this machine is allowed to connect to remote 
  570. objects but cannot act as a server: the machine is prevented from 
  571. connecting to running objects. 
  572.  
  573. In addition, the following registry key is found under 
  574. HKEY_CLASSES_ROOT\CLSID: 
  575.  
  576. {bdc67890-4fc0-11d0-a805-00aa006d2ea4}\InstalledVersion. 
  577. Contains the version number of DCOM95 in the format "a,b,c,d". 
  578. This value can be used by Internet Component Download to 
  579. determine whether DCOM95 is installed. This value is added to the 
  580. registry during setup and should not be modified. 
  581.  
  582. Using Windows 95 as a remote server host
  583.  
  584. Windows 95 can be a remote server host, with the following 
  585. caveats:
  586. *    There is no launch capability. The server process must be 
  587.     already running for a client to connect to it.
  588. *    If secure connections are needed, the server (and in the case
  589.     of callbacks, the client) must have user-level access control
  590.     with the name of a security provider set. 
  591. *    The registry value "EnableRemoteConnect" must be set to "Y".
  592.  
  593. DCOM95 has been tested most extensively using the Windows NT 
  594. Domain security provider. You may encounter problems using other 
  595. security providers.
  596.  
  597. To establish user-level access control, you must have Filesec.vxd 
  598. installed. This file is generally installed on Windows 95 machines 
  599. when you install file and print sharing.
  600.  
  601. To enable user-level access control, open the Network dialog box in 
  602. Control Panel, click the Access Control tab, check the box marked 
  603. User-level Access Control, and enter the name of your security 
  604. domain. This may affect the way you currently share directories on 
  605. the network from your computer; see the online documentation for 
  606. details. If you do not have an Access Control tab in your network 
  607. configuration control panel, you need to install a network client 
  608. service. Click the Network clients, setting up entry in the online 
  609. help index for information on installing a network client.
  610.  
  611. V. Redistribution
  612. -----------------
  613.  
  614. For information about redistributing DCOM95, please review the
  615. redistribution guidelines contained in the end-user license
  616. agreement (license.txt).
  617.  
  618. VI. Support & Resources
  619. -----------------------
  620.  
  621. Paid Support
  622.  
  623. DCOM95 application development is supported by Microsoft 
  624. Technical Support. You can ask questions through your Premier 
  625. Level support contract. You can also ask questions through your 
  626. Priority Level contract or purchase individual Priority Support 
  627. incidents (essentially a one-time fee for one question). If you would 
  628. like to understand more about Microsoft's paid support options, you 
  629. can call Microsoft Support Sales at (800) 936-3500 from 6:00 a.m. 
  630. to 6:00 p.m. Pacific time, Monday through Friday, excluding 
  631. holidays. Please note that technical support is not available through 
  632. this number. Microsoft Technical Support Information is also 
  633. available on the World Wide Web at 
  634.     http://www.microsoft.com/support/. 
  635.  
  636. Free Support
  637.  
  638. Newsgroups are a great place for free peer support. As time and 
  639. resources allow, Microsoft developers, program managers, support 
  640. engineers, and test engineers visit the site to collect feedback and 
  641. answer questions or correct misperceptions. There is no guarantee 
  642. that you will receive a response from Microsoft to any newsgroup 
  643. posting. 
  644.  
  645. The following newsgroups can be used to ask questions about 
  646. DCOM95: 
  647. *    comp.os.ms-windows.programmer.ole 
  648. *    microsoft.public.win32.programmer.ole
  649.  
  650. The DCOM mailing list is another good form of free peer support. 
  651. An advantage to being on a mailing list is that this is where 
  652. Microsoft will make early announcements of information on a given 
  653. topic. Again, it is peer support, and Microsoft staff will often lurk 
  654. there, but are not guaranteed to respond to any postings. 
  655.  
  656. To learn more about the DCOM mailing list, please review our 
  657. Mailing List page, 
  658.     http://www.microsoft.com/sitebuilder/resource/mail.asp.
  659.  
  660. Providing Feedback 
  661.  
  662. Please send any comments or bug reports to the DCOM mailing list. 
  663.  
  664. Resources
  665.  
  666. You can find additional information about DCOM on the COM Home 
  667. Page at http://www.microsoft.com/com/.
  668.  
  669. VII. File List
  670. --------------------
  671.  
  672. This table lists the version numbers of files distributed with 
  673. DCOM95.
  674.  
  675. oleaut32.dll     2.40.4275
  676. secur32.dll      4.10.1999
  677. compobj.dll      2.3.2
  678. ole2.dll         2.3.2
  679. ole32.dll        4.71.2900
  680. olecnv32.dll     4.71.2900
  681. olethk32.dll     4.71.2900
  682. rpcltc1.dll      4.71.2900
  683. rpcltc5.dll      4.71.2900
  684. rpcltccm.dll     4.71.2900
  685. rpclts5.dll      4.71.2900
  686. rpcltscm.dll     4.71.2900
  687. rpcns4.dll       4.71.2900
  688. rpcrt4.dll       4.71.2900
  689. rpcss.exe        4.71.2900
  690. storage.dll      2.3.2
  691. stdole2.tlb      2.40.4275
  692. stdole32.tlb     2.1
  693. imagehlp.dll     4.00
  694. dllhost.exe      4.71.2900
  695. comcat.dll       5.0
  696. iprop.dll        4.00
  697. rpcmqcl.dll      4.71.2900
  698. rpcmqsvr.dll     4.71.2900
  699. olepro32.dll     5.0.4275
  700. asycfilt.dll     2.40.4275
  701. dcom2w98.dll     2.10.35.35
  702.  
  703. This table lists the version numbers of files distributed with 
  704. DCM95CFG.
  705.  
  706. dcomcnfg.exe     5.00.1603.0
  707. ciscnfg.exe      4.71.2618
  708.