17.8 Windows 64 ビットサポート

アプリケーションを 64 ビットにすることが義務付けられていて、ビルド・コンピュータをインストールする時にのみ、64 ビットのサポートを有効にすることが推奨されています。例えば、企業基準で必須の場合などです。64 ビットのサポートを有効にすることによる短所は、以下の通りです。

• 32 ビット及び 64 ビットの両方の DLL が常にビルドされるため、コンパイルにかかる時間が倍になります。
• DISPLAY、REQUEST、POPUP コマンドを使用するファンクションは、32 ビットの DLL であったとしてもコンパイルに失敗します。

• 64 ビットのコンパイラを入手する必要があります。

機能しない、またはサポートされない LANSA 機能

• グラフィック・サーバーはサポートされません。32 ビットと 64 ビットの両方で作動する、最新の代替品が多く存在しますので、それを利用するようにしてください。これは、primitive の PRIM_GRPH にマップされます。
• エクスプローラー・コンポーネントのプロパティ AutoRefresh は機能しません。
• ZIP の BIF はサポートされません。
• DISPLAY、REQUEST、POPUP コマンドは、64 ビットのアプリケーションではサポートされません。
• Web ファンクション はサポートされません。

• 特化された LANSA の組み込み関数 (BIF) は、64 ビットのアプリケーションではサポートされません。開発環境は 32 ビットのため、互換性がないからです。

インストール時の考慮事項

• 開発者は 64 ビットのサポートを有効にしないことが前提となっています。この意図は、ビルド・コンピュータのみ 64 ビットのサポートが有効だからです。ですから、64 ビットのサポートのみにすることはできません。64 ビットのサポートを有効にした結果、どのような影響があるかについて、特に注意すべき点は以下の通りです。

• 32 ビットと 64 ビットの両方でコンパイルが実行されます。つまり、今まで以上に時間がかかることを意味しており、開発者マシンにはあまり向いていません。

• 32 ビットと 64 ビット両方のWindows のインストーラー MSI パッケージが生成されます。

• Visual Studio 2010 Professional (またはこれ以降) もしくは、Visual Studio 2012 Express for Desktop (またはこれ以降) では、64 ビット・コンパイルのサポートが必須です。Visual LANSA のインストールで提供されるコンパイラは、64 ビット・コンパイルがサポートされません。

• LANSA のインストール前に Visual Studio がインストールされていた場合、これが検出され、LANSA が使用するコンパイラとなります。

• サポートされるコンパイラがインストールされていない場合、LANSA 提供のコンパイラがインストールされ、有効なコンパイラとなります。64 ビットのコンパイルを可能にするためには、64 ビット・コンパイルをサポートするコンパイラの 1 つをインストールして、次のレジストリのエントリーを変更して、LANSA 提供のコンパイラを無効にします。
  HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\LANSA\MicrosoftCompiler\2010\Enabled 32 ビット PC の場合、 HKEY_LOCAL_MACHINE\SOFTWARE\LANSA\MicrosoftCompiler\2010\Enabled
  を 0 にする。
• インストールされた Visual Studio の一番新しいバージョンが 64 ビット・コンパイルをサポートするものではない場合、サポートしているものをインストールしてください。これは、次に LANSA が開始された時に検出されます。

• (サポートされていない) DISPLAY、REQUEST、POPUP コマンドを含む関数をコンパイルした場合はエラーとなり、32 ビット・コンパイルだったとしてもコンパイルは全く行われません。これが、開発者のマシンで 64 ビット・サポートを使用可能にすべきでないもう 1 つの理由です。開発者が RDML ファンクションと 64 ビット・アプリケーションの両方で作業する必要がある場合は、コンピュータに同じリポジトリを使用する 2 つのシステムをインストールすることができます。

プログラミング時の考慮事項

• どの LANSA 機能に関しても、最大サイズは増やされていません。例えば、RDMLX リストの最大サイズは 20 億行で、各エントリーは 20 億バイト長のままです。つまり、既存の制限で十分であるとの判断です。これは同時に、32 ビットと 64 ビットアプリケーション間の互換性が高いことを意味しています。例えば、組み込み関数 SND_TO_DATA_QUEUE や RCV_FROM_DATA_QUEUE が区別なく使用できます。ジョブ待ち行列エミュレーション が 32 ビットまたは 64 ビットのジョブ待ち行列モニターのいずれにも使用でき、ジョブは32 ビットまたは 64 ビットのいずれからも実行できます。どのプラットフォームでジョブを実行しようとも、64 ビットのジョブ待ち行列モニターは 実行されたジョブを 64 ビットとして実行することに注意してください。
• 32 ビットの ODBC ドライバを使用してロードされたインポート・テーブルは、ファイルのロードに使用するために同名で 64 ビットの DSN を作成するか、または 64 ビットドライバに IO をリダイレクトするように配布時に CONNECT_SERVER を使用する必要があります。

