Introduction to Exec - Revision history

Costel Mincea: Text replacement - "" to ""

2025-01-26T19:20:48Z

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

← Older revision		Revision as of 19:20, 26 January 2025
Line 50:		Line 50:
	FreeVec() releases memory allocated by AllocVecTags(). It takes only one parameter, a pointer to a memory block allocated by AllocVecTags(). The following example shows how to allocate and deallocate memory.		FreeVec() releases memory allocated by AllocVecTags(). It takes only one parameter, a pointer to a memory block allocated by AllocVecTags(). The following example shows how to allocate and deallocate memory.

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	APTR my_mem = IExec->AllocVecTags(100, TAG_END);		APTR my_mem = IExec->AllocVecTags(100, TAG_END);

Line 69:		Line 69:
	To go to sleep, a task calls a system function called Wait(). This function takes one argument, a bitmask that tells Exec which of the task's signal bits to "listen to". The task will only wake up if it receives one of the signals whose corresponding bit is set in that bitmask. For example, if a task wanted wait for signals 17 and 19, it would call Wait() like this:		To go to sleep, a task calls a system function called Wait(). This function takes one argument, a bitmask that tells Exec which of the task's signal bits to "listen to". The task will only wake up if it receives one of the signals whose corresponding bit is set in that bitmask. For example, if a task wanted wait for signals 17 and 19, it would call Wait() like this:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	mysignals = IExec->Wait(1U << 17 \| 1U << 19);		mysignals = IExec->Wait(1U << 17 \| 1U << 19);
	</syntaxhighlight>		</syntaxhighlight>
Line 93:		Line 93:
	This simple example needs two variables, one to hold the address of the window and the other to hold the address of a message.		This simple example needs two variables, one to hold the address of the window and the other to hold the address of a message.

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct Message mymsg; /defined in <exec/ports.h> */		struct Message mymsg; /defined in <exec/ports.h> */
	struct Window mywin; / defined in <intuition/intuition.h> */		struct Window mywin; / defined in <intuition/intuition.h> */
Line 137:		Line 137:
	An application accesses a library's functions through interfaces. Each library exports one or more interfaces. Before a task can use the functions of a particular interface, it must first acquire the library's base pointer by calling the Exec OpenLibrary() function and then obtain an interface pointer by calling GetInterface().		An application accesses a library's functions through interfaces. Each library exports one or more interfaces. Before a task can use the functions of a particular interface, it must first acquire the library's base pointer by calling the Exec OpenLibrary() function and then obtain an interface pointer by calling GetInterface().

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct Library *OpenLibrary( CONST_STRPTR libName, uint32 libVer );		struct Library *OpenLibrary( CONST_STRPTR libName, uint32 libVer );
	struct Interface GetInterface( struct Library base, CONST_STRPTR ifaceName, uint32 ifaceVer, struct TagItem *tags);		struct Interface GetInterface( struct Library base, CONST_STRPTR ifaceName, uint32 ifaceVer, struct TagItem *tags);
Line 148:		Line 148:
	The OpenLibrary() function looks for a library with a name that matches libName and also with a version at least as high as libVersion. For example, to open version 50 or greater of the Intuition library:		The OpenLibrary() function looks for a library with a name that matches libName and also with a version at least as high as libVersion. For example, to open version 50 or greater of the Intuition library:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	IntuitionBase = IExec->OpenLibrary("intuition.library", 50);		IntuitionBase = IExec->OpenLibrary("intuition.library", 50);
	</syntaxhighlight>		</syntaxhighlight>
Line 166:		Line 166:
	After an application is finished with a library, it ''must'' close it by calling DropInterface() on each interface and finally CloseLibrary():		After an application is finished with a library, it ''must'' close it by calling DropInterface() on each interface and finally CloseLibrary():

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	VOID DropInterface(struct Interface *ifacePtr);		VOID DropInterface(struct Interface *ifacePtr);
	VOID CloseLibrary(struct Library *libPtr);		VOID CloseLibrary(struct Library *libPtr);
Line 179:		Line 179:
	To call a function in an Amiga system library a pointer to an interface is required. For example to call the Intuition function DisplayBeep():		To call a function in an Amiga system library a pointer to an interface is required. For example to call the Intuition function DisplayBeep():

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct IntuitionIFace *IIntuition = IExec->GetInterface(base, "main", 1, NULL);		struct IntuitionIFace *IIntuition = IExec->GetInterface(base, "main", 1, NULL);

Steven Solie: /* Libraries and Devices */

