forrest@ux1.lbl.gov (Jon Forrest) (12/21/88)
(Before I start I want to make it clear that nothing I say is meant to deride what Beebe has done. This is intended strictly as constructive critisism.) I've been playing around trying to get Beebe's drivers working using Turbo C 2.0. I'm doing this before I start doing what I really have in mind, which is doing a Hercules driver using Beebe's software. While playing around I soon learned that Beebe uses "#include" statements extensively - so extensively that all files needed to make a driver are seen by the compiler as a result of "#include"s. In other works to make a driver for the Apple laserwriter you say (more or less) TCC DVIALW.C and that's all even though 20 or 30 files have to be compiled to make the driver. When I first saw this I wondered why separate object files weren't created for each source file needed by the driver. Beebe's approach reminded me of Turbo Pascal and some other old Pascal compilers which didn't permit separate compilation. My objection to this approach was that it made developing new drivers a very slow process on old slow XTs, which is what I happen to own. At first I didn't understand the explaination in Beebe's manual but Beebe kindly explained it to me. The reason for this is that various #define's and #ifdefs are used each time a driver is built. This means that the object code generated when a file is compiled for one driver may not be the same when the same file is compiled for another driver. This means that object files can only be used, in the worst case, for building one driver. I thought about this for a while and then came up with the following suggestion for a solution. My solution involves mainly changes to makefiles, along with the modifications of the source code to remove the "#include"s that become superfluous if my idea is implemented. Also added is the requirement that a directory be created for each driver being built. First of all, divide all the files into two groups, those that contain driver-specific dependencies, and those that don't. Then, modify the makefile so that the object files produced when compiling driver-specific files are put in the driver-specific directory. (Systems that support "make" access to object libraries should use object libraries). Also modify the makefile so that the proper files in the proper directory are used in the linking step. The makefile would of course have to be modified to show the proper dependencies. After a driver has been created the first time, remaking the driver will go much faster because only files that have changed since the driver was last built have to be compiled. Then, if an additional driver is to be built, only the driver-specific files have to be compiled. All the driver-independent files will already have been built. There are several minor disadvantages with this approach. The first is that linking might take longer because there will be more files to be linked. If object libraries are used this shouldn't be much of a problem. The seconds is that more diskspace would be required than in the current method. The actual amount of extra space would depend on the number and size of driver-dependent files. Maybe if I owned a faster PC I wouldn't think this was so important. As things stand, however, I'd have to think hard before starting on any driver development projects because the thought of all that extra compilation time is hard to stomach. Am I being too picky? Is this a good idea? Am I overlooking anything? Jon Forrest Lawrence Berkeley Lab., 486-4991 forrest@lbl.gov (internet) ucbvax!lbl-csam!ux1!forrest (uucp) FORREST@LBL (bitnet)
wilker@batcomputer.tn.cornell.edu (Clarence W. Wilkerson Jr.) (12/21/88)
I am a fan of the Beebe drivers, but have to admit that I stripped out the stuff irrelevant to my interests. I had the following problems with Turbo C and the Beebe drivers: They compiled fine with 1.5 and 2.0 but would not run without crashing. Here most of my experience is with DVIJEP.C. I tracked down to problems to about 4 areas 1) One routine, related to skipping specials in .pk format font files looked for a magic byte to find the end of the file. There was an off by one error somewhere so that the ungetc used always returned EOF, which got reported as a bad byte in the .pk file. 2) The floating point constants in the table to compute magnifications are written with lots of precision, which Turbo C swallowed, except that both Turbo C 1.5 and 2.0 will report 1.5000000000000000 ( lots of trailing zeros') as 1.25, whereas 1.50 is scanned correctly. 3) Finally, one of the rountines (PRNTPAGE??) has lots of local data and eats up the stack space I ended up setting the stack to 12000 bytes instead of the default 2048. It did not seem sufficient to put "_stklen=12000;". I had to redefine MINSTACK in C0.ASM and remake C0C.OBJ. 4) The font caching defines had to be redone for Turbo C versus MSC, but afterwards, seemed to make little difference anyway. Clarence Wilkerson (wilker@msb.cc.rochester.edu)