| Previous | Contents | Index |
To use the UIL compiler for XUI or OSF/Motif Release 1.1.3, perform the following steps:
define type trace_keywords keyword tokens keyword symbols define type warning_keywords keyword nowarnings keyword noinformationals define type version_keywords keyword V1, syntax=xui_uil keyword V2, syntax=xui_uil, default keyword MOTIF11, syntax=motif_uil define syntax xui_uil image decw$uilcompiler define syntax motif_uil image decw$uilmotif define verb uil image decw$uilcompiler parameter p1, label=source_file, prompt="File", value(required,noconcatenate,type=$infile) qualifier trace, label=trace_qual, value(list,noconcatenate,type=trace_keywords), nonnegatable qualifier warnings, label=warnings_qual, value(list,noconcatenate,type=warning_keywords) qualifier list, label=listing_file, batch, value(type=$outfile) qualifier machine, label=machine_qual, qualifier output, label=resource_file, default, value(type=$outfile) qualifier version, label=version_qual, default, value(type=version_keywords), nonnegatable qualifier XUI, default, nonnegatable, syntax=xui_uil qualifier MOTIF, nonnegatable, syntax=motif_uil qualifier widget_meta_description, label=widget_qual, value(required, noconcatenate, type=$infile) disallow XUI and MOTIF |
$ SET COMMAND SYS$SYSROOT:[SYSEXE.DECW$113]DECW$UILCOMPILER.CLD |
If you want to revert back to the previous UIL command definition, execute the following command:
|
V1.1
Transports specific to DECwindows require code modifications to support
POSIX for OpenVMS fork() requirements. If you have written a specific
transport and also plan to implement POSIX for OpenVMS support, you
must make changes to your transport source code. This note describes
the required changes.
3.9.1 POSIX fork() Routine
V1.1
The POSIX fork() routine creates a copy of the currently executing process, completely cloning P1 and P0 space. Both the original process (the parent) and the new process (the child) proceed on identical paths from that point.
When using the POSIX fork() routine, data is not duplicated because:
Because of these limitations, the POSIX for OpenVMS implementation has placed certain demands on protected shareable images, including transports specific to DECwindows:
Specific transports must acknowledge (on the client side) that they can be forked. The SYS$POSIX_FORK_CONTROL system service, described in Section 3.9.2, is provided for this purpose.
Specific transports need not perform any cleanup work.
3.9.2 SYS$POSIX_FORK_CONTROL System Service
V1.1
A new SYS$POSIX_FORK_CONTROL system service was added in VMS
Version 5.5 that registers that a protected shareable image can be
forked. It also registers the address and parameter to a fork callback.
The execution of the POSIX fork() routine fails if the application has been linked with, or has activated, a protected shareable image that has not called SYS$POSIX_FORK_CONTROL.
Therefore, in your specific transport's open routine, add a call to the SYS$POSIX_FORK_CONTROL system service similar to the following:
$ POSIX_FORK_CONTROL(CNTRL = POSIX$C_SETUP_CALLBACK, WHEN = POSIX$M_CALL_IN_CHILD,HANDLER = posix_fork_cb); |
In this example, the CNTRL parameter indicates that the image is setting up a callback so that it can be forked, the WHEN parameter tells when to call the fork callback, and the HANDLER parameter gives the address of the fork callback.
Other parameters that are not used in this example allow for a
parameter to be passed to the callback routine and to specify the
access mode (maximized to that of the caller).
3.10 Translated Image Support (Alpha Only)
This section discusses restrictions and general information about
translated-image support.
3.10.1 Running Translated Images on OpenVMS Systems
V1.2--3
In versions of OpenVMS Alpha systems prior to Version 1.5, translation support was provided to address the following problems for users who migrated to OpenVMS Alpha systems:
For programming languages whose OpenVMS VAX versions are currently under development, native Alpha versions are available in the OpenVMS Alpha Version 6.1 operating system. The translated-image environment is maintained to support language features that are available as of the VMS Version 5.5--2 release.
Similarly, translation is supported for images whose use of system services and run-time library entry points is restricted to those images that existed on the VMS Version 5.5--2 operating system.
If you have installed layered products on your system since the VMS Version 5.5--2 release, you may need to make additional changes if you rebuild an image to support translation. For instance, for applications that are included with DECwindows Motif for OpenVMS VAX software, you must build images with the OSF Motif Release 1.1.3 library or the DECwindows XUI library, instead of with the OSF Motif Release 1.2.3 library.
The DECwindows Motif Version 1.2-5 for OpenVMS release includes the same translated-image support file that was provided with the DECwindows Motif Version 1.2 for OpenVMS Alpha release.
DECwindows Motif Version 1.2 for OpenVMS Alpha includes support for DECwindows Motif Version 1.1 for OpenVMS VAX images on an OpenVMS Alpha system.
V1.2
The DECwindows Motif Version 1.2 for OpenVMS Alpha release does not include support for running translated DECwindows Motif Version 1.2 for OpenVMS VAX images on OpenVMS Alpha systems.
If you want to run an application against DECwindows Motif Version 1.2 shareable images on an OpenVMS Alpha system, build it (compile and link) on an OpenVMS Alpha system. You cannot obtain a Version 1.2 translated image by building your application against the DECwindows Motif Version 1.2 shareable images on an OpenVMS VAX system, copying the resulting image file to an OpenVMS Alpha system, and translating it (using DECmigrate).
If you cannot build your application on an OpenVMS Alpha system and need to obtain a translated image with DECmigrate, you should continue to build your application against the OSF/Motif Release 1.1.3 programming environment provided in the DECwindows Motif Version 1.1 for OpenVMS VAX product. (Note that you are given the option to save your OSF/Motif Release 1.1.3 programming environment when you upgrade to DECwindows Motif Version 1.2 for OpenVMS VAX.) VAX images built against the OSF/Motif Release 1.1.3 programming environment can be copied to an OpenVMS Alpha system, translated, and executed successfully.
You can install translated-image support during the DECwindows Motif installation procedure. See the DECwindows Motif Version 1.2--4 for OpenVMS Installation Guide for instructions.
The OSF/Motif Release 1.1.3 shareable images that are used with translated images are different from and incompatible with the shareable images used for native images. As a result, the following image restrictions apply:
For more information on translated-image support, see the DECmigrate for OpenVMS AXP Systems Translating Images
guide.
3.10.2 DECwindows Motif Toolkit Functionality (Alpha Only)
V1.1
On OpenVMS Alpha systems, DECwindows Motif Toolkit functionality is available with the following restriction: for the DECwindows Motif product, C modules are compiled using the default MEMBER_ALIGNMENT switch in the C compiler to maximize performance. It is recommended that you do not use the NOMEMBER_ALIGNMENT compile-time switch.
If you intend to port a toolkit application that is written in C, see
the VAX C Run-Time Library release notes in the OpenVMS Alpha AXP Version 1.0 Release Notes.
3.11 Problems Using the DECW$INCLUDE:INTRINSIC.H File
V1.2--5
The DECwindows header file, DECW$INCLUDE:INTRINSIC.H, redefines the globalref macro to be extern when using the DEC C compiler, even when the /STANDARD=VAXC compiler switch is specified. This could have a wide impact on user applications.
This redefinition in INTRINSIC.H is required because DECwindows needs to ensure that references to data located in the DECwindows shared images by user-written applications use the same extern model that was used when the DECwindows shared images were compiled.
To workaround this problem, rather than having your application use globalref and globaldef for its own variables, use the following preprocessor directive:
#pragma extern_model strict_refdef |
This workaround has the advantage of being strictly ANSI compliant.
This pragma directive is described in the "Preprocessor
Directives" chapter of the DEC C User's Guide for OpenVMS
Systems manual.
3.12 Compiling Applications Written in C
V1.0
During the VAX C layered-product installation procedure, you have the option of extracting the VAX C definition files (.h files) or leaving the .h files in the text library. If you extract the definition files, you can use #include control lines of the following form:
#include <filename.h> |
The DECwindows header files assume that the .h files were extracted. They contain #include <module_name.h> notation for the included files. The DECwindows programming documentation also makes this assumption.
VAX C should, therefore, be installed using the option to extract the library modules.
If you have already installed VAX C and you did not extract the .h files, the DECwindows sample C programs do not work. To correct this problem, reinstall VAX C and extract the .h files.
With DEC C, the header files do not need to be extracted from the text library if you define the DECC$TEXT_LIBRARY logical name as follows:
$ DEFINE DECC$TEXT_LIBRARY SYS$LIBRARY:DECC$RTLDEF.TLB |
V1.1
On OpenVMS Alpha systems, some of the include files used for writing DECwindows Motif applications in Fortran, such as the DECW$MOTIF.FOR file, contain structure definitions that cause memory layout changes, depending on the compiler switches used.
You can do one of the following:
CDEC$ OPTIONS /ALIGN=RECORDS=NATURAL |
CDEC$ END OPTIONS |
CDEC$ OPTIONS /ALIGN=RECORDS=NATURAL INCLUDE "DECW$MOTIF.FOR" CDEC$ END OPTIONS |
This section contains programming information about the CDA application.
3.14.1 CDA---Implementing the Drag-and-Drop Feature
V1.2
The drag-and-drop feature, which lets you move or copy information between widgets, is implemented in the widgets listed in Table 3-4.
| Widget | Drag Operation | Drop Operation |
|---|---|---|
| XmText | copy and move | copy and move |
| XmTextField | copy and move | copy and move |
| XmLabel | copy | |
| XmPushButton | copy | |
| XmToggleButton | copy | |
| XmList | copy |
For information about how to include additional drag-and-drop
functionality in applications and for an example of a drag-and-drop
program, see the Open Software Foundation: OSF/Motif Programmer's
Guide, Revision 1.2 manual.
3.14.2 CDA Run-Time Services Features
V1.2
This section describes new programming features in this version of the
CDA Run-Time Services. See Chapter 1 for new user features.
3.14.2.1 Version Number
V1.2--4
DECwindows Motif for OpenVMS software incorporates additional problem resolutions that were not provided in the general release of the CDA Version 1.8 product.
CDA Version 1.6 was part of the DECwindows Motif Version 1.1 for OpenVMS release. Starting with
the DECwindows Motif Version 1.2 for OpenVMS release, DECwindows Motif provided the CDA Run-Time
Services component of CDA Version 1.8. As of the DECwindows Motif Version 1.2-4 for OpenVMS release,
DECwindows Motif incorporates Version 1.8A.
3.14.2.2 Changes to the Programming Interface for CDA
V1.2
This section describes the changes to the programming interface for this version of CDA Run-Time Services.
This version provides a new set of header files that define CDA constants, types, and routines using portable naming conventions. By using these new naming conventions, you can use a wider variety of C compilers to minimize the amount of system-specific code in your CDA applications.
The names of the new set of header files are the same as the names of the previous set of header files, except that the dollar sign ($) has been removed. For example, the cda$msg.h include file is now called cdamsg.h. Other examples include the following: The DDIF$K_DSC_MAJOR_VERSION symbol is now declared as DDIF_K_DSC_MAJOR_VERSION, and the CDA$_NORMAL status value is now defined as CDA_NORMAL.
The previous set of header files is also included in this version, but these files will no longer be updated. Changes introduced since the release of DECwindows Motif Version 1.1 (for example, the new definitions for audio support), are available only in the new set of header files. To use the new CDA features, change the file names in your source code.
The new set of header files supplements the previous set of header files. If you want to write ANSI-compliant applications using CDA definitions and CDA Toolkit calls, use the new set of header files. However, you can continue to use the header files that define symbols containing the dollar sign ($) provided you choose a non-ANSI compilation mode.
By using the previous set of header files, you can successfully build existing source code that uses the previous naming conventions.
See Table 3-5 for a list of new header file names.
| Previous Name | New Name |
|---|---|
| cda$def.h | cdadef.h |
| cda$msg.h | cdamsg.h |
| ddif$def.h | ddifdef.h |
| dtif$def.h | dtifdef.h |
| cda$ptp.h | cdaptp.h |
| cda$typ.h | cdatyp.h |
| dvr$msg.h | dvrmsg.h |
| dvr$cc_def.h | dvrccdef.h |
| dvr$cc_ptp.h | dvrccptp.h |
| dvr$decw_def.h | dvrwdef.h |
| dvr$decw_ptp.h | dvrwptp.h |
V1.2
CDA Run-Time Services supports relative file specifications for
external references. Relative references are also supported: that is, a
reference where the directory path is not fully specified but is
relative to the directory path of the parent document.
3.14.2.4 Message for Style Guide Fallback
V1.2
The following message is displayed when a local style guide cannot be found:
STYGDEFBK, Fallback to nonlocale-specific style guide: file-spec
V1.2
During a document conversion, if a logical name is used to specify the directory of the primary document and the document file extension is omitted, external references that contain relative file specifications cause the conversion to fail.
This failure occurs because the back-end converter examines the converter processing options, although the front-end converter opens the input file. Because the converter software cannot predict what default file extension the front-end converter might apply, it uses the OpenVMS file services to resolve the logical name and to find the actual file specification so that the directory can be parsed and extended with a relative specification.
The conversion fails only when the external reference uses a format such as the following:
sys$login:mydoc |
In this case, the reference will not be resolved. The reference is resolved in all other cases. For example:
sys$login:mydoc.doc disk$:[smith]mydoc disk$:[smith]mydoc.doc |
V1.2
The CDA Viewer includes two shareable images to allow installation on systems where DECwindows is not installed.
In DECwindows Motif Version 1.2 for OpenVMS software, shareable images that use the X services are renamed. Table 3-6 lists the shareable images in the various versions of the CDA Viewer.
| CDA Version | Image Name | Description |
|---|---|---|
| Version 1.6 | CDA$ACCESS | CDA Run-Time Services shareable image. |
| DDIF$VIEWSHR | Callable viewer widget. | |
| Version 1.7 | CDA$ACCESS | CDA Run-Time Services shareable image. |
|
DDIF$VIEWSHR
DDIF$DECW_VIEWSHR DDIF$CC_VIEWSHR |
The DDIF$DECW_VIEWSHR widget is a callable viewer widget that uses the LIB$FIND_IMAGE_SYMBOL routine to invoke the DDIF$DECW_VIEWSHR (DECwindows interface) and DDIF$CC_VIEWSHR (character-cell interface) widgets. | |
|
Version 1.8
Version 1.8A |
CDA$ACCESS | CDA Run-Time Services shareable image. |
| DDIF$VIEWSHR12 | The DDIF$VIEWSHR12 widget is a callable viewer widget that uses LIB$FIND_IMAGE_SYMBOL to invoke the DDIF$DECW_VIEWSHR12 (DECwindows interface) and DDIF$CC_VIEWSHR (character-cell interface) widgets. |
By using the LIB$FIND_IMAGE_SYMBOL routine to reference the entry points to the DDIF$DECW_VIEWSHR, DDIF$DECW_VIEWSHR12, and DDIF$CC_VIEWSHR images, an application can dynamically determine whether it can execute in a given environment. The DDIF$VIEW.EXE application now replaces this routine.
The previous DDIF$VIEWSHR.EXE shareable image is still included to maintain compatibility with applications linked against it. However, new applications (and previous applications that take advantage of new features) should use the new shareable images.
| Previous | Next | Contents | Index |