summaryrefslogtreecommitdiff
path: root/dviware/beebe/doc/01readme.txt
blob: 052f00b3bbfb76e21b742aa43a23bd4650138866 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
	    Changes to the Public Domain DVI Driver Family
				 for
		     IBM PC Microsoft Version 5.0
			     [17-Nov-87]

Version 5.0 of Microsoft C finally arrived 13-Nov-87, and I spent the
weekend revising Make to work with this compiler.  Previously,
because of the use of non-standard library functions, it worked only
with Wizard C (now defunct, but forming the basis of Borland
International's Turbo C).  Unfortunately, it would work only in the
small memory model, which in practice limited it to Makefiles of
about 150 lines or less.  This was very inconvenient for the TeX DVI
driver family, which required 5 separate Makefiles.  The new version
of Make now works correctly with Microsoft C Version 5.0, removes
some serious size limitations of the old one, and introduces several
new features; they are described in a 00README.TXT file in the PCMAKE
directory.

Microsoft C Version 5.0 is now essentially completely conformant with
October 1986 draft ANSI C.  Version 4.0 supported draft ANSI C
function prototypes only with type names, not variable names; Version
5.0 eliminates this.  Version 4.0 did not support const and volatile
type modifiers; 5.0 does.    In Version 4.0, function type checking was
selected by defining the preprocessor variable LINT_ARGS; it is
enabled by default with Version 5.0.  The Version 5.0 library also
conforms to draft ANSI C.

The addition of draft ANSI C library conformance changes the types of
a number of functions and arguments, so type declarations have been
modified in gblprocs.h.  Previously, the DVI drivers had a single
flag, ANSI, which previously selected ANSI function prototype
declarations.  This has now been replaced by two, ANSI_LIBRARY, to
indicate library conformance, and ANSI_PROTOTYPES, to indicate
support for function prototypes.  Variable names are NOT used in
these prototypes, so the code will still compile with Version 4.0.

Version 4.0 supported two interfaces to the compiler, MSC and CL.
MSC was the only one available in Version 3.0, so I continued to use
it.  Version 5.0 drops MSC and provides only CL.  The Makefile has
been revised to reflect this.

A few more missing type casts have been installed in the code.
The number of data conversion warning messages has been drastically
reduced by the discovery that a declaration  "float x = 1.0" always
produces a warning, but "double x = 1.0" does not.  The Makefile has
been revised to define float to be double for all the code.  The
warnings that remain (about 3 in each driver, instead of dozens)
appear to possibly be compiler artifacts.  More experimentation is
still required.

Besides full draft ANSI C conformance, Version 5.0 introduces some
new optimization levels, and in-line expansion of some important
library functions from the strxxx and memxxx classes.  I am happy to
report that these seem to work successfully with the DVI drivers, and
optimization level -Oailt is now the default, instead of -Od (no
optimization).   Despite the in-line expansion, the .EXE files are 3K
to 7K bytes shorter than they were with Version 4.0.

Except for the scanf() bug which affects the -o#:#:# option
(documented in the user manual), it looked like Version 4.0 had no
other bugs which affected the drivers.  However, in October 1987, we
found a bug which can be reproduced by a very simple example: the TeX
file containing just 

$VW$
\bye

prints V and W correctly, while

$WV$
\bye

prints V correctly, but produces a black blob for W.   Some length
sessions with Codeview revealed that in the second case, the call to
fseek() in charpk() to position to the bitmap for W was returning a
success status, but not positioning correctly.  In fact, subsequent
getc() calls returned EOF!  End-of-file is not intentionally not
checked for, because in that code section, it cannot happen (unless
the  compiler or library are in error).   Since EOF has the value -1,
or 0xFFFF, this produced a bitmap with all bits set to one, and a
black blob resulted.  Further experimentation showed that a rewind()
issued at the end of readfont() could remove that error, and should
be otherwise harmless, even if it is correctly unnecessary.
With Version 5.0, the bug is no longer there!

A version of qsort() has been added for texidx.   keytst has been
updated for convenience, and a version of sleep() added to it so that
it can be run under PC DOS.

LINK 3.61 supplied with Microsoft C Version 5.0 supports two new
options, /FARCAL and /PACKCODE, which cause the linker to try to
combine code segments, and replace far calls by near calls, in an
effort to speed up the code.  I have not yet experimented with this.

Stack size for programs on the IBM PC remains a thorny issue.
Experimentation with EXEMOD and DVIALW showed that DVIALW would run
with a stack size of 5000 (hex) or larger, but not 4800 (hex) or
less.  I have reduced stack size in MAKEFILE.MSC to 8000 (hex), and
now set it with a LINK option, instead of having to run EXEMOD
separately.  With the new Make, a new rule for producing the .SYM
file has been introduced, shortening the makefile.

One user has reported having downloaded DVI files and font files from
a host that stored them as fixed blocked binary records, with the
last (short) block null-padded.  The DVIxxx.EXE files as distributed
will not handle this.  However, code is there in readgf.h and
readpxl.h to handle this case under OS_VAXVMS; just change the "#if
OS_VAXVMS" to "#if (OS_PCDOS | OS_VAXVMS)".  I have not done this in
the master distribution, because I regard such incorrect padding as an
operating system defect.  Users who download fonts from Unix or
TOPS-20 systems will not experience such problems.