summaryrefslogtreecommitdiff
path: root/dviware/beebe/updates/00mail.15
blob: 3517af3a16f33a0eaa77d6e93d464c1638c24120 (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
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
 9-Dec-87 18:05:25-MST,8641;000000000000
Mail-From: BEEBE created at  9-Dec-87 18:05:21
Date: Wed 9 Dec 87 18:05:21-MST
From: "Nelson H.F. Beebe" <Beebe@SCIENCE.UTAH.EDU>
Subject: DVI driver family update #15
To: "DVI mailing list": ;
cc: beebe@SCIENCE.UTAH.EDU
X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112"
X-Telephone: (801) 581-5254
Message-ID: <12357217912.28.BEEBE@SCIENCE.UTAH.EDU>

                  DVI Driver Family Update #15
                           [09-Dec-87]

This newsletter will be fairly short.  Its primary purpose is to
report some experience with Microsoft C Version 5.0 on the IBM PC,
and provide a fix for a bug uncovered in PCMAKE.

In PCMAKE, in file execute.c, there is an off-by-one error in one
call to strncat().  The argument param should be replaced by
&param[1]; elsewhere in the code, param[0] was set to the string
length, this apparently being required by the Wizard C library
routines that were called.  When I made this fix, I also
installed a check for command line truncation and trimming of
unnecessary leading whitespace.  Here is a difference listing: (<
marks original; > marks new):

130c130,135
<                 return(system(str));
---
>       {
>           if (strlen(str) > 128)
>               fprintf(stderr,
>               "?MAKE -- command line exceeds DOS limit of 128 characters\n");
>           return(system(str));
>       }
228a234
>       char *p;
233c239,245
<       VOID strncat(str,param,MAXCMD);
---
>       p = &param[1];          /* param[0] has string length */
>       while ((*p == ' ') || (*p == '\t'))
>               ++p;            /* discard leading whitespace */
>       VOID strncat(str,p,MAXCMD);
>       if ((strlen(cmd) + 1 + strlen(p)) > MAXCMD)
>           fprintf(stderr,
>           "?MAKE -- command line truncated at DOS limit of 128 characters\n");

It is my intention to implement the new features of PCMAKE in the
multi-O/S version, PDMAKE, and then abandon PCMAKE.  In order to
do this, it has been necessary to implement versions of the Unix
environment area support routines, getenv() and putenv(), for all
the systems supported by PDMAKE.  That work is complete for all
but two of the operating systems, neither of which I have
available for testing.  However, my project backlog is large,
with several commitments months overdue, so further work on
PDMAKE will likely be delayed until spring.  We have initiated an
effort to acquire a supercomputer at the University of Utah, and
I am a member of the committee charged with the task, so that too
will seriously impact the time I can spend on programming
projects.

The remainding text is stored as file 01README.TXT in DVI
distributions after 18-Nov-87.

            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.
-------