gjc@mitech.com (06/19/91)
MAC System 7.0 exists, so it is something that programmers will have to seriously deal with. 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. 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. 540 kilobytes. About half the size of Microsoft Word in the Macintosh. It is non-trivial but managable. 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: *** 315 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. Note: This cannot be that far off. At most doubling the size by adding up directly all the sizes. 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). -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).
asente@adobe.com (Paul Asente) (06/21/91)
In article <619@mitech.com> gjc@mitech.com writes: [Many interesting statistics, and one big mistake] >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). The Display PostScript extension *is* a complete PostScript interpreter. You are probably confusing it with the DPS client library, which does provide c-callable subroutines as an interface to the DPS extension. -paul asente asente@adobe.com ...decwrl!adobe!asente Ratz put a bucket of liquid in front of me. "I wanted a glass of docs, Ratz. What the hell is this?" I barked. "Motif don't fit in a glass anymore," he barked back. I looked at the liquid. It was totally opaque to me.
gjc@mitech.com (06/21/91)
In article <16725@adobe.UUCP>, asente@adobe.com (Paul Asente) writes: > The Display PostScript extension *is* a complete PostScript interpreter. You > are probably confusing it with the DPS client library, which does provide > c-callable subroutines as an interface to the DPS extension. OK. That makes me feel a little better about the size of it. (We are both talking about this file, right? SYS$LIBRARY:DECW$SVEXT_ADOBE_DPS_EXTENSION.EXE) Does the DPS client library dynamically generate and send postscript code down the connection to the X server in question? -gjc