Multiplatform Programming Guide/ja: what changed

Revision 1 to 2. Removed lines have a minus sign; added lines have a plus sign.

Old	New		Line
1	1		このページは、マルチプラットホーム　アプリケーションを書くにあたって考慮すべきチュートリアルの最初のページです。ここでは、これから移植をおこないやすいようなプログラムを書くために、必要な注意事項と、すでに製作したプログラムの移植のプロセスをのべています。この記事をよりよいものにするために、手助けしてくれる他の人を募集しています。
2	2
3	3		## マルチプラットフォームプログラミングへの招待
4	4
5	5		### マルチプラットホーム開発のために、沢山の種類のパソコンが必要でしょうか？
6	6
7	7		この質問に答えるには、まず、誰が潜在的なユーザーなのか、そして、どのようにプログラムが使われるのかということを決めるべきです。まず、アプリケーションをどういう人々に提供するのか考えてみましょう。
8	8
9	9		たとえば、ヨーロッパにおいては、デスクトップソフトウエアを開発するなら、WindowsかOS Xで開発することです。OS Xは一番普及しているUnixであり、デスクトップ環境です。 100:10:1の法則はご存知でしょうか。これは、大きな組織やグループのユーザーのことを言っていますが、Windows,Mac,Linuxでも、だいたいにおいてこの比率があてはまると思います。
10	10
11	11		そのほかの地域では、たとえば、南アメリカでは、Windowsがほとんどですが、Linuxはデスクトッププラットホームでシェアを伸ばしています。商業的にWindowsは大きなスーパーマーケットの販路で売られています。MacOSXはビデオやサウンドの編集に利用されています。
12	12
13	13		OS XやLinuxを走らせているユーザーのために、開発し、パッケージして配布する「特別な努力」をする甲斐があるでしょうか？プロジェクトが明らかに、クロスプラットホームを必要とするならば、答えは「イエス」でしょう。また、もし「特別な努力」が大変小さなものならば、それもまた「イエス」でしょう。クロスプラットホームでの開発が、ソフトウエアの王道として、「特別な努力」が終わりのない、あらゆる困難を越えてでも開発するべきである、と考えるなら、その答えも、また「イエス」でしょう。
14	14
15	15		もし、Webサーバーとしてのソフトウエアを開発する場合は、今のところもっとも利用されているプラットホームはUNIXでしょう。この点において、Linux,Soralis, BSD、そしてほかのUnix互換OSはターゲットとして意味をもつプラットホームです。これに、WindowsNTを加えてもよいでしょう。（訳注：今なら Windows Serverでしょうか。）
16	16
17	17		もし、ひとつのプラットフォームについて開発をおこなうならば、そして、将来にわたって他のプラットフォームをサポートしないならば、おそらくFreePascalとLazarusは仕事には最適なツールではないかもしれません。もし、Windowsのデスクトップのソフトウエアのみを書くならば、Delphiのようがよりよい選択かもしれません。
18	18
19	19		しかし、一度、クロスプラットフォーム開発をマスターすれば、通常は、ソフトウエアの設計や、問題解決にのみ、注力すればよく、どんなプラットフォームで動作させるかについては、ほとんど楽観的に、自由に考えていれば良いことになります。つまり、１つのプラットフォームで書いている時と同様、クロスプラットフォーム開発をきちんと身に付けていれば、プラットフォームについての特有な問題はほとんど無視すればいいのです。しかしながら、いくつかの点で、異なるプラットフォームでプログラムをテストしたり、実際に走らせることは、すべてのターゲットのOSで適用できているかどうか判断する助けになるでしょう。
20	20
21	21		もし、異なる物理的なPCをそろえるのがいやだったら、デュアルブートのWindows-LinuxのPCや、Mac上の仮想マシンの下で動くWindowsやLinuxを使うとよいでしょう。
22	22
23	23		## Windows と Linux間での相互移植
24	24
25	25		### Windows API 関数
26	26
27	27		多くのWindowsプログラムは、WindowsAPIを使っています。クロスプラットホームアプリケーションでは、そういうコードは現れません。それは、({\$IFDEF Win32}のような）コンパイル条件中に隠されるべきです。
28	28
29	29		幸いにも、よく使われる多くのWindowsAPI関数はLazarusでのマルチプラットホーム流ではLCLIntfに隠蔽され実装されています。これは、本当にWindowsAPIに多くを依存するプログラムにとって、解決策となるものです。クロスプラットホームコンポーネントであるLCLを使って置き換えるのがベストです。たとえば、GDI描画関数は、TCanvasのメンバ関数に置き換えられます。
30	30
31	31		### ファイルシステムの違い
32	32
33	33		LinuxとWindows間の移植においての基本的な問題のひとつは、ファイルシステムです。まず、Windowsのファイル名は、大文字小文字を区別しませんが、Unixプラットホームでは区別します。これは、バグの原因になります。移植性のあるアプリケーションは、両方で成り立つファイル名を付けなくてはなりません。
34	34
35	35		### リナックスには "application directory"　はありません
36	36
37	37		LinuxとWindows間でアプリケーションをポーティングするのに、ひとつよくよく考慮すべきことは、ファイルシステムです。多くのプログラマーは、実行ファイルのパスを得るために、ExtractFilePath(ParamStr(0)) や、 Application.ExeName を使ってきました。そして、プログラムの実行に必要なファイルも、実行ファイルのある位置を基点にしています。これは、Linuxでは正しくない方法です。 ParamStr(0)の文字列は実行ファイルのディレクトリを含まないかもしれないだけでなく、シェルプログラム(sh,bash,など）によって、いろんな違いがあるかもしれません。
38	38
39	39		Aplication.ExeNameでさえ、実行ファイルがどのディレクトリにあるか知ることができそうですが、それはシンボリックファイルかもしれません。あなたは、リンクのあるディレクトリを取得しているわけです。
40	40
41	41		それでは、どうしたらよいのでしょうか。Linuxでは、コンフィグレーションやリソースファイルを格納するために、２つの異なった場所を使うべきです。
42	42
43	43		- リソースファイル. (イメージやヘルプファイル等)
44	44
45	45		実行ファイルとリソースファイルのために、固定的に許された場所にあり、それは変更されません。この場所は、 /usr/share/app_name もしくは /opt/app_name のような場所です。
46	46
47	47		ほとんどのプログラムはroot権限なしで動作させることができます。そして、アプリケーションのために固定された（リソースのための）ディレクトリが与えられ、そのディレクトリは rootユーザーに対しては、書き込み権限がありますが、アプリケーションは、（root権限なしで動作した場合は）このディレクトリに書き込むことができません。リソースファイルからは、読み込みだけが可能です。
48	48
49	49		- 設定ファイル（コンフィグレーション）
50	50
51	51		たとえターゲットシステムが異なっていても、設定ファイルに適したファイルの置き場を取得するには、SysUtilsユニットの中の[[doc:rtl/sysutils/getappconfigdir.html\|GetAppConfigDir]]関数を使うことができます。この関数は、グローバルと呼ばれるひとつのパラメータをとります。もし、これがTrueならば、グローバルな設定ディレクトリが取得できます。グローバルというのは、すなわち、システム上のすべてのユーザーに対しての設定です。もし、グローバルパラメータがFalseなら、アプリケーションを実行した特定のユーザーに対するディレクトリが返されます。マルチユーザー環境をサポートしないシステムの場合は、これらの２つのディレクトリは同じかもしれません。
52	52
53	53		アプリケーションの設定のために、 [[doc:rtl/sysutils/getappconfigfile.html\|GetAppConfigFileというファイルもあります]]。
54	54
55	55		異なったシステム上で、これらの出力のサンプルを見てみましょう。
56	56
57	57		program project1;
58	58
59	59		{$mode objfpc}{$H+}
60	60
61	61		uses
62	62		SysUtils;
63	63
64	64		begin
65	65		WriteLn(GetAppConfigDir(True));
66	66		WriteLn(GetAppConfigDir(False));
67	67		WriteLn(GetAppConfigFile(True));
68	68		WriteLn(GetAppConfigFile(False));
69	69		end.
70	70
71	71		GNU/Linux システムの場合は次のように出力されます。
72	72
73	73		/etc
74	74		/home/felipe/project1
75	75		/etc/project1.cfg
76	76		/home/felipe/.project1
77	77
78	78		グローバルな設定ファイルは /etcディレクトリにあり、ローカルな設定ファイルはユーザーのホームディレクトリに隠しフォルダとして保存されます。Linuxでは、ドット(.)ではじまるディレクトリは隠しフォルダです。 GetAppConfigDirで返される場所にディレクトリを作り、コンフィグレーションファイル類をそこへ入れることもできます。
79	79
80	80		Windows XP の場合は次のように出力されます。
81	81
82	82		C:\Programas\teste
83	83		C:\Documents and Settings\felipe\Configurações Locais\Dados de aplicativos\project2
84	84		C:\Programas\teste\project2.cfg
85	85		C:\Documents and Settings\felipe\Configurações Locais\Dados de aplicativos\project2\project2.cfg
86	86
87	87		Windowsでは、関数は、グローバルな設定のために、アプリケーションが入れられているディレクトリを返すことに注意しましょう。
88	88
89	89		UPX Note: The use of UPX interferes with the use of the GetAppConfigDir and GetAppConfigFile functions.
90	90
91	91		## WindowsのCOMオートメーションを使わず、それっぽい事をやるには
92	92
93	93		Windowsにおいて、オートメーションは、他のプログラムをリモート操作したり、他のプログラムから操作させたりするのに、強力な方法です。 Delphiでは、オートメーションクライアント、オートメーションサーバーのどちらも作成することができます。これは、他のプログラムを操作したり、他のプログラムから操作されるプログラムのことです。
94	94
95	95		オートメーションは、OS Xや Linuxでは利用できません。しかし、OS XではAppleScriptを使って同じようなことはできます。
96	96
97	97		AppleScriptはオートメーションと、ある面はとても似ています。たとえば、他のプログラムを操作するスクリプトを書くことができます。これは、AppleScriptがNeoOffice(OpenOffice.orgのMac版)を開始するとても簡単な例です。
98	98
99		-	~~` tell application "NeoOffice"`\~~
100		-	~~` launch`\~~
101		-	~~` end tell`~~
	99	+	``` pascal
	100	+	tell application "NeoOffice"
	101	+	launch
	102	+	end tell
	103	+	```
102	104
103	105		AppleScriptから操作されるように設計されているアプリケーションは、アプリケーションを使うためのクラスとコマンドの"辞書"を持っています。それは、Windowsのオートメーションサーバーと似ています。しかしながら、NeoOfficeのような辞書をもっていないアプリケーションでさえ、"launch","activate","quit"といったコマンドに応答することができます。 AppleScriptはOS Xスクリプトエディタや、ファインダー、ドックにドロップできるどのようなアプリケーションからでも実行できます。次の例のように、自分のプログラムからAppleSriptを実行することもできます。
104	106
105		-	~~` Shell('myscript.applescript');`~~
	107	+	```text
	108	+	Shell('myscript.applescript');
	109	+	```
106	110
107	111		これはスクリプトが明示されているファイルにあることを仮定しています。スクリプトをアプリケーションから、OS X OsaScriptコマンドを使ってすぐに走らせる事もできます。
108	112
109		-	~~` Shell('osascript -e '#39'tell application "NeoOffice"'#39 +`\~~
110		-	~~` ' -e '#39'launch'#39' -e '#39'end tell'#39);`\~~
111		-	~~` {Note use of #39 to single-quote the parameters}`~~
	113	+	``` pascal
	114	+	Shell('osascript -e '#39'tell application "NeoOffice"'#39 +
	115	+	' -e '#39'launch'#39' -e '#39'end tell'#39);
	116	+	{Note use of #39 to single-quote the parameters}
	117	+	```
112	118
113	119		しかし、これらの例は、次のようなopenコマンドと同等です。
114	120
115		-	~~` Shell('open -a NeoOffice');`~~
	121	+	```text
	122	+	Shell('open -a NeoOffice');
	123	+	```
116	124
117	125		AppleScriptの真の力はリモートからプログラムを操作して、文書を開いたり作成したり、ほかの機能を使って自動化できることです。どれくらいプログラムに対して操作できるか、というのは、どれくらいAppleScript辞書に拡張されているか、ということと同じです。たとえば、マイクロソフトOffice XプログラムはAppleScriptではあまり使えるものではありませんでした。しかし、新しいOfiice 2004プログラムは完全にAppleScript向けに書き直され、WindowsのOfficeのオートメーションサーバー機能と同等になっています。
118	126
119	127		一方、Linuxのシェルは洗練されたコマンドラインスクリプトをサポートしています。スクリプトの方法はプログラムにどんなコマンドラインを渡せるか、ということで決まっています。Windowsのオートメーションサーバーや、OS XのAppleScriptのように、プログラムの内部のクラスやコマンドはLinuxでは利用できません。
120	128
121	129		Windowsのように、多くのOS XやLinuxのプログラムは複数のライブラリファイルから成り立っています。（たとえば、.dylibや .so　のような。）一部、これらのライブラリはあなたが書くプログラムでも使えるように設計されています。これは、あなたのプログラムに、外部的な機能を付け加えることはできますが、外部プログラムそのものを操作するものとは、完全に同じではありません。しかしながら、あなたのプログラムは外部のプログラムのライブラリをリンクして使うことができれば、ほかのプログラム用のライブラリのように使うことができます。
122	130
123	131		（訳注：WindowsのCOMのオートメーションサーバようなことをするには、Linuxでシェアードオブジェクトのようなライブラリが共有され、ユーザーに開放ているプログラムで、リンクできれば、似たことは可能であるということです。）
124	132
125	133		## 付記
126	134
127	135		- <http://www.midnightbeach.com/jon/pubs/Kylix.html> A guide for Windows programmers starting with Kylix. Many of concepts / code snippets apply to Lazarus.
128	136
129	137		---
130	138		From the Free Pascal wiki, page "Multiplatform Programming Guide/ja", as it stood on 2006-07-05 after a change by Saeka-jp, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).

Back to history