Difference between revisions of "Multiplatform Programming Guide/ja"

From Free Pascal wiki
Jump to navigationJump to search
 
(15 intermediate revisions by the same user not shown)
Line 9: Line 9:
 
==マルチプラットフォームプログラミングへの招待==
 
==マルチプラットフォームプログラミングへの招待==
  
=== どれくらい沢山の種類のパソコンが必要になるでしょう? ===
+
=== マルチプラットホーム開発のために、沢山の種類のパソコンが必要でしょうか? ===
  
To answer this question, you should first determine who your potential users are and how your program will be used. This question depends on where you are deploying your application.
+
この質問に答えるには、まず、誰が潜在的なユーザーなのか、そして、どのようにプログラムが使われるのかということを決めるべきです。まず、アプリケーションをどういう人々に提供するのか考えてみましょう。
  
For example, on Europe, if you're developing desktop software you may decide that it only makes sense to develop for Windows and OS X. OS X is the most popular Unix in the world and is surging on the desktop, whereas Linux has mostly stalled there. Remember the 100:10:1 rule, which says that in any large organization or group of users, it's not unusual to find Windows, Mac and Linux desktop computers in roughly these ratios.
+
たとえば、ヨーロッパにおいては、デスクトップソフトウエアを開発するなら、WindowsかOS Xで開発することです。OS Xは一番普及しているUnixであり、デスクトップ環境です。
 +
100:10:1の法則はご存知でしょうか。これは、大きな組織やグループのユーザーのことを言っていますが、Windows,Mac,Linuxでも、だいたいにおいてこの比率があてはまると思います。
  
On other places, like South America, Windows is mostly dominant, Linux is rising as a desktop platform, even outselling Windows on big supermarket networks, and Mac OS X is restricted to Video and Sound work.
+
そのほかの地域では、たとえば、南アメリカでは、Windowsがほとんどですが、Linuxはデスクトッププラットホームでシェアを伸ばしています。商業的にWindowsは大きなスーパーマーケットの販路で売られています。MacOSXはビデオやサウンドの編集に利用されています。
  
Are the handful of users running OS X and Linux worth the extra effort that will be required to develop, package, distribute and support separate versions for them? Obviously if the project requires this, then the answer will be yes. Or if the amount of extra effort will be small, then the answer will probably be yes as well. If you want to support them out of principle, then the answer may also be yes as long as the extra effort doesn't get in the way of finishing the software.
+
OS XやLinuxを走らせているユーザーのために、開発し、パッケージして配布する「特別な努力」をする甲斐があるでしょうか?プロジェクトが明らかに、クロスプラットホームを必要とするならば、答えは「イエス」でしょう。また、もし「特別な努力」が大変小さなものならば、それもまた「イエス」でしょう。
 +
クロスプラットホームでの開発が、ソフトウエアの王道として、「特別な努力」が終わりのない、あらゆる困難を越えてでも開発するべきである、と考えるなら、その答えも、また「イエス」でしょう。
  
If you're developing software that will run on a Web server, the most used platform by far is UNIX, on all flavors. In this case, perhaps only Linux, Solaris, *BSD and other Unixes make sense as your target platforms. You may also want to add support for Windows NT.
+
もし、Webサーバーとしてのソフトウエアを開発する場合は、今のところもっとも利用されているプラットホームはUNIXでしょう。この点において、Linux,Soralis, BSD、そしてほかのUnix互換OSはターゲットとして意味をもつプラットホームです。これに、WindowsNTを加えてもよいでしょう。
 +
(訳注:今なら Windows Serverでしょうか。)
  
もし、ひとつのプラットフォームについて開発をおこなうならば、(そして、将来にわたって他のプラットフォームをサポートしないならば)おそらくFreePascalとLazarusは仕事には最適なツールではないかもしれません。
+
もし、ひとつのプラットフォームについて開発をおこなうならば、そして、将来にわたって他のプラットフォームをサポートしないならば、おそらくFreePascalとLazarusは仕事には最適なツールではないかもしれません。
 
もし、Windowsのデスクトップのソフトウエアのみを書くならば、Delphiのようがよりよい選択かもしれません。
 
もし、Windowsのデスクトップのソフトウエアのみを書くならば、Delphiのようがよりよい選択かもしれません。
  
