gnuplot-beta

Do we still need MSDOS support?

[Ethan A M. <sf...@us...>]

A possibly foolish question from someone far outside the DOS/Windows world...

Many places in the gnuplot code are marked
#ifdef MSDOS ...

I thought that MSDOS referred to 16-bit legacy code that we
no longer support.  Maybe I am mistaken.

Who/what needs this code?
Should the test be replaced by a test for _WIN32 instead?

Maybe or maybe not the same question-

Can we get rid of the macros HUGE  and GPFAR?
Can we get rid of GP_FARMALLOC?

Re: Do we still need MSDOS support?

[Hans-Bernhard B. <HBB...@t-...>]

Am 04.04.2018 um 22:47 schrieb Ethan A Merritt via gnuplot-beta:
> 
> I thought that MSDOS referred to 16-bit legacy code that we
> no longer support.  Maybe I am mistaken.

You are, kinda.  MSDOS refers to the operating system, but not 
necessarily in its original 16-bit incarnation.  We still do carry 
support for DJGPP, which is a 32-bit target working on top of MSDOS.  It 
has suffered some bit-rot since I last tried to build it, but it should 
still be viable.

Building and testing the executables built by/for that target is getting 
ever more tricky these days, what with all the usual desktop platforms 
being 64-bit, so they can no longer executabe any 16-bit code (down to 
and including the 16-bit "stub" that starts the 32-bit DJGPP runtime 
environment).  So you need a VirtualBox setup or similar to run it.  But 
OTOH, DJGPP on FREEDOS may well be the only version of gnuplot that 
would still work on truly old boxes that won't support any "modern" 
Linux any more...

> Should the test be replaced by a test for _WIN32 instead?

No.

> Can we get rid of the macros HUGE  and GPFAR?

GPFAR: almost certainly yes.  We've long since dropped support for all 
platforms that needed it (segmented architectures like Win16 and 16-bit 
DOS).

HUGE is a different issue, as that's about quirky floating point 
support, not the target OS.  Or was it GPHUGE you were thinking of? 
That one can actually go, too, if GPFAR does.  Those are two parts of 
the same technique.

> Can we get rid of GP_FARMALLOC?

That would go wherever GPFAR does.

Re: Do we still need MSDOS support?

[sfeam <sf...@us...>]

On Thursday, 05 April 2018 00:23:15 Hans-Bernhard Bröker wrote:
> Am 04.04.2018 um 22:47 schrieb Ethan A Merritt via gnuplot-beta:
> > 
> > I thought that MSDOS referred to 16-bit legacy code that we
> > no longer support.  Maybe I am mistaken.
> 
> You are, kinda.  MSDOS refers to the operating system, but not 
> necessarily in its original 16-bit incarnation.  We still do carry 
> support for DJGPP, which is a 32-bit target working on top of MSDOS.  It 
> has suffered some bit-rot since I last tried to build it, but it should 
> still be viable.
> 
> Building and testing the executables built by/for that target is getting 
> ever more tricky these days, what with all the usual desktop platforms 
> being 64-bit, so they can no longer executabe any 16-bit code (down to 
> and including the 16-bit "stub" that starts the 32-bit DJGPP runtime 
> environment).  So you need a VirtualBox setup or similar to run it.  But 
> OTOH, DJGPP on FREEDOS may well be the only version of gnuplot that 
> would still work on truly old boxes that won't support any "modern" 
> Linux any more...
> 
> > Should the test be replaced by a test for _WIN32 instead?
> 
> No.
> 
> > Can we get rid of the macros HUGE  and GPFAR?
> 
> GPFAR: almost certainly yes.  We've long since dropped support for all 
> platforms that needed it (segmented architectures like Win16 and 16-bit 
> DOS).
> 
> HUGE is a different issue, as that's about quirky floating point 
> support, not the target OS.  Or was it GPHUGE you were thinking of? 

Yeah, sorry. Of course I meant GPHUGE.

> That one can actually go, too, if GPFAR does.  Those are two parts of 
> the same technique.
> 
> > Can we get rid of GP_FARMALLOC?
> 
> That would go wherever GPFAR does.

Thanks.

One more question:  
The emx/gcc compile environment looks pretty moribund compared
to cygwin, mingw, and even djgpp.  Can we get rid of the code
chunks marked
    if defined(__EMX__)

		Ethan

Aw: Re: Do we still need MSDOS support?

[Bastian M. <bma...@we...>]

> Gesendet: Donnerstag, 05. April 2018 um 00:23 Uhr
> Am 04.04.2018 um 22:47 schrieb Ethan A Merritt via gnuplot-beta:
> > 
> > I thought that MSDOS referred to 16-bit legacy code that we
> > no longer support.  Maybe I am mistaken.
> 
> You are, kinda.  MSDOS refers to the operating system, but not 
> necessarily in its original 16-bit incarnation.  We still do carry 
> support for DJGPP, which is a 32-bit target working on top of MSDOS.  It 
> has suffered some bit-rot since I last tried to build it, but it should 
> still be viable.

