Multiplatform Programming Guide/ja

│ Deutsch (de) │ English (en) │ español (es) │ français (fr) │ 日本語 (ja) │ polski (pl) │ русский (ru) │ 中文（中国大陆）‎ (zh_CN) │

このページは、マルチプラットホーム　アプリケーションを書くにあたって考慮すべきチュートリアルの最初のページです。ここでは、これから移植をおこないやすいようなプログラムを書くために、必要な注意事項と、すでに製作したプログラムの移植のプロセスをのべています。この記事をよりよいものにするために、手助けしてくれる他の人を募集しています。

マルチプラットフォームプログラミングへの招待

マルチプラットホーム開発のために、沢山の種類のパソコンが必要でしょうか？

この質問に答えるには、まず、誰が潜在的なユーザーなのか、そして、どのようにプログラムが使われるのかということを決めるべきです。この質問は、アプリケーションをどこへ提供するのかによるからです。

たとえば、ヨーロッパにおいては、デスクトップソフトウエアを開発するなら、WindowsかOS Xで開発することを意味します。OS Xは一番普及しているUnixであり、デスクトップです。 100:10:1の法則を覚えておいてください。これは、大きな組織やグループのユーザーのことを言っていますが、Windows,Mac,Linuxでも、だいたいにおいてこの比率があてはまらないこともありません。

違う場所では、たとえば、南アメリカでは、Windowsがほとんどですが、Linuxはデスクトッププラットホームでシェアを伸ばしています。商業的にWindowsは大きなスーパーマーケットネットワークで売られ、MacOSXがビデオやサウンドの編集に利用されています。

OS XやLinuxを走らせているユーザーのために、開発し、パッケージして配布する特別な努力をする甲斐があるでしょうか？明らかに、プロジェクトがそれを必要とするならば、答えは「イエス」でしょう。また、もし特別な努力が大変小さなものならば、それもまた「イエス」でしょう。 特別な努力が終わりのないソフトウエアの王道として、あらゆる困難を越えてでもすべてのOSをサポートしたいと思うなら、その答えも、また「イエス」でしょう。

もし、Webサーバーとしてのソフトウエアを開発するなら、今のところもっとも利用されているプラットホームはUNIXでしょう。この点において、Linux,Soralis, BSD、そしてほかのUnix互換OSはターゲットとして意味をもつプラットホームです。これに、WindowsNTを加えてもよいでしょう。

もし、ひとつのプラットフォームについて開発をおこなうならば、（そして、将来にわたって他のプラットフォームをサポートしないならば）おそらくFreePascalとLazarusは仕事には最適なツールではないかもしれません。 もし、Windowsのデスクトップのソフトウエアのみを書くならば、Delphiのようがよりよい選択かもしれません。

一度、クロスプラットフォーム開発をマスターすれば、通常は、ソフトウエアの設計や、問題解決にのみ、注力すればよく、どんなプラットフォームで動作させるかについては、ほとんど楽観的に、自由に考えていれば良いことになります。 つまり、１つのプラットフォームで書いている時と同様、クロスプラットフォーム開発を身に付けていれば、他のプラットフォームについての特有な問題はほとんど無視すればいいのです。 しかしながら、いくつかの点で、異なるプラットフォームでプログラムをテストしたり、実際に走らせることは、すべてのターゲットのOSで適用できているかどうか判断する助けになるでしょう。

もし、異なる物理的なPCがいやだったら、デュアルブートのWindows-LinuxのPCや、Mac上の仮想マシンの下で動くWindowsやLinuxを使うとよいでしょう。

Windows と Linux間での相互移植

Windows API 関数

