Organizacja API MorphOS-a - Revision history

Krashan: Translation finished.

2011-04-07T09:07:40Z

Translation finished.

Krashan: Translation in progress.

2011-04-07T08:54:27Z

Translation in progress.

Krashan: Translation in progress.

2011-04-07T08:44:57Z

Translation in progress.

Krashan: Translation in progress.

2011-04-07T08:09:10Z

Translation in progress.

Krashan: Translation in progress.

2011-04-07T07:57:56Z

Translation in progress.

Krashan: Translation in progress.

2011-04-07T07:28:42Z

Translation in progress.

Krashan: Translation in progress.

2011-04-07T07:15:30Z

Translation in progress.

Krashan: Translation in progress.

2011-04-06T19:12:17Z

Translation in progress.

Krashan: Formatting

2011-04-06T13:01:11Z

Formatting

Krashan: Translation in progress.

2011-04-06T13:00:43Z

Translation in progress.

← Older revision		Revision as of 09:07, 7 April 2011
Line 85:		Line 85:


−	<small>~~As with the Amiga historical heritage~~, ~~some of the most important library bases~~ (''SysBase'', ''DOSBase'', ''IntuitionBase'', ''GfxBase'' ~~and a few more~~) ~~are not defined as~~ ''struct Library*'' ~~but as pointers to library specific structures~~. ~~Direct poking of these structures was unavoidable in early~~ AmigaOS ~~versions~~. In MorphOS ~~it is neither needed nor recommended~~.	+	<small>Dla zachowania wstecznej kompatybilności z AmigaOS, niektóre najważniejsze bazy bibliotek (''SysBase'', ''DOSBase'', ''IntuitionBase'', ''GfxBase'' i kilka innych) nie są zdefiniowane jako wskaźniki na ''struct Library'', ale jako wskaźniki na struktury specyficzne dla tych bibliotek. Konieczność bezpośredniego dostępu do pól tych struktur była nie do uniknięcia we wczesnych wersjach AmigaOS. W MorphOS-ie jest to niepotrzebne i niezalecane. Tych definicji baz bibliotek można uniknąć (wymuszają zbędne rzutowania typów przy wywołaniach ''OpenLibrary()'' i ''CloseLibrary()'') definiując stałą __NOLIBBASE__ przed inkludowaniem plików ''proto'', co blokuje definicje baz bibliotek. Wszystkie bazy muszą być wtedy zdefiniowane w kodzie programu jako wskaźniki na ''struct Library''.
−	~~One can avoid the above definitions~~ (~~which forces unnecessary typecasting in~~ ''OpenLibrary()'' ~~and~~ ''CloseLibrary()'') ~~by #defining~~ __NOLIBBASE__ ~~symbol before including~~ ''proto'' ~~files~~. ~~This disables library bases definitions. All bases can (and must) be then explicitly defined in the code as pointers to~~ ''struct Library''.

		+	Również z powodów historycznych niektóre bazy bibliotek nie trzymają się schematu nazewnictwa baz ''[nazwa biblioteki]Base''. Najważniejsze odchylenia od standardu to: '''SysBase''' dla ''exec.library'', '''DOSBase''' dla ''dos.library'' (duże litery), '''GfxBase''' dla ''graphics.library'', '''MUIMasterBase''' dla ''muimaster.library'' (duże litery), '''CyberGfxBase''' dla ''cybergraphics.library''. Nazwę bazy biblioteki można zawsze sprawdzić w jej pliku nagłówkowym ''proto''.

−	~~Also for traditional reasons~~, ~~names of some library bases do not follow the~~ ''~~[Libname]Base~~'' scheme. The most important deviations are: '''SysBase''' for ''exec.library'', '''DOSBase''' for ''dos.library'' (capitalization), '''GfxBase''' for ''graphics.library'', '''MUIMasterBase''' for ''muimaster.library'' (capitalization), '''CyberGfxBase''' for ''cybergraphics.library''. In any case the base name can be checked by looking at the library ''proto'' header.	+	Użycie poprawnej nazwy bazy biblioteki jest bardzo ważne, ponieważ baza używana jest jako '''niejawny argument''' wszystkich wywołań funkcji z danej biblioteki.</small>
−
−
−	~~Using the proper base name is very important, as it is used as an '''implicit~~ argument''' ~~in all the calls of library functions~~.</small>