2014-01-06T20:07:01Z

Libraries and Devices

@@ Line 144: / Line 144: @@
 Where libName is a string naming the library and libVer is a version number for the library. The library base pointer is passed on to GetInterface() along with ifaceName which is the name of the interface and ifaceVer which is the version. An optional tag array completes the call.
-The libVer number reflects a revision of the system software. The chart below lists the specific Amiga OS release versions that system libraries versions correspond to:
+The libVer number reflects a revision of the system software. The [[AmigaOS_Versions|AmigaOS versions chart]] lists the specific AmigaOS release versions that system libraries versions correspond to.
 The OpenLibrary() function looks for a library with a name that matches libName and also with a version at least as high as libVersion. For example, to open version 50 or greater of the Intuition library:
@@ Line 200: / Line 154: @@
 In this example, if version 50 or greater of the Intuition library is not available, OpenLibrary() returns NULL. A version of zero in OpenLibrary() tells the OS to open any version of the library. New code should use a version of 50 or higher unless noted otherwise.
-'''When OpenLibrary() looks for a library, it first looks in memory. If the library is not in memory, OpenLibrary() will look for the library on disk. If libName is a library name with an absolute path (for example, "myapp:mylibs/mylib.library"), OpenLibrary() will follow that absolute path looking for the library. If libName is only a library name ("diskfont.library"), OpenLibrary() will look for the library in the directory that the LIBS: logical assign currently references.'''
+{{Note|text=When OpenLibrary() looks for a library, it first looks in memory. If the library is not in memory, OpenLibrary() will look for the library on disk. If libName is a library name with an absolute path (for example, "myapp:mylibs/mylib.library"), OpenLibrary() will follow that absolute path looking for the library. If libName is only a library name ("diskfont.library"), OpenLibrary() will look for the library in the directory that the LIBS: logical assign currently references.}}
 If OpenLibrary() finds the library on disk, it takes care of loading it and initializing it. As part of the initialization process, OpenLibrary() dynamically creates a vector table. There is a vector for each function in the library. The OS needs to create the vector table dynamically because the library functions can be anywhere in memory.

Steven Solie: /* Calling a Library Function */

2013-10-10T20:19:34Z

Calling a Library Function

← Older revision		Revision as of 20:19, 10 October 2013
Line 226:		Line 226:

	<syntaxhighlight>		<syntaxhighlight>
	struct IntuitionIFace *IIntuition = IExec->GetInterface(base, "main" 1, NULL);		struct IntuitionIFace *IIntuition = IExec->GetInterface(base, "main", 1, NULL);

	IIntuition->DisplayBeep();		IIntuition->DisplayBeep();

Steven Solie: /* Introduction to Exec */

2012-12-03T19:55:09Z

Introduction to Exec

← Older revision		Revision as of 19:55, 3 December 2012
Line 2:		Line 2:

	The ''Multitasking Executive'', better known as ''Exec'', is the heart of the Amiga's operating system. All other systems in the Amiga rely on it to control multitasking, to manage the message-based interprocess communications system, and to arbitrate access to system resources. Because just about every software entity on the Amiga (including application programs) needs to use Exec in some way, every Amiga programmer has to have a basic understanding of its fundamentals.		The ''Multitasking Executive'', better known as ''Exec'', is the heart of the Amiga's operating system. All other systems in the Amiga rely on it to control multitasking, to manage the message-based interprocess communications system, and to arbitrate access to system resources. Because just about every software entity on the Amiga (including application programs) needs to use Exec in some way, every Amiga programmer has to have a basic understanding of its fundamentals.

			Exec was originally written in 68K assembly code. The migration to PowerPC-based systems necessitated a rewrite of Exec while retaining as much of the original API as possible. The PowerPC reimplementation of Exec is named Exec Second Generation or ExecSG for short. For simplicity, throughout this wiki ExecSG will be referred to as Exec.

	== Multitasking ==		== Multitasking ==

Alexandre Balaban: /* Dynamic Memory Allocation */ Make use of the new template Note

2012-07-12T09:54:09Z

Dynamic Memory Allocation: Make use of the new template Note

