Exec Libraries - Revision history

Costel Mincea: Text replacement - "" to ""

2025-01-26T19:12:40Z

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

← Older revision		Revision as of 19:12, 26 January 2025
Line 114:		Line 114:
	A typical taglist for this looks somewhat like this:		A typical taglist for this looks somewhat like this:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct TagItem fubar_libCreateTags[] =		struct TagItem fubar_libCreateTags[] =
	{		{
Line 128:		Line 128:
	The interfaces array might look something like this:		The interfaces array might look something like this:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	uint32 fubar_libInterfaces[] =		uint32 fubar_libInterfaces[] =
	{		{
Line 141:		Line 141:
	For our library manager interface, the tag list looks like this:		For our library manager interface, the tag list looks like this:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct TagItem foobar_managerTags[] =		struct TagItem foobar_managerTags[] =
	{		{
Line 155:		Line 155:
	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:		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>		<syntaxhighlight lang="C" line>
	void *fubar_manager_vectors[] =		void *fubar_manager_vectors[] =
	{		{
Line 199:		Line 199:
	The include file <exec/interfaces.h> introduces the overall structure of an interface:		The include file <exec/interfaces.h> introduces the overall structure of an interface:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct InterfaceData		struct InterfaceData
	{		{
Line 257:		Line 257:
	We assume that the global variable "IExec" contains the main interface pointer of exec.library. Therefore, to open "test.library", we would write		We assume that the global variable "IExec" contains the main interface pointer of exec.library. Therefore, to open "test.library", we would write

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct Library *testLib = IExec->OpenLibrary("test.library", 0);		struct Library *testLib = IExec->OpenLibrary("test.library", 0);
	</syntaxhighlight>		</syntaxhighlight>
Line 263:		Line 263:
	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:		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>		<syntaxhighlight lang="C" line>
	struct TestMainIF IMain = (struct TestMainIF )		struct TestMainIF IMain = (struct TestMainIF )
	IExec->GetInterface(testLib, "main", 1, NULL);		IExec->GetInterface(testLib, "main", 1, NULL);
Line 274:		Line 274:
	Calling a function from IMain would look something like		Calling a function from IMain would look something like

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	int32 test = IMain->DoSomething(10, 100);		int32 test = IMain->DoSomething(10, 100);
	IDOS->Printf("IMain->DoSomething(10, 100) = %ld\n", test);		IDOS->Printf("IMain->DoSomething(10, 100) = %ld\n", test);
Line 281:		Line 281:
	To dispose of the interface, one would call		To dispose of the interface, one would call

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	IExec->DropInterface((struct Interface *)IMain);		IExec->DropInterface((struct Interface *)IMain);
	</syntaxhighlight>		</syntaxhighlight>
Line 287:		Line 287:
	Finally, to close the library call		Finally, to close the library call

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	IExec->CloseLibrary((struct Library*)testLib);		IExec->CloseLibrary((struct Library*)testLib);
	</syntaxhighlight>		</syntaxhighlight>
Line 301:		Line 301:
	Both interfaces are defined in <exec/interfaces.h>.		Both interfaces are defined in <exec/interfaces.h>.

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct LibraryManagerInterface		struct LibraryManagerInterface
	{		{
Line 340:		Line 340:
	Note that we could write		Note that we could write

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

Steven Solie: /* Relationship of Libraries to Devices */

2015-11-03T23:10:41Z

Relationship of Libraries to Devices

← Older revision		Revision as of 23:10, 3 November 2015
Line 50:		Line 50:
	A device is a software specification for hardware control based on the Library structure. The structures of libraries and devices are so similar that the routine CreateLibrary() is used to construct both.		A device is a software specification for hardware control based on the Library structure. The structures of libraries and devices are so similar that the routine CreateLibrary() is used to construct both.

	Devices require the same initial four code vectors as a library, but must have two additional code vectors for beginning and terminating special device I/O commands. The I/O commands that devices are expected to perform, at minimum, are shown in ~~the~~ [[Exec_Device_I/O\|Exec Device I/O]] ~~chapter~~. An example device is listed in [[Example_Device\|Example Device]].		Devices require the same initial four code vectors as a library, but must have two additional code vectors for beginning and terminating special device I/O commands. The I/O commands that devices are expected to perform, at minimum, are shown in [[Exec_Device_I/O\|Exec Device I/O]]. An example device is listed in [[Example_Device\|Example Device]].

	=== Minimum Subset of Library Vectors ===		=== Minimum Subset of Library Vectors ===

Steven Solie: /* Exec Libraries */

2015-11-03T23:10:23Z

Exec Libraries

← Older revision		Revision as of 23:10, 3 November 2015
Line 6:		Line 6:
	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, see [[#What is an Interface?\|What is an Interface?]] below for more details.		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, see [[#What is an Interface?\|What is an Interface?]] below for more details.

	{{Note\|title=Not for Beginners\|text=This ~~chapter~~ concentrates on the internal workings of Exec libraries (and devices). Most application programmers will not to know the internals workings of libraries to program the Amiga. For an introduction to libraries and how to use them, see [[Programming_in_the_Amiga_Environment#Programming_in_the_Amiga_Environment\|Programming in the Amiga Environment]]}}		{{Note\|title=Not for Beginners\|text=This article concentrates on the internal workings of Exec libraries (and devices). Most application programmers will not to know the internals workings of libraries to program the Amiga. For an introduction to libraries and how to use them, see [[Programming_in_the_Amiga_Environment#Programming_in_the_Amiga_Environment\|Programming in the Amiga Environment]]}}

	== What is a Library? ==		== What is a Library? ==

Steven Solie: /* Anatomy of an Interface */

2014-04-13T15:19:09Z

Anatomy of an Interface

← Older revision		Revision as of 15:19, 13 April 2014
Line 241:		Line 241:
	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 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 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:		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:

Steven Solie: /* Library Internals */

2013-05-08T19:17:00Z

Library Internals

Alexandre Balaban: /* Changing the Contents of a Library */ Make use of the Note template

2012-07-12T10:01:14Z

Changing the Contents of a Library: Make use of the Note template

← Older revision		Revision as of 10:01, 12 July 2012
Line 84:		Line 84:
	SetFunction() is also useful for testing an application under conditions it does not encounter normally. For example, a debugging program can force a program's memory allocations to fail or prevent a program's window from opening in order to test the program's error handling code.		SetFunction() is also useful for testing an application under conditions it does not encounter normally. For example, a debugging program can force a program's memory allocations to fail or prevent a program's window from opening in order to test the program's error handling code.

		⚫	{{Note\|title=''SetFunction()'' is for Advanced Users Only\|text=It is very difficult to cleanly exit after performing SetFunction() because other tasks may be executing your code and also because additional SetFunction()'s may have occurred on the same function. Also note that certain libraries (for example the V33 version of DOS library) and some individual library function vectors are of non-standard format and cannot be replaced via SetFunction().}}
	{\| class="wikitable"
⚫	\| ''SetFunction()'' is for Advanced Users Only.It is very difficult to cleanly exit after performing SetFunction() because other tasks may be executing your code and also because additional SetFunction()'s may have occurred on the same function. Also note that certain libraries (for example the V33 version of DOS library) and some individual library function vectors are of non-standard format and cannot be replaced via SetFunction().
	\|}

	Although useful, performing SetFunction() on a library routines poses several problems. If a second task performs SetFunction() on the same library entry, SetFunction() returns the address of the new routine to the second task, ''not'' the original system vector. In that case, the first task can no longer exit cleanly since that would leave the second task with an invalid pointer to a function which it could be relying on.		Although useful, performing SetFunction() on a library routines poses several problems. If a second task performs SetFunction() on the same library entry, SetFunction() returns the address of the new routine to the second task, ''not'' the original system vector. In that case, the first task can no longer exit cleanly since that would leave the second task with an invalid pointer to a function which it could be relying on.
Line 92:		Line 90:
	You also need to know when it is safe to unload your replacement function. Removing it while another task is executing it will quickly lead to a crashed system. Also, the replacement function will have to be re-entrant, like all Exec library functions.		You also need to know when it is safe to unload your replacement function. Removing it while another task is executing it will quickly lead to a crashed system. Also, the replacement function will have to be re-entrant, like all Exec library functions.

		⚫	{{Note\|title=''Don't Do This!''\|For those of you who might be thinking about writing down the ROM addresses returned by SetFunction() and using them in some other programs: ''Forget It''. The address returned by SetFunction() is only good on the current system at the current time.}}
	{\| class="wikitable"
⚫	\| ''Don't Do This!'' For those of you who might be thinking about writing down the ROM addresses returned by SetFunction() and using them in some other programs: ''Forget It''. The address returned by SetFunction() is only good on the current system at the current time.
	\|}

	=== Adding a Library ===		=== Adding a Library ===

Alexandre Balaban: /* Exec Libraries */

2012-07-12T09:59:01Z

Exec Libraries

← Older revision		Revision as of 09:59, 12 July 2012
Line 4:		Line 4:
	Exec maintains lists of ''libraries'' and ''devices''. An Amiga library consists of a collection of related functions which can be anywhere in system memory (RAM or ROM). An Amiga device is very similar to an Amiga library, except that a device normally controls some sort of I/O hardware, and generally contains a limited set of standard functions which receive commands for controlling I/O. For more information on how to use devices for I/O, see the "[[Exec Device I/O]]".		Exec maintains lists of ''libraries'' and ''devices''. An Amiga library consists of a collection of related functions which can be anywhere in system memory (RAM or ROM). An Amiga device is very similar to an Amiga library, except that a device normally controls some sort of I/O hardware, and generally contains a limited set of standard functions which receive commands for controlling I/O. For more information on how to use devices for I/O, see the "[[Exec Device I/O]]".

	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, see [[What is an Interface?]] below for more details.		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, see [[#What is an Interface?\|What is an Interface?]] below for more details.

	{{Note\|title=Not for Beginners\|text=This chapter concentrates on the internal workings of Exec libraries (and devices). Most application programmers will not to know the internals workings of libraries to program the Amiga. For an introduction to libraries and how to use them, see [[Programming_in_the_Amiga_Environment#Programming_in_the_Amiga_Environment\|Programming in the Amiga Environment]]}}		{{Note\|title=Not for Beginners\|text=This chapter concentrates on the internal workings of Exec libraries (and devices). Most application programmers will not to know the internals workings of libraries to program the Amiga. For an introduction to libraries and how to use them, see [[Programming_in_the_Amiga_Environment#Programming_in_the_Amiga_Environment\|Programming in the Amiga Environment]]}}

Alexandre Balaban: /* Exec Libraries */ Make use of the Note template and added some links

2012-07-12T09:58:34Z

Exec Libraries: Make use of the Note template and added some links

← Older revision		Revision as of 09:58, 12 July 2012
Line 2:		Line 2:
	== Exec Libraries ==		== Exec Libraries ==

	Exec maintains lists of ''libraries'' and ''devices''. An Amiga library consists of a collection of related functions which can be anywhere in system memory (RAM or ROM). An Amiga device is very similar to an Amiga library, except that a device normally controls some sort of I/O hardware, and generally contains a limited set of standard functions which receive commands for controlling I/O. For more information on how to use devices for I/O, see the "Exec Device I/O" ~~chapter of this book~~.		Exec maintains lists of ''libraries'' and ''devices''. An Amiga library consists of a collection of related functions which can be anywhere in system memory (RAM or ROM). An Amiga device is very similar to an Amiga library, except that a device normally controls some sort of I/O hardware, and generally contains a limited set of standard functions which receive commands for controlling I/O. For more information on how to use devices for I/O, see the "[[Exec Device I/O]]".

	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.		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, see [[What is an Interface?]] below for more details.

		⚫	{{Note\|title=Not for Beginners\|text=This chapter concentrates on the internal workings of Exec libraries (and devices). Most application programmers will not to know the internals workings of libraries to program the Amiga. For an introduction to libraries and how to use them, see [[Programming_in_the_Amiga_Environment#Programming_in_the_Amiga_Environment\|Programming in the Amiga Environment]]}}
	{\| class="wikitable"
⚫	\|Not for Beginners. This chapter concentrates on the internal workings of Exec libraries (and devices). Most application programmers will not to know the internals workings of libraries to program the Amiga. For an introduction to libraries and how to use them, see [[Programming_in_the_Amiga_Environment#Programming_in_the_Amiga_Environment\|Programming in the Amiga Environment]]
	\|}

	== What is a Library? ==		== What is a Library? ==

Steven Solie: /* Library Initialization */

2012-06-14T21:06:36Z

Library Initialization

Steven Solie: /* Adding a Library */

2012-06-14T21:01:45Z

Adding a Library

← Older revision		Revision as of 21:01, 14 June 2012
Line 98:		Line 98:
	\|}		\|}

	== Adding a Library ==		=== Adding a Library ===

	Exec provides several ways to add your own libraries to the system library list. One rarely used way is to call LoadSeg() (a DOS library function) to load your library and then use the Exec CreateLibrary() and AddLibrary() functions to initialize your library and add it to the system.		Exec provides several ways to add your own libraries to the system library list. One rarely used way is to call LoadSeg() (a DOS library function) to load your library and then use the Exec CreateLibrary() and AddLibrary() functions to initialize your library and add it to the system.

← Older revision		Revision as of 19:17, 8 May 2013
Line 306:		Line 306:
	struct InterfaceData Data;		struct InterfaceData Data;

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

Line 320:		Line 319:
	{		{
	struct InterfaceData Data;		struct InterfaceData Data;
	~~ULONG~~ APICALL (Obtain) (struct DeviceManagerInterface Self);		uint32 APICALL (Obtain) (struct DeviceManagerInterface Self);
	~~ULONG~~ APICALL (Release)(struct DeviceManagerInterface Self);		uint32 APICALL (Release)(struct DeviceManagerInterface Self);
	VOID APICALL (Expunge)(struct DeviceManagerInterface Self);		VOID APICALL (Expunge)(struct DeviceManagerInterface Self);
	struct Interface * APICALL (Clone)(struct DeviceManagerInterface Self);		struct Interface * APICALL (Clone)(struct DeviceManagerInterface Self);
	VOID APICALL (Open)(struct DeviceManagerInterface Self, struct IORequest *ior, ~~ULONG~~ unit, ~~ULONG~~ flags);		VOID APICALL (Open)(struct DeviceManagerInterface Self, struct IORequest *ior, uint32 unit, uint32 flags);
	APTR APICALL (Close)(struct DeviceManagerInterface Self, struct IORequest *ior);		APTR APICALL (Close)(struct DeviceManagerInterface Self, struct IORequest *ior);
	APTR APICALL (LibExpunge)(struct DeviceManagerInterface Self);		APTR APICALL (LibExpunge)(struct DeviceManagerInterface Self);
	struct Interface * APICALL (GetInterface)(struct DeviceManagerInterface Self, STRPTR name, ~~ULONG~~ version,		struct Interface * APICALL (GetInterface)(struct DeviceManagerInterface Self, STRPTR name, uint32 version, struct TagItem *taglist);
	struct TagItem *taglist);
	VOID APICALL (BeginIO)(struct DeviceManagerInterface Self, struct IORequest *ior);		VOID APICALL (BeginIO)(struct DeviceManagerInterface Self, struct IORequest *ior);
	VOID APICALL (AbortIO)(struct DeviceManagerInterface Self, struct IORequest *ior);		VOID APICALL (AbortIO)(struct DeviceManagerInterface Self, struct IORequest *ior);

← Older revision		Revision as of 21:06, 14 June 2012
Line 112:		Line 112:
	Need to show RomTag structure here.		Need to show RomTag structure here.

	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).		Initialization via init tables is no longer supported. 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.		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)~~.		Native libraries expect to find a taglist at rt_Init that is passed to CreateLibrary(). This creates a new-style PowerPC-native library with an optional 68k interface part.

	A typical taglist for this looks somewhat like this:		A typical taglist for this looks somewhat like this:
Line 130:		Line 130:
	</syntaxhighlight>		</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.		In this case, the first tag specifies the size of the base structure, the second tag specifies the libinit function and the last tag specifies the interfaces array. The interfaces array is a null-terminated array of pointers to tag lists for the 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:		The interfaces array might look something like this:
Line 145:		Line 145:
	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.		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:		For our library manager interface, the tag list looks like this:

	<syntaxhighlight>		<syntaxhighlight>
Line 179:		Line 179:
	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).		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 following three vectors are the same as with classic libraries, only that they are assumed to be native code as opposed to 68k code.

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

	== What is an Interface? ==		== What is an Interface? ==