friday, 1 june 2007

posted at 17:16
tags:

Quick notes, as I'm nearly home. Open() handles a few "magical" filenames: NIL:, PROGDIR:, CONSOLE: and *. The last two are identical, and should return a handle on the console that the program is running from, regardless of whether or not standard input or output have been redirected. The Guru Book calls it the error channel, but of course it should be valid for input too.

Under AmigaOS, this was (probably) implemented by calling GetConsoleTask() (which grabs a struct MsgPort * from pr_ConsoleTask in the process context) and sending an approriate ACTION_FIND* packet to it to get a handle. Every console has a seperate task, so a single pointer is all thats required.

Under AROS, each console has a seperate task, but due to the fact that IOFS handlers are actually devices and so have a single global entry point, you need two pointers - one for the device pointer to console.handler, and the other for the unit pointer that represents the individual console task. Obviously two pointers can't be stored in pr_ConsoleTask, so AROS introduces a new handle pr_CES that complements the input and output handles pr_CIS and pr_COS, and two new functions Error() and SelectError() to complement Input()/SelectInput() and Output()/SelectOutput().

This arrangement works well enough but still sucks - any time you have to add a new field to a struct it sucks. Of course, this is no different to the myriad other places that this has been done in DOS to support IOFS over packets. There are a few broken bits though: Opening CONSOLE: or * for input will always use pr_CIS (ie standard input), regardless of whether or not its been redirected. Opening for output will always use pr_COS if you open CONSOLE: (same issue), but curiously will use pr_CES for *, falling back to pr_COS if its undefined.

There's also some AROS-specific magical names: STDIN:, STDOUT: and STDERR:, and their short forms IN:, OUT: and ERR:. As far as I can see they're only used by clib to provide Unix-style /dev/stdxxx compatibility. Its redundant though - we have Input() and Output() for exactly this purpose.

Further, Lock() also knows about CONSOLE: and * (but not PROGDIR: or NIL:) and about STD*:, when it shouldn't - Guru Book says these names are only magical for Open(), noone else (except GetDeviceProc() which knows about PROGDIR:).

Oh, and AROS has a real nil.handler to support NIL: (a bitbucket handle), rather than just swallowing data internally.

Thats all. My intention is to fix all this, though I don't know what order it'll happen in. I'm more just noting it in passing while I work on removing DoName().