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