← Older revision		Revision as of 09:54, 12 July 2012
Line 44:		Line 44:
	If an application does not specify any tags when allocating memory, the system looks for MEMF_PRIVATE memory. There are additional memory allocation tags: MEMF_SHARED and MEMF_EXECUTABLE. See the [[Exec_Memory_Allocation\|Exec Memory Allocation]] section for additional information on attributes and tags.		If an application does not specify any tags when allocating memory, the system looks for MEMF_PRIVATE memory. There are additional memory allocation tags: MEMF_SHARED and MEMF_EXECUTABLE. See the [[Exec_Memory_Allocation\|Exec Memory Allocation]] section for additional information on attributes and tags.

		⚫	{{Note\|title=''Make Sure You Have Memory.''\|text=Always check the result of any memory allocation to be sure the type and amount of memory requested is available. Failure to do so will lead to trying to use an non-valid pointer.}}
	{\| class="wikitable"
⚫	\| ''Make Sure You Have Memory.'' Always check the result of any memory allocation to be sure the type and amount of memory requested is available. Failure to do so will lead to trying to use an non-valid pointer.
	\|}

	FreeVec() releases memory allocated by AllocVecTags(). It takes only one parameter, a pointer to a memory block allocated by AllocVecTags(). The following example shows how to allocate and deallocate memory.		FreeVec() releases memory allocated by AllocVecTags(). It takes only one parameter, a pointer to a memory block allocated by AllocVecTags(). The following example shows how to allocate and deallocate memory.

Steven Solie: /* Interprocess Communications */

2012-07-08T13:24:34Z

Interprocess Communications

← Older revision		Revision as of 13:24, 8 July 2012
Line 81:		Line 81:
	Another feature of the Amiga OS is its system of message-based ''interprocess communication''. Using this system, a task can send a message to a message port owned by another task. Tasks use this mechanism to do things like trigger events or share data with other tasks, including system tasks. Exec's message system is built on top of Exec's task signaling mechanism. Most Amiga applications programming (especially Intuition programming) relies heavily upon this message-based form of interprocess communication.		Another feature of the Amiga OS is its system of message-based ''interprocess communication''. Using this system, a task can send a message to a message port owned by another task. Tasks use this mechanism to do things like trigger events or share data with other tasks, including system tasks. Exec's message system is built on top of Exec's task signaling mechanism. Most Amiga applications programming (especially Intuition programming) relies heavily upon this message-based form of interprocess communication.

	When one task sends a message to another task's message port, the OS adds the message to the port's message queue. The message stays in this queue until the task that owns the port is ready to check its port for messages. Typically, a task has put itself to sleep while it is waiting for an event, like a message to arrive at its message port. When the message arrives, the task wakes up to look in its message port. The messages in the message port's queue are arranged in first-in-first-out (FIFO) order so that, when a task receives several messages, it will see the messages in the order they arrived at the		When one task sends a message to another task's message port, the OS adds the message to the port's message queue. The message stays in this queue until the task that owns the port is ready to check its port for messages. Typically, a task has put itself to sleep while it is waiting for an event, like a message to arrive at its message port. When the message arrives, the task wakes up to look in its message port. The messages in the message port's queue are arranged in first-in-first-out (FIFO) order so that, when a task receives several messages, it will see the messages in the order they arrived at the port.

	A task can use a message to share any kind of data with another task. '''This is possible because a task does not actually transmit an entire message, it only passes a pointer to a message. When a task creates a message (which can have many Kilobytes of data attached to it) and sends it to another task, the actual message does not move.'''		A task can use a message to share any kind of data with another task. '''This is possible because a task does not actually transmit an entire message, it only passes a pointer to a message. When a task creates a message (which can have many Kilobytes of data attached to it) and sends it to another task, the actual message does not move.'''

Gianfranco Gignina: /* Libraries and Devices */

2012-07-08T11:04:32Z

Libraries and Devices

← Older revision		Revision as of 11:04, 8 July 2012
Line 200:		Line 200:
	In this example, if version 50 or greater of the Intuition library is not available, OpenLibrary() returns NULL. A version of zero in OpenLibrary() tells the OS to open any version of the library. New code should use a version of 50 or higher unless noted otherwise.		In this example, if version 50 or greater of the Intuition library is not available, OpenLibrary() returns NULL. A version of zero in OpenLibrary() tells the OS to open any version of the library. New code should use a version of 50 or higher unless noted otherwise.

	When OpenLibrary() looks for a library, it first looks in memory. If the library is not in memory, OpenLibrary() will look for the library on disk. If libName is a library name with an absolute path (for example, "myapp:mylibs/mylib.library"), OpenLibrary() will follow that absolute path looking for the library. If libName is only a library name ("diskfont.library"), OpenLibrary() will look for the library in the directory that the LIBS: logical assign currently references.		'''When OpenLibrary() looks for a library, it first looks in memory. If the library is not in memory, OpenLibrary() will look for the library on disk. If libName is a library name with an absolute path (for example, "myapp:mylibs/mylib.library"), OpenLibrary() will follow that absolute path looking for the library. If libName is only a library name ("diskfont.library"), OpenLibrary() will look for the library in the directory that the LIBS: logical assign currently references.'''

	If OpenLibrary() finds the library on disk, it takes care of loading it and initializing it. As part of the initialization process, OpenLibrary() dynamically creates a vector table. There is a vector for each function in the library. The OS needs to create the vector table dynamically because the library functions can be anywhere in memory.		If OpenLibrary() finds the library on disk, it takes care of loading it and initializing it. As part of the initialization process, OpenLibrary() dynamically creates a vector table. There is a vector for each function in the library. The OS needs to create the vector table dynamically because the library functions can be anywhere in memory.

