この章では、SunOS バイナリ互換パッケージが、システムインタフェースとして提供するバイナリ互換性について説明します。この章で述べる機能と制約事項は、ウィンドウベースと非ウィンドウベースのアプリケーションのどちらにも適用されます。 第 3 章「ウィンドウシステム互換性」には、OpenWindows バイナリ互換パッケージに固有の互換性情報を収めてあります。
まず、SunOS バイナリ互換パッケージ が解決する非互換性の主なものを下にリストします。その後で、それぞれについて詳しく説明します。これらの非互換性の一部はソース互換パッケージにより解決されます。ソース互換パッケージは、バイナリ互換パッケージとともにインストールしておく必要があります。
この 2 つのパッケージは次のことを行います。
SunOS 4.x のバイナリが実行されるとき、正しいライブラリ群が適正にリンクされロードが行われるようにします。
a.out オブジェクトファイル形式の SunOS 4.x 実行ファイルを、Solaris 2.x リリースで実行できるようにします (Solaris 2.x ではデフォルトのオブジェクトファイル形式は ELF です)。
すべてのライブラリルーチンおよびシステムコールについて、SunOS 4.x と同様な動作が実行されるようにします。コールへのインタフェースまたはコールの動作が異なっていても、このマッピングにより SunOS 4.x のバイナリが確実に初期の動作をとるようにされます。
静的リンクと動的リンクの混在した SunOS 4.x の実行可能ファイルが、Solaris 2.x リリースで正常に実行されるようにします。
SunOS 4.x と同様なシグナル処理を提供し、SunOS 4.x と Solaris 2.x のシグナル間のマッピングを正しく行います。
サポートされている SunOS 4.x の ioctl() のセットを、対応する Solaris 2.x の ioctl() に正しくマッピングし、ioctl() のパラメータもマッピングします。
コマンドおよびユーティリティがそれぞれ予期された位置にあることを確認し、必要があれば、パス名のマッピングを透過的に行います。
ファイル形式が異なる場合、または SunOS 4.x のファイルに対応するファイルが Solaris 2.x リリースにない場合には、可能な限りシステムファイルの SunOS 4.x 互換バージョンを提供します。
システムファイルの名前またはパスが異なる場合に、適正なリンクがセットアップされるようにします。
この項では、バイナリ互換パッケージを使っても非互換性が残ってしまうような状況について説明します。非互換として規定されている機能を使用するアプリケーションは、処理が単に失敗するだけの場合もありますが、SunOS 4.x の下で実行したときとは異なる結果をもたらすか、または、SunOS 5.x で予定されているのとは矛盾する結果をもたらすこともあります。
SunOS 4.x には、ユーザ、ホスト、グループなどに関する情報を検索する一群の関数があります。これらは、情報検索の順序によって 2 つのセットに分類されます。1 セット目の関数とは、リファレンスマニュアルの次の項に説明があるものです。
gethostent(3N)、getnetent(3N)、getnetgrent(3N),getprotoent(3N)、 getpublickey(3R)、getrpcent(3N)、getsecretkey(3R)、getservent(3N)、 yp_get_default_domain(3N)
これらの関数は、まず該当の NIS マップを検索します。そして、NIS が実行中でない場合に限り、/etc 内の対応するファイルを検索します。2 セット目の関数は、リファレンスマニュアルの getpwent(3V) と getgrent(3C) の項に説明があります。この 2 つの関数は、まず /etc の中のファイルを検索します。その結果データが見つからない場合は、NIS が実行状態にあれば、NIS に対して照会します。静的にリンクされているアプリケーションの場合は、これらの関数は、SunOS 5.x でも、SunOS 4.x で実行した場合とまったく同じ働きをします。
SunOS 5.0 以降のリリースでは、上に列挙した情報検索関数はすべて、ネームサービススイッチを介してそれぞれの機能を実行するように変更されました。実行時に、構成ファイル /etc/nsswitch.conf を参照して情報ソースとルックアップ順序が決定されます。
SunOS 4.x で静的にリンクされているアプリケーションを、バイナリ互換パッケージを使って SunOS 5.x で実行した場合、これら情報検索関数は SunOS 4.x のときとまったく同じ働きをします。このため、その動作がネイティブ SunOS 5.x アプリケーションと異なる可能性があります。SunOS 5.x を実行するマシンのネームサービススイッチが、この項の冒頭で述べたような動作をするものとして構成されていない場合は、静的にリンクされた 4.x アプリケーションの中の情報検索関数は、ネイティブ 5.x アプリケーションの場合とは異なる動作をすることがあります。一方、SunOS 5.x で実行するものとして動的にリンクされた 4.x アプリケーションにおいては、情報検索関数は、ネイティブ 5.x アプリケーションの場合と同じ動作をします。
SunOS 4.x リリースは、a.out オブジェクトファイル形式を使用します。Solaris 2.x リリースは、新しい拡張可能リンク形式 (ELF) を使用します。Solaris 2.x プログラミングツール (cc、ld、ar など) は ELF ファイルを生成します。また、デフォルトの exec() ファイル形式は ELF です。
Solaris 2.x の exec() システムコールは、実行ファイルの形式 (a.out または ELF) を識別し、それぞれに応じた正しいロード手順を使用します。
デフォルトの core ファイル形式は、SunOS 4.x では a.out であり、Solaris 2.x リリースでは ELF です。Solaris 2.x で バイナリ互換パッケージを使って a.out ファイルを実行した場合、core ファイルは a.out 形式で生成されます。互換性メカニズムが起動されるのは、a.out バイナリ形式のファイルをロードし実行した場合だけです。
a.out 実行ファイル形式、core 形式を想定して動作する SunOS 4.x プログラムは、他の形式のファイルに対しては働きません。たとえば、a.out 形式のファイルを対象とした SunOS 4.x の nm(1) コマンドなどは、ELF 形式に対しては働きません。
Solaris 2.x リリースのプログラミングツールおよびユーティリティは、a.out 形式のバイナリおよび core ファイルに対しては、意図したとおりの働きをしません。
SunOS 4.x と Solaris 2.x のシステムコールの間には、システムコール番号の違いやコールインタフェースや動作の違いなど、大きな相違点がいくつかあります。バイナリ互換パッケージは、マッピングを行なったり、意図したインタフェースまたは動作を提供する代替ルーチンを使用するなどして、2 つのバージョン間のシステムコールの相違点のほとんどを吸収しています。
システムコールのマッピングの結果として、バイナリ互換パッケージの下で実行される truss(1) プログラムの出力が、予測とは異なるものになることがあります。たとえば、システムコールの名前が違ったり、予期したときにシステムコールが発生しなかったりすることがあります。また、コールに渡される引数や戻り値が違うこともあります。たとえば、パス名の解決処理を必要とする場合に (「パス名の解決処理」を参照)、あるファイルに対する open() コールの結果、実際には別のファイルがオープンされることがあります。
アプリケーションは、libc に収められているラッパルーチンを介してシステムコールを呼び出す必要があります。トラップメカニズムを介してシステムコールを直接呼び出すことは、絶対にしないでください。これを行うと、データとシステムコール番号を正しくマップすることができません。
システムコールに関する非互換性の一部は、このパッケージでは対処できません。その理由としては、コールがすでに廃止されていたり、ユーザアプリケーションで使用すべきものではなかったり、他の独立パッケージに組み込まれたりしていることが考えられます。以下、この種のコールをリストし、それぞれについて説明します。
Solaris 2.x バージョンの acct() には、アプリケーションバイナリインタフェース (ABI) および System V インタフェース定義 (SVID) との互換性がありますが、SunOS 4.x にはその互換性はありません。相違点は、アカウントのオフへの切替えに関する点と、アカウントレコードの形式です。Solaris 2.x リリースでは、アカウントがすでにオンになっているときは、特定のパス名を指定して acct() をコールすると、アカウントはオフにされます。同じ条件下での SunOS 4.x リリースの場合は、コールしても別のアカウントファイルに切り替わるだけで、アカウントはオフにはなりません。
バイナリ互換パッケージでも、また Solaris 2.x 環境でも、監査はサポートされていません。監査は、Solaris 2.x リリースでは独立したパッケージで取り扱います。そのパッケージが提供する監査機能には、SunOS 4.x とのバイナリ互換性がありません。
このコールは廃止されました。Solaris 2.x リリースまたはバイナリ互換パッケージではサポートされません。
Solaris 2.x では、fcntl(2) ロックに加えて、flock の 1 バージョンがインプリメントされています。このバージョンと SunOS 4.x のバージョンは、完全なバイナリ互換性を備えているわけではなく、以下のような相違点があります。
flock では、排他的ロックを要求する前にファイルが書き込み用にオープンされていることが必要です。
共用ロックを取得するには、ファイルに対する読み取り許可が必要です。
プロセスが flock() を使ってすでにロックされているセグメントをロックすると、古いロックタイプが除去され、新しいロックタイプが効力を持ちます。
ロックは、fork() 関数の子プロセスには継承されません。
SunOS 4.x の下で flock() メカニズムにより取得したロックは、それを設定したシステムの中でしか認識されませんでした。この制約はなくなりました。
SunOS 4.x の flock() 動作は、デフォルトの Solaris 2.x リリースでもこのパッケージでも利用できません。
古い Version 7 および 4BSD ターミナルドライバによりサポートされていた ioctl() に加えて、filio、sockio、streamio、termio、termios、mtio、および dkio に関連したすべての ioctl がサポートされます。その他には、Solaris 2.x プラットフォームの標準デバイスに関連した ioctl() のみが提供されています。2 つのバージョン間での ioctl() 番号の相違 (サポートされている ioctl() の場合) は、透過的に処理されます。ioctl() のパラメータは、必要に応じてマップされます。
以下に示す SunOS 4.x の ioctl() には、Solaris 2.x との互換性がありません。
この ioctl() は、Solaris 2.x では使用できませんが、バイナリ互換パッケージはこれをサポートしています。この ioctl() は、DKIOCINFO で置き換えられました。DKIOCGCONF には、SunOS 4.x の DKIOCGCONF 構造体と DKIOCINFO 構造体とを組み合わせた情報が含まれています。
この ioctl() は Solaris 2.x ではサポートされていません。バイナリ互換パッケージでは、これは EINVAL を戻します。
SunOS 4.x では、この ioctl() は、フロッピーデバイスの書き込みチェックを切り替えます。バイナリ互換パッケージでは、この ioctl() はフロッピーデバイスの書き込みチェックを切り替えませんが、操作成功のステータスを返します。
この ioctl() が使用できるのは、xd(7)、xy(7)、ipi(7) の各ドライブの場合だけです。この ioctl() は、SCSI デバイスの場合は失敗します。この種のデバイスの場合は、USCSI ioctl() を使用してください。
この ioctl() は廃止され、Solaris 2.x リリース、バイナリ互換パッケージではサポートされません。
この ioctl() は廃止され、Solaris 2.x リリース、バイナリ互換パッケージではサポートされません。
この ioctl() は廃止され、Solaris 2.x リリース、バイナリ互換パッケージではサポートされません。
この ioctl() は廃止され、Solaris 2.x リリース、バイナリ互換パッケージではサポートされません。
この Solaris 2.x システムコールは、SunOS 4.x の場合とは異なる働きをします。最初の引数として -1 が与えられた場合は、呼び出したプロセス自身も終了されます。SunOS 4.x では、この動作はありませんでした。
SunOS 4.x での pipe() システムコールは、1 つのディスクリプタは読み取り用に、別のディスクリプタは書き込み用にと、それぞれ用途を分けてオープンします。Solaris 2.x では、このシステムコールは、ディスクリプタを読み取りと書き込みの両用としてオープンします。この相違点の影響を受けるバイナリは、(仮にあったとしても) ほとんどないので、互換バージョンは提供されていません。
SunOS 4.x の ptrace() システムコールに渡すオプションの addr2 引数は、サポートされていません。また、Solaris 2.x リリースでは、次のリクエストはサポートされません。
/* 10, attach to an existing process */
/* 11, detach from a process */
/* 12, get all registers */
/* 13, set all registers */
/* 14, get all floating point regs */
/* 15, set all floating point regs */
/* 16, read data segment */
/* 17, write data segment */
/* 18, read text segment */
/* 19, write text segment */
/* 20, get all fpa regs */
/* 21, set all fpa regs */
/* 22, get register window n */
/* 23, set register window n */
/* 22, filler */
/* 23, filler */
/* 24, trap next sys call */
/* 25, dump process core */
/* 26, set write breakpoint */
/* 27, set access breakpoint */
/* 28, clear debug register 7 */
/* 26, filler */
/* 27, filler */
/* 28, filler */
/* 29, get u.u_code */
Solaris 2.x リリースとバイナリ互換パッケージには、このシステムコールはありません。ユーザアプリケーションでこのシステムコールは必要とされないはずです。
デフォルトの Solaris 2.x リリースとバイナリ互換パッケージには、このシステムコールはありません。
バイナリ互換パッケージは、SunOS 4.x のライブラリと互換性を持つ一組のライブラリを提供します。Solaris 2.x リリースにおいて、ライブラリルーチンのインタフェースや動作が変更されていても、バイナリ互換パッケージを使用していれば、ユーザアプリケーションがその影響を受けることはありません。
バイナリ互換パッケージを使用している場合は、/etc/xtab ファイルを取り扱うライブラリルーチンは正しく働きません。『SunOS Reference Manual』の中の xtab(5) および exportent(3) の項を参照してください。
setlocale() が戻す文字列内のロケールの順序には、SunOS 4.x と Solaris 2.x の間で相違があります。この文字列は、一般に後続の setlocale() に対するコールで使用されるものであり、この順序は問題ではありません。特定のロケール順序を必要とするようなアプリケーションは、バイナリ互換性を備えていない場合があります。
データのマッピングはすべてバイナリ互換ライブラリの中で行われます。誤ったアドレスが引数として渡された場合に、必ずしも、予定されている EFAULT エラーが戻されるとは限りません。データマッピングライブラリルーチンは誤ったアドレスを捕捉しようとしますが、これは常に可能ではないため、誤ったアドレスのアクセスの結果として、バスエラー/セグメンテーション違反が生じることがあります。
バイナリ互換パッケージは、SunOS 4.x と互換性のあるシグナル処理メカニズムを備えています。また、シグナル番号の相違も解決します。
Solaris 2.x リリースでは、多くのシステムファイルの名前が変更されたり、移動されたりしています。このリリースでは存在しなくなったものもあり、形式が変わったものもあります。バイナリ互換パッケージは、シンボリックリンクを作成するか新規ファイルをインストールし、さらにデータをマップすることによって、可能な限りこの問題に対処します。
移植可能プログラムでは、システム依存ファイルの使用は避けてください。このようなファイルへのアクセスを必要とするプログラムは、提供されている標準インタフェースルーチンを使ってそのアクセスを行う必要があります。たとえば、この種のプログラムでは、/etc/mtab ファイルを直接オープンし読み取るのではなく、getmnt() ファミリのルーチンを使って mtab ファイルの内容にアクセスするようにします。
Solaris 2.x のアカウントファイルは、SunOS 4.x のアカウントファイルと形式が異なります。アカウントファイルにアクセスするアプリケーションには、バイナリ互換性はありません。
Solaris 2.x リリースでは、システムファイルのエクスポートの取り扱い方が SunOS 4.x の場合と大幅に異なります。これらのファイルについてのバイナリ互換性はありません。しかし、ユーザアプリケーションがこれらのファイルにアクセスする必要はないので、これは問題ではありません。
これらのファイルの名前と形式が変わりました。バイナリ互換パッケージは、これらのファイルに対する読み取り専用アクセスをアプリケーションに与えるために必要なマッピングを行います。これらのファイルに対する書き込みアクセスを必要とするアプリケーションには、バイナリ互換性はありません。アプリケーションは、これらのファイルへの書き込みは行わないものと想定されます。
これらのファイルへのシンボリックリンクはサポートされなくなりました。つまり、アプリケーションが /etc/fstab または /etc/mtab へのリンクを作成し、シンボリックリンクをオープンしようとすると、その open() コールは失敗します。
このファイルに直接対応するファイルは Solaris 2.x リリースにはありません。バイナリ互換パッケージの一部としても提供されていません。このファイルを使用するアプリケーションには、バイナリ互換性はありません。
Solaris 2.x リリースでは、実際のパスワードはシャドウファイル内に保管されます。passwd ファイルにアクセスしてパスワードを取得するアプリケーションにバイナリ互換性はありません。すべてのアプリケーションは、getpw() インタフェースルーチンを介してこのファイルにアクセスする必要があります。
SunOS 4.x の printcap は、SunOS 5.x では terminfo ディレクトリツリーで置き換えられました。バイナリ互換パッケージは、アプリケーションが実行されているホスト上の対応するデータへの読み取り専用アクセスを、アプリケーションに与えます。printcap への書き込みアクセスはサポートされていません。
SunOS 4.x ではこのファイルは廃止されました。utmp ファイルの形式およびアクセスメカニズムが著しく異なるため、/etc/ttys と utmp ファイルの間の関係に依存するプログラムは、Solaris 2.x リリースでは働きません。動的にリンクされるアプリケーションには、ttyslot を使用してください (静的にリンクされるアプリケーションには無効です)。
SunOS 4.x では、このファイルは /etc/ttys に取って代わりました。SunOS 5.x では廃止されました。互換性は提供されていません。
これらのファイルには、who、write、login などのコマンドに関連するユーザ情報とアカウント情報が入っています。Solaris 2.x では、これらのファイルはそれぞれ一対のファイルで置き換えられました。たとえば、/etc/utmp は /var/adm/utmp と /var/adm/utmpx で、/var/adm/wtmp は /var/adm/wtmp と /var/adm/wtmpx で置き換えられました。これらのファイルのどちらかをオープンしようとしたアプリケーションは、それに対応する 2 つのファイルを連結したものを受け取ることになります。
これらのファイルへのシンボリックリンクはサポートされなくなりました。つまり、アプリケーションが /etc/utmp または /var/adm/wtmp へのリンクを作成し、シンボリックリンクをオープンしようとすると、その open() コールは失敗します。
ローカライズされた 4.x のアプリケーションは、バイナリ互換パッケージが静的か動的かに関わらず、US 版の SunOS 5.x では実行されません。特定の 4.x アプリケーションがローカライズされた Solaris 2.5 で実行できるかどうかを判別するには、該当のローカライズ関係マニュアルを参照してください。
1 つのプロセスがオープンできるファイルディスクリプタの数に関するデフォルトの制限は 64 です。この制限数は、csh(1) の limit コマンド、sh(1) および ksh(1) の ulimit コマンド、そして setrlimit(2) システムコールを使って大きくすることができます。ファイルディスクリプタの制限数を 256 より大きくした場合は、静的または動的のどちらのバイナリ互換パッケージの下で実行するプロセスも失敗します。これは、実際にオープンされているファイルが 256 より少ない場合でも失敗することがあります。4.x のほとんどのアプリケーションは、ファイルディスクリプタを 256 個までしか扱えません。
SunOS 4.x では、システムがサポートする最大のメジャーデバイス番号は 255 でした。SunOS 5.x では、メジャーデバイス番号に関する最大制限がはるかに大きくなっています。静的または動的バイナリ互換パッケージの下で実行される 4.x アプリケーションは、有効なデバイス番号であっても 255 より大きい値は認識できません。
静的にリンクされている実行可能ファイルの動的リンクを可能にするために、パッケージではデフォルトで動的リンクを使用可能にしています。この設定により、すべて静的にリンクされた SunOS 4.x 実行可能ファイルの性能が低下します。この機能を無効にするには、スーパーユーザになり、/etc/system ファイルの「set:」部分に次の行を追加してください。
set enable_mixed_bcp=0