🚀 go-pugleaf

]
In] article <3928@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes:
]>In article <3635@ece-csc.UUCP> rss@ece-csc.UUCP (Ralph Scherp) writes:
]>>In a previous article I wrote:
]>>One question:  I looked at the FileHandle structure defined in dosextens.h
]>>and was comparing it with the information in the manual and embedded
]>>in Chuck's routines -- and got the impression that the include file
]>>has a mistake in the structure definition:
]>>
]>>  Are the fields "fh_Type" and "fh_Port" in backwards order in the 
]>>  include file?
]>>
]>
]>No, they are in the correct order in the include files.  The
]>manual is incorrect.
]>
]>Are you aure Chuck's example is looking into a filehandle to find the
]>console.device ?  Rather than getting the console process
]>by a FindTask(0) and using the process pointer to the
]>ConsoleTask, then sending a packet to the console task, and
]>getting a return value ?
]>

Yes, I'm sure.  His code does not enable raw io mode for the console
per se, but rather any level 2 file:

     raw(fp)
       FILE * fp;
and  cooked(fp)

I did a lot of poking around with the various structures I could get access
to; i.e, process structures, filehandles, FILE *, etc. and it became obvious
after awhile that doing raw(stdin) did indeed end up accessing the same
FileHandles ultimately as I got by looking at the fields in the Process
structure.  So this gives you two completely different ways of approaching
the problem.  I like Chuck's method in that in works for any arbitrary
input stream (as if I had fopen'ed CON:xxxx and suddenly wanted that window
switched to RAW mode) -- assuming an interactive input source of course --
rather than my original method of poking at the Process structure, which
only works to switch my initial CLI window.  However, Chuck's method does
have the disadvantage of being compiler specific in that the means of getting
to the console.device from an open "FILE *" is strictly dependent on 
the way your stdio library is put together.

As for the reversed order of things in the include files:  I wrote several
C programs which poked at and/or displayed all the process fields et al and
it still seems to me that the include file is backwards.  The fh_Port field
was normally $FFFFFFFF (-1) which sure looks like the "Interactive" field
to me; whereas the fh_Type field contained a value which was the same
as the FileHandle pointer I obtained by several other methods (such as
"fileno(stdin)", and Process->pr_ConsoleTask.  In my manual the Filehandle
fields are documented as:

    LONG Link		not used
    LONG Interact	boolean, true if interactive
    LONG ProcessID	process ID of handler process
    BPTR Buffer		buffer for internal use
    ...

whereas the include file has:

    struct FileHandle {
       struct Message * fh_Link;
       struct MsgPort * fh_Port;
       struct MsgPort * fh_Type;
       LONG             fh_Buf;
       ...


Now; it seemed strange to me that I have to use fh_Type rather than fh_Port
to get at the console handler.  Even if this usage is correct; but then,
what purpose does fh_Port serve?  And is it really a pointer to a MsgPort
or just a long integer [as the manual claims].  I thought fh_Port was
the interactive flag since it was set to -1; plus it goes to zero if
I redirect input from somewhere else (like NIL:).

      Just curious,

        Mark Lanzo