home *** CD-ROM | disk | FTP | other *** search
- DCOM95 1.3
- Release Notes
- Last Modified: March 14, 1998
-
- DCOM95 provides Distributed COM support for Microsoft« Windows« 95.
- The DCOM wire protocol transparently provides support for reliable,
- secure, and efficient communication between Component Object
- Model (COM) components such as ActiveX« controls, scripts, and
- Java applets residing on different machines in a LAN, a WAN, or on
- the Internet. With DCOM, your application can be distributed across
- locations that make the most sense to your customer and to the
- application.
-
- For more in-depth information, see the DCOM Technical overview
- available on the Microsoft COM home page,
- http://www.microsoft.com/com/.
-
- Contents
- ========
- I. New Features since DCOM95 1.2
- II. Bug Fixes since DCOM95 1.2
- III. Known Issues
- IV. Differences from DCOM on Windows NT
- V. Redistribution
- VI. Support & Resources
- VII. File List
-
- I. New Features since DCOM95 1.2
- --------------------------------
-
- Support for VB6.0 Data Types
-
- Visual Basic« 6.0 allows Visual Basic variants to contain user-
- defined data structures. DCOM95 now supports remoting of these
- variants.
-
- II. Bug Fixes since DCOM95 1.2
- ------------------------------
-
- This section describes bugs fixed in DCOM95 1.3 that affected
- applications running on Windows 95 with DCOM95 1.2 installed.
-
- File Monikers Support Additional Path Syntax
-
- File monikers can now be created out of arguments of the form
- <startdir><relativepath>, such as "C:\bug\bug\..\..\foo.jpg." In
- DCOM95 1.1, only relative paths (e.g., "..\..\foo.jpg") or absolute
- paths (e.g., "C:\foo.jpg") were permitted.
-
- General Protection Fault When Oleaut32.dll Unloaded
-
- In previous versions of DCOM95, a general protection fault occurred
- when Oleaut32.dll was unloaded before a call to CoUninitialize. This
- would most often occur when a VB application created a control
- statically linked to Oleaut32.dll, and then freed the control prior
- to calling CoUninitialize. This no longer causes a general
- protection fault in the latest release of DCOM95.
-
- Visual Basic Type Marshaling and Unmarshaling
-
- The marshalling and unmarshaling of certain Visual Basic data
- types has been fixed. Array parameters with a size greater than 64K
- are now allowed. Structures defined using aliases to the type are
- now marshaled and unmarshaled correctly.
-
- Atoms Being Deleted Too Many Times in OleUninitialize
-
- This bug appeared in applications that call OleInitialize and
- OleUninitialize multiple times. During initialization, OLE adds many
- atoms for DDE RPC. If the atoms have already been added by
- another thread, they are not added again. However, during
- uninitialization, atoms were always deleted, and the handles were
- not nullified. Therefore, the next time OleInitialize was called, the
- old handles would still exist, even though the atoms were already
- deleted, and OLE would not add them again. This led to all OLE
- atoms being invalid after multiple calls to OleInitialize and
- OleUninitialize. This problem has been fixed in this release of
- DCOM95.
-
- ADO Servers Shut Down Properly
-
- Active Data Objects (ADOs) use pointer monikers to start a server
- process. Previous versions of DCOM95 contained a bug involving
- pointer moniker reference counting, whereby pointer monikers were
- created with an initial reference count of 1, rather than 0.
- Therefore, the reference count of the pointer moniker would never
- get to zero, and the pointer moniker would never be freed. As a
- result, ADO servers were never shut down, even after the last
- pointer to them had been released. This has been fixed in this
- release of DCOM95.
-
- CoCreateInstance Works with Own DNS Name
-
- In previous versions of DCOM95, calling CoCreateInstance with the
- fully qualified name of the local machine did not work. This has been fixed in
- the current version of DCOM95, and CoCreateInstance now correctly
- creates and instance on the local machine.
-
- Slow Commit On Root Storage With Very Large Compound File
-
- In previous versions of DCOM95, the commit time on a root storage
- opened in STGM_TRANSACTED mode became very slow as the compound
- file became very large (e.g. 400M). The internal page table
- limits have been increased, and this is no longer a problem.
-
- Exporting Objects From a Recreated MTA
-
- In previous versions of DCOM95, a server could not export an
- object from a Multi-Threaded Apartment (MTA) if this was not the
- first time the MTA had been created in the process. This has been
- fixed. Now, if a server creates an MTA, destroys it, and
- subsequently recreates the MTA, objects will be able to be
- exported from the MTA.
-
- Multiple Instances Of Visual Basic 4 EXEs
-
- In DCOM95 v1.1, if you started multiple instances of the same
- Visual Basic 4 executable, then shut them down in any order but
- LIFO (Last-In First-Out), the last exe would hang. This was also
- true of E-Forms in Microsoft Exchange. This has been fixed in
- the latest release of DCOM95. You may now shut down Visual
- Basic 4 exes in any order.
-
- Extended Characters in Visual Basic File Names
-
- If you named a Visual Basic module or class using extended
- characters for a given language, that file might not open on
- machines configured for a different locale. This has been fixed.
-
- Heap Memory Leak When Using IDataObject/IAdviseSink
-
- There was a memory leak when using Uniform Data Transfer between
- a data object on a local server that implements the IDataObject
- interface and a client that implements IAdviseSink. When the
- client used the STA model, every call would leak 32 bytes. This
- problemmanifest itself as the server taking more and more time
- to execute. The leak has been fixed.
-
- III. Known Issues
- -----------------
-
- Corel WordPerfect Suite 7: Installation Causes Invalid Page Fault
-
- If you install Corel WordPerfect Suite 7 on a Windows 95 system
- running DCOM95, you may get an invalid page fault in PfOd70.pfc
- during installation. If this error appears, just close the error
- message dialog box. Setup should continue successfully.
-
- Microsoft Access95: Database Replication Does Not Work
-
- If you try to replicate an Access database using Microsoft Access
- 95 on machines with DCOM95 installed, you may get the following
- error message:
-
- Microsoft Access cannot complete this operation because it
- can't find or initialize the dynamic-link library Msjtrclr.
-
- This is a problem in Microsoft Access 95. You may work around this
- issue by writing a program which uses the Access object model
- rather than the replica tool, or by using the briefcase for replication.
- Microsoft Access 97 is not affected by this issue.
-
- WordPerfect
-
- If you have a WordPerfect document containing an embedded
- Corel spreadsheet and the spreadsheet contains another
- embedded object (for example, a bitmap), you may get a warning
- dialog saying youÆve lost the network connection when you close the
- innermost object. There may be four or five such warnings. All
- these warnings are benign. Just close them and continue.
-
- Multiple-threaded apartment (MTA) clients that use BSTR
- conversion routines may block DDE messages
-
- Automation BSTR conversion routines (for example, BstrFromR4)
- create hidden windows to facilitate the type conversion. These
- windows do not service the Windows message queue. If such a
- window is created from within an MTA client, DDE messages may
- be blocked. The client thread has no obligation to service the
- message queue under the MTA programming model. If it does not,
- this top-level window causes global broadcast messages to block.
-
- There are two ways to work around this situation. Either call the
- BSTR conversion routines from within a single-threaded apartment
- (STA) client, or make the clientÆs MTA thread behave like an
- STA thread. (An STA thread must service the message queue.) If
- the thread is blocking on a win32 handle, it must call the
- MsgWaitForMultipleObjects function to simultaneously dispatch
- Windows messages.
-
- DLL path names longer than 127 characters cause error
-
- If you register a DLL with a path name of 128 characters or longer,
- the registration will succeed, but CoCreateInstance or CoGetClassObject
- will return an error (REGDB_E_CLASSNOTREG) when accessing an object
- supported by this DLL.
-
- IV. Differences from DCOM on Windows NT
- ---------------------------------------
-
- Security Capabilities of DCOM95
-
- The core functionality and application programming interface (API)
- for DCOM95 are identical in both Windows 95 and Windows NT
- 4.0. However, certain capabilities related to security are different
- because of the different security infrastructures of the operating
- systems. Using the default security settings of the system is
- recommended; it is also necessary to enable "user-level" security
- on file-system shares. (See below.)
-
- The following services, which can be used to override default
- security, are available:
- * CoInitializeSecurity
- * CoQueryAuthenticationService
- * CoQueryProxyBlanket
- * CoSetProxyBlanket
- * CoQueryClientBlanket
- * IClientSecurity Interface
- * IServerSecurity Interface
-
- However, certain capabilities that are part of DCOM for Windows
- NT will not be available on Windows 95 because of differences
- in the security infrastructure on Windows 95.
-
- In particular, the lack of security functions in the Win32 API, such
- as the ability to create access control lists (ACLs), and the
- AccessCheck function, as well as the lack of a security context
- associated with thread and process tokens, should be taken into
- account. Windows 95 does not natively support these functions or
- constructs. Because of this, DCOM95 will not support impersonation
- (specifically, the CoImpersonateClient and CoRevertToSelf helper
- functions over the IServerSecurity interface), which is based on
- thread- and process-token security in Windows NT 4.0. Impersonation
- is commonly used to automatically control access to restrictable
- system resources such as the file system, other processes, and the
- network. These resources are not restrictable on Windows 95.
-
- DCOM95 does, however, offer programmers various helper objects
- to provide ACL and access-check functionality, which can be used
- to explicitly control access by remote clients to both system and
- user-defined resources or data. These helper objects are provided
- by the system object CLSID_DCOMAccessControl, which implements the
- IAccessControl interface.
-
- IAccessControl should be used to manage security permissions
- programmatically wherever portability between Windows 95 and
- Windows NT is a concern. The CLSID_DCOMAccessControl object
- is available in all releases of DCOM95 and in Windows NT 4.0
- SP2 or later. For details about IAccessControl, see the Platform
- SDK documentation.
-
- Launch and Access Security
-
- Controlling who can launch server-class code is not supported in
- DCOM95, because launching servers is not supported.
- Servers/classes must already be running in order for remote clients
- to connect to them and make use of their services.
-
- DCOM95 does support the ability to connect to already running
- classes/servers. Access security is supported via the
- \APPID\{.}\AccessPermissions registry key and adjusted via the
- DCOMCNFG tool or during installation or setup of the server code.
- Unauthenticated users will be able to use servers if you configure
- the class to support unauthenticated connections (through static
- configuration tools or dynamically via the CoInitializeSecurity
- function). You can also build arbitrary ACLs to define which users
- and groups can access specific services.
-
- Authentication Levels
-
- DCOM95 clients can make DCOM calls using any authentication
- level. DCOM95 servers or clients receiving callbacks can accept
- only DCOM calls using RPC_C_AUTHN_LEVEL_NONE or
- RPC_C_AUTHN_LEVEL_CONNECT authentication levels.
-
- Transports
-
- DCOM95 supports only TCP connectivity. If you do not have the
- TCP/IP protocol installed, DCOM95 will not be able to support
- cross-machine COM.
-
- Registry Settings
-
- The following registry keys found under
- HKEY_LOCAL_MACHINE\Software\Microsoft\OLE are established
- by DCOM95:
-
- EnableDCOM (default value = "Y"). Enables DCOM on this machine.
- When set to "N", the machine is prevented from connecting to or
- activating objects on remote machines, and remote machines are
- unable to connect to objects on the local machine. Setting this value
- to "Y" enables either connectivity as a client to remote objects
- (when EnableRemoteConnect='N', as explained below), or full
- client/server connectivity (when EnableRemoteConnect='Y', as
- explained below).
-
- EnableRemoteConnect (default value = "N"). Enables COM servers
- to support remote clients. When this value is set to "Y", references
- to interfaces on local objects can be passed to remote clients, and
- remote clients are allowed to connect to running objects. When this
- value is set to "N", this machine is allowed to connect to remote
- objects but cannot act as a server: the machine is prevented from
- connecting to running objects.
-
- In addition, the following registry key is found under
- HKEY_CLASSES_ROOT\CLSID:
-
- {bdc67890-4fc0-11d0-a805-00aa006d2ea4}\InstalledVersion.
- Contains the version number of DCOM95 in the format "a,b,c,d".
- This value can be used by Internet Component Download to
- determine whether DCOM95 is installed. This value is added to the
- registry during setup and should not be modified.
-
- Using Windows 95 as a remote server host
-
- Windows 95 can be a remote server host, with the following
- caveats:
- * There is no launch capability. The server process must be
- already running for a client to connect to it.
- * If secure connections are needed, the server (and in the case
- of callbacks, the client) must have user-level access control
- with the name of a security provider set.
- * The registry value "EnableRemoteConnect" must be set to "Y".
-
- DCOM95 has been tested most extensively using the Windows NT
- Domain security provider. You may encounter problems using other
- security providers.
-
- To establish user-level access control, you must have Filesec.vxd
- installed. This file is generally installed on Windows 95 machines
- when you install file and print sharing.
-
- To enable user-level access control, open the Network dialog box in
- Control Panel, click the Access Control tab, check the box marked
- User-level Access Control, and enter the name of your security
- domain. This may affect the way you currently share directories on
- the network from your computer; see the online documentation for
- details. If you do not have an Access Control tab in your network
- configuration control panel, you need to install a network client
- service. Click the Network clients, setting up entry in the online
- help index for information on installing a network client.
-
- V. Redistribution
- -----------------
-
- For information about redistributing DCOM95, please review the
- redistribution guidelines contained in the end-user license
- agreement (license.txt).
-
- If you elect to redistribute DCOM95, you should include the files
- DCOM95.EXE and optionally DCM95CFG.EXE on your distribution media.
- You should run these self-extracting executables from your setup
- program. These executables will install the correct files only if
- a more recent version is not already installed. They write the
- correct registry entries required by DCOM95. They do not install
- anything on Windows NT.
-
- By default, DCOM95.EXE and DCM95CFG.EXE display a EULA and other
- prompts to the user. DCOM95.EXE prompts the user to reboot the
- system on completion. If you run either executable from your setup
- program, you may elect to run the self-extracting executables in
- "silent" mode. You must prompt the user to reboot the system when
- your setup program exits if DCOM95 has been installed.
-
- To run either DCOM95.EXE or DCM95CFG.EXE in silent mode, use the command line:
- [exe-name] /r:n /q:a
-
- VI. Support & Resources
- -----------------------
-
- Paid Support
-
- DCOM95 application development is supported by Microsoft
- Technical Support. You can ask questions through your Premier
- Level support contract. You can also ask questions through your
- Priority Level contract or purchase individual Priority Support
- incidents (essentially a one-time fee for one question). If you would
- like to understand more about Microsoft's paid support options, you
- can call Microsoft Support Sales at (800) 936-3500 from 6:00 a.m.
- to 6:00 p.m. Pacific time, Monday through Friday, excluding
- holidays. Please note that technical support is not available through
- this number. Microsoft Technical Support Information is also
- available on the World Wide Web at
- http://www.microsoft.com/support/.
-
- Free Support
-
- Newsgroups are a great place for free peer support. As time and
- resources allow, Microsoft developers, program managers, support
- engineers, and test engineers visit the site to collect feedback and
- answer questions or correct misperceptions. There is no guarantee
- that you will receive a response from Microsoft to any newsgroup
- posting.
-
- The following newsgroups can be used to ask questions about
- DCOM95:
- * comp.os.ms-windows.programmer.ole
- * microsoft.public.win32.programmer.ole
-
- The DCOM mailing list is another good form of free peer support.
- An advantage to being on a mailing list is that this is where
- Microsoft will make early announcements of information on a given
- topic. Again, it is peer support, and Microsoft staff will often lurk
- there, but are not guaranteed to respond to any postings.
-
- To learn more about the DCOM mailing list, please review our
- Mailing List page,
- http://www.microsoft.com/sitebuilder/resource/mail.asp.
-
- Providing Feedback
-
- Please send any comments or bug reports to the DCOM mailing list.
-
- Resources
-
- You can find additional information about DCOM on the COM Home
- Page at http://www.microsoft.com/com/.
-
- VII. File List
- --------------------
-
- This table lists the version numbers of files distributed with
- DCOM95.
-
- asycfilt.dll 2.40.4275.1
- comcat.dll 5.0.1601.1
- compobj.dll 2.30.200.1
- dcom2w98.dll 2.10.35.35
- dllhost.exe 4.71.3328.0
- iprop.dll 4.0.1381.6
- ole2.dll 2.30.200.0
- ole32.dll 4.71.3328.0
- oleaut32.dll 2.40.4275.1
- olecnv32.dll 4.71.3328.0
- olepro32.dll 5.0.4275.1
- olethk32.dll 4.71.3328.0
- rpcltc1.dll 4.71.3328.0
- rpcltc5.dll 4.71.3328.0
- rpcltccm.dll 4.71.3328.0
- rpclts5.dll 4.71.3328.0
- rpcltscm.dll 4.71.3328.0
- rpcmqcl.dll 4.71.3328.0
- rpcmqsvr.dll 4.71.3328.0
- rpcns4.dll 4.71.3328.0
- rpcrt4.dll 4.71.3328.0
- rpcss.exe 4.71.3328.0
- secur32.dll 4.10.0.2177
- stdole2.tlb 2.40.4275.1
- stdole32.tlb 2.10.3027.1
- storage.dll 2.30.200.0
-
- This table lists the version numbers of files distributed with
- DCM95CFG.
-
- dcomcnfg.exe 5.00.1603.1
- ciscnfg.exe 4.71.2618.0
-