← Older revision		Revision as of 08:54, 7 April 2011
Line 82:		Line 82:
	Każde udane otwarcie biblioteki przez ''OpenLibrary()'' powinno mieć odpowiadające mu wywołanie ''CloseLibrary()''. Pozostawienie otwartej biblioteki może skutkować wyciekiem pamięci, uniemożliwia też usunięcie biblioteki z pamięci (tzw. ''flush'').		Każde udane otwarcie biblioteki przez ''OpenLibrary()'' powinno mieć odpowiadające mu wywołanie ''CloseLibrary()''. Pozostawienie otwartej biblioteki może skutkować wyciekiem pamięci, uniemożliwia też usunięcie biblioteki z pamięci (tzw. ''flush'').

−	~~There are two special cases for manual library opening and closing~~: ''exec.library'' ~~and~~ ''dos.library''. ~~The first one is always open and cannot be closed~~, ~~as stated above~~. ~~The library base for it~~ (~~named~~ ''SysBase'') ~~is defined and initialized in the startup code~~. ~~If declared manually in an application's source code~~, ~~it should be declared as an~~ ''extern''. ~~The~~ ''dos.library'' ~~is opened and closed as with any other library~~, ~~but because the startup code needs it~~, ~~the~~ ''DOSBase'' ~~is already defined and initialized there~~. ~~As a result the application does not need to open~~ ''dos.library'' ~~before using it~~. ~~If declared in an application,~~ ''DOSBase'' ~~should be an~~ ''extern'' ~~too~~.	+	Przy ręcznym otwieraniu bibliotek mamy do czynienia z dwoma przypadkami specjalnymi: ''exec.library'' i ''dos.library''. Pierwsza z tych bibliotek jest zawsze otwarta i nie da się jej zamknąć, jak już wcześniej wspomniano. Baza tej biblioteki (o nazwie ''SysBase'') jest zdefiniowana i zainicjalizowana w kodzie startowym. Jeżeli jest ręcznie deklarowana w kodzie programu, musi być zadeklarowana ze słowem kluczowym ''extern''. Biblioteka ''dos.library'' jest otwierana i zamykana jak każda inna, ale ponieważ używa jej kod startowy, jej baza (''DOSBase'') jest zdefiniowana i inicjalizowana w tymże kodzie. W rezultacie program nie musi otwierać ''dos.library'' przed jej użyciem, ani zamykać na zakończenie. Jeżeli ''DOSBase'' jest zadeklarowana w kodzie aplikacji, również należy ją zadeklarować jako ''extern''.

@@ Line 67: / Line 67: @@
+  }
-The ''OpenLibrary()'' call takes two parameters. The first one is just the name of the library to be opened. It is only the name, without path. MorphOS searches a few locations for the library in the following order:
+Funkcja ''OpenLibrary()'' ma dwa parametry. Pierwszy to nazwa biblioteki do otworzenia. Podaje się samą nazwę, bez ścieżki. MorphOS szuka biblioteki w kilku standardowych lokacjach, w następującej kolejności:
 * MOSSYS:Libs/
 * LIBS:
-* current directory of the application
+* katalog bieżący programu
 * PROGDIR:Libs/
-The value returned by ''OpenLibrary()'' should be always checked against NULL. Even a library built into the boot image may fail to open (because of a memory shortage for example, or having too low a version). Printing some error message in case of a fail is definitely a good idea.
+W czwartej ścieżce ''PROGDIR:'' jest automatycznym przypisaniem wskazującym na katalog, w którym znajduje się plik wykonywalny programu.
-Every successful ''OpenLibrary()'' call must be matched with ''CloseLibrary()''. Resource leak is created otherwise.
+Program powinien zawsze sprawdzić, czy wartość zwracana przez ''OpenLibrary()'' jest różna od zera. Nawet otwarcie biblioteki wbudowanej w kernel systemu może się nie powieść (z powodu braku pamięci lub za niskiej wersji biblioteki). Wypisanie w takim przypadku komunikatu o błędzie jest z pewnością dobrym pomysłem.
 There are two special cases for manual library opening and closing: ''exec.library'' and ''dos.library''. The first one is always open and cannot be closed, as stated above. The library base for it (named ''SysBase'') is defined and initialized in the startup code. If declared manually in an application's source code, it should be declared as an ''extern''. The ''dos.library'' is opened and closed as with any other library, but because the startup code needs it, the ''DOSBase'' is already defined and initialized there. As a result the application does not need to open ''dos.library'' before using it. If declared in an application, ''DOSBase'' should be an ''extern'' too.

