mart@euteal.UUCP (Mart van Stiphout) (01/24/89)
I have just installed X11.3 on my Apollo DN3000 workstation.
At the moment I'm still working under SR9.7.
Guess what, it doesn't work. So now I have two questions:
1. the problem seems to be that the server cannot find the fonts
(in particular it complains about the cursor and fixed fonts).
I've checked the configuration several times but I
cannot locate the problem. What is the trouble???
2. I found a Pascal file in directory server/ddx/apollo/apc :
`apcfont.pas'. (Why a Pascal source file when all the rest of
the stuff in written in C??). The corresponding apcfont.bin
file is delivered also, in a tar archive. How very peculiar:
the first thing make does is extracting this bin file from
the archive instead of compiling it.
Who has an explanation for all this?
Thanks for your help.
Mart van Stiphout
Eindhoven University of Technology
Dep. of Electr. Engineering
Design Automation Section
Email: mart@euteal.eutrc3.hp4nl.mcvax.uucprterek@shrike.Sun.COM (Robert Terek [Contractor]) (01/26/89)
In article <13@euteal.UUCP> mart@euteal.UUCP (Mart van Stiphout) writes: > > I have just installed X11.3 on my Apollo DN3000 workstation. > At the moment I'm still working under SR9.7. > Guess what, it doesn't work. So now I have two questions: . . . . > 2. I found a Pascal file in directory server/ddx/apollo/apc : > `apcfont.pas'. (Why a Pascal source file when all the rest of > the stuff in written in C??). The corresponding apcfont.bin > file is delivered also, in a tar archive. How very peculiar: > the first thing make does is extracting this bin file from > the archive instead of compiling it. > Who has an explanation for all this? A few comments: - It is Pascal rather than C because that is the language Apollo used for most of its system software. This particular file was not written solely for X - it was written before X was around, and contains internal routines of a graphics library (GPR perhaps, not sure anymore). Note the original coding date of 1981. Xapollo coverts snf fonts to gpr format fonts, then uses gpr to display them, so the implementor chose to "borrow" the gpr internal routines. This was done for R2, possibly due to time constraints. Maybe it's time to rewrite in C. - Since the Pascal compiler is optional software, it was decided that the binary should be included so that those without the compiler could still build X11. Source is provided for those who need it, eg., if one is running SR10 he/she should alter the Makefile to compile the file, since the binary provided is a 9.7 one. - The reason it is in a tar file is to preserve the Apollo specific file "type". MIT does the distribution of R3, and uses a non-Apollo machine to store source and cut tapes. If apcfont.bin was simply given to MIT to include on the tape, the process of putting it onto the non-Apollo machine, cutting a tar tape from that machine, then extracting it onto an Apollo machine would cause the file to lose header info indicating that it was an object. Hence, apcfont.bin was put into a tar archive at Apollo, which would preserve the file "type", and a strange looking target was put into the Makefile. As far as your difficulties in geting the server to come up, you'll have to provide more details, me thinks. The fonts should all be located in the directory indicated in server/include/site.h, as long as they match I can't think of a reason why the server could not find a font. -Bob Disclaimer: I *am* just a contractor.
mark@bruce.oz (Mark Goodwin) (02/06/89)
From article <13@euteal.UUCP>, by mart@euteal.UUCP (Mart van Stiphout): > > I have just installed X11.3 on my Apollo DN3000 workstation. > At the moment I'm still working under SR9.7. > Guess what, it doesn't work. So now I have two questions: What a surprise! A major problem is making the makefiles. Imake uses cpp and DOMAIN/IX cpp misbehaves (of course). Seems that once you have all the makefiles, the problem is a client/server communication problem. Start a client and it hangs waiting for the Xapollo server (which is sleeping in the background). Has anyone managed to get this beast working under SR9.7 yet ? Mark.
richb@sunchat.UUCP (Rich Burridge) (02/08/89)
Please send replies to Mark at the address below, or to the xpert mailing list /comp.windows.x newsgroup. ----- Begin Included Message ----- From: mark@bruce.oz (Mark Goodwin) Newsgroups: comp.sys.apollo,comp.windows.x Subject: Re: X11.3 question on Apollo DN3000. Message-Id: <691@bruce.oz> Date: 6 Feb 89 05:08:14 GMT References: <13@euteal.UUCP> Organization: Comp Sci, Monash Uni, Australia >From article <13@euteal.UUCP>, by mart@euteal.UUCP (Mart van Stiphout): > > I have just installed X11.3 on my Apollo DN3000 workstation. > At the moment I'm still working under SR9.7. > Guess what, it doesn't work. So now I have two questions: What a surprise! A major problem is making the makefiles. Imake uses cpp and DOMAIN/IX cpp misbehaves (of course). Seems that once you have all the makefiles, the problem is a client/server communication problem. Start a client and it hangs waiting for the Xapollo server (which is sleeping in the background). Has anyone managed to get this beast working under SR9.7 yet ? Mark. ----- End Included Message -----
keith@EXPO.LCS.MIT.EDU (Keith Packard) (02/14/89)
The DOMAIN/IX C Compiler under rev 9.7 has some serious bugs, which the server (naturally) exposes. You'll need to either get the fixed compiler from Apollo (which they used to have) or upgrade to 10.1. Keith Packard MIT X Consortium (617) 253-1428 keith@EXPO.LCS.MIT.EDU
rbj@NAV.ICST.NBS.GOV (Root Boy Jim) (03/02/89)
Awhile back... ? From: shrike!rterek@sun.com (Robert Terek [Contractor]) ? Organization: Sun Microsystems, Mountain View ...sez ? A few comments: ? - It is Pascal rather than C because that is the language Apollo ? used for most of its system software. ...and later... ? - Since the Pascal compiler is optional software, I hope Sun doesn't get similar ideas about unbundling the C compiler :-) :-( ? -Bob ? Disclaimer: I *am* just a contractor. And I'm just a protractor. Nilbert T Bignum <rbj@nav.icst.nbs.gov> NTSI: Never Twice the Same Institute