A few months ago I was asking myself if gnuplot could still be 
compiled on MSDOS. Here are my findings:

In fact there are (at least) three 32bit MSDOS compilers which were 
used in the past:
DJGPP:  Still under active development, POSIX, gcc 7.2 available, 
   as well as cross-compilers
OpenWatcom:  Development stale/slowed down, also supported for 
   gnuplot on Windows
EMX:  Used on DOS and OS/2, so removing support for it might break
   OS/2, too (Petr?)

I have tested building with DJGPP and OpenWatcom. There's indeed some bit-rot,
but that can be easily fixed. I just pushed my local "msdos-platform" branch
to my gnuplot "fork" on SF.  Beware of frequent rebases, though.

To my knowledge there have only been official releases using DJGPP in the
more recent past:  4.0 by HBB, 4.2-4.6 by Tatsuro (I think)

> 
> Building and testing the executables built by/for that target is getting 
> ever more tricky these days, what with all the usual desktop platforms 
> being 64-bit, so they can no longer executabe any 16-bit code (down to 
> and including the 16-bit "stub" that starts the 32-bit DJGPP runtime 
> environment).  So you need a VirtualBox setup or similar to run it.  But 
> OTOH, DJGPP on FREEDOS may well be the only version of gnuplot that 
> would still work on truly old boxes that won't support any "modern" 
> Linux any more...

If you build for Windows using cygwin or MSYS/MSYS2, compiling for DJGPP
is actually pretty straightforward using the cross-compilers.  I have updated
the DJGPP makefile to do that and also enabled out-of-tree builds.  Changes
are still entangled with my work on the "svga" terminal, though. It can
be found in the "djsvga-terminal" branch in my "fork". Beware of rebases here,
too.

For the fun of it, I also added most of the modern gnuplot features
to the djsvga terminal:  RGB and palette colors, enhanced text, filled polygons
and boxes, images, and mousing. Since the underlying GRX/MGRX graphics library
is also available on Windows and Linux, this terminal can be maintained even 
without testing on DOS.

The plan was to clean up the patches before integration into mainline gnuplot.
This should resurrect DOS as an actively supported platform.

> 
> > Should the test be replaced by a test for _WIN32 instead?
> 
> No.
> 
> > Can we get rid of the macros HUGE  and GPFAR?
> 
> GPFAR: almost certainly yes.  We've long since dropped support for all 
> platforms that needed it (segmented architectures like Win16 and 16-bit 
> DOS).
> 
> HUGE is a different issue, as that's about quirky floating point 
> support, not the target OS.  Or was it GPHUGE you were thinking of? 
> That one can actually go, too, if GPFAR does.  Those are two parts of 
> the same technique.
> 
> > Can we get rid of GP_FARMALLOC?
> 
> That would go wherever GPFAR does.

As an aside:  PROTO could now finally go there, too.

  Bastian

Re: Aw: Re: Do we still need MSDOS support?

[Tatsuro M. <tma...@ya...>]

> To my knowledge there have only been official releases using DJGPP in the
> more recent past:  4.0 by HBB, 4.2-4.6 by Tatsuro (I think)
> 
Yes. I provided binaries from 4.2-4.6.
 On 64 bit windows, 16 bit MS-DOS does not work and I used Dosbox.
However, in the Dosbox at the time cannot treat long file name.
So I give up to provide DJGPP packages at the point gnuplot began to use
file name in long file name style.
(On native MS-DOS, 8+3 characters can be used as file names.) 

Tatsuro 

Re: Aw: Re: Do we still need MSDOS support?

[Ethan A M. <sf...@us...>]

On Wednesday, April 4, 2018 11:19:18 PM PDT Bastian Märkisch wrote:
> > Gesendet: Donnerstag, 05. April 2018 um 00:23 Uhr
> > Am 04.04.2018 um 22:47 schrieb Ethan A Merritt via gnuplot-beta:
> > > 
> > > I thought that MSDOS referred to 16-bit legacy code that we
> > > no longer support.  Maybe I am mistaken.
> > 
> > You are, kinda.  MSDOS refers to the operating system, but not 
> > necessarily in its original 16-bit incarnation.  We still do carry 
> > support for DJGPP, which is a 32-bit target working on top of MSDOS.  It 
> > has suffered some bit-rot since I last tried to build it, but it should 
> > still be viable.
> 
> A few months ago I was asking myself if gnuplot could still be 
> compiled on MSDOS. Here are my findings:
> 
> In fact there are (at least) three 32bit MSDOS compilers which were 
> used in the past:
> DJGPP:  Still under active development, POSIX, gcc 7.2 available, 
>    as well as cross-compilers
> OpenWatcom:  Development stale/slowed down, also supported for 
>    gnuplot on Windows
> EMX:  Used on DOS and OS/2, so removing support for it might break
>    OS/2, too (Petr?)

