HP OpenVMS Systems Documentation
Common Desktop Environment: Programmer's Overview
4 Portability and Maintenance
Contents of Chapter:
follow the Motif 1.2, ANSI-C, and X11R5 standards. If you are developing your application in C++, use C++ version 2.0 or later. No further assumptions are made that you adhere to any standards, such as POSIX, when you write a Common Desktop Environment application. Applications that use the desktop application program interfaces (APIs) will be portable to other Common Desktop Environment platforms. However, using POSIX can enhance your software's portability.
The POSIX standard, IEEE Std 1003.1-1990, is entitled IEEE Standard for Information Technology--Portable Operating System Interface (POSIX)--Part 1: System Application Program Interface (API) [C Language], ISBN 1-55937-061-0.
For information on ordering IEEE Std 1003.1-1990 and IEEE Std 1295, see "Related Books."
Also, the make program functionality can differ across platforms. If you want to write just one makefile for your application, use the common make functionality used by the platforms to which you want to port your program. Avoid platform-specific make features.
The Common Desktop Environment requires no additional defined constants (-D parameters) to integrate with the desktop. If you do follow a standard, such as POSIX, you might need to compile with additional standard-specific flags. Read about the standard to find out if it includes special compiler considerations.
Each subdirectory of /usr/dt/examples contains sample makefile source files for different platforms. These makefiles take into account system differences. In particular, see the /usr/dt/examples/dtdts directory for generic examples of makefiles.
Compile OptionsTo enable your application to find the desktop include files, add:
to each makefile's compile line.
Link OptionsTo enable your application to reference desktop libraries, add:
to each makefile's link line, where libname1, libname2 are the names of libraries your application needs to reference. You can include as many desktop library names in this line as you want. For example:
enables your application to reference the Desktop Services, ToolTalk Messaging System, and Motif 1.2 libraries.
Do not place length limitations on file names that an end user generates.
The incompatibility occurs because a subclass must contain compiled-in references to its instance fields that are specified relative to the start address of the widget instance. When you install a new Motif library for a widget whose superclass instance structure has been extended, the compiled-in references will point to the wrong memory location.
To avoid this difficulty, Motif provides a mechanism for defining resources and accessing widget fields that allows you to reference all fields in the instance and constraint structures relative to the start of the widget part structure, instead of the overall widget structure. (The overall widget structure includes the superclass part structure.) The mechanism resolves these relative references at run time, when the widget class is first initialized. To resolve references, it factors in the size of the widget's superclass instance structure, which it reads from the currently linked Motif library.
Note: If you implement subclassing, you must use the Motif reference-resolving mechanism if you want your application to be binary compatible with future releases of the Common Desktop Environment.
For details regarding this Motif mechanism, consult the Motif 1.2 XmResolvePartOffsets(3x) and XmResolveAllPartOffsets(3x) man pages and the OSF/Motif Programmer's Reference. You can find example source code in /usr/dt/examples/motif/dogs.