Gianfranco Gignina: /* Libraries and Devices */

2012-07-08T10:45:00Z

Libraries and Devices

← Older revision		Revision as of 10:45, 8 July 2012
Line 147:		Line 147:

	{\| class="wikitable"		{\| class="wikitable"
			\| 27.3 \|\| Kickstart 0.7 \|\| First AmigaOS version shown at Consumer Electronics Show in 1985. This version is obsolete.
			\|-
			\| 29 \|\| Kickstart 0.9 \|\| This is an internal AmigaOS version. This version is obsolete.
			\|-
	\| 30 \|\| Kickstart 1.0 \|\| This revision is obsolete.		\| 30 \|\| Kickstart 1.0 \|\| This revision is obsolete.
	\|-		\|-
Line 153:		Line 157:
	\| 32 \|\| Kickstart 1.1 \|\| This was a PAL only release and is obsolete.		\| 32 \|\| Kickstart 1.1 \|\| This was a PAL only release and is obsolete.
	\|-		\|-
	\| 33 \|\| Kickstart 1.2 \|\|This is the oldest revision of the OS ~~still in use~~.		\| 33 \|\| Kickstart 1.2 \|\| This is the oldest revision of the OS.
	\|-		\|-
	\| 34 \|\| Kickstart 1.3 \|\| This is almost the same as release 1.2 except it has an Autobooting expansion.library		\| 34 \|\| Kickstart 1.3 \|\| This is almost the same as release 1.2 except it has an Autobooting expansion.library
Line 167:		Line 171:
	\| 39 \|\| Kickstart 3.0 \|\| This is the original Release 3 revision hat was initially shipped on ''Amiga 1200'' and ''Amiga 4000'' models.		\| 39 \|\| Kickstart 3.0 \|\| This is the original Release 3 revision hat was initially shipped on ''Amiga 1200'' and ''Amiga 4000'' models.
	\|-		\|-
	\| 40 \|\| Kickstart 3.1 \|\| This is the ~~general~~ Release 3 revision for all Amiga models.		\| 40 \|\| Kickstart 3.1 \|\| This is the original Release 3 revision for all Amiga models.
			\|-
			\| 41 \|\| Kickstart 3.1 \|\| This is version number which was reserved for the Japanese locale version of AmigaOS 3.1, with multi-byte character support (never completed).
			\|-
			\| 42 \|\| \|\| This is version number for some AmigaOS' modules of an internal alpha revision (early 1993).
			\|-
			\| 43 \|\| Kickstart 3.2 \|\| This is the original Release 3 revision for Amiga Walker model (never completed). This revision was used for stuff done by/for Amiga Technologies/Amiga International (1995).
	\|-		\|-
	\| 44 \|\| Kickstart 3.5 \|\| This is an update to Release 3 revision for all Amiga models.		\| 44 \|\| Kickstart 3.5 \|\| This is an update to Release 3 revision for all Amiga models.
Line 173:		Line 183:
	\| 45 \|\| Kickstart 3.9 \|\| This is an update to Release 3 revision for all Amiga models.		\| 45 \|\| Kickstart 3.9 \|\| This is an update to Release 3 revision for all Amiga models.
	\|-		\|-
	\| 50 \|\| Kickstart 4.0 \|\| This is the general Release 4 revision for ~~PPC equipped Amiga models and~~ the new ''AmigaOne'' range.		\| 50 \|\| Kickstart 4.0 \|\| This is the general Release 4 revision for the new ''AmigaOne'' range (Developer PreRelease).
	\|-		\|-
			\| 51 \|\| Kickstart 4.0 \|\| This is an update to Release 4 revision for the new ''AmigaOne'' range (Official Release from Update 1).
	\| 51 \|\| \|\|
	\|-		\|-
	\| 52 \|\| Kickstart 4.0 \|\| This is an update to Release 4 revision to include support for PPC equipped classic Amiga models.		\| 52 \|\| Kickstart 4.0 \|\| This is an update to Release 4 revision to include support for PPC equipped classic Amiga models.
	\|-		\|-
	\| 53 \|\| Kickstart 4.1 \|\| This is an update to Release 4 revision for all supported models.		\| 53 \|\| Kickstart 4.1 \|\| This is an update to Release 4 revision for all supported PPC models.
	\|}		\|}

