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