Copyright (c) Hyperion Entertainment and contributors.

Difference between revisions of "AmigaDOS Packets"

From AmigaOS Documentation Wiki
Jump to navigation Jump to search
 
(20 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
[[Category:DOS]]{{WIP}}
 +
[[Category:DOS]]
 
= Introduction =
  
= Introduction =
   
Line 39: Line 39:
 
Exec Message structure and an AmigaDOS DOSPacket structure:
  
Exec Message structure and an AmigaDOS DOSPacket structure:
   
  +
<syntaxhighlight>
 
struct StandardPacket
  
struct StandardPacket
 
{ struct Message sp_Msg;
  
{ struct Message sp_Msg;
 
struct DOSPacket sp_Pkt;
  
struct DOSPacket sp_Pkt;
 
};
  
};
  +
</syntaxhighlight>
   
 
This structure must be longword-aligned, and initialized to link the
  
This structure must be longword-aligned, and initialized to link the
 
Message and DOSPacket sections to each other:
  
Message and DOSPacket sections to each other:
   
  +
<syntaxhighlight>
 
packet->sp_Msg.mn_Node.ln_Name = (char *) &(packet->sp_Pkt);
  
packet->sp_Msg.mn_Node.ln_Name = (char *) &(packet->sp_Pkt);
 
packet->sp_Pkt.dp_Link = &(packet->sp_Msg);
  
packet->sp_Pkt.dp_Link = &(packet->sp_Msg);
  +
</syntaxhighlight>
   
−
Packets must also be initialized with a ReplyPort which can be created
 +
Packets must also be initialized with a ReplyPort which is created with AllocSysObject():
−
with the amiga.lib function CreatePort():
  
   
  +
<syntaxhighlight>
−
if (replyport = (struct MsgPort *) CreatePort(NULL, 0))
  
  +
if (replyport = (struct MsgPort *) IExec->AllocSysObjectTags(ASOT_PORT, TAG_END))
 
packet->sp_Pkt.dp_Port = replyport;
  
packet->sp_Pkt.dp_Port = replyport;
  +
</syntaxhighlight>
   
 
The DOSPacket portion of the StandardPacket structure is used to pass the
  
The DOSPacket portion of the StandardPacket structure is used to pass the
Line 75: Line 80:
 
| Reply port for the packet. Must be filled in each send
  
| Reply port for the packet. Must be filled in each send
 
|-
  
|-
−
| LONG
 +
| int32
 
| dp_Type
  
| dp_Type
 
| Packet type
  
| Packet type
 
|-
  
|-
−
| LONG
 +
| int32
 
| dp_Res1
  
| dp_Res1
−
| For filesystem calls this is the result that would have been returned by the function; eg. Write("W") returns actual length written.
 +
| For file system calls this is the result that would have been returned by the function; eg. Write("W") returns actual length written.
 
|-
  
|-
−
| LONG
 +
| int32
 
| dp_Res2
  
| dp_Res2
−
| For filesystem calls this is what would have been returned by IoErr()
 +
| For file system calls this is what would have been returned by IoErr()
 
|-
  
|-
−
| LONG
 +
| int32
 
| dp_Arg1
  
| dp_Arg1
 
| Argument 1 (depends on packet type)
  
| Argument 1 (depends on packet type)
 
|-
  
|-
−
| LONG
 +
| int32
 
| dp_Arg2
  
| dp_Arg2
 
| Argument 2 (depends on packet type)
  
| Argument 2 (depends on packet type)
 
|-
  
|-
−
| LONG
 +
| int32
 
| dp_Arg3
  
| dp_Arg3
 
| Argument 3 (depends on packet type)
  
| Argument 3 (depends on packet type)
 
|-
  
|-
−
| LONG
 +
| int32
 
| dp_Arg4
  
| dp_Arg4
 
| Argument 4 (depends on packet type)
  
| Argument 4 (depends on packet type)
 
|-
  
|-
−
| LONG
 +
| int32
 
| dp_Arg5
  
| dp_Arg5
 
| Argument 5 (depends on packet type)
  
| Argument 5 (depends on packet type)
 
|-
  
|-
−
| LONG
 +
| int32
 
| dp_Arg6
  
| dp_Arg6
 
| Argument 6 (depends on packet type)
  
| Argument 6 (depends on packet type)
 
|-
  
|-
−
| LONG
 +
| int32
 
| dp_Arg7
  
| dp_Arg7
 
| Argument 7 (depends on packet type)
  
| Argument 7 (depends on packet type)
 
|}
  
|}
   
  +
The format of a specific packet depends on its type; but in all cases it contains a back-pointer to the Message structure, the MsgPort for the reply, and two result fields. When AmigaDOS sends a packet, the reply port is overwritten with the process ID of the sender so that the packet can be returned. Thus, when sending a packet to an AmigaDOS handler process, you must fill in the reply MsgPort each time; otherwise when the packet returns, AmigaDOS has overwritten the original port. AmigaDOS maintains all other fields except the result fields.
−
The format of a specific packet depends on its type; but in all cases it
  
−
contains a back-pointer to the Message structure, the MsgPort for the
  
−
reply, and two result fields. When AmigaDOS sends a packet, the reply port
  
−
is overwritten with the process ID of the sender so that the packet can be
  
−
returned. Thus, when sending a packet to an AmigaDOS handler process, you
  
−
must fill in the reply MsgPort each time; otherwise when the packet
  
−
returns, AmigaDOS has overwritten the original port. AmigaDOS maintains
  
−
all other fields except the result fields.
  
   
  +
All AmigaDOS packets are sent to the message port created as part of a process; this message port is initialized so that arriving messages cause signal bit 8 to be set. An AmigaDOS process that is waiting for a message waits for signal 8 to be set. When the process wakes up because this event has occurred, GetMsg() takes the message from the message port and
−
All AmigaDOS packets are sent to the message port created as part of a
  
  +
extracts the packet address. If the process is an AmigaDOS handler process, then the packet contains a value in the PktType field that indicates an action to be performed, such as reading some data. The argument fields contain specific information such as the size of the buffer where the characters go.
−
process; this message port is initialized so that arriving messages cause
  
−
signal bit 8 to be set. An AmigaDOS process that is waiting for a message
  
−
waits for signal 8 to be set. When the process wakes up because this event
  
−
has occurred, GetMsg() takes the message from the message port and
  
−
extracts the packet address. If the process is an AmigaDOS handler
  
−
process, then the packet contains a value in the PktType field that
  
−
indicates an action to be performed, such as reading some data. The
  
−
argument fields contain specific information such as the size of the
  
−
buffer where the characters go.
  
   
  +
When the handler process has completed the work required to satisfy this request, the packet returns to the sender, using the same message structure. Both the message structure and the packet structure must be allocated by the client and not deallocated before the reply has been received. Normally AmigaDOS is called by the client to send the packet, such as when a call to Read() is made. However, there are cases where asynchronous I/O is required, and in this case the client may send packets to the handler process as required. The packet and message structures must be allocated, and the process ID field filled in with the message port where this packet must return. A call to PutMsg() then sends the message to the destination. Note that many packets may be sent out, returning to either the same or different message ports.
−
When the handler process has completed the work required to satisfy this
  
−
request, the packet returns to the sender, using the same message
  
−
structure. Both the message structure and the packet structure must be
  
−
allocated by the client and not deallocated before the reply has been
  
−
received. Normally AmigaDOS is called by the client to send the packet,
  
−
such as when a call to Read() is made. However, there are cases where
  
−
asynchronous I/O is required, and in this case the client may send packets
  
−
to the handler process as required. The packet and message structures must
  
−
be allocated, and the process ID field filled in with the message port
  
