Multiplatform Programming Guide/pl: what changed

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

Old	New		Line
1	1		Przewodnik programowania wieloplatformowego
2	2
3	3		To jest samouczek dotyczący pisania aplikacji wieloplatformowych z Lazarusem i Free Pascalem. Obejmuje niezbędne środki ostrożności, aby pomóc w stworzeniu wieloplatformowego programu gotowego do [[Deploying Your Application\|wdrożenia]].
4	4
5	5		Większość aplikacji LCL działa na wielu platformach bez dodatkowej pracy. Ta zasada nazywa się [[Write once compile anywhere/pl\|„napisz raz, kompiluj wszędzie”]].
6	6
7	7		## Wprowadzenie do programowania wieloplatformowego (międzyplatformowego)
8	8
9	9		### Ile platform potrzebujesz?
10	10
11	11		Aby odpowiedzieć na to pytanie, powinieneś najpierw określić, kim są Twoi potencjalni użytkownicy i jak Twój program będzie używany. To pytanie zależy od tego, gdzie wdrażasz swoją aplikację.
12	12
13	13		Jeśli tworzysz ogólne oprogramowanie komputerowe w 2014 roku, Microsoft Windows może być najważniejszą platformą. Pamiętaj, że macOS i/lub Linux zyskują na popularności i mogą być ważnym celem dla Twojej aplikacji.
14	14
15	15		Popularność różnych systemów operacyjnych na komputery stacjonarne różni się w zależności od kraju, rodzaju używanego oprogramowania i grupy docelowej; nie ma ogólnej zasady. Na przykład macOS jest dość popularny w Ameryce Północnej i Europie Zachodniej, podczas gdy w Ameryce Południowej macOS ogranicza się głównie do pracy z wideo i dźwiękiem.
16	16
17	17		W wielu projektach kontraktowych odpowiednia jest tylko jedna platforma. Free Pascal i Lazarus są w stanie pisać oprogramowanie ukierunkowane na konkretną platformę. Możesz na przykład uzyskać dostęp do pełnego interfejsu API Windows, aby napisać dobrze zintegrowany program Windows.
18	18
19	19		Jeśli tworzysz oprogramowanie, które będzie działać na serwerze sieciowym, powszechnie używana jest platforma uniksowa w jednym z jej różnych wariantów. Być może w tym przypadku jako platformy docelowe sens mają tylko Linux, Solaris, *BSD i inne Uniksy, chociaż możesz chcieć dodać do kompletu obsługę Windows.
20	20
21	21		Po rozwiązaniu wszelkich problemów międzyplatformowych w swoim projekcie, możesz w dużej mierze zignorować inne platformy, podobnie jak w przypadku programowania dla jednej platformy. Jednak w pewnym momencie będziesz musiał przetestować wdrażanie i uruchamianie programu na innych platformach. W tym celu pomocny będzie nieograniczony dostęp do maszyn z docelowymi systemami operacyjnymi. Jeśli nie chcesz mieć wielu fizycznych komputerów, sprawdź rozwiązania z podwójnym rozruchem lub maszyną wirtualną (VM), taką jak:
22	22
23	23		- [VMware Fusion for Mac](https://www.vmware.com/products/fusion.html) - Systemie hosta, na którym musi być uruchomiony system Intel macOS (komercyjny/bezpłatny do użytku niekomercyjnego).
24	24		- [VMware Workstation Player](https://www.vmware.com/products/workstation-player.html) - System hosta z 64-bitowym systemem Windows lub 64-bitowym systemem Linux (komercyjny/bezpłatny do użytku osobistego).
25	25		- [VMware Workstation Pro](https://www.vmware.com/products/workstation-pro.html) - System hosta z 64-bitowym systemem Windows lub 64-bitowym systemem Linux (komercyjna/bezpłatna wersja próbna).
26	26		- [Parallels Desktop for Mac](https://www.parallels.com/) - Na systemie hosta musi być uruchomiony system Intel macOS (komercyjna/bezpłatna wersja próbna). Uwaga: istnieje [Podgląd Techniczny](https://b2b.parallels.com/Apple-Silicon), który będzie działał na procesorach Apple M1 ARM64, i który będzie obsługiwał wersje ARM systemu Linux i [Windows 10 Insider Preview](https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewARM64).
27	27		- [VirtualBox](https://www.virtualbox.org/) - Na systemie hosta może działać Intel macOS, Windows, Linux lub Solaris (Open Source).
28	28
29	29		Niektóre z nich, np. Parallels na Macu, sprawiają, że instalacja stacjonarnego systemu operacyjnego Linux za pomocą jednego kliknięcia jest banalna.
30	30
31	31		Zobacz także: [[Small Virtual Machines\|Małe maszyny wirtualne]] i [[Qemu and other emulators\|Qemu i inne emulatory]].
32	32
33	33		## Programowanie międzyplatformowe
34	34
35	35		### Praca z plikami i folderami
36	36
37	37		Podczas pracy z plikami i folderami ważne jest, aby używać niespecyficznych dla platformy ograniczników ścieżki i sekwencji [[End of Line\|końca wiersza]]. Oto lista zadeklarowanych [[Constant\|stałych]] w Lazarusie, które powinny być używane podczas pracy z plikami i folderami.
38	38
39	39		- PathSep, PathSeparator: separator ścieżek używany podczas dodawania wielu ścieżek razem (';', ...)
40	40		- PathDelim, DirectorySeparator: separator katalogów dla każdej platformy ('/', '\\', ...)
41	41		- LineEnding: poprawna sekwencja znaków końca wiersza (#13#10 - CRLF, \#10 - [[Line feed\|LF]], ...)
42	42
43	43		Inną ważną rzeczą, na którą należy zwrócić uwagę, jest rozróżnianie wielkości liter w systemie plików. W systemie Windows w nazwach plików zwykle nie jest rozróżniana wielkość liter, podczas gdy na platformach uniksowych (np. Linux, FreeBSD) zwykle rozróżniana jest wielkość liter, ale nie w macOS, pomimo jego dziedzictwa uniksowego. Należy jednak pamiętać, że jeśli system plików EXT2, EXT3 itp. jest zamontowany w systemie Windows, rozróżniana jest wielkość liter. Podobnie system plików FAT zamontowany w systemie Linux nie powinien rozróżniać wielkości liter.
44	44
45	45		Szczególną uwagę należy zwrócić na NTFS, który nie rozróżnia wielkości liter, gdy jest używany w systemie Windows, ale rozróżnia wielkość liter, gdy jest montowany w systemach POSIX. Może to powodować różne problemy, w tym utratę plików, jeśli pliki o tych samych nazwach, lecz różnych wariantach, istnieją na partycji NTFS zamontowanej w systemie Windows. Programiści powinni rozważyć użycie niestandardowych funkcji do sprawdzania i zapobiegania tworzenia kilku plików o tych samych nazwach w systemie NTFS.
46	46
47	47		macOS domyślnie używa nazw plików bez uwzględniania wielkości liter. Może to być przyczyną irytujących błędów, więc każda przenośna aplikacja powinna konsekwentnie używać takich nazw plików.
48	48
49	49		Funkcje plikowe biblioteki RTL używają kodowania systemowego dla nazw plików. W starszych systemach Windows (95/98/Me) jest to jedna ze stron kodowych systemu Windows, w nowszych UTF-16, podczas gdy Linux, BSD i macOS zwykle używają UTF-8. Moduł FileUtil biblioteki LCL zawiera funkcje plikowe, które przyjmują łańcuchy UTF-8, podobnie jak reszta LCL.
50	50
51	51		``` pascal
52	52		// Funkcje AnsiToUTF8 i UTF8ToAnsi wymagają menedżera widestring pod Linuksem, BSD, macOS,
53	53		// ale zwykle te systemy operacyjne używają UTF-8 jako kodowania systemowego, więc widestringmanager
54	54		// nie jest potrzebny.
55	55		function NeedRTLAnsi: boolean;// true if system encoding is not UTF-8
56	56		procedure SetNeedRTLAnsi(NewValue: boolean);
57	57		function UTF8ToSys(const s: string): string; // podobna do UTF8ToAnsi, ale nie jest już zależna od widestringmanager
58	58		function SysToUTF8(const s: string): string; // podobna do AnsiToUTF8, ale nie jest już zależna od widestringmanager
59	59		function UTF8ToConsole(const s: string): string; // konwertuje ciąg znaków UTF8 na kodowanie konsoli (używane przez Write, WriteLn)
60	60
61	61		// operacje na plikach
62	62		function FileExistsUTF8(const Filename: string): boolean;
63	63		function FileAgeUTF8(const FileName: string): Longint;
64	64		function DirectoryExistsUTF8(const Directory: string): Boolean;
65	65		function ExpandFileNameUTF8(const FileName: string): string;
66	66		function ExpandUNCFileNameUTF8(const FileName: string): string;
67	67		function ExtractShortPathNameUTF8(Const FileName : String) : String;
68	68		function FindFirstUTF8(const Path: string; Attr: Longint; out Rslt: TSearchRec): Longint;
69	69		function FindNextUTF8(var Rslt: TSearchRec): Longint;
70	70		procedure FindCloseUTF8(var F: TSearchrec);
71	71		function FileSetDateUTF8(const FileName: String; Age: Longint): Longint;
72	72		function FileGetAttrUTF8(const FileName: String): Longint;
73	73		function FileSetAttrUTF8(const Filename: String; Attr: longint): Longint;
74	74		function DeleteFileUTF8(const FileName: String): Boolean;
75	75		function RenameFileUTF8(const OldName, NewName: String): Boolean;
76	76		function FileSearchUTF8(const Name, DirList : String): String;
77	77		function FileIsReadOnlyUTF8(const FileName: String): Boolean;
78	78		function GetCurrentDirUTF8: String;
79	79		function SetCurrentDirUTF8(const NewDir: String): Boolean;
80	80		function CreateDirUTF8(const NewDir: String): Boolean;
81	81		function RemoveDirUTF8(const Dir: String): Boolean;
82	82		function ForceDirectoriesUTF8(const Dir: string): Boolean;
83	83
84	84		// środowisko
85	85		function ParamStrUTF8(Param: Integer): string;
86	86		function GetEnvironmentStringUTF8(Index: Integer): string;
87	87		function GetEnvironmentVariableUTF8(const EnvVar: string): String;
88	88		function GetAppConfigDirUTF8(Global: Boolean): string;
89	89
90	90		// inne
91	91		function SysErrorMessageUTF8(ErrorCode: Integer): String;
92	92		```
93	93
94	94		### Puste nazwy plików i podwójne separatory ścieżki
95	95
96	96		Istnieją pewne różnice w obsłudze nazw plików/katalogów w systemie Windows w porównaniu z systemami Linux, Unix i Unix.
97	97
98	98		- Windows zezwala na puste nazwy plików. Dlatego FileExistsUTF8('..\\') sprawdza w systemie Windows w katalogu nadrzędnym, czy istnieje plik bez nazwy.
99	99		- W systemach Linux/Unix/Uniksopodobnych do katalogu mapowany jest pusty plik, a katalogi są traktowane jako pliki. Oznacza to, że FileExistsUTF8('../') pod Uniksem sprawdza istnienie katalogu nadrzędnego, co zwykle daje prawdę.
100	100
101	101		Podwójne separatory ścieżki w nazwach plików są również traktowane inaczej:
102	102
103	103		- Windows: 'C:\\' to nie to samo co 'C:\\\\'
104	104		- Uniksy: ścieżka '/usr//' jest taka sama jak '/usr/'. Jeśli '/usr' jest katalogiem, to nawet wszystkie trzy zapisy są takie same.
105	105
106	106		Jest to ważne przy łączeniu nazw plików. Na przykład:
107	107
108	108		``` pascal
109	109		FullFilename:=FilePath+PathDelim+ShortFilename; // może skutkować dwoma znakami PathDelims, które dają różne wyniki pod Windows i Linux
110	110		FullFilename:=AppendPathDelim(FilePath) + ShortFilename; // tworzy tylko jeden znak PathDelim
111	111		FullFilename:=TrimFilename(FilePath+PathDelim+ShortFilename); // tworzy tylko jeden znak PathDelim i czyści ścieżkę
112	112		```
113	113
114	114		Funkcja TrimFilename zastępuje podwójne separatory ścieżek pojedynczymi jedynkami i skraca ścieżki typu '..'. Na przykład /usr//lib/../src jest przekształcony do postaci /usr/src.
115	115
116	116		Jeśli chcesz wiedzieć, czy katalog istnieje, użyj DirectoryExistsUTF8.
117	117
118	118		Innym częstym zadaniem jest sprawdzenie, czy istnieje ścieżka w nazwie pliku. Ścieżkę można uzyskać za pomocą ExtractFilePath, ale będzie ona zawierać separator ścieżki.
119	119
120	120		- W systemie uniksowym możesz po prostu użyć FileExistsUTF8 na ścieżce. Na przykład FileExistsUTF8('/home/user/') zwróci true, jeśli katalog /home/user istnieje.
121	121		- W systemie Windows musisz użyć funkcji DirectoryExistsUTF8, ale wcześniej musisz usunąć separator ścieżki, na przykład za pomocą funkcji ChompPathDelim.
122	122
123	123		W systemach uniksowych katalogiem głównym jest „/”, a użycie funkcji ChompPathDelim utworzy pusty ciąg. Funkcja DirPathExists działa jak funkcja DirectoryExistsUTF8, ale przycina podaną ścieżkę.
124	124
125	125		Zauważ, że Unix/Linux używa symbolu „~” (tylda) oznaczającego katalog domowy, np. „/home/jan/” dla użytkownika zwanego Jan. Tak więc „~/myapp/myfile” i „/home/jan/myapp/myfile” są identyczne w wierszu poleceń i skryptach. Jednak tylda nie jest automatycznie rozwijana przez Lazarusa. Aby uzyskać pełną ścieżkę, konieczne jest użycie ExpandFileNameUTF8('~/myapp/myfile').
126	126
127	127		### Kodowanie tekstu
128	128
129	129		Pliki tekstowe są często kodowane w bieżącym kodowaniu systemowym. W starszych systemach Windows jest to zwykle jedna ze stron kodowych systemu Windows, a w nowszych UTF-16, podczas gdy Linux, BSD i macOS zwykle używają UTF-8. Nie ma zasady, która na 100% da odpowiedź, jakiego kodowania używa plik tekstowy. Moduł LCL lconvencoding ma funkcję do odgadywania kodowania:
130	130
131	131		``` pascal
132	132		function GuessEncoding(const s: string): string;
133	133		function GetDefaultTextEncoding: string;
134	134		```
135	135
136	136		oraz zawiera funkcje do konwersji z jednego kodowania na inne:
137	137
138	138		``` pascal
139	139		function ConvertEncoding(const s, FromEncoding, ToEncoding: string): string;
140	140
141	141		function UTF8BOMToUTF8(const s: string): string; // UTF8 z BOM
142	142		function ISO_8859_1ToUTF8(const s: string): string; // Europa Środkowa
143	143		function CP1250ToUTF8(const s: string): string; // Europa Środkowa
144	144		function CP1251ToUTF8(const s: string): string; // cyrylica
145	145		function CP1252ToUTF8(const s: string): string; // Latin-1 (Europa Zachodnia)
146	146		...
147	147		function UTF8ToUTF8BOM(const s: string): string; // UTF8 z BOM
148	148		function UTF8ToISO_8859_1(const s: string): string; // Europa Środkowa
149	149		function UTF8ToCP1250(const s: string): string; // Europa Środkowa
150	150		function UTF8ToCP1251(const s: string): string; // cyrylica
151	151		function UTF8ToCP1252(const s: string): string; // Latin-1 (Europa Zachodnia)
152	152		...
153	153		```
154	154
155	155		Na przykład, aby załadować plik tekstowy i przekonwertować go na UTF-8, możesz użyć:
156	156
157	157		``` pascal
158	158		var
159	159		sl: TStringList;
160	160		OriginalText: String;
161	161		TextAsUTF8: String;
162	162		begin
163	163		sl:=TStringList.Create;
164	164		try
165	165		sl.LoadFromFile('jakis_tekst.txt'); // uwaga: zmienia to zakończenia linii na systemowe zakończenia linii
166	166		OriginalText:=sl.Text;
167	167		TextAsUTF8:=ConvertEncoding(OriginalText,GuessEncoding(OriginalText),EncodingUTF8);
168	168		...
169	169		finally
170	170		sl.Free;
171	171		end;
172	172		end;
173	173		```
174	174
175	175		Aby zapisać plik tekstowy w kodowaniu systemowym, możesz użyć:
176	176
177	177		``` pascal
178	178		sl.Text:=ConvertEncoding(TextAsUTF8,EncodingUTF8,GetDefaultTextEncoding);
179	179		sl.SaveToFile('jakis_tekst.txt');
180	180		```
181	181
182	182		### Pliki konfiguracyjne
183	183
184	184		Możesz użyć funkcji [[doc:rtl/sysutils/getappconfigdir.html\|GetAppConfigDir]] z modułu SysUtils, aby uzyskać odpowiednie miejsce do przechowywania plików konfiguracyjnych w innym systemie. Funkcja ma jeden parametr o nazwie Global. Jeśli ma wartość True, zwracany katalog jest katalogiem globalnym, tj. ważnym dla wszystkich użytkowników w systemie. Jeśli parametr Global ma wartość false, katalog jest specyficzny dla użytkownika, który wykonuje program. W systemach, które nie obsługują środowisk wielu użytkowników, te dwa katalogi mogą być takie same.
185	185
186	186		Istnieje również funkcja [[doc:rtl/sysutils/getappconfigfile.html\|GetAppConfigFile]], która zwróci odpowiednią nazwę dla pliku konfiguracyjnego aplikacji. Możesz jej użyć w ten sposób:
187	187
188	188		``` pascal
189	189		ConfigFilePath := GetAppConfigFile(False);
190	190		```
191	191
192	192		Poniżej znajdują się przykłady funkcji wypisujące domyślne ścieżki w różnych systemach:
193	193
194	194		``` pascal
195	195		program project1;
196	196
197	197		{$mode objfpc}{$H+}
198	198
199	199		uses
200	200		SysUtils;
201	201
202	202		begin
203	203		WriteLn(GetAppConfigDir(True));
204	204		WriteLn(GetAppConfigDir(False));
205	205		WriteLn(GetAppConfigFile(True));
206	206		WriteLn(GetAppConfigFile(False));
207	207		end.
208	208		```
209	209
210	210		Możesz zauważyć, że w systemie Linux globalne pliki konfiguracyjne przechowywane są w katalogu /etc, a lokalne w ukrytym katalogu w katalogu domowym użytkownika. Katalogi, których nazwa zaczyna się od kropki (.) są ukryte w systemach operacyjnych UNIX i podobnych do UNIX. Możesz utworzyć katalog w lokalizacji zwróconej przez GetAppConfigDir, a następnie przechowywać tam pliki konfiguracyjne.
211	211
212	212		> Note: Zwykli użytkownicy nie mogą pisać do katalogu /etc. Mogą to zrobić tylko użytkownicy z uprawnieniami administratora.
213	213
214	214		Zauważ, że przed FPC 2.2.4 funkcja korzystała z katalogu, w którym aplikacja przechowywała globalne konfiguracje systemu Windows.
215	215
216	216		Dane wyjściowe w systemie Windows 98 z FPC 2.2.0:
217	217
218	218		C:\Program Files\PROJECT1
219	219		C:\Windows\Local Settings\Application Data\PROJECT1
220	220		C:\Program Files\PROJECT1\PROJECT1.cfg
221	221		C:\Windows\Local Settings\Application Data\PROJECT1\PROJECT1.cfg
222	222
223	223		Dane wyjściowe w systemie Windows XP z FPC 3.0.4:
224	224
225	225		C:\Documents and Settings\All Users\Application Data\project1\
226	226		C:\Documents and Settings\user\Local Settings\Application Data\project1\
227	227		C:\Documents and Settings\All Users\Application Data\project1\project1.cfg
228	228		C:\Documents and Settings\user\Local Settings\Application Data\project1\project1.cfg
229	229
230	230		Dane wyjściowe w systemach Windows 7 i Windows 10 z FPC 3.0.4:
231	231
232	232		C:\ProgramData\project1\
233	233		C:\Users\user\AppData\Local\project1\
234	234		C:\ProgramData\project1\project1.cfg
235	235		C:\Users\user\AppData\Local\project1\project1.cfg
236	236
237	237		Dane wyjściowe w systemie macOS 10.14.5 z FPC 3.0.4 (naruszają Wytyczne Apple — zobacz poniżej, aby poznać prawidłowe lokalizacje plików w systemie macOS):
238	238
239	239		/etc/project1/
240	240		/Users/user/.config/project1/
241	241		/etc/project1.cfg
242	242		/Users/user/.config/project1.cfg
243	243
244	244		Dane wyjściowe na FreeBSD 12.1 z FPC 3.0.4:
245	245
246	246		/etc/project1/
247	247		/home/user/.config/project1/
248	248		/etc/project1.cfg
249	249		/home/user/.config/project1.cfg
250	250
251	251		Obserwator może zauważyć różnicę między danymi wyjściowymi systemów operacyjnych Windows i innych niż Windows — dane wyjściowe systemu Windows dla `WriteLn(GetAppConfigFile(True));` globalne ścieżki konfiguracji zawierają podkatalog projektu, ale inne systemy operacyjne nie. Aby uzyskać te same wyniki dla systemów operacyjnych innych niż Windows, należy dołączyć dodatkowy parametr [[Boolean\|logiczny]]: `WriteLn(GetAppConfigFile(True,True));`.
252	252
253	253		> Note: Użycie UPX zakłóca korzystanie z funkcji GetAppConfigDir i GetAppConfigFile.
254	254
255	255		#### macOS
256	256
257	257		W większości przypadków pliki konfiguracyjne to pliki preferencji, które w systemie macOS powinny być plikami XML z rozszerzeniem „.plist” i znajdować się w katalogu /Library/Preferences lub ~/Library/Preferences z nazwami pobranymi z pola „Identyfikator pakietu” w pliku [[macOS property list files\|Info.plist]] [[Application Bundle\|pakietu aplikacji]]. Używanie plików .config w katalogu użytkownika jest naruszeniem wytycznych programistycznych Apple. Zapoznaj się z artykułem [[Locating macOS app support, preferences folders\|Lokalizowanie obsługi aplikacji macOS, foldery preferencji]], aby zapoznać się z kodem, który obsługuje to w sposób zgodny z Apple.
258	258
259	259		### Pliki danych i zasobów
260	260
261	261		Bardzo częstym pytaniem jest, gdzie przechowywać pliki danych, których może potrzebować aplikacja, takie jak obrazy, muzyka, pliki XML, pliki bazy danych, pliki pomocy itp. Niestety nie ma funkcji wieloplatformowej, aby uzyskać najlepszą lokalizację do wyszukiwania plików danych. Rozwiązaniem jest implementacja w inny sposób na każdej platformie przy użyciu IFDEF.
262	262
263	263		#### Windows
264	264
265	265		W systemie Windows dane aplikacji, które modyfikuje program, nie powinny być umieszczane w katalogu aplikacji (np. C:\Program Files\\), ale w określonej lokalizacji. System Windows Vista i nowsze aktywnie to wymuszają (użytkownicy mają dostęp tylko do zapisu w tych katalogach podczas korzystania z funkcji podnoszenia uprawnień lub wyłączania kontroli konta użytkownika), ale używają mechanizmu przekierowywania folderów, aby uwzględnić starsze, błędnie zaprogramowane aplikacje. Samo odczytywanie, a nie pisanie, danych z katalogów aplikacji nadal działa, ale nie jest to zalecane.
266	266
267	267		W skrócie: użyj takiego folderu:
268	268
269	269		``` pascal
270	270		OpDirLocal:= GetEnvironmentVariableUTF8('appdata')+'\MyAppName';
271	271		```
272	272
273	273		Zobacz: [[Windows Programming Tips\|Wskazówki dotyczące programowania w systemie Windows — uzyskiwanie specjalnych folderów]]
274	274
275	275		#### Unix/Linux
276	276
277	277		W większości systemów Unix (takich jak Linux, FreeBSD, OpenBSD, Solaris, ale nie macOS) pliki danych aplikacji znajdują się w stałej lokalizacji, która może wyglądać tak: /usr/local/share/nazwa_aplikacji lub /opt/nazwa_aplikacji.
278	278
279	279		Dane aplikacji, do których aplikacja musi zapisać, często są przechowywane w miejscach takich jak /usr/local/var/nazwa_aplikacji, /usr/local/share/nazwa_aplikacji lub /usr/local/nazwa_aplikacji, z odpowiednimi uprawnieniami.
280	280
281	281		Pliki pomocy (inaczej strony podręcznika) powinny być przechowywane w /usr/local/man/man\[numer odpowiedniej sekcji podręcznika\]/nazwa_aplikacji\>, z odpowiednimi uprawnieniami. Zauważ, że niektóre sekcje podręcznika FreeBSD i Linuksa różnią się lub nie istnieją.
282	282
283	283		Pliki konfiguracji/danych do odczytu/zapisu specyficzne dla użytkownika będą zwykle przechowywane gdzieś w katalogu domowym użytkownika (np. w ~/.config/\<nazwa programu\>). Zapoznaj się z powyższymi [[Multiplatform Programming Guide\|plikami konfiguracyjnymi]].
284	284
285	285		#### macOS
286	286
287	287		macOS jest wyjątkiem wśród systemów operacyjnych UNIX. Aplikacja jest publikowana w pakiecie (katalog z rozszerzeniem „.app”), który jest traktowany przez menedżera plików Finder jako plik (w Terminalu można użyć „cd path/myapp.app” lub w Finderze prawym przyciskiem myszy na aplikacji i wybierz „Show Package Contents” („Pokaż zawartość pakietu”). Twoje pliki zasobów powinny znajdować się wewnątrz pakietu. Jeśli pakiet to „path/MojaAplikacja.app”, to:
288	288
289	289		- plik wykonywalny to "path/MojaAplikacja.app/Contents/MacOS/myapp"
290	290		- katalog zasobów to "path/MojaAplikacja.app/Contents/Resources"
291	291
292	292		Dane i pliki zasobów dostarczane przez aplikację powinny być zazwyczaj przechowywane w katalogu Resources pakietu aplikacji. Aby zapoznać się z kodem, który obsługuje to w sposób zgodny z Apple, zobacz artykuł [[Locating the macOS application resources directory\|Lokalizowanie katalogu zasobów aplikacji systemu macOS]].
293	293
294	294		Pliki danych aplikacji wygenerowane przez użytkownika powinny być przechowywane w katalogu użytkownika „~/Library/Application Support”. Aby poznać kod, który obsługuje to w sposób zgodny z Apple, zapoznaj się z artykułem [[Locating macOS app support, preferences folders\|Lokalizowanie obsługi aplikacji macOS, foldery preferencji]].
295	295
296	296		> Warning: Nigdy nie używaj `paramStr(0)` ani żadnej funkcji, która go używa, na żadnej platformie UNIX do określenia lokalizacji pliku wykonywalnego, ponieważ jest to konwencja DOS-Windows-OS/2 i ma kilka problemów koncepcyjnych, których nie można rozwiązać za pomocą emulacji na innych platformach. Jedyną rzeczą, którą `paramStr(0)` gwarantuje na platformach UNIX jest nazwa, pod którą program został uruchomiony. Nie ma gwarancji, że katalog, w którym się znajduje, oraz nazwa rzeczywistego pliku binarnego (w przypadku, gdy został uruchomiony przy użyciu dowiązania symbolicznego) będą dostępne za pośrednictwem `paramStr(0)`. W przypadku systemu macOS można niezawodnie zlokalizować katalog pakietu aplikacji przy użyciu kodu natywnego opisanego w [[Locating the macOS application resources directory\|tym artykule]].
297	297
298	298		### 32/64 bit
299	299
300	300		#### Wykrywanie wersji bitowej systemu w czasie wykonywania
301	301
302	302		Chociaż możesz kontrolować, czy kompilujesz dla systemu 32 lub 64-bit za pomocą definicji kompilatora, czasami chcesz wiedzieć, jaka jest bitowość systemu operacyjnego. Na przykład, jeśli używasz 32-bitowego programu Lazarus w 64-bitowym systemie Windows, możesz chcieć uruchomić zewnętrzny program w katalogu 32-bitowych plików programu lub możesz chcieć przekazać użytkownikom inne informacje: Potrzebuję tego w moim instalatorze Lazarusa LazUpdater oferujący użytkownikowi wybór 32- i 64-bitowych kompilatorów. Przykład kodu: [[Detect Windows x32-x64 example\|Wykryj Windows x32-x64]].
303	303
304	304		#### Wykrywanie wersji bitowej zewnętrznej biblioteki przed jej załadowaniem
305	305
306	306		Kiedy chcesz załadować funkcje z biblioteki dynamicznej do twojego programu, musi ona mieć taką samą wersję bitową jak twoja aplikacja. W 64-bitowym systemie Windows aplikacja może być 32-bitowa lub 64-bitowa, a w systemie mogą znajdować się biblioteki 32-bitowe i 64-bitowe. Więc możesz chcieć sprawdzić, czy wersja bitowa biblioteki dll jest taka sama jak twojej aplikacji przed dynamicznym załadowaniem dll. Oto funkcja testująca wersję bitową dll ([opublikowana na forum przez GetMem](http://forum.lazarus.freepascal.org/index.php/topic,36834.msg245859.html#msg245859)) (komentarze zostały przetłumaczone):
307	307
308	308		``` pascal
309	309
310	310		uses {..., } JwaWindows;
311	311
312	312		function GetPEType(const APath: WideString): Byte;
313	313		const
314	314		PE_UNKNOWN = 0; //jeśli plik nie jest poprawną biblioteką dll, zwracane jest 0
315	315		// PE_16BIT = 1; // nieobsługiwane przez tę funkcję
316	316		PE_32BIT = 2;
317	317		PE_64BIT = 3;
318	318		var
319	319		hFile, hFileMap: THandle;
320	320		PMapView: Pointer;
321	321		PIDH: PImageDosHeader;
322	322		PINTH: PImageNtHeaders;
323	323		Base: Pointer;
324	324		begin
325	325		Result := PE_UNKNOWN;
326	326
327	327		hFile := CreateFileW(PWideChar(APath), GENERIC_READ, FILE_SHARE_READ, nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);
328	328		if hFile = INVALID_HANDLE_VALUE then
329	329		begin
330	330		CloseHandle(hFile);
331	331		Exit;
332	332		end;
333	333
334	334		hFileMap := CreateFileMapping(hFile, nil, PAGE_READONLY, 0, 0, nil);
335	335		if hFileMap = 0 then
336	336		begin
337	337		CloseHandle(hFile);
338	338		CloseHandle(hFileMap);
339	339		Exit;
340	340		end;
341	341
342	342		PMapView := MapViewOfFile(hFileMap, FILE_MAP_READ, 0, 0, 0);
343	343		if PMapView = nil then
344	344		begin
345	345		CloseHandle(hFile);
346	346		CloseHandle(hFileMap);
347	347		Exit;
348	348		end;
349	349
350	350		PIDH := PImageDosHeader(PMapView);
351	351		if PIDH^.e_magic <> IMAGE_DOS_SIGNATURE then
352	352		begin
353	353		CloseHandle(hFile);
354	354		CloseHandle(hFileMap);
355	355		UnmapViewOfFile(PMapView);
356	356		Exit;
357	357		end;
358	358
359	359		Base := PIDH;
360	360		PINTH := PIMAGENTHEADERS(Base + LongWord(PIDH^.e_lfanew));
361	361		if PINTH^.Signature = IMAGE_NT_SIGNATURE then
362	362		begin
363	363		case PINTH^.OptionalHeader.Magic of
364	364		$10b: Result := PE_32BIT;
365	365		$20b: Result := PE_64BIT
366	366		end;
367	367		end;
368	368
369	369		CloseHandle(hFile);
370	370		CloseHandle(hFileMap);
371	371		UnmapViewOfFile(PMapView);
372	372		end;
373	373
374	374		//Teraz, jeśli skompilujesz swoją aplikację dla 32-bitowych i 64-bitowych wersji Windows,
375	375		//możesz sprawdzić, czy wersja bitowa dll jest taka sama jak w Twojej aplikacji:
376	376		function IsCorrectBitness(const APath: WideString): Boolean;
377	377		begin
378	378		{$ifdef CPU32}
379	379		Result := GetPEType(APath) = 2; //aplikacja jest kompilowana jako 32-bitowa, pytamy czy GetPeType zwraca 2
380	380		{$endif}
381	381		{$ifdef CPU64}
382	382		Result := GetPEType(APath) = 3; //aplikacja jest kompilowana jako 64-bitowa, pytamy czy GetPeType zwraca 3
383	383		{$endif}
384	384		end;
385	385		```
386	386
387	387		#### Typy wskaźników / liczb całkowitych
388	388
389	389		Wskaźniki pod architekturą 64-bitową zajmują 8 bajtów zamiast 4 na 32-bitowej. Typ 'Integer' pozostaje 32-bitowy na wszystkich platformach, aby zapewnić zgodność. Oznacza to, że nie możesz rzutować wskaźników na typ Integer i z powrotem.
390	390
391	391		FPC definiuje w tym celu dwa typy: PtrInt i PtrUInt. PtrInt to 32-bitowa liczba całkowita ze znakiem na platformach 32-bitowych i 64-bitowa liczba całkowita ze znakiem na platformach 64-bitowych. To samo dla PtrUInt, ale dla liczb całkowitych bez znaku.
392	392
393	393		Użyj dla kodu, który powinien działać z Delphi i FPC:
394	394
395	395		``` pascal
396	396		{$IFNDEF FPC}
397	397		type
398	398		PtrInt = integer;
399	399		PtrUInt = cardinal;
400	400		{$ENDIF}
401	401		```
402	402
403	403		Zamień wszystkie rzutowania wskaźnika Integer(SomePointerOrObject) na PtrInt(SomePointerOrObject).
404	404
405	405		### Kolejność bajtów
406	406
407	407		Platformy Intela są little endian, co oznacza, że najmniej znaczący bajt jest na pierwszym miejscu. Na przykład dwa bajty słowa \$1234 są przechowywane kolejno jako \$34 \$12 w systemach little endian. W systemach typu big endian, takich jak powerpc, dwa bajty słowa \$1234 są przechowywane kolejno jako \$12 \$34. Różnica jest istotna przy odczytywaniu plików utworzonych na innych systemach.
408	408
409	409		Użyj dla kodu, który powinien działać na obu systemach:
410	410
411	411		``` pascal
412	412		{$IFDEF ENDIAN_BIG}
413	413		...
414	414		{$ELSE}
415	415		...
416	416		{$ENDIF}
417	417		```
418	418
419	419		Przeciwieństwo dla ENDIAN_BIG to ENDIAN_LITTLE.
420	420
421	421		Moduł system zapewnia wiele funkcji konwertujących endian, takich jak SwapEndian, BEtoN (big endian do bieżącego endian), LEtoN (little endian do bieżącego endian), NtoBE (bieżący endian do big endian) i NtoLE (bieżący endian do little endian).
422	422
423	423		#### Libc i inne jednostki specjalne
424	424
425	425		Unikaj starszych modułów, takich jak „oldlinux” i „libc”, które nie są obsługiwane poza linux/i386.
426	426
427	427		#### Asembler
428	428
429	429		Unikaj używania [[Assembly language\|asemblera]].
430	430
431	431		#### Dyrektywy kompilatora
432	432
433	433		``` pascal
434	434		{$ifdef CPU32}
435	435		...tutaj napisz kod dla procesorów 32-bitowych
436	436		{$ENDIF}
437	437		{$ifdef CPU64}
438	438		...tutaj napisz kod dla procesorów 64-bitowych
439	439		{$ENDIF}
440	440		```
441	441
442	442		### Projekty, pakiety i ścieżki wyszukiwania
443	443
444	444		Lazarus projects and packages are designed for multi platforms. Normally you can simply copy the project and the required packages to another machine and compile them there. You don't need to create one project per platform. Projekty i pakiety Lazarusa są przeznaczone dla wielu platform. Zwykle możesz po prostu skopiować projekt i wymagane pakiety na inny komputer i tam je skompilować. Nie musisz tworzyć osobnego projektu dla każdej platformy.
445	445
446	446		Kilka rad, jak to osiągnąć.
447	447
448	448		Kompilator tworzy dla każdego modułu plik ppu o tej samej nazwie. Ten plik ppu może być używany przez inne projekty i pakiety. Pliki źródłowe modułu (np. unit1.pas) nie powinny być udostępniane. Po prostu daj kompilatorowi katalog wyjściowy modułu, w którym ma tworzyć pliki ppu. IDE robi to domyślnie, więc nie ma tu nic do roboty.
449	449
450	450		Każdy plik modułu musi być częścią jednego projektu lub pakietu. Jeśli plik modułu jest używany tylko w jednym projekcie, dodaj go do tego projektu. W przeciwnym razie dodaj go do pakietu. Jeśli jeszcze nie utworzyłeś pakietu dla swoich modułów współdzielonych, zobacz tutaj: [[Lazarus Packages\|Tworzenie pakietu dla wspólnych modułów]].
451	451
452	452		Każdy projekt i każdy pakiet powinien mieć oddzielne katalogi - nie powinny one współdzielić katalogów. W przeciwnym razie musisz być ekspertem w dziedzinie ścieżek wyszukiwania kompilatora. Jeśli nie jesteś ekspertem lub jeśli inne osoby, które mogą korzystać z Twojego projektu/pakietu, nie są ekspertami: nie twórz wspólnego katalogu dla projektów i pakietów.
453	453
454	454		#### Moduły zależne od platformy
455	455
456	456		Na przykład moduł wintricks.pas powinien być używany tylko w systemie Windows. W sekcji uses użyj:
457	457
458	458		``` pascal
459	459		uses
460	460		Classes, SysUtils
461	461		{$IFDEF Windows}
462	462		,WinTricks
463	463		{$ENDIF}
464	464		;
465	465		```
466	466
467	467		Jeśli moduł jest częścią pakietu, należy również wybrać ten moduł w edytorze pakietów i odznaczyć pole wyboru Use unit.
468	468
469	469		Zobacz także [[Lazarus Packages\|Moduły zależne od platformy]]
470	470
471	471		#### Ścieżki wyszukiwania specyficzne dla platformy
472	472
473	473		Kiedy wybierasz kilka platform i masz bezpośredni dostęp do systemu operacyjnego, szybko zmęczysz się niekończącymi się konstrukcjami IFDEF. Jednym z rozwiązań często stosowanych w źródłach FPC i Lazarus jest użycie plików dołączanych (include files). Utwórz jeden podkatalog na każdą docelową platformę. Na przykład win32, linux, bsd, darwin. Umieść w każdym katalogu plik dołączany o tej samej nazwie. Następnie użyj makra w ścieżce include. Moduł może używać normalnej dyrektywy include.
474	474
475	475		Przykład jednego pliku include dla każdego zestawu widżetów LCL:
476	476
477	477		Utwórz jeden plik dla każdego zestawu widżetów, który chcesz obsługiwać:
478	478
479		-	~~`win32/example.inc`\~~
480		-	~~`gtk/example.inc`\~~
481		-	~~`gtk2/example.inc`\~~
482		-	~~`carbon/example.inc`~~
	479	+	```text
	480	+	win32/example.inc
	481	+	gtk/example.inc
	482	+	gtk2/example.inc
	483	+	carbon/example.inc
	484	+	```
483	485
484	486		Nie musisz dodawać plików do pakietu lub projektu. Dodaj ścieżkę wyszukiwania include \$(LCLWidgetType) do opcji kompilatora pakietu lub projektu.
485	487
486	488		W swoim module użyj dyrektywy: {\$I example.inc}
487	489
488	490		Oto kilka przydatnych makr i typowych wartości:
489	491
490	492		- LCLWidgetType: win32, gtk, gtk2, qt, carbon, fpgui, nogui
491	493		- TargetOS: linux, win32, win64, wince, freebsd, netbsd, openbsd, darwin (many more)
492	494		- TargetCPU: i386, x86_64, arm, powerpc, sparc
493	495		- SrcOS: win, unix
494	496
495	497		Do używania zmiennych środowiskowych można użyć makra \$Env().
496	498
497	499		I oczywiście możesz używać ich kombinacji. Na przykład LCL wykorzystuje:
498	500
499		-	~~`$(LazarusDir)/lcl/units/$(TargetCPU)-$(TargetOS);$(LazarusDir)/lcl/units/$(TargetCPU)-$(TargetOS)/$(LCLWidgetType)`~~
	501	+	```text
	502	+	$(LazarusDir)/lcl/units/$(TargetCPU)-$(TargetOS);$(LazarusDir)/lcl/units/$(TargetCPU)-$(TargetOS)/$(LCLWidgetType)
	503	+	```
500	504
501	505		Zobacz tutaj pełną listę makr: [[IDE Macros in paths and filenames\|Makra IDE w ścieżkach i nazwach plików]].
502	506
503	507		#### Ścieżki wyszukiwania specyficzne dla maszyny/użytkownika
504	508
505	509		Na przykład masz dwa komputery z systemem Windows, stan i oliver. W komputerze 'stan twoje moduły znajdują się w C:\units, a na oliver w D:\path. Moduły należą do pakietu SharedStuff, który jest w pliku C:\units\sharedstuff.lpk na stan i i w pliku D:\path\sharedstuff.lpk na oliver. Po otwarciu pliku lpk w IDE lub przez lazbuild, ścieżka jest automatycznie zapisywana w jego plikach konfiguracyjnych (packagefiles.xml). Podczas kompilowania projektu, który wymaga pakietu SharedStuff, IDE i lazbuild wiedzą, gdzie on jest. Więc nie jest potrzebna konfiguracja.
506	510
507	511		Jeśli chcesz wdrożyć pakiet na wielu maszynach lub dla wszystkich użytkowników maszyny (np. basen dla studentów), możesz dodać plik lpl w katalogu źródłowym lazarusa. Zobacz katalog Lazarusa packager/globallinks, aby zapoznać się z przykładami.
508	512
509	513		### Różnice regionalne
510	514
511	515		Niektóre funkcje z Free Pascal, takie jak StrToFloat, zachowują się różnie w zależności od ustawień bieżącego [[locale\|regionu]]. Na przykład w USA separatorem dziesiętnym jest zwykle „.”, ale w wielu krajach Europy (w tym w Polsce) i Ameryki Południowej jest to „,”. Może to stanowić problem, ponieważ czasami pożądane jest, aby te funkcje zachowywały się w ustalony sposób, niezależnie od ustawień regionalnych. Przykładem jest format pliku z kropkami dziesiętnymi, które zawsze należy interpretować w ten sam sposób.
512	516
513	517		Następne sekcje wyjaśniają, jak to zrobić.
514	518
515	519		#### macOS
516	520
517	521		Zapoznaj się z artykułem [[Locale settings for macOS\|Ustawienia regionalne dla systemu macOS]], aby uzyskać szczegółowe informacje na temat ustawiania języka w systemie macOS.
518	522
519	523		#### StrToFloat
520	524
521	525		Nowy zestaw ustawień formatu, który ustawia stały separator dziesiętny, można utworzyć za pomocą następującego kodu:
522	526
523	527		``` pascal
524	528		// w pliku projektu .lpr
525	529		uses
526	530		...
527	531		{$IFDEF UNIX}
528	532		clocale
529	533		{ wymagane w systemie Linux/Unix do obsługi ustawień formatów. Powinien być jednym z pierwszych (prawdopodobnie po cthreads?}
530	534		{$ENDIF}
531	535		```
532	536
533	537		and:
534	538
535	539		``` pascal
536	540		// w twoim kodzie:
537	541		var
538	542		FPointSeparator, FCommaSeparator: TFormatSettings;
539	543		begin
540	544		// Format settings to convert a string to a float
541	545		// Ustawienia formatu, aby przekonwertować ciąg string na liczbę zmiennoprzecinkowąq
542	546		FPointSeparator := DefaultFormatSettings;
543	547		FPointSeparator.DecimalSeparator := '.';
544	548		FPointSeparator.ThousandSeparator := '#';// wyłącz separator tysięcy
545	549		FCommaSeparator := DefaultFormatSettings;
546	550		FCommaSeparator.DecimalSeparator := ',';
547	551		FCommaSeparator.ThousandSeparator := '#';// wyłącz separator tysięcy
548	552		```
549	553
550	554		Później możesz użyć tych ustawień formatu podczas wywoływania StrToFloat, na przykład:
551	555
552	556		``` pascal
553	557		// Ta funkcja działa jak StrToFloat, ale po prostu próbuje dwóch możliwych separatorów dziesiętnych
554	558		// Pozwoli to uniknąć wyjątku, gdy format ciągu string nie pasuje do ustawień regionalnych
555	559		function AnSemantico.StringToFloat(AStr: string): Double;
556	560		begin
557	561		if Pos('.', AStr) > 0 then Result := StrToFloat(AStr, FPointSeparator)
558	562		else Result := StrToFloat(AStr, FCommaSeparator);
559	563		end;
560	564		```
561	565
562	566		### Gtk2 i maskowanie wyjątków FPU
563	567
564	568		Biblioteka Gtk2 zmienia domyślną wartość maski wyjątków FPU (koprocesor - jednostka zmiennoprzecinkowa). Konsekwencją tego jest to, że niektóre wyjątki zmiennoprzecinkowe nie są zgłaszane, jeśli aplikacja korzysta z biblioteki Gtk2. Oznacza to, że jeśli na przykład tworzysz aplikację LCL w systemie Windows z zestawem widżetów win32/64 (który jest domyślnym systemem Windows) i planujesz kompilację dla systemu Linux (gdzie Gtk2 jest domyślnym zestawem widżetów), powinieneś pamiętać o tych niezgodnościach.
565	569
566	570		Po [tym zgłoszeniu na forum](http://www.lazarus.freepascal.org/index.php/topic,13460.0.html) i odpowiedziach na [ten raport o błędzie](http://bugs.freepascal.org/view.php?id=19674) stało się jasne, że nic nie można z tym zrobić, więc musimy wiedzieć, czym właściwie są te różnice.
567	571
568	572		Dlatego zróbmy test:
569	573
570	574		``` pascal
571	575		uses
572	576		..., math,...
573	577
574	578		{...}
575	579
576	580		var
577	581		FPUException: TFPUException;
578	582		FPUExceptionMask: TFPUExceptionMask;
579	583		begin
580	584		FPUExceptionMask := GetExceptionMask;
581	585		for FPUException := Low(TFPUException) to High(TFPUException) do begin
582	586		write(FPUException, ' - ');
583	587		if not (FPUException in FPUExceptionMask) then
584	588		write('not ');
585	589
586	590		writeln('masked!');
587	591		end;
588	592		readln;
589	593		end.
590	594		```
591	595
592	596		Nasz prosty program otrzyma domyślne wartości FPC:
593	597
594	598		exInvalidOp - not masked!
595	599		exDenormalized - masked!
596	600		exZeroDivide - not masked!
597	601		exOverflow - not masked!
598	602		exUnderflow - masked!
599	603		exPrecision - masked!
600	604
601	605		Jednak w przypadku Gtk2 tylko exOverflow nie jest maskowany.
602	606
603	607		Konsekwencją jest to, że wyjątki EInvalidOp i EZeroDivide nie są zgłaszane, jeśli aplikacja łączy się z biblioteką Gtk2! Zwykle dzielenie wartości niezerowej przez zero powoduje wyjątek EZeroDivide, a dzielenie zera przez zero powoduje zwiększenie EInvalidOp. Na przykład taki kod:
604	608
605	609		``` pascal
606	610		var
607	611		X, A, B: Double;
608	612		// ...
609	613
610	614		try
611	615		X := A / B;
612	616		// blok kodu 1
613	617		except
614	618		// blok kodu 2
615	619		end;
616	620		// ...
617	621		```
618	622
619	623		przyjmie inny kierunek po skompilowaniu w aplikacji z zestawem widżetów Gtk2. W zestawie widżetów win, gdy B jest równe zero, zostanie zgłoszony wyjątek (EZeroDivide lub EInvalidOp, w zależności od tego, czy A jest zerem) i zostanie wykonany „blok kodu 2”. Na Gtk2 X staje się [Infinity](http://www.freepascal.org/docs-html/rtl/math/infinity.html), [NegInfinity](http://www.freepascal.org/docs-html/rtl/math/neginfinity.html) lub [NaN](http://www.freepascal.org/docs-html/rtl/math/nan.html) i „blok kodu 1” zostanie wykonany.
620	624
621	625		Możemy wymyślić różne sposoby przezwyciężenia tej niespójności. W większości przypadków możesz po prostu sprawdzić, czy B jest równe zero i nie próbować dzielić w takim przypadku. Czasami jednak będziesz potrzebować innego podejścia. Spójrz więc na następujące przykłady:
622	626
623	627		``` pascal
624	628		uses
625	629		..., math,...
626	630
627	631		//...
628	632		var
629	633		X, A, B: Double;
630	634		Ind: Boolean;
631	635		// ...
632	636		try
633	637		X := A / B;
634	638		Ind := IsInfinite(X) or IsNan(X); // z gtk2 wpadamy tutaj
635	639		except
636	640		Ind := True; // w Windows wpadamy tutaj, gdy B równa się zero
637	641		end;
638	642		if Ind then begin
639	643		// blok kodu 2
640	644		end else begin
641	645		// blok kodu 1
642	646		end;
643	647		// ...
644	648		```
645	649
646	650		Lub:
647	651
648	652		``` pascal
649	653		uses
650	654		..., math,...
651	655
652	656		//...
653	657		var
654	658		X, A, B: Double;
655	659		FPUExceptionMask: TFPUExceptionMask;
656	660		// ...
657	661
658	662		try
659	663		FPUExceptionMask := GetExceptionMask;
660	664		SetExceptionMask(FPUExceptionMask - [exInvalidOp, exZeroDivide]); // niemaskowane
661	665		try
662	666		X := A / B;
663	667		finally
664	668		SetExceptionMask(FPUExceptionMask); // natychmiast zwróć poprzednie maskowanie, nie możemy pozwolić, aby wewnętrzne elementy Gtk2 były wywoływane bez maski
665	669		end;
666	670		// blok kodu 1
667	671		except
668	672		// blok kodu 2
669	673		end;
670	674		// ...
671	675		```
672	676
673	677		Bądź ostrożny, nie rób czegoś takiego (wywołanie LCL z wciąż zdjętą maską):
674	678
675	679		``` pascal
676	680		try
677	681		FPUExceptionMask := GetExceptionMask;
678	682		SetExceptionMask(FPUExceptionMask - [exInvalidOp, exZeroDivide]);
679	683		try
680	684		Edit1.Text := FloatToStr(A / B); // NIE! Ustawienie tekstu Edit sprowadza się do wewnętrznych widżetów, a API Gtk2 nie może być wywoływane bez maski!
681	685		finally
682	686		SetExceptionMask(FPUExceptionMask);
683	687		end;
684	688		// blok kodu 1
685	689		except
686	690		// blok kodu 2
687	691		end;
688	692		// ...
689	693		```
690	694
691	695		Ale użyj zmiennej pomocniczej:
692	696
693	697		``` pascal
694	698		try
695	699		FPUExceptionMask := GetExceptionMask;
696	700		SetExceptionMask(FPUExceptionMask - [exInvalidOp, exZeroDivide]);
697	701		try
698	702		X := A / B; // Najpierw ustawiamy zmienną pomocniczą X
699	703		finally
700	704		SetExceptionMask(FPUExceptionMask);
701	705		end;
702	706		Edit1.Text := FloatToStr(X); // Teraz możemy ustawić tekst w Edit.
703	707		// blok kodu 1
704	708		except
705	709		// blok kodu 2
706	710		end;
707	711		// ...
708	712		```
709	713
710	714		We wszystkich sytuacjach podczas tworzenia aplikacji LCL najważniejsze jest, aby o tym wiedzieć i pamiętać, że niektóre operacje zmiennoprzecinkowe mogą przebiegać w inny sposób z różnymi zestawami widżetów. Następnie możesz wymyślić odpowiedni sposób na obejście tego, ale nie powinno to pozostać niezauważone.
711	715
712	716		## Problemy przy przejściu z systemu Windows do *nix itp.
713	717
714	718		W tym miejscu opisano problemy specyficzne dla systemów Linux, macOS, Android i innych Uniksów. Nie wszystkie tematy mogą dotyczyć wszystkich platform.
715	719
716	720		### W Uniksie nie ma „katalogu aplikacji”
717	721
718	722		Wielu programistów jest przyzwyczajonych do wywoływania ExtractFilePath(ParamStr(0)) lub Application.ExeName w celu uzyskania lokalizacji pliku wykonywalnego, a następnie wyszukiwania plików niezbędnych do wykonania programu (obrazy, pliki XML, pliki bazy danych itp.) na podstawie lokalizacji pliku wykonywalnego. To jest złe na unixach. Ciąg w ParamStr(0) może zawierać katalog inny niż plik wykonywalny, a także różni się między różnymi programami powłoki (sh, bash, itp.).
719	723
720	724		Nawet jeśli Application.ExeName może w rzeczywistości znać katalog, w którym znajduje się plik wykonywalny, plik ten może być dowiązaniem symbolicznym, więc zamiast tego można uzyskać katalog dowiązania (w zależności od wersji jądra Linux można uzyskać katalog dowiązania lub samego programu binarnego).
721	725
722	726		Aby tego uniknąć, przeczytaj sekcje dotyczące [[Multiplatform Programming Guide/pl\|plików konfiguracyjnych]] i [[Multiplatform Programming Guide/pl\|plików danych]].
723	727
724	728		### Obycie się bez Windows COM Automation
725	729
726	730		W systemie Windows Automatyzacja COM jest potężnym sposobem nie tylko na zdalne manipulowanie innymi programami, ale także na umożliwienie innym programom manipulowania Twoim programem. Dzięki Delphi możesz uczynić swój program zarówno klientem COM Automation, jak i serwerem COM Automation, co oznacza, że może on zarówno manipulować innymi programami, jak i być manipulowany przez inne programy. Aby zapoznać się z przykładami, zobacz [Używanie automatyzacji COM do interakcji z pakietami OpenOffice i Microsoft Office](http://wiki.lazarus.freepascal.org/Office_Automation#Using_COM_Automation_to_interact_with_OpenOffice_and_Microsoft_Office).
727	731
728	732		#### alternatywa dla macOS
729	733
730	734		Niestety, COM Automation nie jest dostępna w systemach macOS i Linux. Można jednak symulować niektóre funkcje COM Automation w systemie macOS za pomocą AppleScript.
731	735
732	736		AppleScript jest pod pewnymi względami podobny do COM Automation. Na przykład możesz pisać skrypty, które manipulują innymi programami. Oto bardzo prosty przykład AppleScript, który uruchamia NeoOffice (wersja OpenOffice.org na Maca):
733	737
734	738		```applescript
735	739		tell application "NeoOffice"
736	740		launch
737	741		end tell
738	742		```
739	743
740	744		Aplikacja zaprojektowana do manipulowania przez AppleScript udostępnia „słownik” klas i poleceń, których można używać z aplikacją, podobnie jak klasy serwera Windows Automation. Jednak nawet aplikacje, takie jak NeoOffice, które nie udostępniają słownika, nadal będą odpowiadać na polecenia „launch” (uruchom), „activate” (aktywuj) i „quit” (wyjście). AppleScript można uruchomić z edytora skryptów macOS lub Findera, a nawet przekonwertować na aplikację, którą można upuścić do stacji dokującej, tak jak każdą aplikację. Możesz także uruchomić AppleScript ze swojego programu, jak w tym przykładzie:
741	745
742	746		``` pascal
743	747		fpsystem('myscript.applescript');
744	748		```
745	749
746	750		Zakłada się, że skrypt znajduje się we wskazanym pliku. Możesz także uruchamiać skrypty w locie ze swojej aplikacji za pomocą polecenia macOS OsaScript:
747	751
748	752		``` pascal
749	753		fpsystem('osascript -e '#39'tell application "NeoOffice"'#39 +
750	754		' -e '#39'launch'#39' -e '#39'end tell'#39);
751	755		{Zwróć uwagę na użycie #39 jako pojedynczego cudzysłowu do parametrów}
752	756		```
753	757
754	758		Jednak te przykłady są tylko odpowiednikiem następującego polecenia Open (otwórz):
755	759
756	760		``` pascal
757	761		fpsystem('open -a NeoOffice');
758	762		```
759	763
760	764		Podobnie w systemie macOS można emulować polecenia powłoki systemu Windows, aby uruchomić przeglądarkę internetową i uruchomić klienta poczty e-mail za pomocą:
761	765
762	766		``` pascal
763	767		fpsystem('open -a safari "http://gigaset.com/shc/0,1935,hq_en_0_141387_rArNrNrNrN,00.html"');
764	768		```
765	769
766	770		i
767	771
768	772		``` pascal
769	773		fpsystem('open -a mail "mailto:ss4200@invalid.org"');
770	774		```
771	775
772	776		co zakłada, dość bezpiecznie, że system macOS będzie miał zainstalowane aplikacje Safari i Mail. Oczywiście nigdy nie należy przyjmować takich założeń, a w przypadku dwóch poprzednich przykładów można po prostu polegać na systemie macOS, aby postępować właściwie i wybrać domyślną przeglądarkę internetową i klienta poczty e-mail użytkownika, jeśli zamiast tego użyjesz tych odmian:
773	777
774	778		``` pascal
775	779		fpsystem('open "http://gigaset.com/shc/0,1935,hq_en_0_141387_rArNrNrNrN,00.html"');
776	780		```
777	781
778	782		i
779	783
780	784		``` pascal
781	785		fpsystem('open "mailto:ss4200@invalid.org"');
782	786		```
783	787
784	788		Nie zapomnij dołączyć modułu Unix do klauzuli uses, jeśli używasz `fpsystem` lub `shell` (wymiennie).
785	789
786	790		Prawdziwą mocą AppleScript jest zdalne manipulowanie programami w celu tworzenia i otwierania dokumentów oraz automatyzacji innych czynności. To, ile możesz zrobić z programem, zależy od tego, jak obszerny jest jego słownik AppleScript (jeśli taki posiada). Na przykład programy Microsoft Office X nie są zbyt użyteczne z AppleScript, podczas gdy nowsze programy Office 2004 mają całkowicie przepisane słowniki AppleScript, które pod wieloma względami porównywalne są z tym, co jest dostępne za pośrednictwem serwerów Windows Office Automation.
787	791
788	792		#### Alternatywy dla Linuksa
789	793
790	794		Chociaż powłoki Linuksa obsługują zaawansowane skrypty wiersza poleceń, typ skryptów jest ograniczony do tego, co można przekazać do programu w wierszu poleceń. Nie ma jednego, zunifikowanego sposobu, aby uzyskać dostęp do wewnętrznych klas i poleceń programu w systemie Linux w taki sposób, w jaki są one dostępne, za pośrednictwem Windows COM Automation i macOS AppleScript. Jednak indywidualne środowiska graficzne (GNOME/KDE) i frameworki aplikacji często zapewniają takie metody komunikacji międzyprocesowej. W GNOME zobacz Komponenty Bonobo. KDE posiada framework KParts, DCOP. OpenOffice ma neutralne dla platformy API do zdalnego sterowania biurem (Google OpenOffice SDK) – chociaż prawdopodobnie, aby go używać, będziesz musiał napisać kod łączący w innym języku, który ma powiązania (takie jak Python). Ponadto niektóre aplikacje mają „tryby serwera” aktywowane przez specjalne opcje wiersza polecenia, które umożliwiają sterowanie nimi z innego procesu. Możliwe jest również (Borland zrobił to za pomocą przeglądarki dokumentów Kylix) „osadzenie” jednego okna aplikacji X najwyższego poziomu w innym za pomocą XReparentWindow (chyba).
791	795
792	796		Podobnie jak w przypadku systemu Windows, wiele programów dla systemów MacOS i Linux składa się z wielu plików bibliotek (rozszerzenia .dylib i .so). Czasami te biblioteki są zaprojektowane tak, abyś mógł ich używać również w programach, które piszesz. Chociaż może to być sposób na dodanie niektórych funkcji zewnętrznego programu do twojego programu, nie jest to tak naprawdę to samo, co uruchamianie i manipulowanie samym zewnętrznym programem. Zamiast tego twój program po prostu łączy się i używa biblioteki programu zewnętrznego, podobnie jak używałby dowolnej biblioteki programistycznej.
793	797
794	798		### Alternatywy dla funkcji Windows API
795	799
796	800		Wiele programów systemu Windows intensywnie korzysta z interfejsu API systemu Windows. W aplikacjach wieloplatformowych funkcje Win API w module Windows nie powinny być używane lub powinny być zawarte w kompilacji warunkowej (np. {\$IFDEF MSWINDOWS} ).
797	801
798	802		Na szczęście wiele z powszechnie używanych funkcji Windows API jest zaimplementowanych wieloplatformowo w module lclintf. Może to być rozwiązanie dla programów, które w dużym stopniu opierają się na API Windows, chociaż najlepszym rozwiązaniem jest zastąpienie tych wywołań prawdziwymi wieloplatformowymi komponentami z LCL. Na przykład można zastąpić wywołania funkcji malowania GDI za pomocą wywołania metod obiektu TCanvas.
799	803
800	804		### Kody klawiszy
801	805
802	806		Na szczęście wykrywanie kodów klawiszy (np. w zdarzeniach KeyUp) jest przenośne: patrz [[LCL Key Handling\|Obsługa klawiszy LCL]].
803	807
804	808		### Instalowanie swojej aplikacji
805	809
806	810		Zobacz [[Deploying Your Application\|Wdrażanie swojej aplikacji]].
807	811
808	812		## Zobacz także
809	813
810	814		- [[Writing portable code regarding the processor architecture\|Pisanie przenośnego kodu dotyczącego architektury procesora]]
811	815		- [[Introduction to platform-sensitive development\|Wprowadzenie do rozwoju zależnego od platformy]]
812	816		- [[Apple-specific UI elements\|Elementy interfejsu użytkownika specyficzne dla Apple]]
813	817
814	818		## Linki zewnętrzne
815	819
816	820		- <http://www.midnightbeach.com/KylixForDelphiProgrammers.html> Przewodnik dla programistów Windows zaczynających pracę z Kylix. Wiele pojęć / fragmentów kodu dotyczy Lazarusa.
817	821
818	822		- <http://www.stack.nl/~marcov/porting.pdf> Przewodnik po pisaniu przenośnego kodu źródłowego, głównie pomiędzy różnymi kompilatorami.
819	823
820	824		---
821	825		From the Free Pascal wiki, page "Multiplatform Programming Guide/pl", as it stood on 2021-11-01 after a change by Slawek, 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