一度、クロスプラットフォーム開発をマスターすれば、通常は、ソフトウエアの設計や、問題解決にのみ、注力すればよく、どんなプラットフォームで動作させるかについては、ほとんど楽観的に、自由に考えていれば良いことになります。
+
しかし、一度、クロスプラットフォーム開発をマスターすれば、通常は、ソフトウエアの設計や、問題解決にのみ、注力すればよく、どんなプラットフォームで動作させるかについては、ほとんど楽観的に、自由に考えていれば良いことになります。
つまり、1つのプラットフォームで書いている時と同様、クロスプラットフォーム開発を身に付けていれば、他のプラットフォームについての特有な問題はほとんど無視すればいいのです。
+
つまり、1つのプラットフォームで書いている時と同様、クロスプラットフォーム開発をきちんと身に付けていれば、プラットフォームについての特有な問題はほとんど無視すればいいのです。
 
しかしながら、いくつかの点で、異なるプラットフォームでプログラムをテストしたり、実際に走らせることは、すべてのターゲットのOSで適用できているかどうか判断する助けになるでしょう。
 
しかしながら、いくつかの点で、異なるプラットフォームでプログラムをテストしたり、実際に走らせることは、すべてのターゲットのOSで適用できているかどうか判断する助けになるでしょう。
  
もし、異なる物理的なPCがいやだったら、デュアルブートのWindows-LinuxのPCや、Mac上の仮想マシンの下で動くWindowsやLinuxを使うとよいでしょう。
+
もし、異なる物理的なPCをそろえるのがいやだったら、デュアルブートのWindows-LinuxのPCや、Mac上の仮想マシンの下で動くWindowsやLinuxを使うとよいでしょう。
  
 
==Windows と Linux間での相互移植==
 
==Windows と Linux間での相互移植==
Line 34: Line 37:
 
===Windows API 関数===
 
===Windows API 関数===
  
多くのWindowsプログラムは、WindowsAPIを使っています。クロスプラットホームアプリケーションでは、それらのコードは現れないか、({$IFDEF Win32}のような)コンパイル条件中に隠されるべきです。
+
多くのWindowsプログラムは、WindowsAPIを使っています。クロスプラットホームアプリケーションでは、そういうコードは現れません。それは、({$IFDEF Win32}のような)コンパイル条件中に隠されるべきです。
  
幸いにもよく使われる多くのWindowsAPI関数はマルチプラットホーム流にLCLIntfに隠蔽され実装されています。これは、本当にWindowsAPIに多くを依存するプログラムにとって、解決策となるものです。
+
幸いにも、よく使われる多くのWindowsAPI関数はLazarusでのマルチプラットホーム流ではLCLIntfに隠蔽され実装されています。これは、本当にWindowsAPIに多くを依存するプログラムにとって、解決策となるものです。
 
クロスプラットホームコンポーネントであるLCLを使って置き換えるのがベストです。
 
クロスプラットホームコンポーネントであるLCLを使って置き換えるのがベストです。
たとえば、GDI描画関数は、TCanvasの関数に置き換えられます。
+
たとえば、GDI描画関数は、TCanvasのメンバ関数に置き換えられます。
  
 
===ファイルシステムの違い===
 
===ファイルシステムの違い===
  
A basic concern when porting application between Linux and Windows is the file system. To start with Windows filenames are not case sensitive, while they are on Unix platforms. This can be the cause of annoying bugs, so any portable application should use consistently filenames.
+
LinuxとWindows間の移植においての基本的な問題のひとつは、ファイルシステムです。
 +
まず、Windowsのファイル名は、大文字小文字を区別しませんが、Unixプラットホームでは区別します。
 +
これは、バグの原因になります。移植性のあるアプリケーションは、両方で成り立つファイル名を付けなくてはなりません。
  
===リナックスでは "application directory" はありません===
+
===リナックスには "application directory" はありません===
  
One concern when porting applications between Linux and Windows is the file system. Many programmers are used to call ExtractFilePath(ParamStr(0)) or Application.ExeName to get the location of the executable, and then search for the necessary files for the program execution (Images, XML files, database files, etc) based on the location of the executable. This is incorrect in Linux. The string on ParamStr(0) may not only not contain the directory of the executable, as it also varies between different shell programs (sh, bash, etc).
+
LinuxとWindows間でアプリケーションをポーティングするのに、ひとつよくよく考慮すべきことは、ファイルシステムです。多くのプログラマーは、実行ファイルのパスを得るために、ExtractFilePath(ParamStr(0)) や、 Application.ExeName を使ってきました。そして、プログラムの実行に必要なファイルも、実行ファイルのある位置を基点にしています。これは、Linuxでは正しくない方法です。
 +