−
where this packet must return. A call to PutMsg() then sends the message
  
−
to the destination. Note that many packets may be sent out, returning to
  
−
either the same or different message ports.
  
   
 
= Packet Types =
  
= Packet Types =
   
−
Packets sent to a filesystem or handler can be divided into several basic
 +
Packets sent to a file system or handler can be divided into several basic
 
categories:
  
categories:
   
−
; Basic Input/Output.
 +
; Basic Input/Output
 
: These actions deal with transferring data to and from objects controlled by the handler.
  
: These actions deal with transferring data to and from objects controlled by the handler.
−
; File/Directory Manipulation/Information.
  
−
: These actions are used to gain access to and manipulate the high-level structures of the filesystem.
  
−
; Volume Manipulation/Information.
  
−
: These actions allow access to the specific volume controlled by the filesystem.
  
−
; Handler Maintenance and Control.
  
−
: These actions allow control over the handler/filesystem itself, independent of the actual volume or structure underneath.
  
−
; Handler Internal.
  
−
: These actions are never sent to the handler directly. Instead they are generally responses to I/O requests made by the handler. The handler makes these responses look like packets to simplify processing.
  
−
; Obsolete Packets.
 
−
: These packets are no longer valid for use by handlers and filesystems.
  
−
; Console Only Packets.
  
−
: These packets are specific to console handlers. Filesystems can ignore these packets.
  
   
  +
; File/Directory Manipulation/Information
−
Each packet type documented in this section is listed with its action
  
  +
: These actions are used to gain access to and manipulate the high level structures of the file system.
−
name, its corresponding number, any AmigaDOS routines that use this
  
  +
−
packet, and the list of parameters that the packet uses. The C variable
  
  +
; Volume Manipulation/Information
−
types for the packet parameters are one of the following types:
  
  +
: These actions allow access to the specific volume controlled by the file system.
  +
  +
; Handler Maintenance and Control
  +
: These allow control over the handler/file system itself, independent of the actual volume or structure underneath.
  +
  +
; Handler Internal
  +
: These actions are never sent to the handler directly. Instead they are generally responses to IO requests made by the handler.
  +
  +
; Obsolete Packets
  +
: These packets are no longer valid for use by handlers/file systems.
  +
  +
; Deprecated Packets
  +
: These packets are superceded by new ones with updated functionality and file systems/handlers should avoid implementing these packets at all and let dos.library emulate the old and limited functionality.
  +
  +
; Console Only Packets
  +
: These packets are specific to console handlers.
  +
: File Systems can ignore these packets.
  +
  +
Each packet type documented in this section is listed with its action name, its corresponding number, any AmigaDOS routines that use this
  +
packet, and the list of parameters that the packet uses. The C variable types for the packet parameters are one of the following types:
   
 
{| class="wikitable"
  
{| class="wikitable"
Line 179: Line 166:
 
|-
  
|-
 
| BPTR
  
| BPTR
−
| This is a BCPL pointer (the address of the given object shifted right by 2).<br/>''Note:'' This means that the object must be aligned on a longword boundary.
 +
| This is BCPL pointer (an address which is right shifted by 2). This means that the object must be aligned on a 32 bit address.
−
|-
  
−
| LOCK
  
−
| This is a BPTR to a FileLock structure returned by a previous ACTION_LOCATE_OBJECT. A lock of 0 is legal, indicating the root of the volume for the handler.
  
 
|-
  
|-
 
| BSTR
  
| BSTR
−
| This is a BPTR to a string where the first byte indicates the number of characters in the string. A byte of this length is unsigned but because the information is stored in a byte, the strings are limited to 255 characters in length.
 +
| This is a BCPL pointer to a string where the first byte indicates the number of characters in the string. This length byte is unsigned but because it is stored in only 8 bits, the strings are limited to 255 characters in length before V52 of dos.library.<br/>
  +
  +
As of V52+ dos.library, "extended BSTR" (XBSTR) strings can be sent to handlers and file systems from dos.library for extensibility reasons, while still maintaining legacy backward compatibility. These extended BSTR strings are in the same format as a legacy BSTR string but are guaranteed to have a null-terminator byte added to the end, and the length byte of these will be correct only up to 255 characters, past that length, the length byte will always read 255 (0xFF) and is there just for limited legacy compatibility. These extended BSTR strings are always documented and identified by having an additional dospacket identifier parameter supplied, consult the individual DOS packet documentation for details.<br/>
  +
  +
See also ACTION_INHIBIT_DOS_LONGPATH_HANDLING for details on this DOS packet and how to formally control the use of XBSTR strings.
 
|-
  
|-
−
| BOOL
 +
| BOOLEAN
  +
| A 32-bit boolean value which is either ZERO or NON-ZERO. For implementation purposes, non-zero boolean values should be -1 this is also defined as DOSTRUE. However for compatibility reasons, performing equality comparisons with any value other than zero is absolutely forbidden, only 0 or FALSE may be used in a value comparison test.<br/>
−
| A 32-bit boolean value either containing DOSTRUE (-1) or DOSFALSE (0).<br/>''Note:'' Equality comparisons with DOSTRUE should be avoided.
  
  +
  +
See the dos.doc file introduction paragraph for more details on this issue.
 
|-
  
|-
−
| CODE
 +
| RESULT1
−
| A 32-bit error code as defined in the <dos/dos.h> include file. Handlers should not return error codes besides those defined in <dos/dos.h>.
 +
| A 32 bit primary result code as defined for the function.
 
|-
  
|-
−
| ARG1
 +
| RESULT2
  +
| A 32 bit error code as defined in the dos/errors.h include file. Handlers should not return error codes besides those defined. For some functions a secondary result can also be returned here upon success.
−
| The FileHandle->fh_Arg1 field.
  
−
|-
  
−
| LONG
  
−
| A 32-bit integer value.
  
 
|}
  
|}
   
  +
== Summary of Defined Packet Numbers ==
−
== Basic Input/Output ==
  
   
  +
Summary of defined packet numbers, as of DOS library version 53.71
−
The Basic Input/Output actions are supported by both handlers and file systems. In this way, the application can get a stream level access to both devices and files. One difference that arises between the two is that a handler will not necessarily support an ACTION_SEEK while it is generally expected for a file system to do so.
  
   
  +
This is a listing of all the DOS packets defined by Commodore and other relevant authorities since.
−
These actions work based on a FileHandle which is filled in by one of the three forms of opens:
  
−
Packet Mnemonic ID Function Syntax
  
−
======================== ======= ==========================
  
−
'''ACTION_FINDINPUT''' 1005 Open(..., MODE_OLDFILE)
 
−
'''ACTION_FINDOUTPUT''' 1006 Open(..., MODE_NEWFILE)
  
−
'''ACTION_FINDUPDATE''' 1004 Open(..., MODE_READWRITE)
  
−
ARG1: BPTR FileHandle to fill in
  
−
ARG2: LOCK Lock on directory that ARG3 is relative to
  
−
ARG3: BSTR Name of file to be opened (relative to ARG1)
  
−
 
−
RES1: BOOL Success/Failure (DOSTRUE/DOSFALSE)
  
−
RES2: CODE Failure code if RES1 is DOSFALSE
  
   
  +
Unless otherwise noted, packets 2050-2999 and 8500-8999 are reserved for use by third party developers (see chart below).
−
All three actions use the lock (ARG2) as a base directory location from which to open the file. If this lock is NULL, then the file name (ARG3) is relative to the root of the current volume. Because of this, file names are not limited to a single file name but instead can include a volume name (followed by a colon) and multiple slashes allowing the file system to fully resolve the name. This eliminates the need for AmigaDOS or the application to parse names before sending them to the file system. Note that the lock in ARG2 must be associated with the file system in question. It is illegal to use a lock from another file system.
  
  +
  +
