Frank Heckenbach wrote:
CBFalconer wrote:
... snip ...
Proper use of the standard mechanism allows almost anything to be attached to the file system with clear semantics. This includes such things as complete screens, LANs, pipes, etc. No need for so-called CRT units, although they may be convenient.
I don't agree here. The Pascal file system only allows for sequential read or write access (ISO 7185), or record-based random access (ISO 10206). A CRT unit does much more than this.
To start with, coordinates are two-dimensional. Of course, you could compute a sequential offset yourself, but this doesn't exactly sound like a high-level language to me.
Just as an example, one of my systems in bygone years did screen updates. The file was defined as a FILE OF RECORD .... where the record included a 24x80 array of char and a "cursorlocation" x y pair. The main program could examine and alter these fields in f^ as it desired, and then execute "put(f)", which did the actual transmission.
There was then no difference in the code running an external terminal on a serial line, and that running a memory mapped display. There was a great difference in the drivers, which were mapped into the actual file system via a set of tables for such things as open, close, put, get, status. The actual operation could be asynchronous, and handled by interrupts in a serial drive, none of which complication was needed in a local memory driver. That meant a difference in throughput to the actual program, but the apparent speed was virtually unaffected.
If significant variations in the end device existed, they could be reported by invariant fields in f^, such as MAXX and MAXY. After a put to the serial device completion could be detected by examining a 'busy' field. Etc. The details are unimportant, the point is that all this can be mapped into the standard Pascal file system.