# 移植性と保守性

この章は、移植性の高いアプリケーションを書くため、およびアプリケーションが 共通デスクトップ環境の今後のリリースに対して互換性があることを保証するための 情報について説明します。

RDMAP.port.mkr.2
RDMAP.port.mkr.4

## 移植性の問題

この節では、共通デスクトップ環境をサポートする、異なるプラットフォーム間 でのアプリケーションの移植性に関する問題を説明します。

### 規格

アプリケーションを共通デスクトップ環境に準拠させるには、
Motif 2.1、
ANSI-C、
X11R6.2規格に従わなければ なりません。Ｃ＋＋でアプリケーションを開発している場合は、Ｃ＋＋バージョン 2.0以降を使用してください。共通デスクトップ環境のアプリケーションを作成する とき、POSIXなどのほかの規格に固執することはありません。デスクトップの アプリケーション・プログラム・インタフェース(API)を使用するアプリケーションは、 他の共通デスクトップ環境プラットフォームへ移植できます。しかし、POSIXを使用 するとソフトウェアの移植性が拡張されます。

ここで言う
POSIX規格は、 IEEE Std 1003.1-1990、IEEE Standard for Information Technology—Portable Operating System Interface (POSIX)—Part 1: System Application Program Interface (API) [C Language], ISBN 1-55937-061-0を指します。

またMotif 2.1規格は、IEEE Std 1295、Standard for Information Technology—X Window System Graphical User Interface—Modular Toolkit Environment
を指します。

上記の２点の注文については、 RDMAP.pref.mkr.2を参照してください。

### Makefile

X11など、共通デスクトップ環境が依存しているライブラリは、プラットフォーム が異なれば別の場所にインストールされていることがよくあります。これを解決する には、プラットフォーム固有のリファレンスを取り込むか、各プラットフォーム別の makefileを書いてください。

また、`make`プログラムの機能はプラットフォームによって 異なります。アプリケーションに対してmakefileを１つだけしか書かないのであれば、 プログラムの移動先であるプラットフォームが使用している共有の `make`機能を使用してください。プラットフォーム固有の `make`機能は使用しないでください。

デスクトップと統合するのに、共通デスクトップ環境では、定義された定数 (`-D`パラメータなど)を追加する必要はありません。POSIXなど の規格に従う場合は、規格固有のフラグを追加してコンパイルする必要があります。 特殊なコンパイラ要件があるかどうかについては、規格のドキュメントを参照してくだ さい。

`/usr/dt/examples`の各サブディレクトリには、異なる プラットフォーム用のmakefileの例が入っています。これらのmakefileは、システム の相違点を考慮しています。特に、一般的なmakefileの例については、 `/usr/dt/examples/dtdts` `ディレクトリ` を参照してください。

#### コンパイル・オプション

アプリケーションがデスクトップの`include`ファイルを検索 できるようにするには、次の行を各makefileのコンパイル行に追加してください。

    -I/usr/dt/include

#### リンク・オプション

アプリケーションがデスクトップ・ライブラリを参照できるようにするには、 次の行を各makefileのリンク行に追加してください。

    -L/usr/dt/lib -l<libname1> -l<libname2>...

libname1、 libname2はアプリケーションが参照するライブラリ の名前です。
デスクトップ・ライブラリ名は必要なだけ指定することができます。 次に例を示します。

    -L/usr/dt/lib -lDtSvc -ltt -lXm

このように指定すると、アプリケーションはデスクトップ・サービス、ToolTalk メッセージ・システム、Motif 2.1ライブラリを参照します。

### ファイル命名規則

アプリケーション・ファイル名とアプリケーションが生成するファイルの名前は、 １４文字以内にしてください。そうすれば、長いファイル名をサポートしていない プラットフォームに移植できるようになります。この制限を持つプラットフォームが いくつかあります。

エンド・ユーザが生成するファイル名には、この制限は当てはまりません。

### ディスプレイ・サポート

アプリケーションは、次のようなディスプレイ・オプションと構成をサポート する必要があります。

- モノクロ・ディスプレイ （白黒アイコンを含む）

- カラー・ディスプレイ（カラー・アイコンを含む）

- VGA(640x480 - アプリケーション・ウィンドウまたはフォント・サイズが完全に 画面に適合するようにサイズを調整する）のような小さい画面

カラー・アイコンを作成するために
アイコン・エディタを使用すると、より容易にアプリケーションが他のデスクトップ・ アプリケーションとカラーを共有することができます。これにより、
疑似カラー・ディスプレイで実行するときにカラー・セルの浪費を防ぎます。 `
`

## 共通デスクトップ環境のMotifウィジェット・バイナリ の互換性のガイドライン

すでにサブクラス化したウィジェットのデータ構造体のサイズに依存する標準 Xt APIを使用して実装しているウィジェット・サブクラスは、Motifまたは共通デスク トップ環境の新バージョンとの互換性がない可能性があります。Motifの新バージョン のスーパークラスに新規フィールドが追加されている可能性があるからです。たとえば Motif 2.0の`XmManager`および`XmPrimitive` クラスに新規フィールドが追加されています。

サブクラスは、ウィジェット・インスタンスの開始アドレスに関連して指定され たインスタンス・フィールドに対するコンパイルされたリファレンスを持つので、 非互換が起こります。スーパークラス・インスタンス構造体を拡張したウィジェットを 持つ新しいMotifライブラリをインストールした場合に、コンパイルされた リファレンスは間違ったメモリの場所を指します。

このような問題を避けるため、Motifにはリソースを定義する機能と、インスタンス および、ウィジェットの全構造体の代わりにウィジェットの`部分` 構造体の先頭（アドレス）に関連する制約構造体にあるすべてのフィールドを参照 できるようにするウィジェット・フィールドへアクセスする機能があります （ウィジェットの全構造体は、スーパークラス部分構造体を含みます）。ウィジェット・ クラスを最初に初期化したとき、この機能はこれらの関連するリファレンスを実行時 に解決します。そのため、現在リンクされているMotifライブラリから読み取る、 ウィジェットのスーパークラス・インスタンス構造体のサイズを計算に入れます。

サブクラス化を実装する場合、アプリケーションと共通デスクトップ環境の 今後のリリースとのバイナリ互換可能なものにするには、必ず Motifリファレンスの解決機能を使用してください。

このMotif機能に関する詳細については、Motif 2.1の `XmResolvePartOffsets(3x)`および `XmResolveAllPartOffsets(3x)`のマニュアル・ページと、 Motifプログラマーズ・リファレンスを参照してください。 ソースコード例は`/usr/dt/examples/motif/dogs`にあります。 `
`