ParamStr(0)の文字列は実行ファイルのディレクトリを含まないかもしれないだけでなく、シェルプログラム(sh,bash,など)によって、いろんな違いがあるかもしれません。
  
Even if Application.ExeName could in fact know the directory where the file under execution is, that file could be a symbolic link, so you would get the directory of the link instead.
+
Aplication.ExeNameでさえ、実行ファイルがどのディレクトリにあるか知ることができそうですが、それはシンボリックファイルかもしれません。あなたは、リンクのあるディレクトリを取得しているわけです。
  
So what should we do? On Linux you should use two different places to store configurations and resource files:
+
それでは、どうしたらよいのでしょうか。Linuxでは、コンフィグレーションやリソースファイルを格納するために、2つの異なった場所を使うべきです。
  
* Resource files (i.e. images, help files)
+
* リソースファイル. (イメージやヘルプファイル等)
  
A fixed privileged location for the executable and resource files which will not change.
+
実行ファイルとリソースファイルのために、固定的に許された場所にあり、それは変更されません。
 +
この場所は、
 +
/usr/share/app_name
 +
もしくは
 +
/opt/app_name
 +
のような場所です。
  
This location can be something like: /usr/share/app_name or /opt/app_name
+
ほとんどのプログラムはroot権限なしで動作させることができます。そして、アプリケーションのために固定された(リソースのための)ディレクトリが与えられ、そのディレクトリは rootユーザーに対しては、書き込み権限がありますが、アプリケーションは、(root権限なしで動作した場合は)このディレクトリに書き込むことができません。リソースファイルからは、読み込みだけが可能です。
  
Most programs will be executed without root privileges and the fixed directory for a given application usually only available for the root user to write, so don't write on this directory. Only read information from it.
+
* 設定ファイル(コンフィグレーション)
  
* Configuration files
+
たとえターゲットシステムが異なっていても、設定ファイルに適したファイルの置き場を取得するには、SysUtilsユニットの中の[[doc:rtl/sysutils/getappconfigdir.html|GetAppConfigDir]]関数を使うことができます。
 +
この関数は、グローバルと呼ばれるひとつのパラメータをとります。もし、これがTrueならば、グローバルな設定ディレクトリが取得できます。グローバルというのは、すなわち、システム上のすべてのユーザーに対しての設定です。
 +
もし、グローバルパラメータがFalseなら、アプリケーションを実行した特定のユーザーに対するディレクトリが返されます。マルチユーザー環境をサポートしないシステムの場合は、これらの2つのディレクトリは同じかもしれません。
  