Gianfranco Gignina: /* Interprocess Communications */

2012-07-08T10:04:12Z

Interprocess Communications

← Older revision		Revision as of 10:04, 8 July 2012
Line 108:		Line 108:
	IExec->WaitPort(mywin->UserPort);		IExec->WaitPort(mywin->UserPort);
	while (mymsg = IExec->GetMsg(mywin->UserPort))		while (mymsg = IExec->GetMsg(mywin->UserPort))
			{
	/* process message now or copy information from message */		/* process message now or copy information from message */
	IExec->ReplyMsg(mymsg);		IExec->ReplyMsg(mymsg);
			}
	...		...

Gianfranco Gignina: /* Interprocess Communications */

2012-07-08T10:00:50Z

Interprocess Communications

← Older revision		Revision as of 10:00, 8 July 2012
Line 83:		Line 83:
	When one task sends a message to another task's message port, the OS adds the message to the port's message queue. The message stays in this queue until the task that owns the port is ready to check its port for messages. Typically, a task has put itself to sleep while it is waiting for an event, like a message to arrive at its message port. When the message arrives, the task wakes up to look in its message port. The messages in the message port's queue are arranged in first-in-first-out (FIFO) order so that, when a task receives several messages, it will see the messages in the order they arrived at the		When one task sends a message to another task's message port, the OS adds the message to the port's message queue. The message stays in this queue until the task that owns the port is ready to check its port for messages. Typically, a task has put itself to sleep while it is waiting for an event, like a message to arrive at its message port. When the message arrives, the task wakes up to look in its message port. The messages in the message port's queue are arranged in first-in-first-out (FIFO) order so that, when a task receives several messages, it will see the messages in the order they arrived at the

	A task can use a message to share any kind of data with another task. This is possible because a task does not actually transmit an entire message, it only passes a pointer to a message. When a task creates a message (which can have many Kilobytes of data attached to it) and sends it to another task, the actual message does not move.		A task can use a message to share any kind of data with another task. '''This is possible because a task does not actually transmit an entire message, it only passes a pointer to a message. When a task creates a message (which can have many Kilobytes of data attached to it) and sends it to another task, the actual message does not move.'''

	Essentially, when ''task A'' sends a message to ''task B'', ''task A'' lends ''task B'' a chunk of its memory, the memory occupied by the message. After ''task A'' sends the message, it has relinquished that memory to ''task B'', so it cannot touch the memory occupied by the message. ''Task B'' has control of that memory until ''task B'' returns the message to ''task A'' with the ReplyMsg() function.		Essentially, '''when ''task A'' sends a message to ''task B'', ''task A'' lends ''task B'' a chunk of its memory, the memory occupied by the message. After ''task A'' sends the message, it has relinquished that memory to ''task B'', so it cannot touch the memory occupied by the message. ''Task B'' has control of that memory until ''task B'' returns the message to ''task A'' with the ReplyMsg() function.'''

	Let's look at an example. Many applications use Intuition windows as a source for user input. Without getting into too much detail about Intuition, when an application opens a window, it can set up the window so Intuition will send messages about certain user input events. Intuition sends these messages to a message port created by Intuition for use with this window. When an application successfully opens a window, it receives a pointer to a Window structure, which contains a pointer to this message port (Window.UserPort). For this example, we'll assume the window has been set up so Intuition will send a message only if the user clicks the window's close gadget.		Let's look at an example. Many applications use Intuition windows as a source for user input. Without getting into too much detail about Intuition, when an application opens a window, it can set up the window so Intuition will send messages about certain user input events. Intuition sends these messages to a message port created by Intuition for use with this window. When an application successfully opens a window, it receives a pointer to a Window structure, which contains a pointer to this message port (Window.UserPort). For this example, we'll assume the window has been set up so Intuition will send a message only if the user clicks the window's close gadget.