delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2013/12/02/20:45:11

X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Received: by 10.68.137.163 with SMTP id qj3mr11340463pbb.4.1386034064575;
Mon, 02 Dec 2013 17:27:44 -0800 (PST)
X-Received: by 10.49.95.8 with SMTP id dg8mr2711qeb.24.1386034064518; Mon, 02
Dec 2013 17:27:44 -0800 (PST)
Newsgroups: comp.os.msdos.djgpp
Date: Mon, 2 Dec 2013 17:27:44 -0800 (PST)
In-Reply-To: <0404a92b-e194-4e75-97b5-58c8e5b3c076@googlegroups.com>
Complaints-To: groups-abuse AT google DOT com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=65.13.115.246;
posting-account=p5rsXQoAAAB8KPnVlgg9E_vlm2dvVhfO
NNTP-Posting-Host: 65.13.115.246
References: <0404a92b-e194-4e75-97b5-58c8e5b3c076 AT googlegroups DOT com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <e4a3af24-d4a8-4079-806a-dc355d4dea16@googlegroups.com>
Subject: Re: Using DJGPP for C++ DOS development today?
From: rugxulo AT gmail DOT com
Injection-Date: Tue, 03 Dec 2013 01:27:44 +0000
Bytes: 5967
Lines: 101
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

Hi,

On Tuesday, November 26, 2013 7:28:58 PM UTC-6, John Davidson wrote:
> 
> I used to program C and inline assembler with DJGPP under DOS in
> the nineties.
> 
> Now I have a hobby project that would target DOS (yes, seriously),
> and I would like to take the opportunity to get beyond the basics
> of C++ and actually learn the language proper.
> 
> So, my questions:
> 
> * "Which C++" can I realistically expect to use with DJGPP? To what
> extent are features from C++11 supported? C++03?

I don't grok C++, but there are various things to consider here:
dialect, libraries, OS, support, etc.

GCC (since 4.7.x) requires C++03 to build itself, so presumably DJGPP
supports that "fairly" well since it can build that.

> * Google led me to a DJGPP version 2.04-beta. Is this usable?

Both /current/ and /beta/ have 99% of the same ports (with very few
exceptions). It's just not fully finalized for whatever reasons (no
release manager?).

But there aren't enough volunteers (and no GNU help, AFAIK), so
DJGPP is weak in some areas. C99 is only halfway implemented,
and I'm not aware of any C11 nor C++11 support. And of course you
have to be aware that DJGPP is only partially POSIX (2001), it
doesn't support latest POSIX 2008 (mmap) nor Unicode, multi-threading,
64-bit, etc. So most projects don't even indirectly support DJGPP
anymore. If that is a problem (and you can't live with older ports),
you're in for a rough ride.

Let's be honest, everything modern shuns legacy, and DJGPP is
definitely legacy. All the world's a Windows or *nix. Anything
weaker or different is mostly ignored. So you just won't have
very good luck unless you're prepared to live with the gaps.
Don't be surprised when nobody can answer your question or
you get little sympathy. Sad to say, but it's just not the
easiest path.

The easiest path (esp. if all you want to do is learn C++) is
to use MSVC or GCC (MinGW or Cygwin) or Clang.

> * Which GCC version is the latest I can use with DJGPP? (without
> having to do any porting myself)

/current/ has 4.7.3. /beta/ has 4.8.2.

I don't know all the changes. Like I said, I don't grok C++. From
what C++ stuff I've rebuilt over the years (for fun), G++ 3.4.4 or
4.1.2 or 4.2.3 worked fine with DJGPP (when the sources supported it).

> * Can I expect the same performance from C++/DJGPP over C/DJGPP,
> when targeting something like a 20MHz 80386 with 2mb RAM?

Honestly, I don't know, but I doubt it. I think C++ always claimed
to be zero overhead, but I'm not sure how true that is. Anyways,
2 MB is very low, so virtual memory (CWSDPMI ftw!) is your friend.
But I don't think latest 4.8.2 would be a good idea, even if it
did run (which I'm not sure). You may do better to restrict to
an older version.

I don't know, it's sad, nobody cares about anything that isn't
i686 anymore. I used to try running older versions on my ancient
machines (486 and 586) but was unimpressed. I found that 2.95.3
was too slow for a 486, like 2x or worse (vs. 2.7.2.3). My point
is that 2.8.1 (1998) was first to support 586 instructions. But
C++ support supposedly was very weak until 3.x, so I don't know
what to tell you. I don't think anything lower than 3.2.3 would
be recommended (from what little memory I have of using various
versions) for C++98.

> (The the development will _not_ be done on the 386, even with RHIDE
> and all...)

Well, that makes things easier. Yes, I see you mention something about
486 instructions. Dunno, that sucks, that's a bug, IMO. I still have
CWS' reply in my email inbox about a CMOV handler (using signal) to
catch bogus instructions to emulate them, but it was really not
something I was really comfortable messing with (and he's always
busy, heh). So nobody tried, but it's far from impossible. I mean,
DJGPP already has emulation for FPU, so it's not that far a stretch,
but so far nobody has done it for us for newer cpu opcodes.

Rod P. mentioned OpenWatcom. He forgot to mention two things. Since 1.8
(currently at 1.9) it has much better C++ support (though maybe somewhat
worse than G++). Secondly, it refuses to use anything outside of i386
instructions (AFAIK), so -4 -5 -6 switches are just tuning (scheduling?).
Yes, the DOS version still works, so you could definitely try that. A
definite advantage is that the default 80 MB download (installer / .ZIP
sfx) includes all cross-compilers, so you can easily cross-compile for
DOS from atop Windows or OS/2 or Linux without having to build your own
compiler manually. However, DJGPP is still better in some ways (extender,
memory, LFN support).

In short, I don't want to be too pessimistic, but nothing's perfect. You
will just have to try and see whether it fits the bill for your needs.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019