You can use the [[doc:rtl/sysutils/getappconfigdir.html|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.
+
アプリケーションの設定のために、 [[doc:rtl/sysutils/getappconfigfile.html|GetAppConfigFile]]というファイルもあります。
  
There is also the [[doc:rtl/sysutils/getappconfigfile.html|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:
 
  
 
<pre>
 
<pre>
Line 84: Line 95:
 
</pre>
 
</pre>
  
The output on a GNU/Linux system:
+
GNU/Linux システムの場合は次のように出力されます。
  
 
<pre>
 
<pre>
Line 93: Line 104:
 
</pre>
 
</pre>
  
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.
+
グローバルな設定ファイルは /etcディレクトリにあり、ローカルな設定ファイルはユーザーのホームディレクトリに隠しフォルダとして保存されます。Linuxでは、ドット(.)ではじまるディレクトリは隠しフォルダです。
 +
GetAppConfigDirで返される場所にディレクトリを作り、コンフィグレーションファイル類をそこへ入れることもできます。
 +
 
 +
 
  
The output on Windows XP:
+
Windows XP の場合は次のように出力されます。
  
 
<pre>
 
<pre>
Line 104: Line 118:
 
</pre>
 
</pre>
  
Notice that the function uses the directory where the application is to store global configurations on Windows.
+
Windowsでは、関数は、グローバルな設定のために、アプリケーションが入れられているディレクトリを返すことに注意しましょう。
  
 +
UPX
 
Note: The use of UPX interferes with the use of the GetAppConfigDir and GetAppConfigFile functions.
 
Note: The use of UPX interferes with the use of the GetAppConfigDir and GetAppConfigFile functions.
  
==WindowsのCOMオートメーションなしで、それをやる==
+
==WindowsのCOMオートメーションを使わず、それっぽい事をやるには==
 +
 
 +
Windowsにおいて、オートメーションは、他のプログラムをリモート操作したり、他のプログラムから操作させたりするのに、強力な方法です。
 +
Delphiでは、オートメーションクライアント、オートメーションサーバーのどちらも作成することができます。これは、他のプログラムを操作したり、他のプログラムから操作されるプログラムのことです。
  
With Windows, Automation is a powerful way not only of manipulating other programs remotely but also for allowing other programs to manipulate your program. With Delphi you can make your program both an Automation client and an Automation server, meaning it can both manipulate other programs and in turn be manipulated by other programs.
+
オートメーションは、OS Xや Linuxでは利用できません。しかし、OS XではAppleScriptを使って同じようなことはできます。
  
Unfortunately, Automation isn't available on OS X and Linux. However, you can simulate some of the functionality of Automation on OS X using AppleScript.
+
AppleScriptはオートメーションと、ある面はとても似ています。たとえば、他のプログラムを操作するスクリプトを書くことができます。これは、AppleScriptがNeoOffice(OpenOffice.orgのMac版)を開始する
 +
とても簡単な例です。
  
AppleScript is similar to Automation in some ways. For example, you can write scripts that manipulate other programs. Here's a very simple example of AppleScript that starts NeoOffice (the Mac version of OpenOffice.org):
 
  
 
   tell application "NeoOffice"
 
   tell application "NeoOffice"
Line 120: Line 138:
 
   end tell
 
   end tell
  
An app that is designed to be manipulated by AppleScript provides a "dictionary" of classes and commands that can be used with the app, similar to the classes of a Windows Automation server. However, even apps like NeoOffice that don't provide a dictionary will still respond to the commands "launch", "activate" and "quit". AppleScript can be run from the OS X Script Editor or Finder or even converted to an app that you can drop on the dock just like any app. You can also run AppleScript from your program, as in this example:
+
 
 +
AppleScriptから操作されるように設計されているアプリケーションは、アプリケーションを使うためのクラスとコマンドの"辞書"を持っています。それは、Windowsのオートメーションサーバーと似ています。
 +
しかしながら、NeoOfficeのような辞書をもっていないアプリケーションでさえ、"launch","activate","quit"といったコマンドに応答することができます。
 +
AppleScriptはOS Xスクリプトエディタや、ファインダー、ドックにドロップできるどのようなアプリケーションからでも実行できます。
 +
次の例のように、自分のプログラムからAppleSriptを実行することもできます。
  
 
   Shell('myscript.applescript');
 
   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:
+
これはスクリプトが明示されているファイルにあることを仮定しています。スクリプトをアプリケーションから、OS X OsaScriptコマンドを使ってすぐに走らせる事もできます。
  
 
   Shell('osascript -e '#39'tell application "NeoOffice"'#39 +
 
   Shell('osascript -e '#39'tell application "NeoOffice"'#39 +
Line 130: Line 152:
 
         {Note use of #39 to single-quote the parameters}
 
         {Note use of #39 to single-quote the parameters}
  
However, these examples are just the equivalent of the following Open command:
+
しかし、これらの例は、次のようなopenコマンドと同等です。
  
 
   Shell('open -a NeoOffice');
 
   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.
+
AppleScriptの真の力はリモートからプログラムを操作して、文書を開いたり作成したり、ほかの機能を使って自動化できることです。
 +
どれくらいプログラムに対して操作できるか、というのは、どれくらいAppleScript辞書に拡張されているか、ということと同じです。たとえば、マイクロソフトOffice XプログラムはAppleScriptではあまり使えるものではありませんでした。しかし、新しいOfiice 2004プログラムは完全にAppleScript向けに書き直され、WindowsのOfficeのオートメーションサーバー機能と同等になっています。
 +
 
 +
一方、Linuxのシェルは洗練されたコマンドラインスクリプトをサポートしています。スクリプトの方法はプログラムにどんなコマンドラインを渡せるか、ということで決まっています。Windowsのオートメーションサーバーや、OS XのAppleScriptのように、プログラムの内部のクラスやコマンドはLinuxでは利用できません。
  
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.
+
Windowsのように、多くのOS XやLinuxのプログラムは複数のライブラリファイルから成り立っています。
 +
(たとえば、.dylibや .so のような。)一部、これらのライブラリはあなたが書くプログラムでも使えるように設計されています。
 +
これは、あなたのプログラムに、外部的な機能を付け加えることはできますが、外部プログラムそのものを操作するものとは、完全に同じではありません。しかしながら、あなたのプログラムは外部のプログラムのライブラリをリンクして使うことができれば、ほかのプログラム用のライブラリのように使うことができます。
  
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.
+
(訳注:WindowsのCOMのオートメーションサーバようなことをするには、Linuxでシェアードオブジェクトのようなライブラリが共有され、ユーザーに開放ているプログラムで、リンクできれば、似たことは可能であるということです。)
  
 
==付記==
 
==付記==
  
 
* http://www.midnightbeach.com/jon/pubs/Kylix.html A guide for Windows programmers starting with Kylix. Many of concepts / code snippets apply to Lazarus.
 
* http://www.midnightbeach.com/jon/pubs/Kylix.html A guide for Windows programmers starting with Kylix. Many of concepts / code snippets apply to Lazarus.

Latest revision as of 13:35, 5 July 2006

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

日本語版メニュー
メインページ - Lazarus Documentation日本語版 - 翻訳ノート - 日本語障害情報

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

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

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

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

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

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

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

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

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

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

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

Windows と Linux間での相互移植

Windows API 関数

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

幸いにも、よく使われる多くのWindowsAPI関数はLazarusでのマルチプラットホーム流では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では、コンフィグレーションやリソースファイルを格納するために、2つの異なった場所を使うべきです。

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

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

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

  • 設定ファイル(コンフィグレーション)

たとえターゲットシステムが異なっていても、設定ファイルに適したファイルの置き場を取得するには、SysUtilsユニットの中のGetAppConfigDir関数を使うことができます。 この関数は、グローバルと呼ばれるひとつのパラメータをとります。もし、これがTrueならば、グローバルな設定ディレクトリが取得できます。グローバルというのは、すなわち、システム上のすべてのユーザーに対しての設定です。 もし、グローバルパラメータがFalseなら、アプリケーションを実行した特定のユーザーに対するディレクトリが返されます。マルチユーザー環境をサポートしないシステムの場合は、これらの2つのディレクトリは同じかもしれません。

アプリケーションの設定のために、 GetAppConfigFileというファイルもあります。

異なったシステム上で、これらの出力のサンプルを見てみましょう。

program project1;

{$mode objfpc}{$H+}

uses
  SysUtils;

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

GNU/Linux システムの場合は次のように出力されます。

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

グローバルな設定ファイルは /etcディレクトリにあり、ローカルな設定ファイルはユーザーのホームディレクトリに隠しフォルダとして保存されます。Linuxでは、ドット(.)ではじまるディレクトリは隠しフォルダです。 GetAppConfigDirで返される場所にディレクトリを作り、コンフィグレーションファイル類をそこへ入れることもできます。


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

Windowsでは、関数は、グローバルな設定のために、アプリケーションが入れられているディレクトリを返すことに注意しましょう。

UPX 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');

これはスクリプトが明示されているファイルにあることを仮定しています。スクリプトをアプリケーションから、OS X OsaScriptコマンドを使ってすぐに走らせる事もできます。

 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}

しかし、これらの例は、次のようなopenコマンドと同等です。

 Shell('open -a NeoOffice');

AppleScriptの真の力はリモートからプログラムを操作して、文書を開いたり作成したり、ほかの機能を使って自動化できることです。 どれくらいプログラムに対して操作できるか、というのは、どれくらいAppleScript辞書に拡張されているか、ということと同じです。たとえば、マイクロソフトOffice XプログラムはAppleScriptではあまり使えるものではありませんでした。しかし、新しいOfiice 2004プログラムは完全にAppleScript向けに書き直され、WindowsのOfficeのオートメーションサーバー機能と同等になっています。

一方、Linuxのシェルは洗練されたコマンドラインスクリプトをサポートしています。スクリプトの方法はプログラムにどんなコマンドラインを渡せるか、ということで決まっています。Windowsのオートメーションサーバーや、OS XのAppleScriptのように、プログラムの内部のクラスやコマンドはLinuxでは利用できません。

Windowsのように、多くのOS XやLinuxのプログラムは複数のライブラリファイルから成り立っています。 (たとえば、.dylibや .so のような。)一部、これらのライブラリはあなたが書くプログラムでも使えるように設計されています。 これは、あなたのプログラムに、外部的な機能を付け加えることはできますが、外部プログラムそのものを操作するものとは、完全に同じではありません。しかしながら、あなたのプログラムは外部のプログラムのライブラリをリンクして使うことができれば、ほかのプログラム用のライブラリのように使うことができます。

(訳注:WindowsのCOMのオートメーションサーバようなことをするには、Linuxでシェアードオブジェクトのようなライブラリが共有され、ユーザーに開放ているプログラムで、リンクできれば、似たことは可能であるということです。)

付記