Chapter 1

The GSDP server presented here has its own specific task to perform, but in many ways it's
typical, and I'll describe it in sufficient detail here so that you can use it with confidence as a
basis for implementing your own servers.
19.1 Software Structure
You can find the source code for the GSDP server and its client interface in \scmp\gsdp\.
Here's the structure of the server and its interfaces in Figure 19.1:
Figure 19.1
The server and its client interface are delivered in a single DLL, gsdp.dll. The client
interface consists of a header file, gsdp.h, which we'll look at shortly, and corresponding
functions exported from the DLL. Another header file, gsdpdef.h, includes definitions that
tie the client interface and the server together – mainly the request codes passed in the
various messages. All other header files are private either to the client alone or to the server
alone.
The GSDP server is a transient server: it's started when a client needs it, and terminates
itself when no more clients need it. The startup code launches the server as a new thread
under the WINS emulator, or as a new process on target machines. The startup code for the
emulator is also contained in gsdp.dll; for MARM, it's a separate, very small, .exe.
This design minimizes the differences between the two platforms. It follows the design of the
Symbian OS DBMS server, which was written for Symbian OS v5. Among the useful aspects
of this single-DLL design are that it eases debugging under the emulator because there's
only a single project, and it ensures that client and server code are in sync because they're
delivered in the same DLL.
Many Symbian OS servers use a separate DLL for the client interface, and a relatively large
program for the server, delivered as a .exe for target machines, and a DLL for the emulator.
Note
One reason that may compel server authors to use a .exe is if they cannot
do anything to eliminate writable static data in the server code, perhaps
because they are porting code.