多くのWindowsプログラムは、WindowsAPIを使っています。クロスプラットホームアプリケーションでは、それらのコードは現れないか、({$IFDEF Win32}のような）コンパイル条件中に隠されるべきです。

幸いにもよく使われる多くのWindowsAPI関数はマルチプラットホーム流にLCLIntfに隠蔽され実装されています。これは、本当にWindowsAPIに多くを依存するプログラムにとって、解決策となるものです。 クロスプラットホームコンポーネントであるLCLを使って置き換えるのがベストです。 たとえば、GDI描画関数は、TCanvasのメンバ関数に置き換えられます。

ファイルシステムの違い

LinuxとWindows間の移植においての基本的な問題のひとつは、ファイルシステムです。 まず、Windowsのファイル名は、大文字小文字を区別しませんが、Unixプラットホームでは区別します。 これは、バグの原因になります。移植性のあるアプリケーションは、両方で成り立つファイル名を付けなくてはなりません。

リナックスには "application directory"　はありません

LinuxとWindows間でアプリケーションをポーティングするのに、ひとつよくよく考慮すべきことは、ファイルシステムです。多くのプログラマーは、実行ファイルのパスを得るために、ExtractFilePath(ParamStr(0)) や、 Application.ExeName を使ってきました。そして、プログラムの実行に必要なファイルも、実行ファイルのある位置を基点にしています。これは、Linuxでは正しくない方法です。 ParamStr(0)の文字列は実行ファイルのディレクトリを含まないかもしれないだけでなく、シェルプログラム(sh,bash,など）によって、いろんな違いがあるかもしれません。

Aplication.ExeNameでさえ、実行ファイルがどのディレクトリにあるか知ることができそうですが、それはシンボリックファイルかもしれません。あなたは、リンクのあるディレクトリを取得しているわけです。

それでは、どうしたらよいのでしょうか。Linuxでは、コンフィグレーションやリソースファイルを格納するために、２つの異なった場所を使うべきです。

• リソースファイル. (イメージやヘルプファイル等)

実行ファイルとリソースファイルのために、固定的に許された場所にあり、それは変更されません。 この場所は、次のようなところです。:/usr/share/app_name もしくは /opt/app_name

ほとんどのプログラムはroot権限なしで動作させることができます。そして、アプリケーションのために固定された（リソースのための）ディレクトリが与えられ、そのディレクトリは rootユーザーに対してのみ、書き込み権限があるので、このディレクトリは書き込むことができません。リソースファイルからは、読み込みだけが可能です。

• 設定ファイル（コンフィグレーション）

You can use the GetAppConfigDir function from SysUtils unit to get a suitable place to store configuration files on different system. The function has one parameter, called Global. If it is True then the directory returned is a global directory, i.e. valid for all users on the system. If the parameter Global is false, then the directory is specific for the user who is executing the program. On systems that do not support multi-user environments, these two directories may be the same.

There is also the GetAppConfigFile witch will return an appropriate name for an application configuration file.

Here is an example of the output of those functions on different systems:

program project1;

{$mode objfpc}{$H+}

uses
  SysUtils;

begin
  WriteLn(GetAppConfigDir(True));
  WriteLn(GetAppConfigDir(False));
  WriteLn(GetAppConfigFile(True));
  WriteLn(GetAppConfigFile(False));
end.

The output on a GNU/Linux system:

/etc
/home/felipe/project1
/etc/project1.cfg
/home/felipe/.project1

You can notice that glocal configuration files are stored on the /etc directory and local configurations are stored on a hidden folder on the user's home directory. Directories whose name begin with a dot (.) are hidden on Linux. You can create a directory on the location returned by GetAppConfigDir and then store configuration files there.

The output on Windows XP:

C:\Programas\teste
C:\Documents and Settings\felipe\Configurações Locais\Dados de aplicativos\project2
C:\Programas\teste\project2.cfg
C:\Documents and Settings\felipe\Configurações Locais\Dados de aplicativos\project2\project2.cfg

Notice that the function uses the directory where the application is to store global configurations on Windows.

Note: The use of UPX interferes with the use of the GetAppConfigDir and GetAppConfigFile functions.

WindowsのCOMオートメーションなしで、それっぽい事をやるには

Windowsにおいて、オートメーションは、他のプログラムをリモート操作したり、他のプログラムから操作させたりするのに、強力な方法です。 Delphiでは、オートメーションクライアント、オートメーションサーバーのどちらも作成することができます。これは、他のプログラムを操作したり、他のプログラムから操作されるプログラムのことです。

オートメーションは、OS Xや Linuxでは利用できません。しかし、OS XではAppleScriptを使って同じようなことはできます。

AppleScriptはオートメーションと、ある面はとても似ています。たとえば、他のプログラムを操作するスクリプトを書くことができます。これは、AppleScriptがNeoOffice(OpenOffice.orgのMac版)を開始する とても簡単な例です。

 tell application "NeoOffice"
   launch
 end tell

AppleScriptから操作されるように設計されているアプリケーションは、アプリケーションを使うためのクラスとコマンドの"辞書"を持っています。それは、Windowsのオートメーションサーバーと似ています。 しかしながら、NeoOfficeのような辞書をもっていないアプリケーションでさえ、"launch","activate","quit"といったコマンドに応答することができます。 AppleScriptはOS Xスクリプトエディタや、ファインダー、ドックにドロップできるどのようなアプリケーションからでも実行できます。 次の例のように、自分のプログラムからAppleSriptを実行することもできます。

 Shell('myscript.applescript');

This assumes the script is in the indicated file. You can also run scripts on the fly from your app using the OS X OsaScript command:

 Shell('osascript -e '#39'tell application "NeoOffice"'#39 +
       ' -e '#39'launch'#39' -e '#39'end tell'#39);
       {Note use of #39 to single-quote the parameters}

However, these examples are just the equivalent of the following Open command:

 Shell('open -a NeoOffice');

The real power of AppleScript is to manipulate programs remotely to create and open documents and automate other activities. How much you can do with a program depends on how extensive its AppleScript dictionary is (if it has one). For example, Microsoft's Office X programs are not very useable with AppleScript, whereas the newer Office 2004 programs have completely rewritten AppleScript dictionaries that compare in many ways with what's available via the Windows Office Automation servers.

While Linux shells support sophisticated command line scripting, the type of scripting is limited to what can be passed to a program on the command line. No access to a program's internal classes and commands are available with Linux the way they are via Windows Automation and OS X AppleScript.

As with Windows, many OS X and Linux programs are made up of multiple library files (.dylib and .so extensions). Sometimes these libraries are designed so you can also use them in programs you write. While this can be a way of adding some of the functionality of an external program to your program, it's not really the same as running and manipulating the external program itself. Instead, your program is just linking to and using the external program's library similar to the way it would use any programming library.

付記

• http://www.midnightbeach.com/jon/pubs/Kylix.html A guide for Windows programmers starting with Kylix. Many of concepts / code snippets apply to Lazarus.