@@ Line 5: / Line 5: @@
 API (interfejs programisty aplikacji) systemu operacyjnego składa się zazwyczaj z tysięcy funkcji. MorphOS nie jest tu wyjątkiem. Jego kernel nie jest jednak monolityczny, API jest funkcjonalnie i fizycznie podzielone na biblioteki. Tylko kilka największych bibliotek zawiera więcej niż 50 funkcji. Zestaw najważniejszych bibliotek znajduje się w startowym pliku kernela (ang. ''boot image''). Pozostałe umieszczone są na partycji systemowej dysku w katalogu ''MOSSYS:Libs'' (biblioteki dostarczane z systemem) i ''SYS:Libs'' (zewnętrzne biblioteki dodatkowe). Biblioteki znajdujące się na dysku są ładowane do pamięci na żądanie. Wszystkie te biblioteki są współdzielone, co oznacza, że wszystkie procesy używające danej biblioteki wykonują ten sam kod, umieszczony w pamięci jednokrotnie.
 ==Przegląd najważniejszych bibliotek==
@@ Line 47: / Line 48: @@
 ==Ręczne otwieranie i zamykanie bibliotek==
-While not as convenient as automatic handling, manual opening and closing of libraries is not very complicated. A ''library base'' variable has to be defined, then two functions from ''exec.library'': ''OpenLibrary()'' and ''CloseLibrary()'' have to be used.
+Ręczne otwieranie i zamykanie bibliotek jest proste, choć, rzecz jasna, nie tak wygodne jak automatyczne. Przy ręcznej obsłudze potrzebna jest zmienna, tak zwana '''baza biblioteki'''. Następnie korzystamy z dwóch funkcji ''exec.library'': ''OpenLibrary()'' i ''CloseLibrary()''.
-&nbsp;&nbsp;CloseLibrary(FoobarBase);
+Baza biblioteki jest zdefiniowana w jej pliku ''proto'' (głównym pliku nagłówkowym biblioteki), jako zmienna globalna. Jest ona wskaźnikiem na strukturę ''Library''. Strukturę tę powinno się zasadniczo traktować jako "czarną skrzynkę". W zmiennej umieszczamy wynik zwrócony przez funkcję ''OpenLibrary()'', trzeba to zrobić zanim wywołamy jakąkolwiek funkcję otwieranej biblioteki. W momencie, gdy biblioteka nie jest już potrzebna, zamykamy ją funkcją ''CloseLibrary()'', podając jej bazę biblioteki jako argument. Oto przykład użycia hipotetycznej biblioteki ''foobar.library'' w programie:
-}</tt>
+ /* wewnątrz <proto/foobar.h> */
 The ''OpenLibrary()'' call takes two parameters. The first one is just the name of the library to be opened. It is only the name, without path. MorphOS searches a few locations for the library in the following order:

@@ Line 27: / Line 27: @@
 ==Jak używać bibliotek w programach==
-Najczęściej użycie biblioteki w programie jest praktycznie automatyczne. Jedyna rzecz, jaką trzeba zrobić, to zainkludowanie głównego pliku nagłówkowego biblioteki, którego nazwa tworzona jest według schematu ''<proto/[nazwa biblioteki].h>'', na przykład ''<proto/exec.h>'', ''<proto/muimaster.h>'' i tak dalej. Otwarcie i zamknięcie biblioteki jest wykonywane automatycznie w kodzie startowym, pochodzącym z ''libnix''-a albo ''ixemul.library''. W kodzie można więc po prostu używać funkcji danej biblioteki.
+Najczęściej użycie biblioteki w programie jest praktycznie automatyczne. Jedyna rzecz, jaką trzeba zrobić, to zainkludowanie głównego pliku nagłówkowego biblioteki, którego nazwa tworzona jest według schematu ''<proto/[nazwa biblioteki].h>'', na przykład ''<proto/exec.h>'', ''<proto/muimaster.h>'' i tak dalej. Otwarcie i zamknięcie biblioteki jest wykonywane automatycznie w kodzie startowym, pochodzącym z ''libnix''-a albo ''ixemul.library''. W programie można więc po prostu używać funkcji danej biblioteki.
-A few big libraries have separate subdirectories in the system include tree. Examples of such libraries are ''exec.library'', ''dos.library'' and ''graphics.library''. Header files in these directories contain definitions of constants, data structures, attributes etc. used by the library, divided by functionality. Including of these headers depends on which functions are used in the application, for example to use ''exec.library'' memory allocation functions one has to include the ''<exec/memory.h>'' header.
+Inne biblioteki mogą posiadać pojedynczy plik nagłówkowy w katalogu ''libraries''. Na przykład ''<libraries/locale.h>'' lub ''<libraries/mui.h>'' (ten drugi przykład pokazuje małą niekonsekwencję w nazewnictwie...). Ten plik może być automatycznie inkludowany z bazowego ''proto'', ale czasem musi być inkludowany ręcznie w kodzie programu.
-Other libraries have a single header file in the ''libraries'' directory. Examples are ''<libraries/locale.h>'' or ''<libraries/mui.h>'' (the latest is some deviation from the naming rule). This single header may be automatically included from the ''proto'' file or not.
+* Dodatkowe biblioteki pisane przez niezależnych programistów. Większość z nich nie jest dodana do listy bibliotek otwieranych automatycznie.
-* Third party libraries. Most of them are not included in the autoopen feature.
+==Ręczne otwieranie i zamykanie bibliotek==
 While not as convenient as automatic handling, manual opening and closing of libraries is not very complicated. A ''library base'' variable has to be defined, then two functions from ''exec.library'': ''OpenLibrary()'' and ''CloseLibrary()'' have to be used.

