how do I tell the size of a pseudoterm window?

[Michael "Ford" Ditto]

In a previous article <5444 at cbmvax.UUCP> I wrote:
>Do you think that a windowing system running on SysVr3 should support
>the layers/xt ioctl for window size?  (I don't mean whether it should
>allow such a function, just whether it should use the same ioctl
>command code and return the same data structure.)

Everyone responding seems to think that a windowing system should
support the layers ioctl (JWINSIZE).  From a practical standpoint, I
agree, but there are a few counter aguments that I will throw out at
the world...

For example, what about the dependency this introduces on the existence
of a device driver in the Unix kernel?  If this ioctl is to be the
standard means of inquiring window size, then any conforming windowing
system *must* have a special device driver installed on the *client*
system.

What about a windowing system which communicates with its clients with
"in band" data, using escape sequences in both directions?  Such a
system has several disadvantages, but it is also appealing for many
reasons, such as its usefulness over a "plain" tty connection or a
long stream of virtual connections (like telnet, dataswitches, etc.).
It could not support an ioctl of any kind.

Also, the idea of display LINES & COLUMNS is not specific to "windowing
systems" -- "/dev/console" on the Amiga, for example, is just a plain
ANSI text-only terminal, but it might be 80x25, 80x32, 80x50, or 128x100,
depending on what kind of monitor and video format are being used, and
other factors.  I would like to use the same method of inquiring about
screen size with this device as with the windowing system.  Why should
this depend on an ioctl command defined in a header file for a windowing
system?

In article <9091 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>The really interesting question is, what should sort-of-UNIX-portable
>source code do to cope with the three major (and several minor) variations
>on this theme?  It's made worse by the inability to test for the presence
>of header files such as <sys/jioctl.h>.

This is more what I was getting at.  My complaint is mostly about the
idea that one particular implementation be used as a "standard".  Kind
of like the way Unix system calls are a "standard" way to access files
even on non-Unix systems; almost every C compiler for PC OSes provides
emulation for open(), read(), etc., even though there was an
OS-independent access method documented with almost every Unix system
ever distributed.

How about a library function to inquire about screen size?  Obviously
it should be automatically called by curses/terminfo libraries, but
in also needs to be available directly.  This function would be
implemented differently on various systems, hiding the specifics in
a library that a portable program could use.  The task of window-size-
change notification should also be handled.

I suppose this is somewhat of a moot point, since even if I wrote
this function in the next hour and posted it, it wouldn't become a
standard.  If submitted to a standards organization, it wouldn't
go anywhere for a few years, and in the mean time all the software
would have been using JWINSIZE and that would have become the
standard.  :-)

Oh well, maybe I'll feel better now that I've mumbled and complained
a bit.  Comments, opinions, flames welcome.
-- 
					-=] Ford [=-

"The number of Unix installations	(In Real Life:  Mike Ditto)
has grown to 10, with more expected."	ford at kenobi.cts.com
- The Unix Programmer's Manual,		...!sdcsvax!crash!elgar!ford
  2nd Edition, June, 1972.		ditto at cbmvax.commodore.com