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 >
Wrap
Text File
|
1998-07-02
|
32KB
|
790 lines
DCOM95 1.2
Release Notes
Last Modified: June 25, 1998
DCOM95 1.2 extends support for DCOM for Microsoft« Windows« 95.
The following instructions, guidelines, and features are new to
this release of COM and OLE for 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. Installation Notes
A. Downloading and Extracting DCOM95
B. International Version
C. Before You Install DCOM95
D. Uninstalling DCOM95
II. Release Notes
A. What's New in DCOM95 1.2
B. Bug Fixes in DCOM95 1.2
C. Known Issues
D. DCOM95 File List
III. Developer Notes
A. What's New in DCOM95 1.2
B. Bug Fixes in DCOM95 1.2 Affecting Developers
C. Known Issues Affecting Developers
D. Differences from DCOM on Windows NT
E. Redistributing DCOM95 1.2
F. Support & Resources
I. Installation Notes
A. Downloading and Extracting DCOM95
If you have downloaded this release of DCOM95 from a Web site,
you should read the release notes completely before you extract
and install DCOM95.
You do not need DCOM95 on Windows NT« or Windows 98 because DCOM
functionality has been implemented into the operating systems.
For DCOM bug fixes on Windows NT and Windows 98, you have to install
latest service packs of the corresponding operating system.
After downloading DCOM95, you will have one or two compressed
executable files on your hard drive:
* Dcom95.exe contains the COM system DLLs.
* Dcm95cfg.exe contains the DCOM Configuration utility.
To extract either file and begin the installation process, type the file
name at the Command Prompt or double-click the file in the
Windows Explorer. After running DCOM95.EXE, you will be
prompted to restart your computer to complete the installation. Your
existing OLE and COM system components will be saved so you
can uninstall DCOM95, if necessary.
If you run DCOM95 programs on any version of Windows NT or Windows 98,
no system components will be overwritten.
B. International Version
DCOM95 can be installed on any localized version of Windows 95.
DCOM95 does not include the OLE Common Dialogs (OLEDLG.DLL),
which is the only portion of DCOM95 requiring localization.
Note
The end-user license agreement (EULA), release notes, and setup
prompts have not been localized. When you run DCOM95.EXE on
a localized version of Windows, standard Windows buttons will be
localized, but the remaining prompts will not. In addition, the DCOM
Configuration utility, DCOMCNFG, is provided only in English in this
web release. The program will work correctly on localized versions
of Windows 95, but the instructions will only appear in English.
C. Before You Install DCOM95
The DCOM95 installation program updates your system DLLs. You
should save all open documents and close all programs before
installing DCOM95.
D. Uninstalling DCOM95
Use caution when uninstalling DCOM95: other applications may
depend on the functionality it provides. To make it less likely that
DCOM95 would be removed inadvertently, the DCOM entry has
been removed from the Add/Remove Programs dialog box in
Control Panel. However, you can uninstall DCOM95 from the
Command Prompt window.
If you are certain that you want to uninstall DCOM95, enter the
following in the Command Prompt window:
cd \windows\system\dcom95\oldole
uninstall
Follow the instructions on the screen. You will have to restart your
computer to complete the uninstall. Upon completion, the
uninstalled files are not deleted automatically, but you can safely
delete them if you choose to.
If a version of Microsoft Internet Explorer that depends on DCOM is
installed on a computer that is running Windows 95, you must
uninstall Internet Explorer before you can uninstall DCOM.
II. Release Notes
A. What's New in DCOM95 1.2
This section lists the major new features of DCOM95 1.2 that are visible
to end users and administrators. Additional features for developers
are described in the Developer Notes below.
Replacing DCOM95 1.2 with older version prohibited
In previous releases of DCOM95, you could replace a newer
version of DCOM95 with an older version of DCOM95. DCOM95 1.2
now checks version numbers on installation, and you are not
permitted to install an older version over a newer version. This
change will avoid problems with incompatible versions of DLLs.
Visual Studio 6.0 process monitoring support
In support of Visual Studio 6.0, DCOM95 1.2 provides monitoring
information for developers to help them understand the behavior,
performance, and structure of their application. If you are using
Visual Studio Analyzer on a computer that is running Windows 95,
you should always use DCOM95 1.2.
New directory created by setup
Setup creates a directory called DCOM95 under your system
directory. The end-user license agreement and other files are
stored there. Setup also creates a subdirectory of DCOM95 called
OLDOLE, into which the old DCOM95 or OLE binaries are backed
up. These files are restored if you later uninstall DCOM95 1.2.
COM Internet Services
The COM Internet Services (CIS) enable clients and servers to be
connected over the Internet using COM. CIS consists of
* A new DCOM protocol, Tunneled TCP
* A new moniker type, OBJREF moniker
* A new CISCNFG utility
For CIS client support in Windows 95, you must install both DCOM95
and DCOM95CFG as described in the Installation Notes section above.
Then use the CISCNFG tool, which is installed when you install the
DCOM configuration utility, to change the registry key that defines
which protocol to use for remote processes. In the Command Prompt
window, enter:
ciscnfg <protocol>
Where <protocol> is:
* rpc to use RPC
* http to use HTTP
* tcp_http to try TCP first and then, if the server times out,
to try HTTP.
The ciscnfg command with no argument provides usage
information.
No SDK updates are required to use the Tunneled TCP protocol.
There are a few updates for OBJREF monikers.
CreateObjrefMoniker
Creates an OBJREF moniker based on a pointer to an object.
WINOLEAPI CreateObjrefMoniker(
LPUNKNOWN pUnk, //Pointer to the object
LPMONIKER *ppMk //Address of pointer to OBJREF moniker
);
Parameters
pUnk
Pointer to the IUnknown interface on the object that the moniker
is to represent.
ppMk
Address of a pointer to the IMoniker interface on the OBJREF
moniker created.
Return Values
This function supports the standard return values
E_OUTOFMEMORY and E_UNEXPECTED, as well as the
following:
S_OK
The OBJREF moniker was successfully created.
Remarks
Clients use OBJREF monikers to obtain a marshaled pointer to a
running object in the serverÆs address space.
The server typically calls CreateObjrefMoniker to create an
OBJREF moniker and then calls IMoniker::GetDisplayName, and
finally releases the moniker. The display name for an OBJREF
moniker is of the form:
OBJREF:nnnnnnnn
Where nnnnnnnn is an arbitrarily long base-64 encoding that
encapsulates the machine location, process endpoint, and interface
pointer ID (IPID) of the running object.
The display name can then be transferred to the client as text. For
example, the display name can reside on an HTML page that the
client downloads.
The client can pass the display name to MkParseDisplayName,
which creates an OBJREF moniker based on the display name. A
call to the monikerÆs IMoniker::BindToObject method then obtains
a marshaled pointer to the running instance on the server.
For example, a server-side COM component contained in an active
server page can create an OBJREF moniker, obtain its display
name, and write the display name to the HTML output that is sent to
the client browser. A script that runs on the client side can use the
display name to get access to the running object itself. A client-side
Visual Basic script, for instance, could store the display name in a
variable called strMyName and include this line:
objMyInstance = GetObject(strMyName)
The script engine internally makes the calls to
MkParseDisplayName and IMoniker::BindToObject, and the
script can then use objMyInstance to refer directly to the running
object.
If the running object uses static IPIDs and the server process
always runs on the same computer at a well-known endpoint, the
display name of the OBJREF moniker will always be the same. In
that case, the server can store the display name instead of
calculating it each time it receives a request for the object.
IMoniker - OBJREF Moniker Implementation
OBJREF monikers represent a reference to an object instance that
is running on an out-of-process server, either locally or remotely.
The moniker identifies the object instance and the computer the
object is running on.
An OBJREF moniker is similar in many ways to a pointer moniker,
except that the running object is out-of-process. A client can call
IMoniker::BindToObject on an OBJREF moniker and use the
pointer it obtains to access the running object, regardless of its
location.
An important distinction from a pointer moniker is that the display
name of an OBJREF moniker can be embedded in an HTML page,
and the running object represented by the moniker can be bound by
a client script, applet, or ActiveX control.
When to Use
The primary use for an OBJREF moniker is to obtain access to a
running object instance over the Internet. An active server page or
some other means of generating dynamic HTML content places the
display name of an OBJREF moniker in a parameter to an applet or
an ActiveX control. The code of the applet or control calls
CreateObjrefMoniker to create an OBJREF moniker based on the
display name, and it then calls IMoniker::BindToObject on the
resulting OBJREF moniker to get access to the running object
instance. The active server page then marshals a pointer to the
running object back to the pageÆs client.
Remarks
IMoniker::BindToObject. For OBJREF monikers, the pmkToLeft
parameter must be NULL. Because the OBJREF moniker
represents a running object, no activation takes place. If the
represented object is no longer running, BindToObject fails with
E_UNEXPECTED.
IMoniker::BindToStorage. This method obtains a marshaled
pointer to the requested interface on the storage that contains the
running object. Because the OBJREF moniker represents a running
object, no activation takes place. If the represented object is no
longer running, BindToStorage fails with E_UNEXPECTED.
IMoniker::Reduce. This method returns
MK_S_REDUCED_TO_SELF and passes back the same moniker.
IMoniker::ComposeWith. If pmkRight is an anti-moniker, the
returned moniker is NULL. If pmkRight is a composite whose
leftmost component is an anti-moniker, the returned moniker is the
composite with the leftmost anti-moniker removed. If pmkRight is
neither an anti-moniker nor a composite moniker whose leftmost
component is an anti-moniker, then the method checks the
fOnlyIfNotGeneric parameter. If it is FALSE, the method combines
the two monikers into a generic composite; if it is TRUE, the method
sets *ppmkComposite to NULL and returns
MK_E_NEEDGENERIC.
IMoniker::Enum. This method returns S_OK and sets
ppenumMoniker to NULL.
IMoniker::IsEqual. This method returns S_OK if *pmkOther is an
OBJREF moniker and the paths for both monikers are identical
(using a case-insensitive comparison). Otherwise, the method
returns S_FALSE.
IMoniker::Hash. This method calculates a hash value for the
moniker.
IMoniker::IsRunning. Because OBJREF monikers represent a
running object instance, this method returns TRUE unless the
object is known to be no longer running because a recent call failed.
The method ignores pmkToLeft.
IMoniker::GetTimeOfLastChange. This method returns
E_NOTIMPL.
IMoniker::Inverse. This method returns an anti-moniker (i.e., the
results of calling CreateAntiMoniker).
IMoniker::CommonPrefixWith. If the two monikers are equal, this
method returns MK_S_US and sets *ppmkPrefix to NULL. If the
other moniker is not an OBJREF moniker, this method passes both
monikers to the MonikerCommonPrefixWith function. This
function correctly handles the case where the other moniker is a
generic composite.
If there is no common prefix, this method returns MK_E_.
IMoniker::RelativePathTo. This method returns E_NOTIMPL.
IMoniker::GetDisplayName. This method obtains the display
name for the OBJREF moniker. The display name is a 64-bit
encoding that encapsulates the machine location, process endpoint,
and interface pointer ID (IPID) of the running object. For future
compatibility, the display name is restricted to characters that can
be specified as part of a URL.
IMoniker::ParseDisplayName. If pmkToLeft is not NULL, this
method returns MK_E_SYNTAX.
IMoniker::IsSystemMoniker. This method returns S_OK and
passes back MKSYS_OBJREFMONIKER.
B. Bug Fixes in DCOM95 1.2
This section describes bugs fixed in DCOM95 1.2 that affected
applications running on Windows 95 with DCOM95 1.1 installed.
Additional bug fixes are described in the Developer Notes section
below.
Race condition when unloading multiple modules
When multiple modules were unloaded simultaneously, a race
condition would occur in DCOM95 v1.1. Depending upon the order
in which the modules were unloaded, an access violation could
result. This has been corrected in DCOM95 1.2.
Desktop unresponsive during RPC protocol negotiations
DCOM95 1.1 did not dispatch messages while it was negotiating RPC
protocols. In certain cases, if the user launched another application
during the time that RPC protocols were being negotiated, the
machine would appear to be unresponsive. After 30 seconds,
processing of messages would resume. This behavior has been
changed in DCOM95 1.2, and applications can be launched while RPC
protocols are being negotiated.
Desktop unresponsive when new application launched
RPC creates a hidden window in the Multiple-Threaded Apartment (MTA),
which is not required to dispatch messages per DCOM spec.
When a user launches a new application from the desktop,
Windows sends a message to all other window handles, notifying
them of this event, and expecting a reply. Under DCOM95 1.1, the
hidden RPC window might not reply, and Windows would hang. DCOM95
1.2 fixes this problem, and the RPC window no longer makes the
desktop unresponsive when new applications are launched.
Multiple IP addresses heap corruption
In certain situations, if you were running DCOM95 1.1 on a
machine with more than one IP address, the IP address buffer
would be overrun and the heap would be corrupted. This has been
fixed in DCOM95 1.2.
Only first IP address used
If you were running DCOM95 1.1 on a machine that had two
network adapter cards (and therefore two IP addresses, each
assigned to a different address card), DCOM95 1.1 would use only
one network adapter. In DCOM95 1.2, if the first one tried does not
work, the second one will be used.
RPC now tries multiple IP addresses
When doing a remote procedure call to a machine with multiple IP
addresses, subsequent IP addresses will now be tried if connecting
to the first one fails.
C. Known Issues
This section describes known problems in DCOM95 1.2 that affect
applications running on Windows 95 with DCOM95 1.2 installed.
Additional issues are described in the Developer Notes section
below.
Corel WordPerfect Suite 7: Installation Causes Invalid Page Fault
If you install Corel WordPerfect Suite 7 on a Windows 95 system
running DCOM95 1.2, 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 1.2 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.
D. DCOM95 File List
This table lists the version numbers of files distributed with
DCOM95 1.2.
oleaut32.dll 2.30.4261
secur32.dll 4.10.1999
compobj.dll 2.3.1
ole2.dll 2.3.1
ole32.dll 4.71.2618
olecnv32.dll 4.71.2618
olethk32.dll 4.71.2618
rpcltc1.dll 4.71.2618
rpcltc5.dll 4.71.2618
rpcltccm.dll 4.71.2618
rpclts5.dll 4.71.2618
rpcltscm.dll 4.71.2618
rpcns4.dll 4.71.2618
rpcrt4.dll 4.71.2618
rpcss.exe 4.71.2618
storage.dll 2.3.1
stdole2.tlb 2.30.4261
stdole32.tlb 2.1
imagehlp.dll 4.00
dllhost.exe 4.71.2618
comcat.dll 5.0
iprop.dll 4.00
rpcmqcl.dll 4.71.2618
rpcmqsvr.dll 4.71.2618
olepro32.dll 5.0.4261
asycfilt.dll 2.30.4261
dcom2w98.dll 2.1
This table lists the version numbers of files distributed with
DCM95CFG.
mfc40.dll 4.1.6139
msvcrt40.dll 4.21.0000
dcomcnfg.exe 5.00.1601.0
ciscnfg.exe 4.71.2618
III. Developer Notes
A. What's New in DCOM95 1.2
Support for VB6.0 data types
Visual Basic« 6.0 allows Visual Basic variants to contain user-
defined data structures. DCOM95 1.2 supports remoting of these
variants.
B. Bug Fixes in DCOM95 1.2 Affecting Developers
This section lists additional bug fixes in DCOM95 1.2. These fixes
are not likely to affect end-users, but developers or testers might
encounter them.
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 DCOM95 1.1, 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 DCOM95 1.2.
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 DCOM95 1.2.
ADO servers shut down properly
Active Data Objects (ADOs) use pointer monikers to start a server
process. DCOM95 1.1 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 DCOM95 1.2.
CoCreateInstance works with own DNS name
In DCOM95 1.1, calling CoCreateInstance with the fully qualified
name of the local machine did not work. This has been fixed in
DCOM95 1.2, and CoCreateInstance now correctly creates an
instance on the local machine.
C. Known Issues Affecting Developers
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 behaves 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.
D. Differences from DCOM on Windows NT
Security Capabilities of DCOM95 1.2
The core functionality and application programming interface (API)
for DCOM95 1.2 are identical in both Windows 95 and Windows NT
4.0/5.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 do not natively support these functions or
constructs. Because of this, DCOM95 1.2 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 1.2 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/98 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 1.2, 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 1.2 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 1.2 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 1.2:
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.
E. Redistributing DCOM95 1.2
If you depend on DCOM951.2 functionality, you have two options:
redistribute the updated system files (DCOM95) with your
application, or direct users to the DCOM95 release on the Microsoft
Web site. If your application will be downloaded from the web, you
should direct users to the Microsoft Web site. DCOM95 is fairly
large, and many users may already have it.
For further information about redistributing DCOM95, please review
the redistribution guidelines contained in the end-user license
agreement (license.txt).
F. 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/.