All remaining packets are reserved for future OS expansion.
   
  +
{| class="wikitable"
−
The calling program owns the file handle (ARG1). The program must initialize the file handle before trying to open anything (in the case of a call to Open(), AmigaDOS allocates the file handle automatically and then frees it in Close() ). All fields must be zero except the fh_Pos and fh_End fields which should be set to -1. The Open() function fills in the fh_Type field with a pointer to the MsgPort of the handler process. Lastly, the handler must initialize fh_Arg1 with something that allows the handler to uniquely locate the object being opened (normally a file). This value is implementation specific. This field is passed to the READ/WRITE/SEEK/ END/TRUNCATE operations and not the file handle itself.
  
  +
! Decimal !! Hex !! Action #define !! Status
−  
  +
|-
−
FINDINPUT and FINDUPDATE are similar in that they only succeed if the file already exists. FINDINPUT will open with a shared lock while FINDUPDATE will open it with a shared lock but if the file doesn't exist, FINDUPDATE will create the file. FINDOUTPUT will always open the file (deleting any existing one) with an exclusive lock.
  
  +
| 0 || 0x0000 || ACTION_NIL or ACTION_STARTUP
−  
  +
|-
−
Packet Mnemonic ID Function Syntax
  
  +
| 1 || || <Reserved for operating system>
−
======================== ======= ==========================
  
  +
|-
−
'''ACTION_READ''' 'R' Read(...)
  
  +
| 2 || 0x0002 || ACTION_GET_BLOCK || Obsolete
−
ARG1: ARG1 fh_Arg1 field of the opened FileHandle
  
  +
|-
−
ARG2: APTR Buffer to put data into
  
  +
| 3 || || <Reserved for operating system>
−
ARG3: LONG Number of bytes to read
  
  +
|-
−
 
  +
| 4 || 0x0004 || ACTION_SET_MAP || Obsolete
−
RES1: LONG Number of bytes read.
  
  +
|-
−
0 indicates EOF.
  
  +
| 5 || 0x0005 || ACTION_DIE || Deprecated
−
-1 indicates ERROR
  
  +
|-
−
RES2: CODE Failure code if RES1 is -1
  
  +
| 6 || 0x0006 || ACTION_EVENT || Obsolete
−  
  +
|-
−
This action extracts data from the file (or input channel) at the current position. If fewer bytes remain in the file than requested, only those bytes remaining will be returned with the number of bytes stored in RES1. The handler indicates an error is indicated by placing a -1 in RES1 and the error code in RES2. If the read fails, the current file position remains unchanged. Note that a handler may return a smaller number of bytes than requested, even if not at the end of a file. This happens with interactive type file handles which may return one line at a time as the user hits return, for example the console handler, CON:.
  
  +
| 7 || 0x0007 || ACTION_CURRENT_VOLUME || Obsolete
−  
  +
|-
−
Packet Mnemonic ID Function Syntax
  
  +
| 8 || 0x0008 || ACTION_LOCATE_OBJECT
−
======================== ======= ==========================
  
  +
|-
−
'''ACTION_WRITE''' 'W' Write(...)
  
  +
| 9 || 0x0009 || ACTION_RENAME_DISK
−
ARG1: ARG1 fh_Arg1 field of the opened file handle
  
  +
|-
−
ARG2: APTR Buffer to write to the file handle
  
  +
| 10-14 || || <Reserved for operating system>
−
ARG3: LONG Number of bytes to write
  
  +
|-
−
 
  +
| 15 || 0x000F || ACTION_FREE_LOCK
−
RES1: LONG Number of bytes written.
  
  +
|-
−
RES2: CODE Failure code if RES1 not the same as ARG3
  
  +
| 16 || 0x0010 || ACTION_DELETE_OBJECT
−  
  +
|-
−
This action copies data into the file (or output channel) at the current position. The file is automatically extended if the write passes the end of the file. The handler indicates failure by returning a byte count in RES1 that differs from the number of bytes requested in ARG3. In the case of a failure, the handler does not update the current file position (although the file may have been extended and some data overwritten) so that an application can safely retry the operation.
  
  +
| 17 || 0x0011 || ACTION_RENAME_OBJECT
−  
  +
|-
−
Packet Mnemonic ID Function Syntax
  
  +
| 18 || 0x0012 || ACTION_MORE_CACHE || Deprecated
−
======================== ======= ==========================
  
  +
|-
−
'''ACTION_SEEK''' 1008 Seek(...)
  
  +
| 19 || 0x0013 || ACTION_COPY_DIR or ACTION_COPY_LOCK
−
ARG1: ARG1 fh_Arg1 field of the opened FileHandle
  
  +
|-
−
ARG2: LONG New Position
  
  +
| 20 || 0x0014 || ACTION_WAIT_CHAR
−
ARG3: LONG Mode: OFFSET_BEGINNING,OFFSET_END, or OFFSET_CURRENT
  
  +
|-
−
 
  +
| 21 || 0x0015 || ACTION_SET_PROTECT
−
RES1: LONG Old Position. -1 indicates an error
  
  +
|-
−
RES2: CODE Failure code if RES1 = -1
  
  +
| 22 || 0x0016 || ACTION_CREATE_DIR
  +
|-
  +
| 23 || 0x0017 || ACTION_EXAMINE_OBJECT || Deprecated
  +
|-
  +
| 24 || 0x0018 || ACTION_EXAMINE_NEXT || Deprecated
  +
|-
  +
| 25 || 0x0019 || ACTION_DISK_INFO
  +
|-
  +
| 26 || 0x001A || ACTION_INFO
  +
|-
  +
| 27 || 0x001B || ACTION_FLUSH
  +
|-
  +
| 28 || 0x001C || ACTION_SET_COMMENT
  +
|-
  +
| 29 || 0x001D || ACTION_PARENT
  +
|-
  +
| 30 || 0x001E || ACTION_TIMER || Internal
  +
|-
  +
| 31 || 0x001F || ACTION_INHIBIT
  +
|-
  +
| 32 || 0x0020 || ACTION_DISK_TYPE || Obsolete
  +
|-
  +
| 33 || 0x0021 || ACTION_DISK_CHANGE || Obsolete
  +
|-
  +
| 34 || 0x0022 || ACTION_SET_DATE
  +
|-
  +
| 35-39 || || <Reserved for operating system>
  +
|-
  +
| 40 || 0x0028 || ACTION_SAME_LOCK
  +
|-
  +
| 41-52 || || <Reserved for operating system>
  +
|-
  +
| 53 || 0x0035 || ACTION_SAME_FH
  +
|-
  +
| 54-81 || || <Reserved for operating system>
  +
|-
  +
| 82 || 0x0052 || ACTION_READ
  +
|-
  +
| 83-86 || || <Reserved for operating system>
  +
|-
  +
| 87 || 0x0057 || ACTION_WRITE
  +
|-
  +
| 88-993 || || <Reserved for operating system>
  +
|-
  +
| 994 || 0x03E2 || ACTION_SCREEN_MODE or ACTION_SINGLE_CHARACTER_MODE
  +
|-
  +
| 995 || 0x03E3 || ACTION_CHANGE_SIGNAL
  +
|-
  +
| 996-1000 || || <Reserved for operating system>
  +
|-
  +
| 1001 || 0x03E9 || ACTION_READ_RETURN || Internal
  +
|-
  +
| 1002 || 0x03EA || ACTION_WRITE_RETURN || Internal
  +
|-
  +
| 1003 || 0x03EB || ACTION_INT_WRITE_RETURN || Internal
  +
|-
  +
| 1004 || 0x03EC || ACTION_FINDUPDATE (MODE_READWRITE)
  +
|-
  +
| 1005 || 0x03ED || ACTION_FINDINPUT (MODE_OLDFILE)
  +
|-
  +
| 1006 || 0x03EE || ACTION_FINDOUTPUT (MODE_NEWFILE)
  +
|-
  +
| 1007 || 0x03EF || ACTION_END
  +
|-
  +
| 1008 || 0x03F0 || ACTION_SEEK || Deprecated
  +
|-
  +
| 1009 || 0x03F1 || ACTION_ICONIFY || Internal
  +
|-
  +
| 1010-1019 || || <Reserved for operating system>
  +
|-
  +
| 1020 || 0x03FC || ACTION_FORMAT
  +
|-
  +
| 1021 || 0x03FD || ACTION_MAKE_LINK
  +
|-
  +
| 1022 || 0x03FE || ACTION_SET_FILE_SIZE || Deprecated
  +
|-
  +
| 1023 || 0x03FF || ACTION_WRITE_PROTECT
  +
|-
  +
| 1024 || 0x0400 || ACTION_READ_LINK
  +
|-
  +
| 1025 || || <Reserved for operating system>
  +
|-
  +
| 1026 || 0x0402 || ACTION_FH_FROM_LOCK
  +
|-
  +
| 1027 || 0x0403 || ACTION_IS_FILESYSTEM
  +
|-
  +
| 1028 || 0x0404 || ACTION_CHANGE_MODE
  +
|-
  +
| 1029 || || <Reserved for operating system>
  +
|-
  +
| 1030 || 0x0406 || ACTION_COPY_DIR_FH
  +
|-
  +
| 1031 || 0x0407 || ACTION_PARENT_FH
  +
|-
  +
| 1032 || || <Reserved for operating system>
  +
|-
  +
| 1033 || 0x0409 || ACTION_EXAMINE_ALL || Deprecated
  +
|-
  +
| 1034 || 0x040A || ACTION_EXAMINE_FH || Deprecated
  +
|-
  +
| 1035 || 0x040B || ACTION_EXAMINE_ALL_END || Deprecated
  +
|-
  +
| 1036 || 0x040C || ACTION_SET_OWNER || Deprecated
  +
|-
  +
| 1037 || 0x040D || ACTION_SET_OWNER_INFO
  +
|-
  +
| 1038 || || <Reserved for operating system>
  +
|-
  +
| 1039 || 0x040F || ACTION_NEWMEMFILE || Internal
  +
|-
  +
| 1040 || 0x0410 || ACTION_NEWMEMLOCK || Internal
  +
|-
  +
| 1041-1997 || || <Reserved for operating system>
  +
|-
  +
| 1998 || 0x07CE || ACTION_WAIT_FOR_DATA
  +
|-
  +
| 1999 || 0x07CF || ACTION_SET_BLOCKING_MODE
  +
|-
  +
| 2000-2007 || || <Reserved for operating system>
  +
|-
  +
| 2008 || 0x07D8 || ACTION_LOCK_RECORD || Optional
  +
|-
  +
| 2009 || 0x07D9 || ACTION_FREE_RECORD || Optional
  +
|-
  +
| 2010-2049 || || <Reserved for operating system>
  +
|-
  +
| 2050-2999 || || <Reserved for 3rd Party Handlers>
  +
|-
  +
| 3000 || 0x0BB8 || ACTION_SHUTDOWN
  +
|-
  +
| 3001 || 0x0BB9 || ACTION_COLLECT
  +
|-
  +
| 3002-3004 || || <Reserved for operating system>
  +
|-
  +
| 3005 || 0x0BBD || ACTION_FILESYSTEM_ATTR
  +
|-
  +
| 3006 || 0x0BBE || ACTION_OBTAIN_CON_INFO
  +
|-
  +
| 3007 || 0x0BBF || ACTION_RELEASE_CON_INFO
  +
|-
  +
| 3008-3029 || || <Reserved for operating system>
  +
|-
  +
| 3030 || 0x0BD6 || ACTION_EXAMINEDATA
  +
|-
  +
| 3031 || 0x0BD7 || ACTION_EXAMINEDATA_FH
  +
|-
  +
| 3032-3039 || || <Reserved for operating system>
  +
|-
  +
| 3040 || 0x0BE0 || ACTION_EXAMINEDATA_DIR
  +
|-
  +
| 3041-4096 || || <Reserved for operating system>
  +
|-
  +
| 4097 || 0x1001 || ACTION_ADD_NOTIFY || Optional
  +
|-
  +
| 4098 || 0x1002 || ACTION_REMOVE_NOTIFY || Optional
  +
|-
  +
| 4099-4199 || || <Reserved for operating system>
  +
|-
  +
| 4200 || 0x1068 || ACTION_SERIALIZE_DISK
  +
|-
  +
| 4201 || 0x1069 || ACTION_GET_DISK_FSSM
  +
|-
  +
| 4202 || 0x106A || ACTION_FREE_DISK_FSSM
  +
|-
  +
| 4203-5322 || || <Reserved for operating system>
  +
|-
  +
| 5323 || 0x14CB || ACTION_INHIBIT_DOS_LONGPATH_HANDLING
  +
|-
  +
| 5324-8000 || || <Reserved for operating system>
  +
|-
  +
| 8001 || 0x1F41 || ACTION_CHANGE_FILE_POSITION64
  +
|-
  +
| 8002 || 0x1F42 || ACTION_GET_FILE_POSITION64
  +
|-
  +
| 8003 || 0x1F43 || ACTION_CHANGE_FILE_SIZE64
  +
|-
  +
| 8004 || 0x1F44 || ACTION_GET_FILE_SIZE64
  +
|-
  +
| 8005-8499 || || <Reserved for operating system 64 bit functions>
  +
|-
  +
| 8500-8999 || || <Reserved for use by 3rd Party Handlers for 64 bit functions>
  +
|-
  +
| 9000-... || || <Reserved for operating system>
  +
|}
   
  +
