knudsen@ihwpt.UUCP (05/12/87)
Thinking about why I had worked thru that notorious BASIC09
example (page 9-40, SELECT) a dozen times and never figured
out myself what the error was, I finally found my mental
block. Maybe you'd like to be warned about this.
Hanging around UN*X, OS9, and Pipes leads you to think
that input comes in over here and output goes out over there.
That is, you have StdIn and StdOut and never the twain shall
meet. I would get real nervous contemplating the idea of
reading and writing over the same path--that ain't OS9,
hell it isn't even RS-BASIC! And might not terrible things
happen when the bytes collide in the middle of the buffer?
Won't the buffer get confused? Turns out all these fears
are unfounded, but they kept me from seeing the solution.
These fears also made me wonder about the new
"<>>>" and related redirects in the Level 2 Shell.
Could they really mean what they said?
I recall getting confused in some BASIC09 code about
whether stdin and stdout were really separate, or both on
path #1. I think they are paths #0 and #1, just as in "real"
OS9 programs (C, assembler) and UN*X programs.
However, once you open a device window and SELECT it,
the manual flatly states that "it becomes THE interactive
window." In other words, BOTH input and output (keys and
screen) are thru the same path # you got when OPENing the
window before SELECTing it. This statement must have clued
someone in as to where the program example's errors were.
So that's why it must be OPENed in UPDATE mode.
And why the INPUT or GET or INKEY$ must be done on that
OPENed path#, not on stdin (and why did the example use #1
instead of #0, or is that right?)
So there it is--you can have In and Out thru the
same path # to an SCF device, if OPENed with UPDATE.
Hey, them OS9 buffer managers in SCFMan are pretty smart.
Should work for RS232 and modems too. Good riddance to another
mental block.
--
Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs(AT&T)
Delphi: RAGTIMER CIS: <memory failure, too many digits>
"Just say NO to MS-DOS!"dibble@rochester.ARPA (Peter C. Dibble) (05/12/87)
In article <1671@ihwpt.ATT.COM>, knudsen@ihwpt.ATT.COM (mike knudsen) writes: > Thinking about why I had worked thru that notorious BASIC09 > example (page 9-40, SELECT) a dozen times and never figured > out myself what the error was, I finally found my mental > block. Maybe you'd like to be warned about this. > > Hanging around UN*X, OS9, and Pipes leads you to think > that input comes in over here and output goes out over there. > That is, you have StdIn and StdOut and never the twain shall > meet. I would get real nervous contemplating the idea of The three standard paths are often just three aliases for the same path. A process's path numbers (0 to 15) are actually indexes into a table in the process descriptor. The table stores indexes into the system path table (this makes it clear how calls like dup work). When the system starts it opens the terminal, and dups it twice. All three standard path numbers therefore refer to the same actual path. ((Of course, it isn't healthy to think about this. Input paths go IN, output PATHs go out. Update paths to the terminal are a strange concept.)) Peter