Re: 16-bit versions of gnuplot doomed?

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>Hello, all,
>
>I've got round to trying to build 16-bit binaries of gnuplot for DOS and
>Windows and the news, so far, is bad.
>
>Win16 (i.e. good old Windows 3.1 and Windows for Workgroups 3.11) kills
>itself directly on startup.  I may be blowing the stack or something ---
>investigating that is a nightmare without at least a Win9x machine.
>
>DOS-16bit works, sort of.  But that's after I disabled most of the bit
>optional features (filled boxes, PM3D) *and* removed pretty much all
>terminal drivers besides dospc (the interactive graphics driver), table
>and cgm.  Yes, that does mean I had to throw out post.trm ;-( The reason
>post.trm had to go is the PS_header[] string array.  This is simply too
>large, and the way it's constructed (array of many short strings) means
>that Borland's compiler, which is otherwise quite clever at squeezing a
>lot of code into those 640KB, fails to move the bulk of it into a separate
>segment.  As is, term.obj with post.trm in it costs 26000 of the total of
>64 precious kilobytes of "dgroup".  I won't give up on this quite yet,
>though.
>
>The other major challenge is graphics.c, and it affects both 16-bit
>platforms: that module is plain and simply too large.  BCC chokes already
>on compiling that source file because it contains more than 64KB of code.  
>Maybe I'm overlooking some optimization (the 32-bit graphics.o on Linux
>has only 52KB...), but for the time being, I decided to tentatively split
>graphics.c into two files: I copied all the "steps" plotting style handler
>(plot_{f,hi,}steps) and their helper functions to a separate source file
>and #ifdef'ed out their implementations in graphics.c.  The new files
>steps2d.[ch] currently contain copies of the relevant parts of
>graphics.[ch], but those may be replaced by #include'ing graphics.c if I
>put even more #ifdef's into the latter.
>
>I will leave the CVS version free of these complications for now, until
>the following question is settled: Is support for 16-bit machines (think:
>old lab PCs, "poor pupils", under-developed countries...) important enough
>to warrant changes as deep as these before the release?
>
>I'll hands-up poll of any users of the 16-bit versions to the newsgroup to
>get some additional feedback.
>

I think "graphics.c" is the file I argued should be restructured because 
2D and 3D graphics seemed to be bifurcating.  (Ultimately, everything 
ends up being plotted in 2D.)  It should be just the core routines for 
graphics and then maybe a "graph2D.c" and "graph3D.c".  If a major 
change is made to graphics.c right now it will undoubtedly mess up some 
of the patches currently on SF.  Supporting 16-bit would probably be 
nice, but a conscious decision needs to be done on how to make that 
happen, i.e., how should software be organized, what features will be 
included.  That will be difficult to make work in the time span of 
making a release.  Maybe it would be best to not rock the 16-bit boat 
until 4.1.  That is, don't make an untested upgrade for 16-bit. 
 Otherwise the 16-bit world will upgrade and probably end up wrecking 
their current, workable set up.  I don't look back fondly on software 
upgrades in the 16-bit days.

Dan