== Detailed DOS Packet Documentation ==
−
This packet sets the current file position. The new position (ARG2) is relative to either the beginning of the file (OFFSET_BEGINNING), the end of the file (OFFSET_END), or the current file position (OFFSET_CURRENT), depending on the mode set in ARG3. Note that ARG2
  
−
can be negative. The handler returns the previous file position in RES1. Any attempt to seek past the end of the file will result in an error and will leave the current file position in an unknown location.
 
   
  +
See the [http://wiki.amigaos.net/amiga/autodocs/dos.dospackets.txt dos.dospackets.doc autodoc] for all the detailed information regarding each DOS packet.
−
Packet Mnemonic ID Function Syntax
  
−
======================== ======= ==========================
  
−
'''ACTION_END''' 1007 Close(...)
  
−
ARG1: ARG1 fh_Arg1 field of the opened FileHandle
  
−
 
−
RES1: LONG DOSTRUE
  
−  
−
This packet closes an open file handle. This function generally returns a DOSTRUE as there is little the application can do to recover from a file closing failure. If an error is returned under 2.0, DOS will not deallocate the file handle. Under 1.3, it does not check the result.
  
−  
−
Packet Mnemonic ID Function Syntax
  
−
======================== ======= ==========================
  
−
'''ACTION_LOCK_RECORD''' 2008 LockRecord(fh,pos,len,mod,tim)
  
−
ARG1: BPTR FileHandle to lock record in
  
−
ARG2: LONG Start position (in bytes) of record in the file
  
−
ARG3: LONG Length (in bytes) of record to be locked
  
−
ARG4: LONG Mode
  
−
0 = Exclusive
  
−
1 = Immediate Exclusive (timeout is ignored)
  
−
2 = Shared
  
−
3 = Immediate Shared (timeout is ignored)
  
−
ARG5: LONG Timeout period in AmigaDOS ticks (0 is legal)
  
−
 
−
RES1: BOOL Success/Failure (DOSTRUE/DOSFALSE)
  
−
RES2: CODE Failure code if RES1 is DOSFALSE
  
−  
−
This function locks an area of a file in either a sharable (indicating read-only) or exclusive (indicating read/write) mode. Several sharable record locks from different file handles can exist simultaneously on a particular file area but only one file handle can have exclusive record locks on a particular area at a time. The exclusivity of an exclusive file lock only applies to record locks from other file handles, not to record locks within the file handle. One file handle can have any number of overlapping exclusive record locks. In the event of overlapping lock ranges, the entire range must be lockable before the request can succeed. The timeout period (ARG5) is the number of AmigaDOS ticks (1/50 second) to wait for success before failing the operation.
  
−  
−
Packet Mnemonic ID Function Syntax
  
−
======================== ======= ==========================
  
−
'''ACTION_FREE_RECORD''' 2009 UnLockRecord(file,pos,len)
  
−
ARG1: BPTR FileHandle to unlock record in
  
−
ARG2: LONG Start position (in bytes) of record in the file
  
−
ARG3: LONG Length of record (in bytes) to be unlocked
  
−
 
−
RES1: BOOL Success/Failure (DOSTRUE/DOSFALSE)
  
−
RES2: CODE Failure code if RES1 is DOSFALSE
  
−  
−
This function unlocks any previous record lock. If the given range does not represent one that is currently locked in the file, ACTION_FREE_RECORD returns an error. In the event of multiple locks on a given area, only one lock is freed.
  
−  
−
Packet Mnemonic ID Function Syntax
  
−
======================== ======= ==========================
  
−
'''ACTION_SET_FILE_SIZE''' 1022 SetFileSize(file,off,mode)
  
−
ARG1: BPTR FileHandle of opened file to modify
  
−
ARG2: LONG New end of file location based on mode
  
−
ARG3: LONG Mode. One of OFFSET_CURRENT, OFFSET_BEGIN, or OFFSET_END
  
−
 
−
RES1: BOOL Success/Failure (DOSTRUE/DOSFALSE)
  
−
RES2: CODE Failure code if RES1 is DOSFALSE
  
−  
−
This function is used to change the physical size of an opened file. ARG2, the new end-of-file position, is relative to either the current file position (OFFSET_CURRENT), the beginning of the file (OFFSET_BEGIN), or the end of the file (OFFSET_END), depending on the mode set in ARG3. The current file position will not change unless the current file position is past the new end-of-file position. In this case, the new file position will move to the new end of the file. If there are other open file handles on this file, ACTION_SET_FILE_SIZE sets the end-of-file for these alternate file handles to either their respective current file position or to the new end-of-file position of the file handle in ARG1, whichever makes the file appear longer.
  
−  
−
== Directory/File Manipulation/Information ==
  
−  
−
== Volume Manipulation/Information ==
  
−  
−
== Handler Maintenance and Control ==
  
−  
−
== Handler Internal ==
  
−  
−
== Obsolete Packets ==
  
−  
−
== Console Only Packets ==
  
−  
−
== Summary of Defined Packet Numbers ==
  
   
 
= Using Packets Directly =
  
= Using Packets Directly =
   
  +
AmigaDOS contains many features that can only be accessed by sending a packet directly to a process. For example, the ACTION_DISK_INFO packet may be used to find the Intuition window pointer of a CON: or RAW: window. This is useful for redirecting system requesters so that they appear where the user can see them (see "Redirecting System Requesters" above). The Window pointer will be returned in the ID_VolumeNode field, and a pointer to the console's I/O request will be returned in the ID_InUse field. Note that auxiliary consoles (AUX:) can return a NULL Window pointer, and also may have no ConUnit (io_Unit) associated with their I/O request block. Be careful to check for these possibilities when you use this packet. If your application runs in a CLI window, a user may be running you in an auxiliary (AUX:) CLI.
−
AmigaDOS contains many features that can only be accessed by sending a
  
−
packet directly to a process. For example, the ACTION_DISK_INFO packet may
  
−
be used to find the Intuition window pointer of a CON: or RAW: window.
  
−
This is useful for redirecting system requesters so that they appear where
  
−
the user can see them (see "Redirecting System Requesters" above). The Window
  
−
pointer will be returned in the ID_VolumeNode field, and a pointer to the
  
−
console's I/O request will be returned in the ID_InUse field. Note that
  
−
auxilary consoles (AUX:) can return a NULL Window pointer, and also may
  
−
have no ConUnit (io_Unit) associated with their I/O request block. Be
  
−
careful to check for these possibilities when you use this packet. If your
  
−
application runs in a CLI window, a user may be running you in an auxilary
  
−
(AUX:) CLI.
  
   
−
Another example is the ACTION_SCREENMODE_MODE packet which can be sent
 +
Another example is the ACTION_SCREENMODE_MODE packet which can be sent to the handler process of a CON: window to put the console into raw or cooked mode.
−
to the handler process of a CON: window to put the console into raw or
  
−
cooked mode.
  
   
  +
By default, CON: provides mapped keyboard input which is filtered, buffered, and automatically echoed. Many of the special key escape sequences (such as those generated by the function, cursor, and help keys) are filtered out; all strokes are buffered and held back from the reader until the user hits the RETURN key; and the nonfiltered keypresses (such
−
By default, CON: provides mapped keyboard input which is filtered,
  
  +
as alphanumeric keys and backspace) are automatically echoed to the CON: window. This "cooked" mode is perfect for general line input from a user because it provides automatic line editing features (same as in the Shell command line).
−
buffered, and automatically echoed. Many of the special key escape
  
−
sequences (such as those generated by the function, cursor, and help keys)
  
−
are filtered out; all strokes are buffered and held back from the reader
  
−
until the user hits the RETURN key; and the nonfiltered keypresses (such
  
−
as alphanumeric keys and backspace) are automatically echoed to the CON:
  
−
window. This "cooked" mode is perfect for general line input from a user
  
−
because it provides automatic line editing features (same as in the Shell
  
−
command line).
  
   
−
Sometimes, however, an application needs to get individual keys
 +
Sometimes, however, an application needs to get individual keys immediately from a CON: window, or control its own echoing, or receive the escape strings that the keymap generates for special keys such as the Help key or cursor keys.
−
immediately from a CON: window, or control its own echoing, or receive the
  
−
escape strings that the keymap generates for special keys such as the Help
  
−
key or cursor keys.
  
   
  +
In this case, an ACTION_SCREEN_MODE packet with the argument DOSTRUE (-1) may be sent to the MsgPort of a CON: window to put the CON: into "raw" mode. In raw mode, a CON: behaves much like a RAW: window. Keyboard console input is not automatically filtered, buffered, or echoed. When reading a CON: which has been set to "raw" mode, each keypress can be read immediately as the ASCII value or string to which the key is mapped by the keymap.
−
In this case, an ACTION_SCREEN_MODE packet with the argument DOSTRUE
  
−
(-1) may be sent to the MsgPort of a CON: window to put the CON: into
  
−
"raw" mode. In raw mode, a CON: behaves much like a RAW: window. Keyboard
  
−
console input is not automatically filtered, buffered, or echoed. When
  
−
reading a CON: which has been set to "raw" mode, each keypress can be read
  
−
immediately as the ASCII value or string to which the key is mapped by the
  
−
keymap.
  
   
−
For some applications, it may be convenient to toggle a CON: window
 +
For some applications, it may be convenient to toggle a CON: window between cooked and raw modes, to use cooked mode for use line input, and raw mode when keypresses should cause immediate actions.
−
between cooked and raw modes, to use cooked mode for use line input, and
  
−
raw mode when keypresses should cause immediate actions.
  
   
−
ACTION_SCREEN_MODE with the argument DOSFALSE (0L) will place a CON:
 +
ACTION_SCREEN_MODE with the argument DOSFALSE (0L) will place a CON: window in cooked mode. Note that the ACTION_SCREEN_MODE packet may also be used on auxiliary (AUX:) consoles.
−
window in cooked mode. Note that the ACTION_SCREEN_MODE packet may also be
  
−
used on auxilary (AUX:) consoles.
  
   
  +
The handler MsgPort of most named AmigaDOS devices (like DF0:) can be found with the DeviceProc() function. Note that DeviceProc() cannot be used to find a CON: or RAW: handler because there may be many handlers for each of these. The handler MsgPort (ProcessID) of a CON: or RAW: window is in its FileHandle structure (fh_Type). The MsgPort of a CLI process's "*" window is process->pr_ConsoleTask.
−
The handler MsgPort of most named AmigaDOS devices (like DF0:) can be
  
−
found with the DeviceProc() function. Note that DeviceProc() cannot be
  
−
used to find a CON: or RAW: handler because there may be many handlers for
  
−
each of these. The handler MsgPort (ProcessID) of a CON: or RAW: window is
  
−
in its FileHandle structure (fh_Type). The MsgPort of a CLI process's "*"
  
−
window is process->pr_ConsoleTask.
  
   
−
Here's how to find the MsgPort of a handler process (in all cases make
 +
Here's how to find the MsgPort of a handler process (in all cases make sure that port is non-NULL before using it):
−
sure that port is non-NULL before using it):
  
   
 