← Older revision		Revision as of 07:28, 7 April 2011
Line 25:		Line 25:


−	==~~How to Use a Library in an Application~~==	+	==Jak używać bibliotek w programach==

−	~~In typical cases it is pretty automatic~~. ~~The only thing which has~~ to ~~be done is including the main library header file~~, ~~which is~~ ''<proto/[~~libname~~].h>'', ~~for example~~ ''<proto/exec.h>'', ''<proto/muimaster.h>'' ~~and so on~~. ~~Library opening and closing is handled automatically by the startup code provided by either~~ ''libnix'' or ''ixemul.library''. ~~Then one can just use functions from the library~~.	+	Najczęściej użycie biblioteki w programie jest praktycznie automatyczne. Jedyna rzecz, jaką trzeba zrobić, to zainkludowanie głównego pliku nagłówkowego biblioteki, którego nazwa tworzona jest według schematu ''<proto/[nazwa biblioteki].h>'', na przykład ''<proto/exec.h>'', ''<proto/muimaster.h>'' i tak dalej. Otwarcie i zamknięcie biblioteki jest wykonywane automatycznie w kodzie startowym, pochodzącym z ''libnix''-a albo ''ixemul.library''. W kodzie można więc po prostu używać funkcji danej biblioteki.

@@ Line 14: / Line 14: @@
 * '''dos.library''', odpowiada za operacje wejścia/wyjścia na plikach i innych urządzeniach (np. konsola tekstowa). Jest interfejsem do bardziej złożonych funkcji systemów plików (np. przeszukiwanie katalogów). Współdziała z ''exec.library'' przy tworzeniu procesów. Zawiera podstawowe funkcje zegara czasu rzeczywistego.
-* '''graphics.library''', is responsible for low-level graphics functions like drawing pixels and other primitives, copying rectangular blocks of display, scrolling etc. Many programs do not use it directly.
+* '''graphics.library''', zawiera niskopoziomowe funkcje graficzne, np. rysowanie pojedynczych pikseli i prostych figur geometrycznych, kopiowanie prostokątnych obszarów obrazu, przewijanie (scroll) itp. Wiele programów nie korzysta z niej bezpośrednio.
-* '''intuition.library''', delivers intermediate level graphics interface objects like screens and windows. Interfaces to user input devices (mouse and keyboard to name a few). Provides very basic user controls (gadgets). Provides also BOOPSI (''Basic Object Oriented System for Intuition''), a language independent object oriented programming framework, used commonly by other components.
+* '''intuition.library''', zarządza podstawowymi obiektami interfejsu użytkownika, takimi jak ekrany i okna. Zajmuje się obsługą urządzeń wejściowych (mysz, klawiatura i inne). Zawiera w sobie [[Rzut oka na BOOPSI|BOOPSI]] (''Basic Object Oriented System for Intuition''), który jest bazą dla niezależnego od języka programowania obiektowego. Baza ta jest używana przez wiele innych komponentów systemu.
-* '''muimaster.library''', the main interface to MUI (''Magic User Interface''), which is the MorphOS high level GUI toolkit. Provides a complete, object oriented framework (based on BOOPSI) for GUI driven applications and a rich set of GUI objects.
+* '''muimaster.library''', jest głównym interfejsem MUI (''Magic User Interface'') &ndash; podstawowej wysokopoziomowej biblioteki do tworzenia graficznego interfejsu użytkownika programów. MUI jest rozwinięciem BOOPSI, daje programiście kompletny szkielet do programowania obiektowego sterowanego zdarzeniami i dostarcza bogaty zestaw gadżetów (kontrolek).
-* '''locale.library''', is responsible for system and application internationalization. This simple yet powerful subsystem allows for supporting multiple language versions of a program with a single executable, also provides localization data such as date format, local currency, timezone, number grouping and more.
+* '''locale.library''', służy do tworzenia wielojęzycznych wersji programów. Oprócz umożliwienia prostej lokalizacji interfejsu użytkownika, pozwala również programom na pobranie od systemu ogólnych danych specyficznych dla kraju i języka użytkownika (np. waluta, format daty, strefa czasowa, grupowanie cyfr w dużych liczbach itp.)
-* '''bsdsocket.library''' is an interface for TCP/IP networking, compatible with BSD sockets. What is unusual with this library, is that it is neither built into the kernel, nor placed on disk. The TCP/IP stack creates it in memory dynamically.
+* '''bsdsocket.library''', jest biblioteką obsługującą protokół TCP/IP, kompatybilną z interfejsem BDS sockets. Co ciekawe biblioteka ta nie znajduje się ani w kernelu ani na dysku &ndash; jest tworzona dynamicznie w pamięci przez stos TCP/IP.

