7,763
社区成员
发帖
与我相关
我的任务
分享请问dcom的运行环境问题？
我写了一个dcom,在nt4.0下正常，到了win98下却不成，显示没有注册，请问是98不支持dcom吗，如果支持，该如何做呢？
...全文
请发表友善的回复…
发表回复
vcshcn 2002-01-27
- 打赏
- 举报
看了半个小时，是不是可以呀，用dcomcnfig设置。
uguess 2002-01-24
- 打赏
- 举报
98下需要先安装DCOM组件！好像就在SYSTEM目录下有。
NT是内建支持的。
dbcontrols 2002-01-24
- 打赏
- 举报
HOWTO: Use DCOM Config (DCOMCNFG.EXE) with Windows 95
Last reviewed: March 10, 1998
Article ID: Q182248
The information in this article applies to:
Microsoft Visual Basic Professional and Enterprise Editions for Windows, version 5.0
SUMMARY
DCOMCNFG.EXE (known as DCOM Config) is a utility that can be used to secure distributed COM (DCOM) objects that have been created.
Because security is much more advanced on Windows NT, the options differ on Windows NT systems. This article, written for those running DCOM Config on Windows 95 systems, describes the options and settings in DCOM Config.
MORE INFORMATION
The DCOM Config's main window is divided into three tabs:
Applications Tab.
Default Properties Tab.
Default Security Tab.
The following explains each tab in DCOM Config, beginning with the Applications tab.
Applications Tab
The Applications tab shows each of the items registered under the following registry key:
HKEY_CLASSES_ROOT\AppId
Beneath this key are all of the objects that can be launched on a remote machine. DCOM Config displays just the ProgIDs (friendly names) of each object, such as "Microsoft Word Document" or "Microsoft Access Database." Some objects may register without registering a ProgID; in these cases, the GUID of the object will be displayed, such as "{4E6B942A-01B0-11D1-A9CB- 00AA00B7B36F}."
Properties for each application listed in the Applications tab can be viewed either by selecting an item and choosing the "Properties" button, or by double-clicking the application name.
Default Properties Tab
Each of the values displayed under the Default Properties tab may be found under the following key in the registry:
HKEY_LOCAL_MACHINE\Software\Microsoft\OLE
The first item in the Default Properties tab is a check box:
"Enable Distributed COM on this computer"
This is a global setting for the entire machine. When this option is checked, the machine allows the creation of DCOM objects. If it is not checked, no objects may be created via DCOM.
NOTE: You must reboot the system in order for a change in this setting to take effect.
The second part of the Default Properties tab is the Default Distributed COM Communication properties, which consists of two parts:
Default Authentication Level
Default Impersonation Level
These two options can only be modified if DCOM is enabled on this system.
Default Authentication Level
Authentication Levels are as follows:
Name Description
None No authentication.
Connect Authentication occurs when a connection
is made to the server. Connectionless
protocols do not use this.
Unlike Windows NT, Windows 95 machines can only accept calls on the 'None' or 'Connect' levels.
Default Impersonation Level
If no security is set at the object level, the server uses the security setting specified here as the default. The possible values are:
Name Description
Identify The server can impersonate the client to
check permissions in the ACL (Access Control
List) but cannot access system objects.
Impersonate The server can impersonate the client and
access system objects on the client's behalf.
The last item on the Default Properties tab is a check box:
"Provide additional security for reference tracking"
This tells the server to track connected client applications by keeping an additional reference count. Checking this box uses more memory and may slow down COM, but it ensures that a client application cannot kill a server process by artificially forcing a reference count to zero.
Default Security Tab
On Windows 95 machines, there is an option under the Default Security tab for Default Access Permission. The value displayed here may be found in the Windows registry at the following location:
HKEY_LOCAL_MACHINE\Software\Microsoft\OLE
Default Access Permission - This value determines the users who can access an object when no other access permissions are provided. For information on how to give individual access permissions to specific DCOM objects, see the "Application Properties" section later in this document.
An additional option under the Default Security tab is "Enable remote connection." This option must be selected in order to enable remote connections to DCOM Servers running on Windows 95. The value is stored as a Yes or No value in the Windows registry at the following location:
HKEY_LOCAL_MACHINE\Software\Microsoft\OLE\EnableRemoteConnect
Application Properties
You may specify custom settings for individual DCOM applications by choosing the Properties button on the "Applications" tab in DCOM Config. This section describes each tab (General, Location, and Security) and setting found within Application Properties.
General
The General tab provides general information about the application. This tab displays the Application name, type (local server or remote server), and location (local path or remote computer). These settings are not modifiable through the DCOM Config interface.
The General Tab retrieves all of its information from subkeys of the following registry key:
HKEY_CLASSES_ROOT\CLSID\{...CLSID...}
where {...CLSID...} is the unique CLSID for the Object Server currently being viewed.
Location
This tab is used to determine where DCOM will execute the application. There are three possible choices:
Run application on the computer where the data is located - If selected, DCOM will execute the application where the data is located. This is useful only if the application provides a data file for the server application.
Run application on this computer - Indicates that the DCOM application should run on the local machine.
Run application on the following computer - Allows you to specify a computer to execute on. This option should only be selected on DCOM Client machines to specify where the DCOM server is located. For DCOM Servers this option will not work as expected, Windows 95 machines cannot delegate an application to execute on a different machine
Security
On this tab, you may customize settings for individual application permissions. This tab is only available for objects capable of performing as DCOM Servers. You may customize the settings for the following permissions:
Use default access permissions.
Use custom access permissions.
With custom access permissions, you may specify individual users who may access the application. If you do not choose to use custom access permissions, the default security settings are used. For more information about the Security tab see the "Default Security" section earlier in this article.
Last reviewed: March 10, 1998
Article ID: Q182248
The information in this article applies to:
Microsoft Visual Basic Professional and Enterprise Editions for Windows, version 5.0
SUMMARY
DCOMCNFG.EXE (known as DCOM Config) is a utility that can be used to secure distributed COM (DCOM) objects that have been created.
Because security is much more advanced on Windows NT, the options differ on Windows NT systems. This article, written for those running DCOM Config on Windows 95 systems, describes the options and settings in DCOM Config.
MORE INFORMATION
The DCOM Config's main window is divided into three tabs:
Applications Tab.
Default Properties Tab.
Default Security Tab.
The following explains each tab in DCOM Config, beginning with the Applications tab.
Applications Tab
The Applications tab shows each of the items registered under the following registry key:
HKEY_CLASSES_ROOT\AppId
Beneath this key are all of the objects that can be launched on a remote machine. DCOM Config displays just the ProgIDs (friendly names) of each object, such as "Microsoft Word Document" or "Microsoft Access Database." Some objects may register without registering a ProgID; in these cases, the GUID of the object will be displayed, such as "{4E6B942A-01B0-11D1-A9CB- 00AA00B7B36F}."
Properties for each application listed in the Applications tab can be viewed either by selecting an item and choosing the "Properties" button, or by double-clicking the application name.
Default Properties Tab
Each of the values displayed under the Default Properties tab may be found under the following key in the registry:
HKEY_LOCAL_MACHINE\Software\Microsoft\OLE
The first item in the Default Properties tab is a check box:
"Enable Distributed COM on this computer"
This is a global setting for the entire machine. When this option is checked, the machine allows the creation of DCOM objects. If it is not checked, no objects may be created via DCOM.
NOTE: You must reboot the system in order for a change in this setting to take effect.
The second part of the Default Properties tab is the Default Distributed COM Communication properties, which consists of two parts:
Default Authentication Level
Default Impersonation Level
These two options can only be modified if DCOM is enabled on this system.
Default Authentication Level
Authentication Levels are as follows:
Name Description
None No authentication.
Connect Authentication occurs when a connection
is made to the server. Connectionless
protocols do not use this.
Unlike Windows NT, Windows 95 machines can only accept calls on the 'None' or 'Connect' levels.
Default Impersonation Level
If no security is set at the object level, the server uses the security setting specified here as the default. The possible values are:
Name Description
Identify The server can impersonate the client to
check permissions in the ACL (Access Control
List) but cannot access system objects.
Impersonate The server can impersonate the client and
access system objects on the client's behalf.
The last item on the Default Properties tab is a check box:
"Provide additional security for reference tracking"
This tells the server to track connected client applications by keeping an additional reference count. Checking this box uses more memory and may slow down COM, but it ensures that a client application cannot kill a server process by artificially forcing a reference count to zero.
Default Security Tab
On Windows 95 machines, there is an option under the Default Security tab for Default Access Permission. The value displayed here may be found in the Windows registry at the following location:
HKEY_LOCAL_MACHINE\Software\Microsoft\OLE
Default Access Permission - This value determines the users who can access an object when no other access permissions are provided. For information on how to give individual access permissions to specific DCOM objects, see the "Application Properties" section later in this document.
An additional option under the Default Security tab is "Enable remote connection." This option must be selected in order to enable remote connections to DCOM Servers running on Windows 95. The value is stored as a Yes or No value in the Windows registry at the following location:
HKEY_LOCAL_MACHINE\Software\Microsoft\OLE\EnableRemoteConnect
Application Properties
You may specify custom settings for individual DCOM applications by choosing the Properties button on the "Applications" tab in DCOM Config. This section describes each tab (General, Location, and Security) and setting found within Application Properties.
General
The General tab provides general information about the application. This tab displays the Application name, type (local server or remote server), and location (local path or remote computer). These settings are not modifiable through the DCOM Config interface.
The General Tab retrieves all of its information from subkeys of the following registry key:
HKEY_CLASSES_ROOT\CLSID\{...CLSID...}
where {...CLSID...} is the unique CLSID for the Object Server currently being viewed.
Location
This tab is used to determine where DCOM will execute the application. There are three possible choices:
Run application on the computer where the data is located - If selected, DCOM will execute the application where the data is located. This is useful only if the application provides a data file for the server application.
Run application on this computer - Indicates that the DCOM application should run on the local machine.
Run application on the following computer - Allows you to specify a computer to execute on. This option should only be selected on DCOM Client machines to specify where the DCOM server is located. For DCOM Servers this option will not work as expected, Windows 95 machines cannot delegate an application to execute on a different machine
Security
On this tab, you may customize settings for individual application permissions. This tab is only available for objects capable of performing as DCOM Servers. You may customize the settings for the following permissions:
Use default access permissions.
Use custom access permissions.
With custom access permissions, you may specify individual users who may access the application. If you do not choose to use custom access permissions, the default security settings are used. For more information about the Security tab see the "Default Security" section earlier in this article.
dbcontrols 2002-01-24
- 打赏
- 举报
自定义业务对象需要确保客户端能将其程序名称 (ProgId) 映射到可用于 DCOM 的标识符 (CLSID)。为此 DCOM 对象的 ProgID 必须位于客户端注册表并映射到服务器端业务对象的类标识码。不过，这对于所支持的其他协议（HTTP、HTTPS 以及进程内）则没有必要。
例如，如果要显示具有特定类标识码的名为 MyBObj 的服务器端业务对象如“{00112233-4455-6677-8899-00AABBCCDDEE}”，就需要确认以下条目已经添加到了客户端注册表：
[HKEY_CLASSES_ROOT]
\MyBObj
\Clsid
(Default) "{00112233-4455-6677-8899-00AABBCCDDEE}"
How To Configure a Non-DCOM Server and Client to Use DCOM
Last reviewed: November 6, 1996
Article ID: Q158582
The information in this article applies to:
Microsoft COM/DCOM libraries included with: Microsoft Windows NT 4.0 Microsoft Windows 95 with DCOM support
SUMMARY
COM server and client applications that were written before the introduction of DCOM can be configured to use DCOM by making appropriate changes to the server application's registry entries. The server and client applications do not need to be rewritten. This procedure can be applied to any COM server and client, including those created using MFC or Visual Basic.
MORE INFORMATION
The registry entries can be changed using the DCOMCNFG.EXE tool, the OLE Viewer tool, or manually.
Before making the changes, register the server application in the registry of the client machine and server machine. This may involve running the server application's setup program or running the server application and shutting it down on both machines. The server application does not need to reside on the client machine. If the server uses custom interfaces, the marshaling code must be installed on the client and server machines. Automation servers that support vtbl-binding must install their type libraries on the client and server machines. Automation servers that do not support vtbl-binding do not need to install their type libraries on the client machine.
After the registry changes have been made, run the client application on the client machine. DCOM will look at the server application registry entries on the client machine and will determine the name of the server machine. It will then connect to the server machine, determine the location of the server application from the registry entries on the server machine, and launch the server application on that machine.
Note that DCOM is not supported for 16-bit applications. Also, see the last section of this article for special instructions for DCOM on Windows 95.
Changing the Registry Using DCOMCNFG
Launch the DCOMCNFG.EXE graphical utility (found in the Windows NT system32 directory) on the client machine. It will list all the registered servers. If you do not see the name of your server, it is probably listed by CLSID. (This is true for many Visual Basic servers because they do not put a name string as the default value of their CLSID key.) To determine the CLSID of your server, run the registry editor (regedit.exe). Open the HKEY_CLASSES_ROOT folder. All the ProgIDs (for example, 'MyServer.MyClass') of the registered servers will be listed in the left pane. Select the ProgID key of your server and open it. Then select the CLSID sub-key and open it. The CLSID value will be listed in the right pane.
If your server is listed by its CLSID and if you would like DCOMCNFG to list the name of the server instead, open the registry editor (after closing DCOMCNFG) and go down the list in the left pane until you reach the CLSID key. Open the CLSID key and find and open your server's CLSID. At the top of the right pane is a value preceded by "(Default)." Double- click on this prefix; a string editor will pop up. Enter the name of your server in this string editor and close the registry editor. Now when DCOMCNFG is run, it will list your server by name instead of CLSID. Do this on the server machine and the client machine.
Run DCOMCNFG on the client machine, select your server (by name or by CLSID) and select the Properties button. This will bring up a Properties dialog. Select the Location tab. Then select the "Run application on the following computer" checkbox and specify the name of the server machine. Clear the other checkboxes, and then press the Apply button.
Run DCOMCNFG on the server machine, select your server, and select the Properties dialog. Select the Security tab. You can choose to apply the default access and launch permissions to the server or you can choose to apply custom permissions. The default permissions can be changed using the Default Security tab in DCOMCNFG. Make sure that SYSTEM is in the Launch and Access permissions, and then add the account of the user on the client machine to the Launch and Access permissions. Press the Apply button. You are now ready to access the server from the client.
Changing the Registry Using the OLE Viewer Tool
Get the latest version of the OLE Viewer tool from http://www.microsoft.com/oledev/olecom/oleview.htm on the World Wide Web.
Run the OLE Viewer tool on the client machine and select the View/ExpertMode menu. Double-click "All Objects" in the left pane and select your server. Select the "Implementation" tab in the right pane, select the LocalServer sub-tab. and clear the location of the server. Select the "Activation" tab and specify the name of the server machine. Close the OLE Viewer tool.
Run the OLE Viewer tool on the server machine and select the View/ExpertMode menu. Double-click "All Objects" in the left pane and select your server. Use the LaunchPermissions and AccessPermissions tabs in the right pane to set permissions for the server. You can choose to apply the default access and launch permissions or you can choose to apply custom permissions. The default permissions can be changed using the File/SystemConfiguration menu. Make sure that SYSTEM is in the Launch and Access permissions, and then add the account of the user on the client machine to the Launch and Access permissions. You are now ready to access the server from the client.
Changing the Registry Manually
You can also make many of these modifications manually instead of using the DCOMCNFG tool, as follows:
Using the registry editor, modify the server application's registry entries on the client and the server machines. The following registration information uses the REGEDIT4 syntax where the key is specified in square brackets. The line after each key specifies a name and a value. The name is on the left of '=' and the value on the right.
'@' on the left indicates a value without a name. Replace the following
GUIDs with your GUIDs. You can generate a new GUID for AppID (using
uuidgen.exe), or use the same GUID as the CLSID. Replace hello.exe with
your server's EXE name and replace 'Hello App' with a string that
describes your server application:
REGEDIT4
;;;; CLSID key
[HKEY_CLASSES_ROOT\CLSID\{0bf52b11-8cab-11cf-8572-00aa00c006cf}]
"AppID"="{0bf52b15-8cab-11cf-8572-00aa00c006cf}"
;;;; AppID key
[HKEY_CLASSES_ROOT\APPID\{0bf52b15-8cab-11cf-8572-00aa00c006cf}]
@="Hello App"
[HKEY_CLASSES_ROOT\APPID\hello.exe]
"APPID"="{0bf52b15-8cab-11cf-8572-00aa00c006cf}"
Remove any InprocServer32 and LocalServer32 keys from the server application's registry entries on the client machine. (These should not be removed on the server machine where the server application resides.) Add the following key to the server's registry entries on the client machine. Use the same GUID for the AppID as in the previous step. Replace server_machine_name with the name of the machine on which the server is located:
[HKEY_CLASSES_ROOT\APPID\{0bf52b15-8cab-11cf-8572-00aa00c006cf}] "RemoteServerName"="server_machine_name"
On the server machine, use DCOMCNFG or the OLE View tool to specify access and launch permissions for the server application. See the sections in this article that describe these tools for more information about how to specify permissions.
DCOM on Windows 95
DCOM for Windows 95 is in Beta at the time this article is being written. At this time, DCOMCNFG is not available for Windows 95 and the registry changes will have to made either by using the OLE Viewer tool or manually.
On Windows 95 with DCOM, there is an additional registry setting that enables or disables incoming calls:
[HKEY_LOCAL_MACHINE\Software\Microsoft\OLE]
"EnableRemoteConnections"="N"
By default, the EnableRemoteConnections named value is set to "N" and incoming calls are disabled. To enable incoming calls, change this to "Y." The OLE Viewer tool can be used to change this using its File/SystemConfiguration menu. Note that this affects server applications that run on Windows 95 machines and that it does not affect client applications on these machines.
It is not possible to launch a process on a Windows 95 machine securely from a client machine because all processes in Windows 95 run in the security context of the currently logged-on user. Therefore, DCOM on Windows 95 does not support remote activation. A server application on a Windows 95 machine will have to be launched manually or by some other mechanism to be accessed by a client application on another machine. Consequently, the DefaultLaunchPermissions and LaunchPermissions registry values have no affect on Windows 95.
例如，如果要显示具有特定类标识码的名为 MyBObj 的服务器端业务对象如“{00112233-4455-6677-8899-00AABBCCDDEE}”，就需要确认以下条目已经添加到了客户端注册表：
[HKEY_CLASSES_ROOT]
\MyBObj
\Clsid
(Default) "{00112233-4455-6677-8899-00AABBCCDDEE}"
How To Configure a Non-DCOM Server and Client to Use DCOM
Last reviewed: November 6, 1996
Article ID: Q158582
The information in this article applies to:
Microsoft COM/DCOM libraries included with: Microsoft Windows NT 4.0 Microsoft Windows 95 with DCOM support
SUMMARY
COM server and client applications that were written before the introduction of DCOM can be configured to use DCOM by making appropriate changes to the server application's registry entries. The server and client applications do not need to be rewritten. This procedure can be applied to any COM server and client, including those created using MFC or Visual Basic.
MORE INFORMATION
The registry entries can be changed using the DCOMCNFG.EXE tool, the OLE Viewer tool, or manually.
Before making the changes, register the server application in the registry of the client machine and server machine. This may involve running the server application's setup program or running the server application and shutting it down on both machines. The server application does not need to reside on the client machine. If the server uses custom interfaces, the marshaling code must be installed on the client and server machines. Automation servers that support vtbl-binding must install their type libraries on the client and server machines. Automation servers that do not support vtbl-binding do not need to install their type libraries on the client machine.
After the registry changes have been made, run the client application on the client machine. DCOM will look at the server application registry entries on the client machine and will determine the name of the server machine. It will then connect to the server machine, determine the location of the server application from the registry entries on the server machine, and launch the server application on that machine.
Note that DCOM is not supported for 16-bit applications. Also, see the last section of this article for special instructions for DCOM on Windows 95.
Changing the Registry Using DCOMCNFG
Launch the DCOMCNFG.EXE graphical utility (found in the Windows NT system32 directory) on the client machine. It will list all the registered servers. If you do not see the name of your server, it is probably listed by CLSID. (This is true for many Visual Basic servers because they do not put a name string as the default value of their CLSID key.) To determine the CLSID of your server, run the registry editor (regedit.exe). Open the HKEY_CLASSES_ROOT folder. All the ProgIDs (for example, 'MyServer.MyClass') of the registered servers will be listed in the left pane. Select the ProgID key of your server and open it. Then select the CLSID sub-key and open it. The CLSID value will be listed in the right pane.
If your server is listed by its CLSID and if you would like DCOMCNFG to list the name of the server instead, open the registry editor (after closing DCOMCNFG) and go down the list in the left pane until you reach the CLSID key. Open the CLSID key and find and open your server's CLSID. At the top of the right pane is a value preceded by "(Default)." Double- click on this prefix; a string editor will pop up. Enter the name of your server in this string editor and close the registry editor. Now when DCOMCNFG is run, it will list your server by name instead of CLSID. Do this on the server machine and the client machine.
Run DCOMCNFG on the client machine, select your server (by name or by CLSID) and select the Properties button. This will bring up a Properties dialog. Select the Location tab. Then select the "Run application on the following computer" checkbox and specify the name of the server machine. Clear the other checkboxes, and then press the Apply button.
Run DCOMCNFG on the server machine, select your server, and select the Properties dialog. Select the Security tab. You can choose to apply the default access and launch permissions to the server or you can choose to apply custom permissions. The default permissions can be changed using the Default Security tab in DCOMCNFG. Make sure that SYSTEM is in the Launch and Access permissions, and then add the account of the user on the client machine to the Launch and Access permissions. Press the Apply button. You are now ready to access the server from the client.
Changing the Registry Using the OLE Viewer Tool
Get the latest version of the OLE Viewer tool from http://www.microsoft.com/oledev/olecom/oleview.htm on the World Wide Web.
Run the OLE Viewer tool on the client machine and select the View/ExpertMode menu. Double-click "All Objects" in the left pane and select your server. Select the "Implementation" tab in the right pane, select the LocalServer sub-tab. and clear the location of the server. Select the "Activation" tab and specify the name of the server machine. Close the OLE Viewer tool.
Run the OLE Viewer tool on the server machine and select the View/ExpertMode menu. Double-click "All Objects" in the left pane and select your server. Use the LaunchPermissions and AccessPermissions tabs in the right pane to set permissions for the server. You can choose to apply the default access and launch permissions or you can choose to apply custom permissions. The default permissions can be changed using the File/SystemConfiguration menu. Make sure that SYSTEM is in the Launch and Access permissions, and then add the account of the user on the client machine to the Launch and Access permissions. You are now ready to access the server from the client.
Changing the Registry Manually
You can also make many of these modifications manually instead of using the DCOMCNFG tool, as follows:
Using the registry editor, modify the server application's registry entries on the client and the server machines. The following registration information uses the REGEDIT4 syntax where the key is specified in square brackets. The line after each key specifies a name and a value. The name is on the left of '=' and the value on the right.
'@' on the left indicates a value without a name. Replace the following
GUIDs with your GUIDs. You can generate a new GUID for AppID (using
uuidgen.exe), or use the same GUID as the CLSID. Replace hello.exe with
your server's EXE name and replace 'Hello App' with a string that
describes your server application:
REGEDIT4
;;;; CLSID key
[HKEY_CLASSES_ROOT\CLSID\{0bf52b11-8cab-11cf-8572-00aa00c006cf}]
"AppID"="{0bf52b15-8cab-11cf-8572-00aa00c006cf}"
;;;; AppID key
[HKEY_CLASSES_ROOT\APPID\{0bf52b15-8cab-11cf-8572-00aa00c006cf}]
@="Hello App"
[HKEY_CLASSES_ROOT\APPID\hello.exe]
"APPID"="{0bf52b15-8cab-11cf-8572-00aa00c006cf}"
Remove any InprocServer32 and LocalServer32 keys from the server application's registry entries on the client machine. (These should not be removed on the server machine where the server application resides.) Add the following key to the server's registry entries on the client machine. Use the same GUID for the AppID as in the previous step. Replace server_machine_name with the name of the machine on which the server is located:
[HKEY_CLASSES_ROOT\APPID\{0bf52b15-8cab-11cf-8572-00aa00c006cf}] "RemoteServerName"="server_machine_name"
On the server machine, use DCOMCNFG or the OLE View tool to specify access and launch permissions for the server application. See the sections in this article that describe these tools for more information about how to specify permissions.
DCOM on Windows 95
DCOM for Windows 95 is in Beta at the time this article is being written. At this time, DCOMCNFG is not available for Windows 95 and the registry changes will have to made either by using the OLE Viewer tool or manually.
On Windows 95 with DCOM, there is an additional registry setting that enables or disables incoming calls:
[HKEY_LOCAL_MACHINE\Software\Microsoft\OLE]
"EnableRemoteConnections"="N"
By default, the EnableRemoteConnections named value is set to "N" and incoming calls are disabled. To enable incoming calls, change this to "Y." The OLE Viewer tool can be used to change this using its File/SystemConfiguration menu. Note that this affects server applications that run on Windows 95 machines and that it does not affect client applications on these machines.
It is not possible to launch a process on a Windows 95 machine securely from a client machine because all processes in Windows 95 run in the security context of the currently logged-on user. Therefore, DCOM on Windows 95 does not support remote activation. A server application on a Windows 95 machine will have to be launched manually or by some other mechanism to be accessed by a client application on another machine. Consequently, the DefaultLaunchPermissions and LaunchPermissions registry values have no affect on Windows 95.
