Libraries and Devices - Revision history

Costel Mincea: Text replacement - "" to ""

2025-01-26T19:06:08Z

Text replacement - "<syntaxhighlight>" to "<syntaxhighlight lang="C" line>"

← Older revision		Revision as of 19:06, 26 January 2025
Line 13:		Line 13:
	Through this special function attribute, the gcc compiler for AmigaOS 4 will recognize a construct of the form		Through this special function attribute, the gcc compiler for AmigaOS 4 will recognize a construct of the form

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	IExec->CloseLibrary(libBase);		IExec->CloseLibrary(libBase);
	</syntaxhighlight>		</syntaxhighlight>
Line 19:		Line 19:
	and implicitly (not by preprocessor magic, but through the code generator) transform this into		and implicitly (not by preprocessor magic, but through the code generator) transform this into

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	IExec->CloseLibrary(IExec, libBase);		IExec->CloseLibrary(IExec, libBase);
	</syntaxhighlight>		</syntaxhighlight>
Line 101:		Line 101:
	These two declarations would result in the following two method prototypes:		These two declarations would result in the following two method prototypes:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct PCIResourceRange AllocResource(struct PCIIFace Self,		struct PCIResourceRange AllocResource(struct PCIIFace Self,
	uint32 ResType, uint32 NumBytes);		uint32 ResType, uint32 NumBytes);
