AmigaDOS Data Structures - Revision history

Steven Solie: /* Locks */

2015-10-02T18:54:04Z

Locks

← Older revision		Revision as of 18:54, 2 October 2015
Line 684:		Line 684:
	on that file. The lock contains the actual disk block location of the		on that file. The lock contains the actual disk block location of the
	directory or file header and is thus a shorthand way of specifying a		directory or file header and is thus a shorthand way of specifying a
	particular ~~filesystem~~ object. The structure of a lock is as follows:		particular file system object. The structure of a lock is as follows:

	{\| class="wikitable"		{\| class="wikitable"

Steven Solie: /* DOS Library Structure */

2015-10-02T18:50:51Z

DOS Library Structure

Show changes

Steven Solie: /* Process Data Structures */

2013-03-28T21:30:33Z

Process Data Structures

← Older revision		Revision as of 21:30, 28 March 2013
Line 33:		Line 33:
	\| LONG		\| LONG
	\| pr_TaskNum		\| pr_TaskNum
	\| CLI task number of zero if not a CLI		\| CLI task number or zero if not a CLI
	\|-		\|-
	\| BPTR		\| BPTR

Alexandre Balaban: Removed unneeded category

2012-07-11T12:38:57Z

Removed unneeded category

← Older revision		Revision as of 12:38, 11 July 2012
Line 1:		Line 1:
	[[Category:DOS\|Data Structures]]{{WIP}}		[[Category:DOS\|Data Structures]]{{WIP}}
	{{NeedUpdate}}
	= Process Data Structures =		= Process Data Structures =

Alexandre Balaban: /* Process Data Structures */ Reformatted the article, added some links, added category and added recommendation to use dedicated DOS functions

2012-07-11T12:38:03Z

Process Data Structures: Reformatted the article, added some links, added category and added recommendation to use dedicated DOS functions

Show changes

Alexandre Balaban: Categorizing

2012-05-11T13:26:02Z

Categorizing

← Older revision		Revision as of 13:26, 11 May 2012
Line 1:		Line 1:
			[[Category:DOS\|Data Structures]]{{WIP}}
	{{WIP}}
	= Process Data Structures =		= Process Data Structures =

Steven Solie: /* Info Substructure */

2012-05-09T03:43:58Z

Info Substructure

← Older revision		Revision as of 03:43, 9 May 2012
Line 488:		Line 488:

	Most of the fields in the Info substructure are empty at this time, and		Most of the fields in the Info substructure are empty at this time, and
	~~Commodore-Amiga~~ will use them for expanding the system.		the AmigaOS development team will use them for expanding the system.

	The DevInfo structure is a linked list. You use it to identify all the		The DevInfo structure is a linked list. You use it to identify all the

Steven Solie at 16:11, 2 May 2012

2012-05-02T16:11:21Z

← Older revision		Revision as of 16:11, 2 May 2012
Line 1:		Line 1:
			{{WIP}}
	= Process Data Structures =		= Process Data Structures =

Steven Solie: /* File Handles */

2012-04-27T16:04:47Z

File Handles

← Older revision		Revision as of 16:04, 27 April 2012
Line 835:		Line 835:
	handle by user programs. In general, you should not read the values either		handle by user programs. In general, you should not read the values either
	(except fh_Arg1 which is used for direct packet I/O).		(except fh_Arg1 which is used for direct packet I/O).

			= Locks =

			The filing system extensively uses a data structure called a lock. This
			structure serves two purposes. First, it serves as the mechanism to open
			files for multiple reads or a single write. Note that oibtaining a shared
			read lock on a directory does not stop that directory being updated.

			Second, the lock provides a unique identification for a file. Although a
			particular file may be specified in many ways, the lock is a simple handle
			on that file. The lock contains the actual disk block location of the
			directory or file header and is thus a shorthand way of specifying a
			particular filesystem object. The structure of a lock is as follows:

			{\| class="wikitable"
			! Type
			! Name
			! Description
			\|-
			\| BPTR
			\| fl_Link
			\| BPTR to next lock in chain, else zero
			\|-
			\| LONG
			\| fl_Key
			\| Block number of directory or file header
			\|-
			\| LONG
			\| fl_Access
			\| Shared or exclusive access
			\|-
			\| struct MsgPort*
			\| fl_Task
			\| Process ID of handler
			\|-
			\| BPTR
			\| fl_Volume
			\| BPTR to dlt_volume DOS list entry
			\|}

			Because AmigaDOS uses the fl_Link field to chain locks together, you
			should not alter it. The filing system fills in [the] fl_Key field to
			represent the location on disk of the directory block or the file header
			block. The fl_Access serves to indicate whether this is a shared read
			lock, when it has the value -2, or an exclusive write lock, when it has
			the value -1. The fl_Task field contains a pointer to the handler process
			for the device containing the file to which this lock refers. Finally the
			fl_Volume field points to the node in the DevInfo structure that
			identifies the volume to which this lock refers. Volume entries in the
			DevInfo structure remain there if a disk is inserted or if there are any
			locks open on that volume.

			Note that a lock can also be a zero. The special case of lock zero
			indicates that the lock refers to the root of the initial filing system,
			and the pr_FileSystemTask field within the process data structure gives
			the handler process. None of the fields in the Lock structure should be
			changed by your code. The Lock structure is strictly handler-private and
			read-only.

Steven Solie: /* Info Substructure */

2012-04-27T16:01:59Z

Info Substructure

← Older revision		Revision as of 16:01, 27 April 2012
Line 715:		Line 715:
	\| Volume name		\| Volume name
	\|}		\|}

			For multidrectory assigns, the additional locks are strung off of
			dol_List. For nonbinding and late assigns, dol_AssignName has the string
			for the assign (path). Late-binding assigns turn into regular assigns once
			they bind. Also note that any normal assign can have more locks strung off
			the dol_List.

			= Memory Allocation =

			AmigaDOS obtains all the memory it allocates by calling the AllocMem()
			function provided by Exec. In this way, AmigaDOS obtains structures such
			as locks and file handles; it usually places them back in the free pool by
			calling FreeMem(). Under V2.0 and later versions of AmigaDOS, AllocVec()
			and FreeVec() are available to do this. In either case, each memory
			segment allocated by AmigaDOS is identified by a BPTR to the second
			longword in the structure. The first longword always contains the length
			of the entire segment in bytes. Thus the structure of allocated memory is
			as follows:

			{\| class="wikitable"
			! Type
			! Name
			! Description
			\|-
			\| LONG
			\| BlockSize
			\| Size of memory block
			\|-
			\| LONG
			\| FirstData
			\| First data segment, BPTR to block points here
			\|}

			= Segment Lists =

			To obtain a segment list, you call LoadSeg(). The result is a BPTR to
			allocated memory, so that the length of the memory block containing each
			list entry is stored at -4 from the BPTR. This length is 8 more than the
			size of the segment list entry, allowing for the link field and the size
			field itself.

			The SegList is a list linked together by BPTRs and terminated by zero.
			The remainder of each segment list entry contains the code loaded. Thus
			the format is:

			{\| class="wikitable"
			! Type
			! Name
			! Description
			\|-
			\| LONG
			\| NextSeg
			\| BPTR to next segment or zero
			\|-
			\| LONG
			\| FirstCode
			\| First value from binary file
			\|}

			= File Handles =

			File handles are created by the AmigaDOS function Open(), and you use them
			as arguments to other functions such as Read() and Write(). AmigaDOS
			returns them as a BPTR to the following structure:

			{\| class="wikitable"
			! Type
			! Name
			! Description
			\|-
			\| struct Message*
			\| fh_Link
			\| Reserved for AmigaDOS
			\|-
			\| struct Message*
			\| fh_Key
			\| Reply port for the packet
			\|-
			\| struct Message*
			\| fh_Port
			\| Process ID of handler
			\|-
			\| LONG
			\| fh_Buf
			\| Buffer for internal use
			\|-
			\| LONG
			\| fh_Pos
			\| Character position for internal use
			\|-
			\| LONG
			\| fh_End
			\| End position for internal use
			\|-
			\| LONG
			\| fh_Func1
			\| Function called when buffer [is] exhausted
			\|-
			\| LONG
			\| fh_Func2
			\| Function called when buffer is full
			\|-
			\| LONG
			\| fh_Func3
			\| Function called when handle is closed
			\|-
			\| LONG
			\| fh_Arg1
			\| Argument depends on file handle type
			\|-
			\| LONG
			\| fh_Arg2
			\| Argument depends on file handle type
			\|}

			Most of these fields are only used by AmigaDOS internally; normally Read()
			or Write() uses the file handle to indicate the handler process and any
			arguments to be passed. Values should not be altered within the file
			handle by user programs. In general, you should not read the values either
			(except fh_Arg1 which is used for direct packet I/O).