Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!ukma!rutgers!cbmvax!ditto From: ditto@cbmvax.UUCP (Michael "Ford" Ditto) Newsgroups: comp.unix.wizards Subject: Re: how do I tell the size of a pseudoterm window? Summary: But why should "jioctl" be the standard? Keywords: window standards layers xt Message-ID: <5463@cbmvax.UUCP> Date: 8 Dec 88 23:29:26 GMT References: <2081@vedge.UUCP> <6766@spool.cs.wisc.edu> <9042@smoke.BRL.MIL> <5444@cbmvax.UUCP> <9091@smoke.BRL.MIL> Reply-To: ditto@cbmvax.UUCP (Michael "Ford" Ditto) Organization: Commodore Technology, West Chester, PA Lines: 70 In a previous article <5444@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@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) 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 . 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@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!elgar!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com