This document covers the following topics:
The distribution kit for EntireX DCOM contains a variety of examples for demonstrating product functionality. The examples for UNIX are in the UNIX kit; the same sources but with Windows makefiles and MSDEV Workspaces/Projects are in the Windows Installation.
EntireX DCOM delivers a basic set of advanced Distributed COM features on UNIX, Midrange and Mainframe systems.
We have created two classes of samples for EntireX DCOM. This is to give you the possibility to verify your installation and to give you a head start on DCOM.
The basic RPC example is mainly to verify the installation process for the RPC runtime piece of EntireX DCOM. It is a simple application that is interoperable with an example as shipped by Microsoft with the WIN32 SDK on Windows.
The DCOM examples cover some features (both basic ones and more sophisticated types) of the distributed object mechanisms as provided by EntireX DCOM. In addition there are pre-built images for Windows (Intel) of a particular sample that can be used to verify the installation of the DCOM piece of this kit. Review the detailed instructions and learn how to run the verification and interoperability test.
These samples work both locally with the EntireX DCOM implementation as provided by Software AG and remotely with DCOM on Windows. In addition, the forthcoming versions of EntireX DCOM on various platforms will be interoperable with these samples.
Note:
These samples are provided to you "as is" and without
warranty of any kind, expressed or implied, including but not limited to,
warranties of performance, merchantability, or fitness for a particular
purpose. User bears all risk as to the quality and performance of the software
and as such neither the author, nor Software AG shall be held liable for any
loss of data, down time, loss of revenue or any other direct or indirect damage
or claims caused by these programs.
There is a whole series of distributed object applications delivered with Software AG's EntireX DCOM. We have tried to cover all of the major aspects of DCOM that are supported by EntireX DCOM. However, the set of applications is far from being complete in the sense that we show how to use all of the features of EntireX DCOM. The idea is to provide a framework of applications that demonstrate the use of DCOM and that can be used to write your own applications. We recommend that you build and run the applications and browse the sources in addition to get a better understanding of DCOM in general and of EntireX DCOM in particular.
Some of the samples are UNIX ports of DCOM applications that are available from Microsoft's COM and DCOM developer page. Others are new and have been written without an existing Windows source. We provide samples that operate locally only, as well as applications that use DCOM to communicate over the network. Use of C and C++ is demonstrated as well as interoperability with Visual Basic applications. Most of the samples can be compiled and built on Windows as well, but it is not the intent of these applications to demonstrate portability of DCOM source code across various platforms. This distribution contains source code that is customized to support EntireX DCOM from Software AG.
Check the EntireX DCOM documentation for details and review the Microsoft documentation to get information on how to migrate the samples to Windows and how to write native DCOM applications for Windows. The sample source code contains the necessary files that are required to build the application with the exception of the public header files that come with EntireX DCOM. You should be able to build these applications on all target platforms. Take a look at the sources and at the makefiles for the various platforms for detailed information.
In general the EntireX DCOM samples share a common structure.
The RPC HELLO program is a client/server implementation of the classic "Hello, world" program. It is mainly used to verify the installation process.
It is a simple application that is interoperable with an example as shipped by Microsoft with the WIN32 SDK and with the Visual C++ compiler. Check out the documentation within the WIN32 SDK for more information on how to build this application on Windows.
The port contains the necessary files that are required to build the application with the exception of the public header files that come with EntireX DCOM. The application that can be built here should be interoperable with the one that comes with the Microsoft SDK (see above). You can build both the hello and the whello (a wide-character version of hello).
This example application can be used to:
verify the installation of the basic RPC as part of EntireX DCOM. If the installation is correct, the application will build with the makefile provided with the sample.
verify the proper configuration and operation of the basic RPC as an IPC mechanism on the local machine. The basic RPC is operational if both client and server are successfully started on the local machine and the server is able to present the information sent by the client.
verify the proper configuration and operation of the basic RPC as transport mechanism for DCOM between different machines. The basic RPC is operational if both client and server are successfully started on different machines and the server is able to present the information sent by the client.
verify the security settings (either local or domain-controller authentication).
To build the UNIX application - and to verify the installation - it is sufficient to do the following:
Use the make utility (see the documentation or man pages e.g. man make). Make should start the MIDL (Microsoft Interface Definition Language) compiler, which in turn generates C sources and a header file. The next step of the make process is to generate a client (helloc) and a server (hellos) application for testing.
Although this very basic example only uses plain Microsoft RPC, it
also requires correct security settings which are applicable to both DCOM and
Microsoft RPC. If you are using local authentication (paulad -local), make sure
that the user who starts the example program has an entry in the
$EXXDIR/$EXXVERS/etc/ntpasswd.txt file (use ntpasswd
uid to add an entry). If you are using domain
controller authentication (paulad -rpc) the user must have a valid, enabled
account on the domain controller (see EntireX DCOM Security for
information on how to set this up).
Then run the RPC tests locally on the UNIX machine. First enter hellos to start the server process. Hellos will register with the RPC runtime component of EntireX DCOM and wait for a client application to request a service. Then (in a different terminal window) enter helloc to activate the client application. Helloc tries to get in contact with hellos and then activates the advertised service. Both hellos and helloc will print some information on their state to standard output (usually the controlling terminal), so you can follow the client/server interaction.
Running hellos or helloc against a remote (Windows) partner requires
additional command-line arguments. Try the -help
command-line switch for exact names.
If you want to generate the wide-character version, you have to edit the makefiles and enable the compiler flag TEST_WCS.
The SIMPLE_C sample is a C version of the SIMPLE application. It provides the identical functionality and it uses the same interface and class definition (only differs in CLSID and names). So, with this sample and the matching C++ version, you can see how to mix C and C++ in your applications. The purpose of this sample is to demonstrate the use of COM from the C programming language.
| Name | Description |
|---|---|
| client/simple_c.c | client application (container) for the simple in-process server |
| inproc/printstr_c.c | simple "print-string" in-process server |
| inproc/printstr_c.def | definition file for the inproc server shared library |
| common/iprint.h | include file with the CLSID definition of the interface |
To build all components
Execute make in the current working
directory. This builds the simple_c executable
(simple_c) and the inproc server shared library named
libprintstr_c.so.
To run the application
Register the generated inproc server shared library by importing the
registry information with the command make register.
Start the simple_c executable (make sure to follow the shell quoting rules for the command argument)
without any argument a default string is printed to standard output.
command option -s[tring] <string> allows you to
overwrite the default output string.
command option -h[elp] presents a help screen.
The SIMPLE sample is a very basic in-process server implemented in a shared library called libprintstr.so. It provides the well-known "Hello World" example as a COM in-process server. The purpose of this sample is to illustrate the minimum required to implement an object that can be used by clients for in-process activation. This in-process component can also be used in a surrogate process either on the local machine or on a remote machine.
| Name | Description |
|---|---|
| client/simple.cxx | client application (container) for the simple inproc server |
| inproc/printstr.cxx | simple "print-string" in-process server |
| inproc/printstr.def | definition file for the inproc server shared library |
| proxy/simple.idl | interface definition file for the Simple example |
| proxy/printps.def | definition file for the proxy/stub library |
To build all components
Execute make in the current working
directory. This builds the simple executable (simple), the inproc-server shared
library named libprintstr.so and the proxy/stub library libprintps.so.
To run the application
Register the generated inproc server shared library and the
proxy/stub library by importing the registry information with make
register.
Start the simple executable (make sure to follow the shell quoting rules for the command argument)
without any argument a default string is printed to standard output.
command option -t
<string> allows you to overwrite
the default output string.
command option -n
<node> allows you to run the
in-proc dll as a surrogate on a remote machine.
command option -s uses dllhost as the
surrogate process.
command option -h[elp] presents a help
screen.
The client application will print some information on its state to standard output (usually the controlling terminal), so you can follow the in-process server activation and interaction. If you use the surrogate option, the surrogate process dllhost will be launched and will print the text.
This example is also availabe with Microsoft Visual Studio workspace on Windows.
The MSSIMPLE program is a simple DCOM application that is able to perform local (out-of-process) as well as remote activation. This application implements the SimpleObject class as a LocalServer. Instances of this class support a limited form of the IStream interface. Calls to IStream::Read and IStream::Write will "succeed" (they do nothing), calls on any other methods fail with _NOTIMPL. The purpose of this sample is to demonstrate what is minimally required to implement an object that can be used by clients (both those on the same machine using COM and those using DCOM across the network). The initial version of this software was published by Microsoft with the first beta version of DCOM for Windows 95. It was operable on Windows NT (4.0) and Windows 95 at that time; this distribution contains source code that has been modified to support EntireX DCOM from Software AG. You should be able to build this application on all target platforms. Take a look at the sources and at the makefiles for the various platforms for detailed information.
Make sure you are familiar with the DCOM configuration on your machine and read the hints we give for migrating sources to Windows if you want to use this sample for cross-platform tests (see Remote Activation).
| Name | Description |
|---|---|
| client/sclient.cxx | client application (container) for the out-of-process server |
| server/sserver.cxx | server application code |
To build all components
make in the current working directory.
This builds the client (sclient) and server (sserver) executables.
To run the application
You can register the generated server application with the command
make register or you can invoke the server application directly
with the -regserver command option. By default the
server executable is generated into the
$EXXDIR/$EXXVERS/examples/bin directory. You can
unregister the server with the -unregserver command
option.
There is NO proxy/stub shared library that has to be registered for this application, since it uses a standard COM interface.
Start the server (sserver) with the
-embedding option, if you want to have a pre-started
server.
Start the client (sclient) executable (be sure to follow the shell quoting rules for the command argument)
without any argument, default values are used to connect to the server (local node) and to read/write data.
command option -node <node
address> allows you to overwrite the default node
address.
command option -bytes <byte
count> allows you to overwrite the default block size
for reading/writing data.
command option -help presents a help
screen.
If you want remote activation of this example, refer to how to build the Windows version of a sample.
The BASIC application is a set of DCOM programs and libraries that
cover all aspects of server activation (in-process, out-of-process local and
remote). The application implements the CReadOnly and
CReadWrite classes as a LocalServer and as an
InProcServer. Instances of these classes support calls to IReader and IWriter
interfaces. The purpose of this sample is to demonstrate the minimum
requirement to implement an object that can be used by clients for in-process
and out-of-process activation (either on the same machine or remotely across
the network) using non-standard interfaces.
| Name | Description |
|---|---|
| proxy/basic.idl | interface definition for the Basic example |
| proxy/basicps.def | definition file for the proxy/stub library |
| inproc/basic.def | definition file for the inproc server shared library |
| client/basicl.cxx | client application (container) for the in-process and out-of-process server. |
| server/basicsvc.cxx | out-of-process and in-process server application code |
| server/cf.cxx | class factory for out-of-process and in-process server |
| server/cf.h | definition of class factory C++ class |
| server/basicobjs.cxx | implementation of CReadOnly and CReadWrite C++ classes |
| server/baseobjs.h | definition of CReadOnly and CReadWrite C++ classes |
| common/resource.h | commonly used header file with definitions from the Microsoft Developers Studio |
| common/string816.h | commonly used header file with definitions of some Unicode to MBCS/ANSI translation classes |
To build all components
execute make in the current working
directory. This builds the client (basiccl) and server (basicsvc) executables,
the proxy/stub shared library libbasicps.so, the type
library (basic.tlb) as well as the in-process server
shared library libbasicsvc.so.
To run the application
Register the generated proxy/stub shared library
(libbasicps.so) and the in-process server
(libbasicsvc.so) with the command make
register or use the regsvr utility that is provided
with EntireX DCOM.
Register the out-of-process server with the command make
register or by starting the server directly with the
-r[egserver] command option. This will make all the
necessary entries in the registry to allow an activation of this server by the
DCOM runtime process (namely RPCSS). To unregister the server again, use the
-u[nregserver] command option.
Start the server with the -e[mbedding] option
if you want to have a pre-started server.
Start the basiccl executable (make sure to follow the shell quoting rules for the command argument)
without any argument, default values are used to connect to a local out-of-process server.
command option -n[ode] <node address> allows
you to overwrite the default node address for out-of-process activation.
command option -i[nproc] activates an
in-process server.
command option -h[elp] presents a help
screen.
If you want remote activation of this example, refer to how to build the Windows version of a sample.
The Car RENTAL application is a DCOM sample with a Visual Basic client on Windows and a server on the UNIX side. It is a simplified car rental system. The server delivers all necessary data about the cars except for some photographs of them, which are located on the client side in bitmap format. The purpose of this sample is to demonstrate how a Visual Basic client can talk with a C++ server on UNIX.
Make sure you are familiar with the DCOM configuration on your machine and read the hints we give for how to build the Windows version of a sample if you want to use this sample for cross-platform tests.
| Filename | Platform | Comment |
|---|---|---|
| clerk/main.cpp | UNIX | main routine which contains the data and the code for registering/un-registering. |
| clerk/cf.cpp | UNIX | implements the class factory. |
| clerk/clerksrv.cpp | UNIX | implements the IRentalClerk interface and the class CRentalClerk. |
| clerk/clerksrv.h | UNIX | include file for the Clerk Server |
| proxy/clerksrv.idl | UNIX | interface definition for the rental demo |
To build all components on UNIX
Execute make in the current working
directory. This builds the server (clerksrv) and the proxy/stub shared library
(librentalps.so).
To run the application
Register the server with the command make register or
with clerksrv -r[egserver] on UNIX. The procedure is the same on
Windows. You can later
unregister the server with clerksrv -u[nregserver]
Pre-start the server with clerksrv if you
do not want to use the launch capabilities of rpcss.
Using DCOM config (select on the
menu then type dcomcnfg),
set the remote host name of the SAG Rental Clerk server to the hostname or IP
address of your server machine.
Start the rental client on Windows (rental.exe).
The Active Template Library (ATL) was created to provide developers with a convenient mechanism for building lightweight and fast COM (Component Object Model) objects. COM is the technical underpinning of all Microsoft ActiveX technologies. The ATL sample suite is a client/server application that shows the use of the ATL sources that have been ported as part of EntireX DCOM. It operates both locally as well as remotely.
| Name | Description |
|---|---|
| proxy/atltest3.idl | interface definition of AtlTest3 |
| proxy/atltest3ps.def | definition file for the proxy/stub library |
| client/atltest3.cpp | client side test application for the ATL code |
| server/atlinc.cpp | source file that includes the Microsoft ATL template code |
| server/atltest3_s.cpp | source file with the main server code |
| server/atltest.h | header file with the class definition for the test module |
| server/atltest3_rc.cpp | C++ version of Windows resource file |
| server/resource.h | header file with definitions from the Microsoft Developers Studio |
| makefile | makefile as input for the make utility |
To build all components
Execute the command make in the current
working directory. This builds the client (atltest3) and server (atltest3_s)
executables for testing the type library, as well as the proxy/stub shared
library.
To run the application
Register the generated proxy/stub shared library
libatltest3ps.so and the test server
atltest3_s with the command make register. As
an alternative you can use the regsvr utility that is
provided with EntireX DCOM to register the proxy/stub shared library
libatltest3ps.so.
Register the out-of-process server by starting the server with the
-regserver command option (this is automatically done
with the command make as well). This will make all
the necessary entries into the registry to allow an activation of this server
by the DCOM runtime. To unregister the server again, use the
-unregserver command option.
Start the server (atltest3_s) with the
-embedding option, if you want to have a pre-started
server.
Start the atltest3 executable (make sure to follow the shell quoting rules for the command argument).
without any argument, default values are used to connect to the server (local node).
command option -node <node address> allows you
to overwrite the default node address.
command option -help presents a help
screen.
To run the test between Windows and your EntireX DCOM platform,
register the proxy/stub dll on Windows with regsvr32 <library
name> and the server with atltest3_s -r.
Both the client application and the server application will print some information on their state to standard output (usually the controlling terminal), so you can follow the server activation and interaction.
If you want remote activation of this example, refer to how to build the Windows version of a sample.
The Active Template Library (ATL) was created to provide developers with a convenient mechanism for building lightweight and fast COM (Component Object Model) objects. COM is the technical underpinning of all Microsoft ActiveX technologies. The Labrador sample is a client/server application that shows the use of the ATL 3.0 sources that have been ported as part of EntireX DCOM. It operates both locally and remotely.
| Name | Description |
|---|---|
| proxy/labrador.idl | Interface definition of Labrador Object |
| proxy/labps.def | Definition file for the proxy/stub Library |
| client/labdriv.cpp | Client side test application for the ATL 3.0 code |
| client/prelabdr.cpp | Source file that includes the file with IIDs of the interfaces supported |
| client/prelabdr.h | Include file for standard and project specific include files changed infrequently |
| server/labrador.cpp | Source file with the main server code |
| server/labobj.h | Declaration of the CLabrador class |
| server/prelab.h | Include file for standard and project specific include files changed infrequently |
| server/prelab.cpp | Source file that includes the ATL Implementation File |
| server/labrador_rc.cpp | C++ version of Windows resource file |
| server/labres.h | Header file with definitions from the Microsoft Developers Studio |
| makefile | Makefile as input for the make utility |
To build all components
Execute the command make in the current
working directory. This builds the client (labdriv) and server (labrador)
executables for testing the type library, as well as the proxy/stub shared
library (labps).
To run the application
Register the generated proxy/stub shared library
liblabps.so and the test server (labrador) with the
command make register. As an alternative you can use the
regsvr utility that is provided with EntireX DCOM to
register the proxy/stub shared library liblabps.so.
Register the out-of-process server by starting the server with the
-regserver command option (this is automatically done
with the command make register as well). This will make all the
necessary entries into the registry to allow an activation of this server by
the DCOM runtime (namely RPCSS). To unregister the server again, use the
-unregserver command option.
Start the server (labrador) with the
-embedding option, if you want to have a pre-started
server.
Start the labdriv executable (make sure to follow the shell quoting rules for the command argument).
without any argument, default values are used to connect to the server (local node).
command option -node <node address> overrides
the default node address.
command option -help presents a help
screen.
To run the test between Windows and your EntireX DCOM platform,
register the proxy/stub dll on Windows with regsvr32 <library
name>; for local tests on Windows, register the server with
labrador -r as well.
Both the client application and the server application will print information on their state to standard output (usually the controlling terminal), so you can follow the server activation and interaction.
If you want remote activation of this example, refer to how to build the Windows version of a sample.
The STGTEST program is a simple COM application that creates a structured storage document file TEST.DFL with substorages and streams. It then performs miscellaneous tests using IStorage and IStream interface methods. It does not fall into the category of client/server sample applications and therefore does not use the standard directory layout with client, server and prox/stub components.
Once you have created the document file you can use the stgview utility that is part of the EntireX DCOM distribution to view the contents of the generated document file.
| Name | Description |
|---|---|
| stgtest.cxx | Sample application that creates the structured storage document. |
To build all components
execute make in the current working
directory. This builds the client (stgtest) executables.
To run the application
Start the stgtest sample. Check out the various command options
(stgtest -h) for customization.
This application does not produce significant output. The appeal of this sample is more in the area of source code browsing than presenting COM features at runtime.
The BEER application is a DCOM program and library that demonstrates the use of monikers. The server can be activated through a file moniker which points to the specified file.
The client activates an object via a File Moniker and the object loads its persistent state out of the file.
There is an additional client application for this server that implements a dual interface client.
| Name | Description |
|---|---|
| beer_mon | This is the file moniker client. |
| beer_oa | This is the dual interface client |
| server/beer.cxx | Out-of-process server application code |
| server/copoint.cxx | Contains the implementation of CoPoint C++ class |
| server/copoint.h | Definition of CoPoint C++ class |
| common/clsids.h | Definition of the CLSIDs |
To build all components
Execute make in the current working
directory. This builds the clients (beer_mon and beer_oa) and server (beer)
executables as well as the proxy/stub shared library
libbeerps.so.
To build this example on Windows, refer to how to build the Windows version of a sample.
To run the application
Register the generated proxy/stub shared library
libbeerps.so with the regsvr utility that is
provided with EntireX DCOM or register it with the make register
command.
Register the server with beer -regserver in the
registry. You can later unregister the server with beer
-unregserver. You can also register the server with the make
regserver command. This will also register the generated type library
ipoint.tlb.
Start the server with beer -embedding if you want to
run the server in interactive mode. If the server is not pre-started, it will
be launched automatically when the client wants to bind to the object.
On Windows, register the proxy/stub dll with regsvr32
<library name> and the server with beer -r.
Decide on one of the client applications to run
Both the client application and the server application will print some information on their state to standard output (usually the controlling terminal), so you can follow the server activation and interaction.
The BEER_MON application is a client for the beer server sample. It demonstrates the use of file monikers. The purpose of this example is to show how a server can be launched using the file's extension and how an object can be instantiated via a file moniker. The client activates an object using a file (file moniker which points to the specified file) and the object loads its persistent state out of the file. The default file extension (.bar) must be a key in the registry and it contains the CLSID of the object. The file contains two long values which represent the co-ordinates of a point. To start the example it is sufficient that the file contains 8 bytes, representing the two long values. After the first time, the server automatically converts the file into a storage file. You can also see how the client can set new values for the point co-ordinates and how this state of the object can be saved to the file and loaded at a later point in time.
| Name | Description |
|---|---|
| beer_mon.cxx | This is the moniker client. |
| foo.bar | sample file with the co-ordinates x=111 and y=222 |
To build all components
Check out the instructions that come with the server side of this application, on how to build the images and shared libraries required.
To run the application
Perform the required registration and activation steps for the server side
Start the beer_mon executable (make sure to follow the shell quoting rules for the command argument)
without any argument, default values are used to launch the server and to activate the object. The default is the file foo.bar (the file must be in the current working directory). This file must be a storage file containing two long values or a plain file containing 8 bytes which represent two long values.
command option -file
file_name gives you the opportunity to
specify a different file (e.g. if the file is not in your current working
directory or if the filename is not foo.bar). In this case
you must have the file extension as a key in the registry (see the .bar entry
under HKEY_CLASSES_ROOT) with the same CLSID as .bar
command option -item uses not only the
file moniker with the file foo.bar (i.e. the file
foo.bar has to be in your current working directory) but
also composes this moniker with an item moniker. In this case the client will
set the coordinates of the point to x=100 and y=200 and the server will save
this object state before running down (e.g. running
beer_mon with the -item option will
overwrite the current coordinate settings in foo.bar).
command option -pointer binds to the
object as described under default but then also creates a pointer moniker to
the object and uses this pointer moniker later to bind again to the object. The
-pointer command option can be combined with the
-file option.
command option -help shows the help
information.
Both the client application and the server application will print some information on their state to standard output (usually the controlling terminal), so you can follow the server activation and interaction.
Build the proxy/stub dll, the type library and the beer_mon client on Windows as described in the section on how to build the Windows version of a sample (see Remote Activation).
Register the proxy/stub dll.
Import the file beer_nt.reg to your Windows registry.
You must mount the UNIX file system on Windows (e.g using Samba). Then start the beer_mon client as described above where the executable is located on the UNIX file system. You need the file foo.bar in the same directory. You can use the same file as you use for the UNIX example because the structured storage file is binary compatible.
If you use the delivered file foo.bar, be aware
that the coordinates will be different because of the different endianness of
UNIX and Windows. If you use an already generated file (e.g. after running
beer_mon under UNIX with -item) you should also receive
the same values on Windows.
The BEER_OA application is a program that extends the Moniker sample application with a dual interface client. The purpose of this example is to show the implementation of a dual interface.
| Name | Description |
|---|---|
| beer_oa.cxx | This is the dual interface client as an extension to the Moniker sample server. |
To build the client components
Execute make in the current working
directory. This builds the client (beer_oa) only. To generate the server
component, check out the server side of the
Moniker
sample application.
To run the application
Follow the instructions for the server, as described in the server side of the Moniker sample documentation.
Start the beer_oa executable (make sure to follow the shell quoting rules for the command argument)
without any argument, default values are used to launch the server and to activate the object.
command option -node <node address> activates
the server application on the specified host.
command option -help shows the help information.
Both the client application and the server application will print some information on their state to standard output (usually the controlling terminal), so you can follow the server activation and interaction.
Build the proxy/stub dll, the type library and the beer_oa client on Windows as described in the section on how to build the Windows version of a sample.
Register the proxy/stub dll.
Import the file beer_nt.reg to your Windows registry (after adjusting the path information).
Start the beer_oa with the additional option -node <node
address>.
The VARTYPES application is a set of DCOM programs and libraries that tests the supported variant types. This application implements the CVarTypes class as a LocalServer or RemoteServer. The purpose of this sample is to demonstrate how to use Automation to get access to local or remote objects. The example is implemented as Dual Interface to show all available kinds of invocation.
| Name | Description |
|---|---|
| client/vartest.cxx | Automation controller for the objects in the server. |
| client/fktcalls.cxx | source code for the method calls. |
| client/vartest.h | prototypes for the internal functions. |
| server/vartypes.cxx | class factory for out-of-process server and main function |
| server/typfkt.cxx | server application code for the Automation objects |
| server/typefkt.h | definition of C++ class CVarTypes |
| proxy/vartypes.idl | interface definition file |
To build all components
Execute make in the current working
directory. This builds the client (vartest) and server (vartypes) executables
and the type library (vartypes.tlb).
To build this example on Windows, refer to how to build the Windows version of a sample.
To run the application
Register the out-of-process server with the command make
register or by starting the server directly with the
-regserver command option. This will make all the
necessary entries in the registry to allow an activation of this server by the
DCOM runtime (namely RPCSS). To unregister the server again, use the
-unregserver command option.
Start the server with the -embedding option,
if you want to have a pre-started server.
Start the vartest executable (make sure to follow the shell quoting rules for the command argument)
without any argument default values are used to connect to a local server.
command option -node <node address> allows you
to overwrite the default node address for out-of-process activation.
command option -help presents a help
screen.
command option -invoke calls the method
using IDispatch invoke
command option -names calls the method
using IDispatch invoke with named arguments
command option -vtable calls the method
directly
Both the client application and the server application will print some information on their state to standard output (usually the controlling terminal), so you can follow the server activation and interaction.
Register the server with vartypes -r.
Start the vartest.exe with the additional option
-node <node address>.
The CoolRot application is a DCOM program and library that shows how to
use the ROT (Running Object Table). A server is registered in the ROT using a
composite Moniker (CoolRot Item Moniker 1 and CoolRot Item
Moniker 2) and the client binds the object via this moniker. The
application implements the CLSID_CoRot as a LocalServer, instances of this
class support calls to SetCoords, GetCoords and Shut interfaces. The purpose of
this sample is to demonstrate how a server can register in the ROT using a
moniker and how a client, knowing only the CLSID and the moniker name, can bind
to the object.
After starting the server rot_s, you can use the irotview utility to see the moniker as it is registered in the ROT.
| Name | Description |
|---|---|
| client/rot_c.cxx | client application. |
| server/rot_s.cxx | out-of-process server application code |
| server/corot.cxx | implementation of CoRot C++ class |
| server/corot.h | definition of CoRot C++ class |
To build all components
Execute make in the current working
directory. This builds the client (rot_c) and server (rot_s) executables, the
proxy/stub shared library libirotps.so.
To run the application
Register the generated proxy/stub shared library
libirotps.so with the command make register
or with the regsvr utility that is provided with EntireX
DCOM.
Register the server with the command make register or
with rot_s -regserver in the registry. You can later unregister
the server with rot_s -unregserver.
Start the server with rot_s.
Start the rot_c executable (make sure to follow the shell quoting rules for the command argument)
without any argument, default values are used to connect to bind to the running object and execute two method calls. The first call sets some coordinates to the values x=11111 and y=22222. The second call gets these coordinates back from the server.
command option -shut gives the server a
signal to unregister from the ROT and to terminate.
command option -help presents a help
screen.
Both the client application and the server application will print some information on their state to standard output (usually the controlling terminal), so you can follow the server activation and interaction.
The ConnBall DCOM application shows how to construct a Connectable DCOM object (ConnBall) in a thread-safe server (conserve) using the DCOM Connection Points. The ConnBall class implements the standard COM interface, IConnectionPointContainer, and it also implements a custom interface (IBall).
The principal focus is the connectable object support in ConnBall and how connected clients are notified of ball events. conserve works with the guiclient text-based client code.
ConnBall implements a virtual moving ball, defining the internal logic of a moving ball that exists within a specified two-dimensional bounding rectangle. ConnBall provides only a description of a ball. Clients move the virtual ball using its IBall interface. ConnBall's internal logic will bounce the ball when it collides with a boundary. The client can obtain the ball's current position, size and color to permit display of the ball's moving image. The client can also use the connection facilities of ConnBall to receive notifications of ball bounce events. The client will use these connection facilities to produce some warnings when the ball bounces.
| Name | Description |
|---|---|
| win_client/* | Win32 client application files |
| vb5cli/* | Visual Basic client application files |
| proxy/iball.idl | Interface definition of Ball and Sink Objects |
| proxy/conserveps.def | The module definition file for building the Proxy/Stub Library |
| client/conclien.cpp | The guiclient's main implementation file. It is a text-based C++ program |
| client/nonguiball.cpp | Implementation file for the CNonGuiBall C++ class |
| client/nonguiball.h | The class declaration for the CNonGuiBall C++ class |
| client/sink.cpp | Implementation file for the COBallSink class |
| client/sink.h | The class declaration for the COBallSink class |
| server/conserve.cpp | The main implementation file for conserve. Has DllMain/main and the COM server functions (e.g. DllGetClassObject) |
| server/conserve.h | The include file for declaring as imported or defining as exported the service functions in the InProc version of conserve |
| server/ball.cpp | The implementation file for the COBall object class |
| server/ball.h | The include file for the COBall object class |
| server/connect.cpp | The implementation file for the connection point enumerator, connection point, and connection enumerators objects |
| server/connect.h | The include file for the connection point enumerator, connection point, and connection enumerator classes |
| server/apputil.cpp | Implementation file for the general application utility class CThreaded and some functions (e.g. Message) |
| server/apputil.h | Include file for the general application utility class CThreaded and some functions |
| server/factory.cpp | The implementation file for the server's class factories |
| server/factory.h | The include file for the server's class factory COM objects |
| server/server.cpp | The implementation file for the server control object |
| server/server.h | The include file for the server control C++ object |
| server/ballguid.h | Include file for the ball-related IIDs and CLSIDs |
| server/conserve.def | The module definition file for building the InProc version of the server |
| outproc/makefile | Makefile as input for the make utility in order to build the OutProc version of the server (conserve) |
| makefile | Makefile as input for the make utility |
To build all components
Execute make in the current working
directory. This builds the proxy/stub shared library
(libconserveps.so), the text-based client executable
(conclien), and the server in two versions, OutProc
(conserve) and InProc
(libconserve.so).
To run the application
Register the generated proxy/stub shared library
(libconserveps.so) with the command make
register or with the regsvr utility that is
provided with EntireX DCOM.
Register the server with the command make register or
with conserve -regserver. You can later unregister the server with
conserve -unregserver.
If you want to use the in-process version of the server
(libconserve.so), register it with the command make
register or with the regsvr utility.
Start the server with conserve -embedding option if you
want to have a pre-started server. If the server is not pre-started, it will be
launched automatically when the client wants to bind to the object.
Start the text-based conclien executable (make sure to follow the shell quoting rules for the command argument)
without any argument default values are used to connect to a local out of process server.
command option -c number
allows you to overwrite the number of calls to Ball's Move.
command option -n node
name allows you to specify the node name or IP-address for
remote out-of-process activation.
command option -i activates an in-process
server.
command option -h presents a help
screen.
There are two additional client applications available:
Both the client application and the server application will print some information on their state to standard output (usually the controlling terminal), so you can follow the server activation and interaction.
If you want remote activation of this example, refer to how to build the Windows version of a sample.
The vbconclien application is a Visual Basic program that creates and uses the ConnBall application housed in the conserve server.
The vbconclien client creates one ConnBall object reference and controls it through the IBall interface that the object exposes, using the generated type library. vbconclien sets up a Timer control to use IBall to periodically move the ball and obtain updates of data describing the ConnBall object's position. It uses that data, obtained by calling the IBall::GetBall method, to display graphical snapshot images of the ball in the client's main window.
In response to the timer's events, vbconclien uses the IBall interface to move and paint images of the ball. ConnBall object also sends events back to vbconclien, using the IBallSink interface, when the ball bounces off of a side of its bounding rectangle. vbconclien responds to these events to produce a sound when the ball collides with a Top, Side, or Bottom boundary of the display frame.
| Name | Description |
|---|---|
| vb5cli/vbconclien.vbp | Visual Basic project |
| vb5cli/*.frx | VB form binaries |
| vb5cli/connball.frm | Main window application and code |
| vb5cli/frmSplash.frm | Initial window |
| vb5cli/frmAbout.frm | About dialog |
To build all components
First of all, build the Proxy/Stub library on your Windows and build the conserve server (and proxy/stub library) on the UNIX machine with EntireX DCOM. Then build vbconclien client with Visual Basic.
Execute make in the current working
directory. This builds the proxy/stub shared library
(libconserveps.so), the client executable (conclien), and
the server in two versions, out-of-process (conserve) and in-process
(libconserve.so).
To run the application