Finding the MsgPort of a unique named handler process such as "DF0:":
  
Finding the MsgPort of a unique named handler process such as "DF0:":
  +
<syntaxhighlight>
−
<pre>
  
−
port = (struct MsgPort *) DeviceProc("DF1:");
 +
port = (struct MsgPort *) IDOS->DeviceProc("DF1:");
  +
</syntaxhighlight>
−
</pre>
  
   
 
Finding the MsgPort of the handler process for an open file:
  
Finding the MsgPort of the handler process for an open file:
  +
<syntaxhighlight>
−
<pre>
  
−
fh = Open("CON:0/40/640/140/Test", MODE_NEWFILE);
 +
fh = IDOS->Open("CON:0/40/640/140/Test", MODE_NEWFILE);
 
if ((fh) && (fh->Type))
  
if ((fh) && (fh->Type))
 
{ /* if Open() succeeded and fh_Type is non-NULL */
  
{ /* if Open() succeeded and fh_Type is non-NULL */
Line 400: Line 459:
 
(((struct FileHandle *) (fh << 2))->fh_Type);
  
(((struct FileHandle *) (fh << 2))->fh_Type);
 
}
  
}
  +
</syntaxhighlight>
−
</pre>
  
   
 
Finding the MsgPort of your process's console handler:
  
