Path: utzoo!attcan!uunet!cs.utexas.edu!usc!bloom-beacon!EXPO.LCS.MIT.EDU!jim
From: jim@EXPO.LCS.MIT.EDU (Jim Fulton)
Newsgroups: comp.windows.x
Subject: Re: Size of toolkit-using programs?
Message-ID: <8906302107.AA23472@expo.lcs.mit.edu>
Date: 30 Jun 89 21:07:39 GMT
References: <8811@venera.isi.edu>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: X Consortium, MIT Laboratory for Computer Science
Lines: 43


>        xmh             434176          439004           ---
>        xman            418816          410337           ---
>        xterm           431104          423500          188068  **
>        xedit           377856          385514           ---
>

Yes, X11 programs are getting larger, but then they are also beginning to be
useful as well (since you're comparing the V10R2 xterm, I assume that it had
tek mode in it; I can't remember).  It could definitely be smaller, but a fair
bit of that overhead is what gives you the ability to tailor the program to
your environment as well as make it easier to develop and maintain. 

For chuckles let's also add a line for the current xterm on a Sun3 with SunOS
4.0.1 and shared Xlib: 327,680 bytes.  If Xt, Xaw, and Xmu were shared as well,
I'd be even happier (but don't hold your breath, that represents a fair amount
of surgery). 


>        **  BTW, xterm's level of functional complexity is about
>            the same as what I implemented in less than 32K for a custom
>            terminal a decade ago.  That included a small OS kernel.

Gee, vt102, tek4014, multiclick selections, 8bit input and output, string
insertion, resizing, repainting, dynamic scrolling, colors, popup menus,
logging, jump and smooth scroll, all with user-settable bindings in under 32k.



>       Maybe we should all buy stock in companies that manufacture
>       RAM and disks...

Didn't you know that was what all of these consortia are about!  :-)


>                          or take another look at the architecture
>       of multi-layered system software, including Xlib and Xt.

Yes, things have grown (and have even gotten a little fat in places), but
functionality and flexibility don't come for free.  They're part of what
separates hacks from applications (a term which I'm hesitant to apply to any of
the programs in the MIT distribution, although xman, xmh, and xterm are
starting to come close).