Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Using DJGPP for C++ DOS development today?
763 views
Skip to first unread message
John Davidson
Nov 26, 2013, 8:28:58 PM11/26/13
to
Hi!
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 I'll try to implement this program in as elegant C++ code as possible. (The program will be of a moderate size and I have written similar programs before in C)
Having spent some time reading up on C++, it seems that C++ has evolved a lot in recent years, and modern C++ is quite different from the dog-turned-octopus I remember frowning upon.
So, my questions:
* "Which C++" can I realistically expect to use with DJGPP? To what extent are features from C++11 supported? C++03?
* Google led me to a DJGPP version 2.04-beta. Is this usable?
* Which GCC version is the latest I can use with DJGPP? (without having to do any porting myself)
* Can I expect the same performance from C++/DJGPP over C/DJGPP, when targeting something like a 20MHz 80386 with 2mb RAM?
(The the development will _not_ be done on the 386, even with RHIDE and all...)
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 I'll try to implement this program in as elegant C++ code as possible. (The program will be of a moderate size and I have written similar programs before in C)
Having spent some time reading up on C++, it seems that C++ has evolved a lot in recent years, and modern C++ is quite different from the dog-turned-octopus I remember frowning upon.
So, my questions:
* "Which C++" can I realistically expect to use with DJGPP? To what extent are features from C++11 supported? C++03?
* Google led me to a DJGPP version 2.04-beta. Is this usable?
* Which GCC version is the latest I can use with DJGPP? (without having to do any porting myself)
* Can I expect the same performance from C++/DJGPP over C/DJGPP, when targeting something like a 20MHz 80386 with 2mb RAM?
(The the development will _not_ be done on the 386, even with RHIDE and all...)
Andris Pavenis
Nov 26, 2013, 11:46:57 PM11/26/13
to dj...@delorie.com
On 11/27/2013 03:28 AM, John Davidson wrote:
> Hi!
>
> 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 I'll try to implement this program in as elegant C++ code as possible. (The program will be of a moderate size and I have written similar programs before in C)
>
> Having spent some time reading up on C++, it seems that C++ has evolved a lot in recent years, and modern C++ is quite different from the dog-turned-octopus I remember frowning upon.
>
> So, my questions:
>
> * "Which C++" can I realistically expect to use with DJGPP? To what extent are features from C++11 supported? C++03?
You can see summary about C++11 support in GCC at http://gcc.gnu.org
> Hi!
>
> 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 I'll try to implement this program in as elegant C++ code as possible. (The program will be of a moderate size and I have written similar programs before in C)
>
> Having spent some time reading up on C++, it seems that C++ has evolved a lot in recent years, and modern C++ is quite different from the dog-turned-octopus I remember frowning upon.
>
> So, my questions:
>
> * "Which C++" can I realistically expect to use with DJGPP? To what extent are features from C++11 supported? C++03?
>
> * Google led me to a DJGPP version 2.04-beta. Is this usable?
I do not know when it will be released. As usually : when it is ready
>
> * Which GCC version is the latest I can use with DJGPP? (without having to do any porting myself)
All recent versions. Although gcc-4.8.X only for DJGPP v2.04. One could even get my builds of later
> * Which GCC version is the latest I can use with DJGPP? (without having to do any porting myself)
GCC development snapshots for DJGPP (latest is less than week old now) if is wanting to test
snapshots at his own risk.
>
> * Can I expect the same performance from C++/DJGPP over C/DJGPP, when targeting something like a 20MHz 80386 with 2mb RAM?
>
> (The the development will _not_ be done on the 386, even with RHIDE and all...)
You surely will have trouble with C++ standard library on 80386 not only due to small memory amount.
> * Can I expect the same performance from C++/DJGPP over C/DJGPP, when targeting something like a 20MHz 80386 with 2mb RAM?
>
> (The the development will _not_ be done on the 386, even with RHIDE and all...)
C++ library uses instructions only available since 80486. 80486 may be OK. I myself have
nothing lower than Core 2.
Andris
John Davidson
Nov 27, 2013, 7:12:43 PM11/27/13
to
> You surely will have trouble with C++ standard library on 80386 not only due
> to small memory amount.
>
> C++ library uses instructions only available since 80486. 80486 may be OK. I
> myself have nothing lower than Core 2.
I tried to find some more info about this, but came up short. Do you know when glibc stopped supporting the i386? I see GCC supported the 386 until ~2012 (4.8). And does the STL use glibc for everything?
> to small memory amount.
>
> C++ library uses instructions only available since 80486. 80486 may be OK. I
> myself have nothing lower than Core 2.
What I really want to know is what is the latest version of DJGPP or GCC that I can use with an 80386, so I can figure out what subset of C++ I must limit myself to. Or if there are any other C++ compiler I should use.
Hans-Bernhard Bröker
Nov 27, 2013, 7:42:39 PM11/27/13
to
On 28.11.2013 01:12, John Davidson wrote:
> I tried to find some more info about this, but came up short. Do you
> know when glibc stopped supporting the i386?
glibc has nothing to do with that. DJGPP doesn't use that. It couldn't
> I tried to find some more info about this, but came up short. Do you
> know when glibc stopped supporting the i386?
even it wanted to.
The library in question would be the C++ runtime library, a.k.a. libstdc++
Rod Pemberton
Nov 28, 2013, 1:26:50 AM11/28/13
to
On Wed, 27 Nov 2013 19:12:43 -0500, John Davidson <codew...@gmail.com>
wrote:
An alternate solution might be instruction emulation.
There were DOS TSR's that emulated missing instructions
using the processor's invalid instruction interrupt.
The TSRs I was able to locate are listed below. I've
never used these, so I'm not familiar with them. I think
there was one for 486 too, but I'm not able to locate it.
It's possible Rugxulo or someone else might be familiar
with some emulators for 486. You might try a post to
comp.os.msdos.programmer and comp.os.msdos.misc, etc,
in case someone remembers.
It's also possible that you could find enough support
in those listed below, although unlikely...
Also, these are from old and obscure DOS websites like
Garbo, Simtel, Hobbes, Funet.fi, so do a virus scan
before using.
http://www.sac.sk/files.php?d=16&p=25
em3134b1.zip 386 for 286
em386133.zip 386 for 286
http://www.sac.sk/files.php?d=16&l=Q
q87_413.zip 8087 ?
http://ftp.sunet.se/pub/simtelnet/msdos/emulate
387.zip 80387
em3134b1.zip 386 for 286
em87v1_3.zip 8087 for AT or 386
emul87.zip 8087 for 286/386
http://archives.scovetta.com/pub/fehq/DOSUtils/00_index.htm
emxxx87.zip 8087 ?
mmx.zip MMX instructions
mmx386.zip MMX for 386
q387_366.zip 387
Rod Pemberton
wrote:
> On Tue, 26 Nov 2013 23:46:57 -0500, Andris Pavenis
> <andris....@iki.fi> wrote:
>> C++ library uses instructions only available since 80486.
>
> <andris....@iki.fi> wrote:
>> C++ library uses instructions only available since 80486.
>
> What I really want to know is what is the latest version of
> DJGPP or GCC that I can use with an 80386, [...]
An alternate solution might be instruction emulation.
There were DOS TSR's that emulated missing instructions
using the processor's invalid instruction interrupt.
The TSRs I was able to locate are listed below. I've
never used these, so I'm not familiar with them. I think
there was one for 486 too, but I'm not able to locate it.
It's possible Rugxulo or someone else might be familiar
with some emulators for 486. You might try a post to
comp.os.msdos.programmer and comp.os.msdos.misc, etc,
in case someone remembers.
It's also possible that you could find enough support
in those listed below, although unlikely...
Also, these are from old and obscure DOS websites like
Garbo, Simtel, Hobbes, Funet.fi, so do a virus scan
before using.
http://www.sac.sk/files.php?d=16&p=25
em3134b1.zip 386 for 286
em386133.zip 386 for 286
http://www.sac.sk/files.php?d=16&l=Q
q87_413.zip 8087 ?
http://ftp.sunet.se/pub/simtelnet/msdos/emulate
387.zip 80387
em3134b1.zip 386 for 286
em87v1_3.zip 8087 for AT or 386
emul87.zip 8087 for 286/386
http://archives.scovetta.com/pub/fehq/DOSUtils/00_index.htm
emxxx87.zip 8087 ?
mmx.zip MMX instructions
mmx386.zip MMX for 386
q387_366.zip 387
Rod Pemberton
John Davidson
Nov 28, 2013, 4:34:05 AM11/28/13
to
Hans-Bernhard Bröker wrote:
> The library in question would be the C++ runtime library, a.k.a. libstdc++
Sorry if I'm just misunderstanding something (I don't know anything about compilers beyond a basic grasp and never had to rebuild anything), but can't I just rebuild libstdc++ from source for the 386? Is it full of inline assembler?
> The library in question would be the C++ runtime library, a.k.a. libstdc++
I found this:
https://groups.google.com/forum/#!topic/comp.os.msdos.djgpp/WeMjxnR1NBc
which seems to indicate that GCC will output non-386 opcodes anyway :-(
http://gcc.gnu.org/onlinedocs/libstdc++/faq.html says:
"Only when actually running the code on a i386 will the problem appear.
This is fixed in 3.2.2."
Rod Pemberton wrote:
> An alternate solution might be instruction emulation.
Surely something as basic as the xadd or cmpxchg instruction must be used by every other function if it was enabled during compilation, so opcode emulation would be a big performance hit?
Or do I just write the 486 emulation myself in DJGPP? I can't remember all this DOS interrupt business. I guess I'll have some catching up to do. And stocking up, on aspirin...
Rod Pemberton
Nov 28, 2013, 6:56:04 AM11/28/13
to
On Thu, 28 Nov 2013 04:34:05 -0500, John Davidson <codew...@gmail.com>
wrote:
You could also search and ask on Vogons and "DOS Ain't Dead" forums:
DOS Ain't Dead
http://www.bttr-software.de/forum/forum.php
Vogons
http://www.vogons.org/
Otherwise, if emulation becomes the primary option, I may have
to post links to all the old DOS websites so you can comb
through them...
Why are you using a 386 anyway? Or, can you upgrade slightly?
Seriously, spending money is the easiest solution.
Rod Pemberton
wrote:
> Rod Pemberton wrote:
>> An alternate solution might be instruction emulation.
>
> Thanks, didn't think about that! It sounds like a fragile solution
> though; wouldn't there be problems with switching in and out of
> protected mode? (man, I never thought I'd ever say that again!)
>
> Surely something as basic as the xadd or cmpxchg instruction must be
> used by every other function if it was enabled during compilation, so
> opcode emulation would be a big performance hit?
>
> Or do I just write the 486 emulation myself in DJGPP? I can't remember
> all this DOS interrupt business. I guess I'll have some catching up to
> do. And stocking up, on aspirin...
I would assume the answer to all three questions is: "likely" ... :-)
>> An alternate solution might be instruction emulation.
>
> Thanks, didn't think about that! It sounds like a fragile solution
> though; wouldn't there be problems with switching in and out of
> protected mode? (man, I never thought I'd ever say that again!)
>
> Surely something as basic as the xadd or cmpxchg instruction must be
> used by every other function if it was enabled during compilation, so
> opcode emulation would be a big performance hit?
>
> Or do I just write the 486 emulation myself in DJGPP? I can't remember
> all this DOS interrupt business. I guess I'll have some catching up to
> do. And stocking up, on aspirin...
You could also search and ask on Vogons and "DOS Ain't Dead" forums:
DOS Ain't Dead
http://www.bttr-software.de/forum/forum.php
Vogons
http://www.vogons.org/
Otherwise, if emulation becomes the primary option, I may have
to post links to all the old DOS websites so you can comb
through them...
Why are you using a 386 anyway? Or, can you upgrade slightly?
Seriously, spending money is the easiest solution.
Rod Pemberton
John Davidson
Nov 28, 2013, 8:18:39 AM11/28/13
to
Rod Pemberton wrote:
> Why are you using a 386 anyway?
> Why are you using a 386 anyway?
> Seriously, spending money is the easiest solution.
Actually, using a modern machine and a modern language is another solution :) It's just a hobby project, so I thought I'd look into the options of using C++. I have an old 386 and it would be fun to have a reason to do some low level assembly stuff again.
It seems like my best option with the C++ route would be to settle for C++98. Doesn't seem all that bad since I've gotten a feeling that one really ought to know the old stuff to understand the reasoning behind C++11.
Thanks guys.
Rod Pemberton
Nov 28, 2013, 7:02:12 PM11/28/13
to
On Thu, 28 Nov 2013 08:18:39 -0500, John Davidson <codew...@gmail.com>
wrote:
You could try other C compilers, e.g., OpenWatcom, or old Turbo C, etc.
RP
wrote:
RP
rug...@gmail.com
Dec 2, 2013, 8:27:44 PM12/2/13
to
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.
>
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.
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:
>
> * "Which C++" can I realistically expect to use with DJGPP? To what
> extent are features from C++11 supported? C++03?
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?
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)
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?
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...)
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.
Andris Pavenis
Dec 3, 2013, 2:36:02 AM12/3/13
to dj...@delorie.com
On 12/03/2013 03:27 AM, rug...@gmail.com wrote:
> Hi,
Additionally C++ library would be seriously cripled relative to what is
supported for v204 development versions. So I do not think it worth
trying to fix build with v2.03v2.
Example random number support would be left out from libstdc++
as it relies on a more complete implementation of current C standard
as one from v2.03.
Andris
PS. Similarly gmp-5.1.X did not entirely build with DJGPP v2.03 due to
the same reason, so I released only packages for /beta/
> Hi,
>
>
> /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).
>
4.8.X does not even build with DJGPP v2.03v2 at least when I last checked.
>
> /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).
>
Additionally C++ library would be seriously cripled relative to what is
supported for v204 development versions. So I do not think it worth
trying to fix build with v2.03v2.
Example random number support would be left out from libstdc++
as it relies on a more complete implementation of current C standard
as one from v2.03.
Andris
PS. Similarly gmp-5.1.X did not entirely build with DJGPP v2.03 due to
the same reason, so I released only packages for /beta/
0 new messages