• ActiveX を LANSA RDML に加えるには、登録された ActiveX の 32 ビット・バージョンが必要です。この ActiveX を実行するには、LANSA ランタイムと同じプロセッサ・アーキテクチャのバージョンが登録されいる必要があります。つまり、もし LANSA ランタイムが 64 ビットの場合には、64 ビットの ActiveX が配布先のPCに登録されていなくてはいけません。

32 ビット及び 64 ビットアプリケーションの同一データベースへのアクセス

32 ビットと 64 ビットアプリケーションが同一のデータベースにアクセスしている場合、特に実稼働システムにアプリケーションを配布する際の考慮事項は以下の通りです。

• LANSA では、32 ビットまたは 64 ビットいずれかのアプリケーションを使用することを推奨しています。この方がよりシンプルだからです。例えば、SuperServer の利用時、32 ビットと 64 ビットのクライエント両方を使用している場合は、64 ビットのサーバーのみを使用してください。クライアントはデータベースには直接アクセスしないため、複雑にはなりません。どちらか一方のみに限定して選択する方が良いです。
• 自動生成を使用して相対レコード番号を割り当ててください。外部ファイルを使用して相対レコード番号を割り当てる場合、32 ビット及び 64 ビットのアプリケーションの両方に対して RPTH パラメータに同じパスが割り当てられていない限り、重複が発生します。現在外部ファイルを使用しているファイルは、アップグレードツール機能 [ファイルを変換して識別用の列を使用] を使って自動生成を使用するように変更することができます。

• デーブルのアップグレードは、以前の CTD ファイルとインストールされる新しい CTD ファイルを比較することで特定されます。従って、アップグレードされる最初のシステムのみ、データベースをアップグレードする必要があります。これが、MSI インストール時にデータベースのアップグレードが省略値としてオフになっている理由であり、ユーザーごとのインストールにてデータベースのアップグレードができない理由です。
  既存の OAM について、64 ビットが存在せず 32 ビットのみ存在する場合、または逆の場合、どちらが最新の OAM でしょうか? これは、ユーザーが管理しなければいけません。もし 32 ビットが最初にインストールされる環境である場合、すべてのアップグレードやパッチについても、引き続き 32 ビットを使用してください。64 ビット環境が同じレベルである場合には、アップグレードやパッチのデータベース変更用マシンを切り替えるという選択肢はありますが、あまりお勧めできる方法ではありません。一貫性を持ち、最初から一つのマシンを使用するようにしてください。

注意すべき環境の相違点

• 32 ビットアプリケーションのシステム・ディレクトリは x_win95\x_lansa の形式です。64 ビットアプリケーションの場合は、 x_win64\x_lansa となります。つまり、*SYS_DIR などのシステム変数は異なる値を返します。
• Visual LANSA は 32 ビットアプリケーションです。その為、Visual LANSA と 64 ビットで生成された DLL との間のやり取りは発生しません。
• Visual LANSA がテーブルからデータをロードしたりアンロードしたりするのに 32 ビットの OAM を必要とする為、32 ビットの OAM が常に作成されてきていましたし、今後も常に作成されます。64 ビットのビルドコマンドは、32 ビット にて既に行われたものとして、常に SQL テーブルのビルドをスキップします。
• Windows インストーラーには、ショートカットのターゲット・ディレクトリが c:\program files から c:\program files (x86) に変更されてしまうという既に知られている問題があります。しかしながら、それでもショートカットはあたかも c:\program files であるかのように、正しく動きます。たとえ 32 ビットバージョンのアプリケーションが c:\program files (x86) にインストールされていたとしても、実行はされません。実行されるのは、64 ビットバージョンです。詳細は、64 ビット OS の 32 ビット MSI: 64 ビット・アプリのターゲット・パスを 32 ビットに変換 (英語) を参照してください。

• Windows\system 32 でも同様の状況が発生します。ショートカットは正しいように見えていても、オブジェクトを探すことができません。ですから、このディレクトリを指すショートカットを作成することは、有効ではありません。