gjc@mitech.com (06/19/91)
MAC System 7.0 exists, so it is something that programmers will have to seriously deal with. (Apple Computer is of course somewhat important in the computer area, even at universities and research institutions). People must not forget a very important thing about X. That the X protocol itself, and especially what is presented at the XLIB level is really not very complicated. It is not a cpu/codesize killer thing to implement. It is not a language interpreter and operating system environment warmed over, like the Postscript/News stuff. And without backing store it is not something that implies the using up of lots of resources to run. It is most definitely a reasonable thing to have a small XLIB implementation available on the MAC-OS. One that would make XLIB level calls, and of course by implication XT and above level stuff available. Before I give the X sizes, I'll give the sizes of some commonly used system programs under SunOS Release 4.1 on a SUN-4 as built by what I beleive is a pretty typical site, Boston University. Kermit: 139 Kbytes. mail: 123 Kbytes bash: 650 Kbytes. xemacs: 1581 Kbytes. Here are some MAC applications sizes: Microsoft Word: 700 Kbytes Powerpoint: 400 Kbytes NCSA Telnet: 200 Kbytes Now for some X sizes. Taken from a VMS 5.4 system. This should be a pretty good predictor of what is possible on a Macintosh. For all I know Apple has already done better than this in terms of efficiency and compactness. Info from VAX/VMS executable and shared executable library sizes. Contains symbol tables and some debug information. XLIB: 278 Kbytes X SERVER COMMON: 335 Kbytes. X SERVER DRIVER-LEVEL: 104 Kbytes. DECTERM COMMON: 150 Kbytes. ADOBE DPS EXTENSION: 513 Kbytes. Now. XLIB here might be aa good deal bigger than it could be, because it includes twice as many procedure calls as required, because DEC put its own optional Fortran/Pascal-Style (essentially) calling sequence stuff in with the regular MIT C Xlib stuff. (A dumb idea, since j-random fortran program might already be using some of the MIT X-ish names for some random purpose). Give me a conservative guess if you will of 200 Kbytes for the true size of XLIB. Look at the size of the Server. 439 kilobytes. How much code of the XLIB level and the Server level is dedicated to encoding operations and events in and out of bytestreams? The last time I looked was in X11 R3, and it was about 50% of what was going on at XLIB level, and 30% of the what you would consider to be the X SERVER COMMON level. Rough guess as to how much code would be involved in a streamlined XLIB<->SERVER combination: *** 426 Kbytes. *** Now, if all of a sudden you needed your XLIB level to connect via TCP outward to some other server, then the bytestream level code would be loaded and activated, and of course if your server wanted to have bytestream capability you would need the extra 111Kbytes of code for that. But this is definitely increased functionality. Compare this with the size of the Display Postscript Extension. At 513 Kbytes it looks giant. Bigger than the entire rest of the X Server code. (And DPS is c-callable subroutines only, *not* a postscript interpreter). Of course, it *might* be considered truly increased functionality *if* the application is really making use of the fancy stuff you can specify in postscript. I think this is unlikely in an interactive program with good user-responsiveness. For final hardcopy generation, that is another thing. -gjc p.s. Running several programs in the same virtual address space with no address-specific checking? No problem for us ex-Lispmachine hacker types. In other words, thats not a bug, thats a feature. (Actually, it can be a real pain in the "implementation area". But the ability to share address space can save a lot of code-size an implementation complexity for some things. It makes it a lot easier to implement a stream-lined and efficient XLIB<->X-SERVER for example).