@@ Line 6: / Line 6: @@
 API (interfejs programisty aplikacji) systemu operacyjnego składa się zazwyczaj z tysięcy funkcji. MorphOS nie jest tu wyjątkiem. Jego kernel nie jest jednak monolityczny, API jest funkcjonalnie i fizycznie podzielone na biblioteki. Tylko kilka największych bibliotek zawiera więcej niż 50 funkcji. Zestaw najważniejszych bibliotek znajduje się w startowym pliku kernela (ang. ''boot image''). Pozostałe umieszczone są na partycji systemowej dysku w katalogu ''MOSSYS:Libs'' (biblioteki dostarczane z systemem) i ''SYS:Libs'' (zewnętrzne biblioteki dodatkowe). Biblioteki znajdujące się na dysku są ładowane do pamięci na żądanie. Wszystkie te biblioteki są współdzielone, co oznacza, że wszystkie procesy używające danej biblioteki wykonują ten sam kod, umieszczony w pamięci jednokrotnie.
-==Libraries Overview==
+==Przegląd najważniejszych bibliotek==
-MorphOS comes with over 100 different libraries. Not all of them are listed below, just the most common ones. Browse the system autodocs in the SDK for more.
+Dystrybucja MorphOS-a zawiera ponad 100 różnych bibliotek. Oczywiście poniżej wymienione są tylko najważniejsze. Opis pozostałych można znaleźć w dokumentacji znajdującej się w SDK.
-* '''exec.library''', the master library. This is the system core, responsible for process scheduling, control and creation, communication between processes, memory management, managing other libraries and overall system control. This is the only library which is always open and cannot be closed.
+* '''exec.library''', główna biblioteka systemu, tu znajdują się podstawowe elementy systemu takie jak zarządzanie procesami i zarządzanie pamięcią, ładowanie innych bibliotek, kontrola stanu systemu i tak dalej. Jako jedyna biblioteka jest zawsze otwarta i nie da się jej zamknąć.
-* '''dos.library''', responsible for file and console input/output. Provides an interface to advanced filesystem functions (like scanning directories for example). Cooperates with the ''exec.library'' in process creation. Delivers basic system time services.
+* '''dos.library''', odpowiada za operacje wejścia/wyjścia na plikach i innych urządzeniach (np. konsola tekstowa). Jest interfejsem do bardziej złożonych funkcji systemów plików (np. przeszukiwanie katalogów). Współdziała z ''exec.library'' przy tworzeniu procesów. Zawiera podstawowe funkcje zegara czasu rzeczywistego.
 * '''graphics.library''', is responsible for low-level graphics functions like drawing pixels and other primitives, copying rectangular blocks of display, scrolling etc. Many programs do not use it directly.

@@ Line 1: / Line 1: @@
 ''Grzegorz Kraszewski''
 ----
-<small>Ten artykuł w innych językach [[MorphOS API and Its Organization|angielski]]</small>
+<small>Ten artykuł w innych językach: [[MorphOS API and Its Organization|angielski]]</small>