Organizacja API MorphOS-a

Grzegorz Kraszewski

---

Ten artykuł w innych językach: angielski

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

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, 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, 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.

• 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.

• 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.

• 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.

• 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.

How to Use a Library in an Application

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.

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.

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.

There are a few cases, where automatic library handling does not work, or cannot be used.

• Third party libraries. Most of them are not included in the autoopen feature.
• Custom startup code (linking with −nostartfiles).
• Opening libraries in a subprocess.
• Dynamic on-demand library opening.
• The library base has been defined in the application code. Autoopening for this library is automatically disabled in this case.

In all of these cases, libraries have to be handled manually.

Manual Library Opening and Closing

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.

The library base is defined in its proto file (the main header) as a global variable. It is a pointer to a Library structure, which should be treated as an opaque pointer. The result returned by OpenLibrary() should be placed in the library base before any function of the library is called. Then, when the library is no longer needed, it should be closed with CloseLibrary() using its base as the argument. The layout for using the hypothetical foobar.library is as follows:

/* inside <proto/foobar.h> */

struct Library *FoobarBase;

/* inside application */

#include <proto/foobar.h>

if (FoobarBase = OpenLibrary((STRPTR)"foobar.library", 7))

{

  /* use library functions here */

  CloseLibrary(FoobarBase);

}

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:

• MOSSYS:Libs/
• LIBS:
• current directory of the application
• PROGDIR:Libs/

In the fourth path PROGDIR: is an automatic assign pointing to the directory containing the application executable.

The second parameter of OpenLibrary() is the minimum required version. Zero here opens any version, any positive number means "this version or higher". There is no straightforward way for requesting a particular version of a library. It can be noticed that this approach only works if newer versions of a library are always backward compatible with older ones. On the other hand it avoids having multiple versions of the same library in the system, which is a common problem with Linux shared objects.

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.

Every successful OpenLibrary() call must be matched with CloseLibrary(). Resource leak is created otherwise.

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.

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. 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.

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.

Using the proper base name is very important, as it is used as an implicit argument in all the calls of library functions.