On Sat, 19 May 2018, Sven Schreiber wrote: Fair question. The answer is quite long but I'll try to be succinct. For one thing, we want to be able to offer the user full access to the gnuplot GUI for Windows, wgnuplot.exe (e.g. under /Tools/Gnuplot). Given that, the question becomes: Is there any advantage in also including the console program gnuplot.exe? From gretl's point of view the answer is No, since wgnuplot.exe works fine in non-interactive "slave" mode to do what we want -- namely, accept a script as input and generate a plot file in some specified output format (PNG for our GUI, but also PDF, EPS, SVG or whatever). The "selling point" of gnuplot.exe is that it accepts commands on stdin, but the way gretl interacts with gnuplot we have no need for that facility. There are basically two ways in which a program like gretl or Octave can make a gnuplot plot modifiable by the user. (1) The plot's "state" can be saved on the gnuplot side. It is shown in a gnuplot window, and incremental commands to modify it are sent to gnuplot via stdin. This is what gretl did in the old, old days. (2) State is saved in the caller (gretl). The plot specification takes the two interchangeable forms of a gnuplot script and a C struct which represents the content of the script in a structured manner in memory. When the user requests a modification gretl rewrites the script, recompiles the plot to PNG via gnuplot, and reloads it into a GTK window. By adopting method (2) we're able to show our plots in (I would say) a "nicer" window than the native gnuplot one. It's easier to get a consistent appearence across platforms, and we're able to attach a much more functional menu system. Oh, and one more thing: we need wgnuplot to show 3-D plots that can be manipulated interactively. To be clear: the "compilation" of gnuplot scripts to PNG (etc.) could certainly be accomplished using gnuplot.exe instead of wgnuplot.exe; it's just that since we want wgnuplot.exe anyway there's no advantage to packaging a second gnuplot executable. Allin