Petr:

Are you still building gnuplot on OS/2?
What toolset[s] are needed for that?

In particular I am wondering if the __EMX__ conditional code and the
emxvga.trm driver can be removed.  

The EMX project web page seems to show that the most recent
supported gcc is 3.0.4 (from 2002).  I suspect that if we move to
requiring a compiler that accepts C99 syntax that version is too old.

What are your thoughts?

	Ethan

Re: Do we still need MSDOS support?

[Petr M. <mi...@ph...>]

I build gnuplot on OS/2 via gcc/emx. The binary then runs on OS/2, 
eCommStation, DOS with emx.exe or rsx.exe. Thus it is necessary to keep 
__OS2__ and __EMX__.

The gcc/emx I use is gcc 2.8.1, and it does not know command line option 
"-std=c99".

I've prepared some patches for OS/2 in 2017 but not committed them due to the 
transfer of cvs to git. I'll have to learn how to submit them.

BTW, would not C99 syntax break VMS/VAX compilers? Its makefile is still 
in the config/ directory.

Petr


>> EMX:  Used on DOS and OS/2, so removing support for it might break
>>    OS/2, too (Petr?)
>
> Petr:
>
> Are you still building gnuplot on OS/2?
> What toolset[s] are needed for that?
>
> In particular I am wondering if the __EMX__ conditional code and the
> emxvga.trm driver can be removed.
>
> The EMX project web page seems to show that the most recent
> supported gcc is 3.0.4 (from 2002).  I suspect that if we move to
> requiring a compiler that accepts C99 syntax that version is too old.

Re: Do we still need MSDOS support?

[sfeam <sf...@us...>]

On Friday, 06 April 2018 15:27:10 Petr Mikulik wrote:
> I build gnuplot on OS/2 via gcc/emx. The binary then runs on OS/2, 
> eCommStation, DOS with emx.exe or rsx.exe. Thus it is necessary to keep 
> __OS2__ and __EMX__.
> 
> The gcc/emx I use is gcc 2.8.1, and it does not know command line option 
> "-std=c99".

Do you use (or build) the emxvga terminal?
The source is basically untouched since 2002.

> I've prepared some patches for OS/2 in 2017 but not committed them due to the 
> transfer of cvs to git. I'll have to learn how to submit them.
> 
> BTW, would not C99 syntax break VMS/VAX compilers? Its makefile is still 
> in the config/ directory.

VMS support is also a candidate for being dropped.
I was myself test-building releases on VMS through version 4.6
but I no longer have a bootable VMS machine.   To the extent that VMS
lives on in the larger world, it is via emulation on virtual machines.
I have not been able to find any mention of gnuplot being used in that
context, but even if it is I imagine that the output is not via
the VAX Windowing System (vws.trm).
	
	Ethan



> Petr
> 
> 
> >> EMX:  Used on DOS and OS/2, so removing support for it might break
> >>    OS/2, too (Petr?)
> >
> > Petr:
> >
> > Are you still building gnuplot on OS/2?
> > What toolset[s] are needed for that?
> >
> > In particular I am wondering if the __EMX__ conditional code and the
> > emxvga.trm driver can be removed.
> >
> > The EMX project web page seems to show that the most recent
> > supported gcc is 3.0.4 (from 2002).  I suspect that if we move to
> > requiring a compiler that accepts C99 syntax that version is too old.
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Do we still need MSDOS support?

[sfeam <sf...@us...>]

On Friday, 06 April 2018 08:53:52 sfeam via gnuplot-beta wrote:
> On Friday, 06 April 2018 15:27:10 Petr Mikulik wrote:
> > I build gnuplot on OS/2 via gcc/emx. The binary then runs on OS/2, 
> > eCommStation, DOS with emx.exe or rsx.exe. Thus it is necessary to keep 
> > __OS2__ and __EMX__.
> > 
> > The gcc/emx I use is gcc 2.8.1, and it does not know command line option 
> > "-std=c99".
> 
> Do you use (or build) the emxvga terminal?
> The source is basically untouched since 2002.
> 
> > I've prepared some patches for OS/2 in 2017 but not committed them due to the 
> > transfer of cvs to git. I'll have to learn how to submit them.
> > 
> > BTW, would not C99 syntax break VMS/VAX compilers? Its makefile is still 
> > in the config/ directory.

I went back and looked at the documentation.
C99 has been supported by the OpenVMS C compiler since the mid 2000s.
So I don't think that by itself is a concern.

> VMS support is also a candidate for being dropped.
> I was myself test-building releases on VMS through version 4.6
> but I no longer have a bootable VMS machine.   To the extent that VMS
> lives on in the larger world, it is via emulation on virtual machines.
> I have not been able to find any mention of gnuplot being used in that
> context, but even if it is I imagine that the output is not via
> the VAX Windowing System (vws.trm).
> 	
> 	Ethan