Finding the MsgPort of your process's console handler:
  +
<syntaxhighlight>
−
<pre>
  
−
struct Task* task = FindTask(NULL);
 +
struct Task* task = IExec->FindTask(NULL);
 
if (task->tc_Node.ln_Type == NT_PROCESS)
  
if (task->tc_Node.ln_Type == NT_PROCESS)
 
{ /* port may be NULL - check before using! */
  
{ /* port may be NULL - check before using! */
 
port = ((struct Process *) task)->pr_ConsoleTask;
  
port = ((struct Process *) task)->pr_ConsoleTask;
 
}
  
}
  +
</syntaxhighlight>
−
</pre>
  
   
−
Packets are sent by initializing a longword-aligned StandardPacket
 +
Packets are sent by initializing a longword-aligned StandardPacket structure and sending the packet to the MsgPort of a handler process.
−
structure and sending the packet to the MsgPort of a handler process.
  
   
−
The dos.library provides new simple functions for sending and
 +
The dos.library provides simple functions for sending and replying to packets:
−
replying to packets:
  
   
  +
{| class="wikitable"
−
SendPkt() - asynchronously send your initialized packet
  
  +
| SendPkt() || asynchronously send your initialized packet
−
WaitPkt() - wait for asynchronous packet to complete
  
  +
|-
−
ReplyPkt() - reply a packet which has been sent to you
  
−
DoPkt() - creates and sends a packet, and waits for completion
 +
| WaitPkt() || wait for asynchronous packet to complete
  +
|-
  +
| ReplyPkt() || reply a packet which has been sent to you
  +
|-
  +
| DoPkt() || creates and sends a packet, and waits for completion
  +
|}

Latest revision as of 19:59, 2 October 2015

Introduction

Packet passing handles all communication performed by AmigaDOS between processes. The function diagram below shows how packets fit in with the other components of the Amiga operating system. 

   +--------------+
   | User Process +-----------------------+
   +-------+------+                       |
           |                              |
           |                              |
    Function Calls                        |
           |                              |
          \|/                             |
 +---------+--------+                     |
 | AmigaDOS Open(), |                     |
 |   Close(), etc.  |                     |
 +---------+--------+                     |
           |                              |
           |                              |
      +-Packets---+--------+     +-----Packets--------+
      |           |        |     |        |           |
     \|/         \|/      \|/   \|/      \|/         \|/
 +----+----+ +----+----+ +-+--+--+-+ +----+----+ +----+----+
 | FFS/OFS | | FFS/OFS | | FFS/OFS | |   CON:  | |   CON:  |
 |   DH0:  | |   DF0:  | |   DF1:  | | Window1 | | Window2 |
 | Handler | | Handler | | Handler | | Handler | | Handler |
 | Process | | Process | | Process | | Process | | Process |
 +----+----+ +-------+-+ +----+----+ +----+----+ +----+----+
      |              |        |           |           |
     \|/            \|/      \|/         \|/         \|/
 +----+--------+  +--+--------+----+ +----+-----------+----+
 |Hddisk.device|  |Trackdisk.device| |    Console.device   |
 +-------------+  +----------------+ +---------------------+

A StandardPacket (defined in <dos/dosextens.h>) is used to send packet commands to a process's MsgPort. The StandardPacket structure contains an Exec Message structure and an AmigaDOS DOSPacket structure: 

    struct StandardPacket
    {   struct Message   sp_Msg;
        struct DOSPacket sp_Pkt;
    };

This structure must be longword-aligned, and initialized to link the Message and DOSPacket sections to each other: 

    packet->sp_Msg.mn_Node.ln_Name = (char *) &(packet->sp_Pkt);
    packet->sp_Pkt.dp_Link         = &(packet->sp_Msg);

Packets must also be initialized with a ReplyPort which is created with AllocSysObject(): 

    if (replyport = (struct MsgPort *) IExec->AllocSysObjectTags(ASOT_PORT, TAG_END))
        packet->sp_Pkt.dp_Port = replyport;

The DOSPacket portion of the StandardPacket structure is used to pass the packet type and arguments, and to receive the results of the packet. The argument types, number of arguments, and results vary for different packet types and are documented with each packet description. A DOSPacket must be longword-aligned and has the following general structure:

