dpg@caen.engin.umich.edu (David P Gorgen) (11/12/88)
--------
Recently there has been some discussion of problems porting the MIT X.V11R3 tape
to SR10. I'd like to clear up what I see as a general misunderstanding in this
discussion, and a couple of specific misunderstandings related to Apollo
graphics support as well. Although I work for Apollo, I am speaking for myself
in this message, not necessarily for Apollo Computer Inc. (or CITI either).
The MIT X11 server driver code for Apollo was written for SR9.7 and donated to
MIT last spring. Due to the many changes in the Apollo program environment at
SR10, and the size and complexity of the X software, the code does not just
compile and run on SR10 systems right out of the box, as it pretty much does on
SR9.7. I might point out that the MIT X11 code also presents problems for the
compilers and graphics options of at least two other workstation companies with
their recent major software releases, according to discussions on
comp.windows.x. Since the MIT code is not supported by the computer vendors for
whose systems it can be built, none of these situations, though regrettable, are
cause for computer-vendor-bashing.
Some of the vendors in question, including Apollo, are spending their effort on
producing supported product versions of X11 (which may differ materially from
the MIT code in their implementation), so that users do not have to continue
these struggles. To the degree that they spent effort fixing software build or
performance problems with the MIT code instead, they would delay the completion
of the products.
I hasten to add that these problems cannot be blamed on the MIT X Consortium,
either, since they have limited resources and don't have the equipment or
software to test their code on all platforms, for all OS versions. (Also, they
are often powerless to fix or work around compiler bugs.) Of course, they
appreciate contributions of code improvements from others.
I'm not qualified to address the complaints about the SR10 C compiler and its
use of __STDC__. As for the question of the missing "font_$" routines, I can
give some help. The suggestion to get this code from gmrlib was misguided. It
was news to me that these routines were a part of that library; they must be
there for internal reasons. However, gmrlib is intended for 2-D display list
oriented graphics, not raster graphics primitives, and the X server has never
used it and should not do so.
The font routines are internal support for manipulating native Apollo font
files; they were written a long time ago in Pascal. The X server uses these
routines to convert SNF format font files to Apollo format. (This support, by
the way, is only used when the MIT server runs in color on Apollos.) The source
for the routines is on the MIT tape, in "server/ddx/apollo/apc/apcfont.pas".
There is also a copy of the binary "apcfont.bin", wrapped inside a tar file so
it can be copied back and forth among different systems. This was supplied in
case you don't have a Pascal compiler.
The problem is that the apc Makefile always just unwraps the binary file and
uses it, even if you have a Pascal compiler and could compile the source.
Furthermore, since at SR10 the object file format changed from "obj" to "coff",
the old SR9.7 "obj" binary you get from the tar file won't bind in with the rest
of the code in "coff" format. So it gets left out, causing the undefined
"font_$" globals.
If you have an SR10 Pascal compiler, just change the Makefile to compile
apcfont.pas and use the resulting apcfont.bin. If not, there's a converter
program in SR10 which converts "obj" files to "coff" files which you can use on
the binary you extract from the tar file. It's in "/usr/apollo/bin/obj2coff".
As for the complaint that gmrlib has been unbundled, first of all I've just
explained why you don't want to use it for X. Aside from that, here's the
history as I understand it. gmrlib was actually unbundled and made a separate
product at SR9.7 (or SR9.7.1, I'm not sure). However, the old pre-sr9.7 version
was left in /lib as a transition aid. This was all explained in letters to
sales offices and in the SR9.7.1 release notes. Here's a quote from the latter:
Prior to SR9.7, 2DGMR was part of standard software, not a
layered product. This standard version is still supported in
SR9.7 and SR9.7.1 (as version 1.0). At SR10, 2DGMR will be
available as a layered product only.
New functionality has been added to 2DGMR at SR9.7.1. 2DGMR
changes are documented in their own release document
(online). For the standard software version of the 2DGMR
release document, refer to /doc/gmr2d.release_notes
(009917-B01). For the layered product version of 2DGMR,
refer to /gmr2D/doc/gmr2d.release_notes (009917-A02).
So, I don't know whether this was a good decision or not, but it was "announced"
well in advance. I think that it would have been a good idea to make the
announcement much more conspicuous than just a section in the release notes.
The speculation that gprlib was unbundled at SR10 is not true. As has been
pointed out, much software, including the DM, depends on gprlib. To answer an
implied question from one poster, the X11 product will not make gprlib obsolete.
First, the DM will not be abandoned, and second, the X server is layered on
gprlib too. So gprlib is not in any danger of obsolescence.
I hope this clears up some confusion, and helps those trying to build X on SR10.
--------------------------------------------------------------------------------
Dave Gorgen dpg@citi.umich.edu
Apollo Computer Inc.
located at Center for Information Technology Integration, University of Michigankrowitz@RICHTER.MIT.EDU (David Krowitz) (11/14/88)
I beg to differ on the "announcement that gmr would become unbundled". We're running SR9.7 (not 9.7.1) and the SR10 release is the first we've heard of this. What is most upsetting that that the GMR library, not just the insert files, has been removed. This means that we can't run executable programs which have already been developed without paying a ransom fee to Apollo. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)