Line 119:		Line 119:
	All functions need to be modified in such a way that the LibBase parameter (if present) is removed, and the new Self parameter needs to be added. For example, consider this function (AmigaOS 3.9 style) from a fictitious library "fubar.library":		All functions need to be modified in such a way that the LibBase parameter (if present) is removed, and the new Self parameter needs to be added. For example, consider this function (AmigaOS 3.9 style) from a fictitious library "fubar.library":

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	ULONG FubarFunc(ULONG param1, ULONG param2, struct FubarBase *libBase)		ULONG FubarFunc(ULONG param1, ULONG param2, struct FubarBase *libBase)
	{		{
Line 132:		Line 132:
	We assume that our interface for the library is called "FubarMainIFace". You may chose any name but it is recommended (though not enforced) that they start with the library name and end with "IFace".		We assume that our interface for the library is called "FubarMainIFace". You may chose any name but it is recommended (though not enforced) that they start with the library name and end with "IFace".

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	uint32 FubarFunc(struct FubarMainIFace *Self, uint32 param1, uint32 param2)		uint32 FubarFunc(struct FubarMainIFace *Self, uint32 param1, uint32 param2)
	{		{
Line 139:		Line 139:
	So far, things that have changed is the types are modernized and the removal of the libBase parameter and the addition of the interface pointer. What follows depends on the choice of placement of the FubarCalled and FoobarFactor fields. Let's first assume that we left them in the library base, so we need a pointer to the library. That pointer is always stored in the interface:		So far, things that have changed is the types are modernized and the removal of the libBase parameter and the addition of the interface pointer. What follows depends on the choice of placement of the FubarCalled and FoobarFactor fields. Let's first assume that we left them in the library base, so we need a pointer to the library. That pointer is always stored in the interface:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct FubarBase libBase = (struct FubarBase )Self->Data.LibBase;		struct FubarBase libBase = (struct FubarBase )Self->Data.LibBase;
	libBase->FubarCalled++;		libBase->FubarCalled++;
Line 149:		Line 149:
	Now, if we decided to move these fields into the interface itself, things look a bit different. Generally if you think that data is specific to an interface, and hence specific to a task context, put the fields into the interface. Otherwise leave them in the base. Migrated libraries will probably want to keep them in the base structure, but just in case this is the way to access the data from the interface:		Now, if we decided to move these fields into the interface itself, things look a bit different. Generally if you think that data is specific to an interface, and hence specific to a task context, put the fields into the interface. Otherwise leave them in the base. Migrated libraries will probably want to keep them in the base structure, but just in case this is the way to access the data from the interface:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct FubarMainData *ifData =		struct FubarMainData *ifData =
	(struct FubarMainData *)((uint32)Self - Self->Data.NegativeSize);		(struct FubarMainData *)((uint32)Self - Self->Data.NegativeSize);

Steven Solie: /* Migrating the Source Code */

2013-04-22T21:36:18Z

Migrating the Source Code

← Older revision		Revision as of 21:36, 22 April 2013
Line 122:		Line 122:
	ULONG FubarFunc(ULONG param1, ULONG param2, struct FubarBase *libBase)		ULONG FubarFunc(ULONG param1, ULONG param2, struct FubarBase *libBase)
	{		{
	libBase-~~>~~FubarCalled++;		libBase->FubarCalled++;
	ULONG x = param1 * libBase-~~>~~FubarFactor / param2;		ULONG x = param1 * libBase->FubarFactor / param2;
	return x;		return x;
	}		}

Steven Solie: /* Using Devices */

2012-06-14T21:09:21Z

Using Devices

← Older revision		Revision as of 21:09, 14 June 2012
Line 6:		Line 6:

	For an introduction to some basic concepts see [[Exec_Libraries\|Exec Libraries]].		For an introduction to some basic concepts see [[Exec_Libraries\|Exec Libraries]].

	==== Using Devices ====

	Using devices is almost exactly the same as under AmigaOS 3.9, only that you call the methods of IExec. Since you usually don't call any of the device vectors directly, there is no apparent change to using a device. You still create an IORequest and message port, open the Device with the IExec->OpenDevice() call and call IExec->DoIO() to perform tasks.

	==== The Self Pointer and the APICALL Tag ====		==== The Self Pointer and the APICALL Tag ====

Steven Solie: /* Library Initialization */

2012-06-14T21:06:47Z

Library Initialization

← Older revision		Revision as of 21:06, 14 June 2012
Line 163:		Line 163:

	This example assumes that your data layout for the interface looks like the struct FubarMainData structure.		This example assumes that your data layout for the interface looks like the struct FubarMainData structure.

	==== Library Initialization ====

	Initialization via init tables is no longer supported starting with AmigaOS 4. To initialize a library you need to provide a ROMTAG structure like with previous versions of the OS, although the interpretation of some of the fields are a bit different. Most notably, the rt_Flags field must have the RTF_NATIVE flag set to indicate that the code in this library is native PowerPC and not 68k. If the RTF_AUTOINIT flag is not set, the rt_Init field is assumed to point to a function that is called up on initialization (depending on the RTF_NATIVE flag, it might be called under emulator control).

	If the RTF_AUTOINIT flag is set, then the rt_Init must point to a taglist that will be passed to a function - the function again depends on RTF_NATIVE ROMTAGs without the RTF_NATIVE flag will be handled identically to the old way - their rt_Init field points to a init table and is passed to MakeLibrary.

	Native libraries expect to find a taglist at rt_Init that is passed to exec.library/CreateLibrary. This creates a new-style PowerPC-native library with an optional 68k interface part (We'll cover the 68k part later).

	A typical taglist for this looks somewhat like this:

	<syntaxhighlight>
	struct TagItem fubar_libCreateTags[] =
	{
	{CLT_DataSize, sizeof(struct FubarBase)},
	{CLT_InitFunc, (uint32)fubar_libInit},
	{CLT_Interfaces, (uint32)fubar_libInterfaces},
	{TAG_END, 0}
	};
	</syntaxhighlight>

	In this case, the first tag specifies the size of the base structure, the second tag specifies the libinit function (we'll look at that in a minute) and the last tag specifies the interfaces array. The interfaces array is a null-terminated array of pointers to tag lists for the exec.library/MakeInterface call. Typically you will have at least two interfaces here, the library manager interface and an exported interface (which will most likely be "main"). The layout of the library manager interface has already been discussed, we are going to cover the methods in a few moments.

	The interfaces array might look something like this:

	<syntaxhighlight>
	uint32 fubar_libInterfaces[] =
	{
	(uint32)fubar_managerTags,
	(uint32)fubar_mainTags,
	0
	};
	</syntaxhighlight>

	The first would be the taglist for creating the manager interface, the second for the main interface. We will only cover the manager interface here, since the main interface looks exactly the same, with different functions only. Note that both start with the four default vectors.

	For out library manager interface, the tag list looks like this:

	<syntaxhighlight>
	struct TagItem foobar_managerTags[] =
	{
	{MIT_Name, (uint32)"__library"},
	{MIT_VectorTable, (uint32)foobar_manager_vectors},
	{MIT_Version, 1},
	{TAG_END, 0}
	};
	</syntaxhighlight>

	Here, the name is fixed (in any other interface the name could be chosen freely) and the version number is also fixed to "1". you may use different version numbers in "normal" interfaces, but an interface of this type must be present.

	The foobar_manager_vectors variable is the vector table. This is simply a null-terminated array of methods, in the order in which they appear in the interface. For the library manager interface, we need to have the methods as outlined earlier in this document. The table should look somewhat like this:

	<syntaxhighlight>
	void *fubar_manager_vectors[] =
	{
	(void *)generic_Obtain,
	(void *)generic_Release,
	(void *)0,
	(void *)0,
	// In general, start the "normal" methods here
	(void *)fubar_libOpen,
	(void *)fubar_libClose,
	(void *)fubar_libExpunge,
	(void *)0,
	(void *)-1,
	};
	</syntaxhighlight>

	As per usual the interface starts with the default methods. We use the generic obtain and release methods, and leave both expunge and clone unimplemented (if you leave expunge unimplemented, the interface will simply be freed).

	The following three vectors are the same as with classic libraries, only that they are assumed to be native code as opposed to 68k code. We'll list sample implementations a bit further down.

	The last (in this case unimplemented) vector is the GetInterface call. With all probability you will leave this empty for just about everything. Exec already offers a GetInterface function that should be sufficient for just about every purpose. Only very special cases require this vector, so we will skip its discussion for the purpose of this document.

	The idltool provides a good sample implementation of the three above-mentioned library manager methods and should be referenced for more details.

	We now need to look at the libInit function. This was specified using the CLT_InitFunc tag in the ROMTAG-anchored taglist for CreateLibrary. The function is responsible for setting up one-shot resource stuff and things that are not handled in the open code. Generally, you will almost always be able to use the generic implementation provided by the idltool.

	== Handling 68K ==		== Handling 68K ==

Steven Solie: /* Anatomy of an Interface */

2012-06-14T20:46:21Z

Anatomy of an Interface

← Older revision		Revision as of 20:46, 14 June 2012
Line 6:		Line 6:

	For an introduction to some basic concepts see [[Exec_Libraries\|Exec Libraries]].		For an introduction to some basic concepts see [[Exec_Libraries\|Exec Libraries]].

	==== Anatomy of an Interface ====

	The first four function pointers are fixed and need to be present in every interface. After that, any number of function pointers may follow.

	Each interface has a version number. Any change in the interface will keep the version number if and only if function pointers are added to the interface. That is, if any prototype or location of an interface function changes, the version number needs to be incremented. Programs using an interface can request a specific version number; if that version is available, it will be returned, otherwise an error is generated.

	The include file <exec/interfaces.h> introduces the overall structure of an interface:

	<syntaxhighlight>
	struct InterfaceData
	{
	struct Node Link; /* Node for linking several interfaces */
	struct Library LibBase; / Library this interface belongs to */
	ULONG RefCount; /* Reference count */
	ULONG Version; /* Version number of the interface */
	ULONG Flags; /* Various flags (see below) */
	ULONG CheckSum; /* Checksum of the interface */
	ULONG PositiveSize; /* Size of the function pointer part */
	ULONG NegativeSize; /* Size of the data area */
	// ...
	};

	struct Interface
	{
	struct InterfaceData Data; /* Interface data area */
	/* Increment reference count */
	ULONG (Obtain)(struct Interface Self) APICALL;
	/* Decrement reference count */
	ULONG (Release)(struct Interface Self) APICALL;
	/* Destroy interface. May be NULL */
	void (Expunge)(struct Interface Self) APICALL;
	/* Clone interface. May be NULL */
	struct Interface * (Clone)(struct Interface Self) APICALL;
	};
	</syntaxhighlight>

	Let's first have a look at the embedded InterfaceData structure. RefCount is a counter that works like the OpenCnt in the library base. Only Interfaces with a RefCount of zero can be deleted. The Version number is stored in the Version field. Flags contains a number of bitdefs that specify certain behaviour principles of the interface. A number of flags have been currently defined:

	* IFLF_PROTECTED indicates that this is a protected interface, that is, an interface that must not be modified by exec/SetMethod() (exec/SetMethod is to interfaces what SetFunction() is to AmigaOS 3.9 libraries). An attempt to patch a protected interface fails. This protection may or may not be enforced by hardware. Potential usage for this is an SSL interface, Password/Login interface, or any interface that is security-sensitive.

	* IFLF_NOT_NATIVE indicates that this is an interface that contains emulator stubs for calling a classic 68k jump table. This flag doesn't serve any particular purpose other than to mark this interface as potentially slow.

	* IFLF_PRIVATE indicates that this is a private interface. Private interfaces are non-sharable, and usually carry contextual information that are local to a process or task.

	* IFLF_CHANGED and IFLF_UNMODIFIED are used by the system. The Set-Method method sets the IFLF_CHANGED flag, and the SumInterface method recalculates the checksum and sets IFLF_UNMODIFIED again.

	* IFLF_CLONED marks a cloned interface. See below in the description of the Clone method.

	The CheckSum field contains a checksum over the interface, and is used for sanity checking and for security, much the same way as the library checksum.

	The PositiveSize and NegativeSize fields specify, as the name implies the positive and negative size of an interface. The positive size is the size from the interface start to the end, stretching across the fields at the start of the interface and all function pointers. The negative size is usually zero; if it is non-zero, it specifies the size of the interface's private data area, which is located NegativeSize bytes before the Interface data. Contrary to the AmigaOS 3.9 library, data is always stored in front of the interface. Most interfaces don‚Äôt contain their private data, and therefore the NegativeSize is zero.

	The interface itself start with the embedded InterfaceData structure, followed by the four standard interface functions (we will call interface functions "methods" from now on). The four standard methods are:

	* ULONG Obtain() This method adds a reference to the interface. It increments the RefCount field by one and returns the current RefCount. In order to use an interface, the Obtain method must be called first. The exec library method "GetInterface" does this implicitly.

	* ULONG Release() This method removes a reference from the interface. After releasing the interface it must not be used again.

	* void Expunge() This method deletes the interface and frees all associated resources. This function is usually not called directly.

	* struct Interface *Clone() This method clones an interface. Usually it is sufficient to use Obtain() to be able to use the interface. However, some interfaces might contain data that need to be cloned. For example, consider an interface that can load an image from disk, and store the image data within the interface. That interface would have methods for reading/writing pixels within the picture. Now your paint package want to apply a filter and offer a preview function. For this, the picture would need to be modified, but the original needs to stay around in case the user pressed cancel. For this reason, the interface would be cloned (and hence the picture with it), and the preview could be done on the clone.

	==== Using Devices ====		==== Using Devices ====

Steven Solie: /* Library Internals */

2012-06-14T20:44:40Z

Library Internals

← Older revision		Revision as of 20:44, 14 June 2012
Line 90:		Line 90:

	This saves the user the hassle of writing this, but of course this only works on the AmigaOS 4 compiler. Obviously, any compiler adapted for AmigaOS 4 must implement this mechanism.		This saves the user the hassle of writing this, but of course this only works on the AmigaOS 4 compiler. Obviously, any compiler adapted for AmigaOS 4 must implement this mechanism.

	== Library Internals ==

	Internally, libraries and devices look very similar. They both can export any number of interfaces, making it possible for e.g. timer.device to export its time arithmetic functions in its main interface (or under any other name). The only difference between libraries and devices is that a library must export at least one interface called "__library" of type LibraryManagerInterface, and a device must export an interface called "__device" of type DeviceManagerInterface.

	Both interfaces are defined in <exec/interfaces.h>:

	<syntaxhighlight>
	struct LibraryManagerInterface
	{
	struct InterfaceData Data;

	ULONG APICALL (Obtain) (struct LibraryManagerInterface Self);
	ULONG APICALL (Release)(struct LibraryManagerInterface Self);
	VOID APICALL (Expunge)(struct LibraryManagerInterface Self);
	struct Interface * APICALL (Clone)(struct LibraryManagerInterface Self);
	struct Library * APICALL (Open)(struct LibraryManagerInterface Self, ULONG version);
	APTR APICALL (Close)(struct LibraryManagerInterface Self);
	APTR APICALL (LibExpunge)(struct LibraryManagerInterface Self);
	struct Interface * APICALL (GetInterface)(struct LibraryManagerInterface Self, STRPTR name, ULONG version,
	struct TagItem *taglist);
	};

	struct DeviceManagerInterface
	{
	struct InterfaceData Data;
	ULONG APICALL (Obtain) (struct DeviceManagerInterface Self);
	ULONG APICALL (Release)(struct DeviceManagerInterface Self);
	VOID APICALL (Expunge)(struct DeviceManagerInterface Self);
	struct Interface * APICALL (Clone)(struct DeviceManagerInterface Self);
	VOID APICALL (Open)(struct DeviceManagerInterface Self, struct IORequest *ior, ULONG unit, ULONG flags);
	APTR APICALL (Close)(struct DeviceManagerInterface Self, struct IORequest *ior);
	APTR APICALL (LibExpunge)(struct DeviceManagerInterface Self);
	struct Interface * APICALL (GetInterface)(struct DeviceManagerInterface Self, STRPTR name, ULONG version,
	struct TagItem *taglist);
	VOID APICALL (BeginIO)(struct DeviceManagerInterface Self, struct IORequest *ior);
	VOID APICALL (AbortIO)(struct DeviceManagerInterface Self, struct IORequest *ior);
	};
	</syntaxhighlight>

	As you can see, a library has four and a device six additional function pointers. The four library function pointers are also represented in the device manager interface. The Open/Close/Expunge vectors serve the exact same purpose as under AmigaOS 3.9, and their implementation can more or less follow their AmigaOS 3.9 counterpart. The fourth vector, GetInterface, is usually empty, because exec.library already implements that functionality. However, some libraries might want to override the functionality and implement their own GetInterface function.

	A device manager interface has two additional vectors, BeginIO and AbortIO whose functionality mirrors that of the AmigaOS 3.9 device.

	== Migrating a Library from AmigaOS 3.x ==		== Migrating a Library from AmigaOS 3.x ==

Steven Solie: /* Using Libraries and Interfaces */

2012-06-14T20:38:08Z

Using Libraries and Interfaces

← Older revision		Revision as of 20:38, 14 June 2012
Line 68:		Line 68:

	* struct Interface *Clone() This method clones an interface. Usually it is sufficient to use Obtain() to be able to use the interface. However, some interfaces might contain data that need to be cloned. For example, consider an interface that can load an image from disk, and store the image data within the interface. That interface would have methods for reading/writing pixels within the picture. Now your paint package want to apply a filter and offer a preview function. For this, the picture would need to be modified, but the original needs to stay around in case the user pressed cancel. For this reason, the interface would be cloned (and hence the picture with it), and the preview could be done on the clone.		* struct Interface *Clone() This method clones an interface. Usually it is sufficient to use Obtain() to be able to use the interface. However, some interfaces might contain data that need to be cloned. For example, consider an interface that can load an image from disk, and store the image data within the interface. That interface would have methods for reading/writing pixels within the picture. Now your paint package want to apply a filter and offer a preview function. For this, the picture would need to be modified, but the original needs to stay around in case the user pressed cancel. For this reason, the interface would be cloned (and hence the picture with it), and the preview could be done on the clone.

	==== Using Libraries and Interfaces ====

	In order to use an interface, the appropriate library needs to be opened first. This is done with the usual call to OpenLibrary(), which returns a library base pointer like under AmigaOS 3.x. It is not possible, however, to directly call function from that library (except for "classic" libraries).

	To call library functions, you need to retrieve an interface pointer first. This is done using the exec.library GetInterface function (see the autodoc for GetInterface). The method returns an already Obtained() interface that must be disposed with exec.library/DropInterface after usage. Interfaces are retrieved by name; most libraries export at least the "main" interface, which is the representation of their basic functionality, especially for classic libraries.

	If an interface pointer is passed along to another entity, for example another thread, then that entity must call Obtain() before using the interface. Likewise, when the entity is done, it needs to call Release().

	To sum up: New interfaces must always be created using GetInterface/DropInterface; existing interfaces must be referenced/dereferenced with Obtain/Release.

	"Classic" libraries pose a special case in this equation, since any source code from the classic OS expects to open e.g. intuition.library and directly call OpenWindow on it. These libraries (which are supposedly opened during startup code) have special inline functions that call the appropriate method in the "main" interface.

	A simple example illustrates this. We assume that the global variable "IExec" contains the main interface pointer of exec.library. To open "test.library", we would call

	<syntaxhighlight>
	struct Library *testLib = IExec->OpenLibrary("test.library", 0);
	</syntaxhighlight>

	Note that we could also write

	<syntaxhighlight>
	struct Library *testLib = OpenLibrary("test.library", 0);
	</syntaxhighlight>

	because there is a stub function OpenLibrary() for backwards compatibility with classic programs. The OpenLibrary stub function assumes that the global variable IExec contains the "main" interface pointer of exec. The first version is the preferred version for AmigaOS 4.

	In any case the above will yield a struct Library pointer in testLib that we can use to retrieve interfaces from test.library. Since this library isn't a classic library (it has no parallel version under AmigaOS 3.9) it doesn't automatically export any methods. To get the "main" interface of this library we would write:

	<syntaxhighlight>
	struct TestMainIF IMain = (struct TestMainIF )
	IExec->GetInterface(testLib, "main", 1, NULL);
	</syntaxhighlight>

	The struct TestMainIF is a structure that contains an embedded struct Interface along with additional function pointers - the methods that the interface offers. After this code sequence we can use the IMain interface. Note that by convention, all interface pointers are written as a capital 'I', followed by a capitalized name. IExec and IIntuition would be examples. A test for a NULL pointer should always be performed before using any interface.

	While this at first glance looks a bit intimidating, keep in mind that you usually only do this once and for libraries like Intuition, most of this stuff is already handled by startup code.

	Calling a function from IMain would look something like

	<syntaxhighlight>
	int32 test = IMain->;DoSomething(10, 100);
	IDOS->Printf("IMain->DoSomething(10, 100) = %ld\n", test);
	</syntaxhighlight>

	To dispose of the interface, one would call

	<syntaxhighlight>
	IExec->DropInterface((struct Interface *)IMain);
	</syntaxhighlight>

	Finally, to close the library call

	<syntaxhighlight>
	IExec->CloseLibrary((struct Library*)testLib);
	</syntaxhighlight>

	==== Using Devices ====		==== Using Devices ====

Steven Solie: /* Overview */

2012-06-14T20:18:04Z

Overview

← Older revision		Revision as of 20:18, 14 June 2012
Line 3:		Line 3:
	==== Overview ====		==== Overview ====

	This guide is most specifically directed at programmers wanting to convert library code to AmigaOS 4.x. ~~Finally, a~~ (hopefully) comprehensive explanation of the process of converting a library will be presented.		This guide is most specifically directed at programmers wanting to convert library code to AmigaOS 4.x. A (hopefully) comprehensive explanation of the process of converting a library will be presented.

	For an introduction to some basic concepts see [[Exec_Libraries\|Exec Libraries]].		For an introduction to some basic concepts see [[Exec_Libraries\|Exec Libraries]].

Steven Solie: /* Overview */

2012-06-14T20:17:44Z

Overview

← Older revision		Revision as of 20:17, 14 June 2012
Line 3:		Line 3:
	==== Overview ====		==== Overview ====

	This guide is most specifically directed at programmers wanting to convert library code to AmigaOS 4.x~~. We will first introduce some basic concepts, then cover some of the internals in more detail~~. Finally, a (hopefully) comprehensive explanation of the process of converting a library will be presented.		This guide is most specifically directed at programmers wanting to convert library code to AmigaOS 4.x. Finally, a (hopefully) comprehensive explanation of the process of converting a library will be presented.

			For an introduction to some basic concepts see [[Exec_Libraries\|Exec Libraries]].

	==== Anatomy of an Interface ====		==== Anatomy of an Interface ====

Steven Solie: /* Overview */

2012-06-14T20:16:32Z

Overview

← Older revision		Revision as of 20:16, 14 June 2012
Line 2:		Line 2:

	==== Overview ====		==== Overview ====

	Unlike AmigaOS 3.9 and previous, AmigaOS 4.x libraries can export more than one function table (and usually do). Function tables under AmigaOS 4.x are called "interfaces". An interface is a simple structure with a few predefined fields at the front, and function pointers thereafter.

	This guide is most specifically directed at programmers wanting to convert library code to AmigaOS 4.x. We will first introduce some basic concepts, then cover some of the internals in more detail. Finally, a (hopefully) comprehensive explanation of the process of converting a library will be presented.		This guide is most specifically directed at programmers wanting to convert library code to AmigaOS 4.x. We will first introduce some basic concepts, then cover some of the internals in more detail. Finally, a (hopefully) comprehensive explanation of the process of converting a library will be presented.