Type Name Description
struct Message* dp_Link Pointer back to Exec message structure
struct Message* dp_Port Reply port for the packet. Must be filled in each send
int32 dp_Type Packet type
int32 dp_Res1 For file system calls this is the result that would have been returned by the function; eg. Write("W") returns actual length written.
int32 dp_Res2 For file system calls this is what would have been returned by IoErr()
int32 dp_Arg1 Argument 1 (depends on packet type)
int32 dp_Arg2 Argument 2 (depends on packet type)
int32 dp_Arg3 Argument 3 (depends on packet type)
int32 dp_Arg4 Argument 4 (depends on packet type)
int32 dp_Arg5 Argument 5 (depends on packet type)
int32 dp_Arg6 Argument 6 (depends on packet type)
int32 dp_Arg7 Argument 7 (depends on packet type)

The format of a specific packet depends on its type; but in all cases it contains a back-pointer to the Message structure, the MsgPort for the reply, and two result fields. When AmigaDOS sends a packet, the reply port is overwritten with the process ID of the sender so that the packet can be returned. Thus, when sending a packet to an AmigaDOS handler process, you must fill in the reply MsgPort each time; otherwise when the packet returns, AmigaDOS has overwritten the original port. AmigaDOS maintains all other fields except the result fields.

All AmigaDOS packets are sent to the message port created as part of a process; this message port is initialized so that arriving messages cause signal bit 8 to be set. An AmigaDOS process that is waiting for a message waits for signal 8 to be set. When the process wakes up because this event has occurred, GetMsg() takes the message from the message port and extracts the packet address. If the process is an AmigaDOS handler process, then the packet contains a value in the PktType field that indicates an action to be performed, such as reading some data. The argument fields contain specific information such as the size of the buffer where the characters go.

When the handler process has completed the work required to satisfy this request, the packet returns to the sender, using the same message structure. Both the message structure and the packet structure must be allocated by the client and not deallocated before the reply has been received. Normally AmigaDOS is called by the client to send the packet, such as when a call to Read() is made. However, there are cases where asynchronous I/O is required, and in this case the client may send packets to the handler process as required. The packet and message structures must be allocated, and the process ID field filled in with the message port where this packet must return. A call to PutMsg() then sends the message to the destination. Note that many packets may be sent out, returning to either the same or different message ports.

Packet Types

Packets sent to a file system or handler can be divided into several basic categories:

Basic Input/Output
These actions deal with transferring data to and from objects controlled by the handler.
File/Directory Manipulation/Information
These actions are used to gain access to and manipulate the high level structures of the file system.
Volume Manipulation/Information
These actions allow access to the specific volume controlled by the file system.
Handler Maintenance and Control
These allow control over the handler/file system itself, independent of the actual volume or structure underneath.
Handler Internal
These actions are never sent to the handler directly. Instead they are generally responses to IO requests made by the handler.
Obsolete Packets
These packets are no longer valid for use by handlers/file systems.
Deprecated Packets
These packets are superceded by new ones with updated functionality and file systems/handlers should avoid implementing these packets at all and let dos.library emulate the old and limited functionality.
Console Only Packets
These packets are specific to console handlers.
File Systems can ignore these packets.

Each packet type documented in this section is listed with its action name, its corresponding number, any AmigaDOS routines that use this packet, and the list of parameters that the packet uses. The C variable types for the packet parameters are one of the following types:

Type Description
BPTR This is BCPL pointer (an address which is right shifted by 2). This means that the object must be aligned on a 32 bit address.
BSTR This is a BCPL pointer to a string where the first byte indicates the number of characters in the string. This length byte is unsigned but because it is stored in only 8 bits, the strings are limited to 255 characters in length before V52 of dos.library.

As of V52+ dos.library, "extended BSTR" (XBSTR) strings can be sent to handlers and file systems from dos.library for extensibility reasons, while still maintaining legacy backward compatibility. These extended BSTR strings are in the same format as a legacy BSTR string but are guaranteed to have a null-terminator byte added to the end, and the length byte of these will be correct only up to 255 characters, past that length, the length byte will always read 255 (0xFF) and is there just for limited legacy compatibility. These extended BSTR strings are always documented and identified by having an additional dospacket identifier parameter supplied, consult the individual DOS packet documentation for details.

See also ACTION_INHIBIT_DOS_LONGPATH_HANDLING for details on this DOS packet and how to formally control the use of XBSTR strings.

BOOLEAN A 32-bit boolean value which is either ZERO or NON-ZERO. For implementation purposes, non-zero boolean values should be -1 this is also defined as DOSTRUE. However for compatibility reasons, performing equality comparisons with any value other than zero is absolutely forbidden, only 0 or FALSE may be used in a value comparison test.

See the dos.doc file introduction paragraph for more details on this issue.

RESULT1 A 32 bit primary result code as defined for the function.
RESULT2 A 32 bit error code as defined in the dos/errors.h include file. Handlers should not return error codes besides those defined. For some functions a secondary result can also be returned here upon success.

Summary of Defined Packet Numbers

Summary of defined packet numbers, as of DOS library version 53.71

This is a listing of all the DOS packets defined by Commodore and other relevant authorities since.

Unless otherwise noted, packets 2050-2999 and 8500-8999 are reserved for use by third party developers (see chart below).

All remaining packets are reserved for future OS expansion.

