[Thomas Richter]

Originally Posted by dissident

What about the entries "pointer to the message reply port" and "length of the message structure"?

Not needed. Tripos aka dos.library does not use the reply port, but replies to Pkt->dp_Port. It neither uses the lengh, but expects always a standard packet pointed to by mn_Node.ln_Name.

Originally Posted by dissident

Only the entries "sp_link"," dp_port" and "dp_type" of the packet structure are initialized.

That is correct. sp_link points to the message, dp_Port to the port it should be replied to, and dp_Type is the type of the packet. Also, dp_Args needs to be initialized by additional arguments, i.e. the direction into which to switch.

Originally Posted by dissident

And what does this line below mean?

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

The pointer to the node name points to the message structure in the standard packet structure and this is a string

It means, "put the address of the standard packet into mn_Node.ln_Name, do not worry about it being not a string.


Well, this is the beauty of Tripos: It was an operating system of its own, and all what happend when "Caos" did not become ready was that our friendly developers used an enourmous amount of hot-glue, duct-tape and chewing gum to fit the Tripos core - which we nowadays call the dos.library - on top of the already existing multitasking core, which we call the exec.library. What you see here is exactly this type of "hot glue":


Message passing requires messages, but Tripos does not use messages. It uses packets. So the message is used to transport the packet as exec uses the latter, but tripos depends on the former. There is no pointer to in an exec message to point to the message, so Tripos hijacks the name pointer, which is then not a name at all.


Also, the handler you send the packet to - here the console - was part of tripos, and it did not use the exec message at all. Instead, Tripos has its own way of replying messages, namely to use pkt->dp_Port as reply port, and "PutMsg" the packet back there. mn_ReplyPort is not used at all. Junk, I know, but this is another layer of hotglue, ducktape... you name it.

Originally Posted by dissident

The only thing I've understood is how to get the pointer to the message port of the CON device. There are two ways:


One way is via the input-handle like Thomas told me:

  CALLDOS Input
  move.l  d0,input_handle(a3) ;Save handle
  beq     input_handle_error ;If NULL -> skip
  move.l  d0,a0              ;BPTR
  add.l   a0,a0              ;*4 = CPTR
  add.l   a0,a0
  move.l  fh_type(a0),d0     ;Get Message-Port for PutMsg()
  beq     port_error         ;If NULL -> skip
  move.l  d0,a4              ;Get pointer to Message-Port structure

Or the second way via the Process structure directly:

  sub.l   a1,a1               ;NULL = Search for own Task
  CALLEXEC FindTask           ;Get pointer to own Task-structure/Process structure
  tst.l   d0                  
  beq     no_task_found       ;If NULL -> skip
  move.l  d0,a0               ;Get pointer to Task/Process
  move.b  LN_TYPE(a0),d0      ;Get type
  cmp.b   #NT_PROCESS,d0      ;DOS process ?
  bne     no_dos_process      ;No -> skip
  move.l  pr_ConsoleTask(a0),a4 ;Get pointer to message port structure

Be warned, these two are not identical! The Input() file handle is where the input of the program is coming from. That is, it can be changed by the shell via input redirection. "<ram:foo" makes it come from "ram:foo". pr_ConsoleTask is always the handler that is responsible for "*", that is, the current console. It is not changed by input redirection. The 3.9 and 3.1.4 shells allow its change by means of the "*>ram:foo" redirection, read as "the console (*) goes to ram:foo". Its closest equivalent is "stderr" in the *ix world (though, confusingly, we also have pr_CES = error output in 3.1, which is - however - not be used before Os 3.2).

Originally Posted by dissident

I understand that a packet structure is combined with a message structure and via PutMsg() sent to the CON device, but how this is done in detail is still a mystery to me. Maybe someone can enlighten me.

This "StandardPacket" is just a convenience structure. They don't have to sit near each other as it is here. The only important thing is that pkt->dp_Link points to the message, pkt->dp_Port back to the reply port where the handler puts the message back to indicate that it is done, and msg->mn_Node.ln_Name points to the packet.


Thus, there are actually two structures, the packet and the message, that are crosswise linked to each other, one over the "dp_Link" pointer, the other by hijacking mn_Node.ln_Name.


As said... layers of hot glue, duct tape and chewing gum.