Decimal Hex Action #define Status
0 0x0000 ACTION_NIL or ACTION_STARTUP
1 <Reserved for operating system>
2 0x0002 ACTION_GET_BLOCK Obsolete
3 <Reserved for operating system>
4 0x0004 ACTION_SET_MAP Obsolete
5 0x0005 ACTION_DIE Deprecated
6 0x0006 ACTION_EVENT Obsolete
7 0x0007 ACTION_CURRENT_VOLUME Obsolete
8 0x0008 ACTION_LOCATE_OBJECT
9 0x0009 ACTION_RENAME_DISK
10-14 <Reserved for operating system>
15 0x000F ACTION_FREE_LOCK
16 0x0010 ACTION_DELETE_OBJECT
17 0x0011 ACTION_RENAME_OBJECT
18 0x0012 ACTION_MORE_CACHE Deprecated
19 0x0013 ACTION_COPY_DIR or ACTION_COPY_LOCK
20 0x0014 ACTION_WAIT_CHAR
21 0x0015 ACTION_SET_PROTECT
22 0x0016 ACTION_CREATE_DIR
23 0x0017 ACTION_EXAMINE_OBJECT Deprecated
24 0x0018 ACTION_EXAMINE_NEXT Deprecated
25 0x0019 ACTION_DISK_INFO
26 0x001A ACTION_INFO
27 0x001B ACTION_FLUSH
28 0x001C ACTION_SET_COMMENT
29 0x001D ACTION_PARENT
30 0x001E ACTION_TIMER Internal
31 0x001F ACTION_INHIBIT
32 0x0020 ACTION_DISK_TYPE Obsolete
33 0x0021 ACTION_DISK_CHANGE Obsolete
34 0x0022 ACTION_SET_DATE
35-39 <Reserved for operating system>
40 0x0028 ACTION_SAME_LOCK
41-52 <Reserved for operating system>
53 0x0035 ACTION_SAME_FH
54-81 <Reserved for operating system>
82 0x0052 ACTION_READ
83-86 <Reserved for operating system>
87 0x0057 ACTION_WRITE
88-993 <Reserved for operating system>
994 0x03E2 ACTION_SCREEN_MODE or ACTION_SINGLE_CHARACTER_MODE
995 0x03E3 ACTION_CHANGE_SIGNAL
996-1000 <Reserved for operating system>
1001 0x03E9 ACTION_READ_RETURN Internal
1002 0x03EA ACTION_WRITE_RETURN Internal
1003 0x03EB ACTION_INT_WRITE_RETURN Internal
1004 0x03EC ACTION_FINDUPDATE (MODE_READWRITE)
1005 0x03ED ACTION_FINDINPUT (MODE_OLDFILE)
1006 0x03EE ACTION_FINDOUTPUT (MODE_NEWFILE)
1007 0x03EF ACTION_END
1008 0x03F0 ACTION_SEEK Deprecated
1009 0x03F1 ACTION_ICONIFY Internal
1010-1019 <Reserved for operating system>
1020 0x03FC ACTION_FORMAT
1021 0x03FD ACTION_MAKE_LINK
1022 0x03FE ACTION_SET_FILE_SIZE Deprecated
1023 0x03FF ACTION_WRITE_PROTECT
1024 0x0400 ACTION_READ_LINK
1025 <Reserved for operating system>
1026 0x0402 ACTION_FH_FROM_LOCK
1027 0x0403 ACTION_IS_FILESYSTEM
1028 0x0404 ACTION_CHANGE_MODE
1029 <Reserved for operating system>
1030 0x0406 ACTION_COPY_DIR_FH
1031 0x0407 ACTION_PARENT_FH
1032 <Reserved for operating system>
1033 0x0409 ACTION_EXAMINE_ALL Deprecated
1034 0x040A ACTION_EXAMINE_FH Deprecated
1035 0x040B ACTION_EXAMINE_ALL_END Deprecated
1036 0x040C ACTION_SET_OWNER Deprecated
1037 0x040D ACTION_SET_OWNER_INFO
1038 <Reserved for operating system>
1039 0x040F ACTION_NEWMEMFILE Internal
1040 0x0410 ACTION_NEWMEMLOCK Internal
1041-1997 <Reserved for operating system>
1998 0x07CE ACTION_WAIT_FOR_DATA
1999 0x07CF ACTION_SET_BLOCKING_MODE
2000-2007 <Reserved for operating system>
2008 0x07D8 ACTION_LOCK_RECORD Optional
2009 0x07D9 ACTION_FREE_RECORD Optional
2010-2049 <Reserved for operating system>
2050-2999 <Reserved for 3rd Party Handlers>
3000 0x0BB8 ACTION_SHUTDOWN
3001 0x0BB9 ACTION_COLLECT
3002-3004 <Reserved for operating system>
3005 0x0BBD ACTION_FILESYSTEM_ATTR
3006 0x0BBE ACTION_OBTAIN_CON_INFO
3007 0x0BBF ACTION_RELEASE_CON_INFO
3008-3029 <Reserved for operating system>
3030 0x0BD6 ACTION_EXAMINEDATA
3031 0x0BD7 ACTION_EXAMINEDATA_FH
3032-3039 <Reserved for operating system>
3040 0x0BE0 ACTION_EXAMINEDATA_DIR
3041-4096 <Reserved for operating system>
4097 0x1001 ACTION_ADD_NOTIFY Optional
4098 0x1002 ACTION_REMOVE_NOTIFY Optional
4099-4199 <Reserved for operating system>
4200 0x1068 ACTION_SERIALIZE_DISK
4201 0x1069 ACTION_GET_DISK_FSSM
4202 0x106A ACTION_FREE_DISK_FSSM
4203-5322 <Reserved for operating system>
5323 0x14CB ACTION_INHIBIT_DOS_LONGPATH_HANDLING
5324-8000 <Reserved for operating system>
8001 0x1F41 ACTION_CHANGE_FILE_POSITION64
8002 0x1F42 ACTION_GET_FILE_POSITION64
8003 0x1F43 ACTION_CHANGE_FILE_SIZE64
8004 0x1F44 ACTION_GET_FILE_SIZE64
8005-8499 <Reserved for operating system 64 bit functions>
8500-8999 <Reserved for use by 3rd Party Handlers for 64 bit functions>
9000-... <Reserved for operating system>

Detailed DOS Packet Documentation

See the dos.dospackets.doc autodoc for all the detailed information regarding each DOS packet.

Using Packets Directly

AmigaDOS contains many features that can only be accessed by sending a packet directly to a process. For example, the ACTION_DISK_INFO packet may be used to find the Intuition window pointer of a CON: or RAW: window. This is useful for redirecting system requesters so that they appear where the user can see them (see "Redirecting System Requesters" above). The Window pointer will be returned in the ID_VolumeNode field, and a pointer to the console's I/O request will be returned in the ID_InUse field. Note that auxiliary consoles (AUX:) can return a NULL Window pointer, and also may have no ConUnit (io_Unit) associated with their I/O request block. Be careful to check for these possibilities when you use this packet. If your application runs in a CLI window, a user may be running you in an auxiliary (AUX:) CLI.

Another example is the ACTION_SCREENMODE_MODE packet which can be sent to the handler process of a CON: window to put the console into raw or cooked mode.

By default, CON: provides mapped keyboard input which is filtered, buffered, and automatically echoed. Many of the special key escape sequences (such as those generated by the function, cursor, and help keys) are filtered out; all strokes are buffered and held back from the reader until the user hits the RETURN key; and the nonfiltered keypresses (such as alphanumeric keys and backspace) are automatically echoed to the CON: window. This "cooked" mode is perfect for general line input from a user because it provides automatic line editing features (same as in the Shell command line).

Sometimes, however, an application needs to get individual keys immediately from a CON: window, or control its own echoing, or receive the escape strings that the keymap generates for special keys such as the Help key or cursor keys.

In this case, an ACTION_SCREEN_MODE packet with the argument DOSTRUE (-1) may be sent to the MsgPort of a CON: window to put the CON: into "raw" mode. In raw mode, a CON: behaves much like a RAW: window. Keyboard console input is not automatically filtered, buffered, or echoed. When reading a CON: which has been set to "raw" mode, each keypress can be read immediately as the ASCII value or string to which the key is mapped by the keymap.

For some applications, it may be convenient to toggle a CON: window between cooked and raw modes, to use cooked mode for use line input, and raw mode when keypresses should cause immediate actions.

ACTION_SCREEN_MODE with the argument DOSFALSE (0L) will place a CON: window in cooked mode. Note that the ACTION_SCREEN_MODE packet may also be used on auxiliary (AUX:) consoles.

The handler MsgPort of most named AmigaDOS devices (like DF0:) can be found with the DeviceProc() function. Note that DeviceProc() cannot be used to find a CON: or RAW: handler because there may be many handlers for each of these. The handler MsgPort (ProcessID) of a CON: or RAW: window is in its FileHandle structure (fh_Type). The MsgPort of a CLI process's "*" window is process->pr_ConsoleTask.

Here's how to find the MsgPort of a handler process (in all cases make sure that port is non-NULL before using it):

Finding the MsgPort of a unique named handler process such as "DF0:": 

    port = (struct MsgPort *) IDOS->DeviceProc("DF1:");

Finding the MsgPort of the handler process for an open file: 

    fh = IDOS->Open("CON:0/40/640/140/Test", MODE_NEWFILE);
    if ((fh) && (fh->Type))
    {   /* if Open() succeeded and fh_Type is non-NULL */
        port = (struct MsgPort *)
               (((struct FileHandle *) (fh << 2))->fh_Type);
    }

Finding the MsgPort of your process's console handler: 

    struct Task* task = IExec->FindTask(NULL);
    if (task->tc_Node.ln_Type == NT_PROCESS)
    {   /* port may be NULL - check before using! */
        port = ((struct Process *) task)->pr_ConsoleTask;
    }

Packets are sent by initializing a longword-aligned StandardPacket structure and sending the packet to the MsgPort of a handler process.

The dos.library provides simple functions for sending and replying to packets:

SendPkt() asynchronously send your initialized packet
WaitPkt() wait for asynchronous packet to complete
ReplyPkt() reply a packet which has been sent to you
DoPkt() creates and sends a packet, and waits for completion
Retrieved from "http://wiki.amigaos.net/w/index.php?title=AmigaDOS_Packets&oldid=8184"