noshutdown wrote:

1. djgpp or watcom for compiler?

Both, if you can afford disk space 😉
DJGPP will give you a recent C/C++ compiler - GCC 8 (!), but it's protected mode DOS only.
OpenWatcom's compiler is outdated but it can generate 16- and 32-bit EXEs for DOS, Win3.x, Win9x and some old exotic platforms that you'll probably never need.

noshutdown wrote:

which is better to use, and generates faster executables?

I'd expect DJGPP to win here because GCC has a reputation of being a very good optimizing compiler. (Watcom also had that reputation but that was ages ago).

2. which ide works with them? just like the vs+icc combinations for windows.

Watcom has its own IDE if I remember correctly, but I've never used it.
DJGPP had RHIDE but last time I checked it was unmaintained and didn't work anymore.

Also, I remember having some problems with DJGPP on DOS 6.22, as it assumed long filenames to be available.
Windows XP is the recommended platform for DJGPP development.

Not sure about speed but I found that the executables created by djgpp are LARGE even for the simplest 'hello world' project when compared to other compilers (even after running the exe through strip to remove the debugging information). But it does have the advantage of creating programs that run in protected mode so you have a lot more memory available to work with.

Personally I don't use an IDE I just use vi and fall back to the command prompt for compiling. Inefficient, yes, but it works for me.

OpenWatcom will build for xt + pentium, its fine. djgpp can be a hassle but its also fine.. djgpp still feels like a hack to me tho trying to get gcc+binutils all working in dos.

gca wrote:

Not sure about speed but I found that the executables created by djgpp are LARGE even for the simplest 'hello world' project when compared to other compilers

This can be true for Watcom as well, if you choose to embed the DOS extender into the exe (as opposed to separate DOS4GW.EXE file or such).

But by "large" we are talking of 100 kB or so of initial payload. It takes a lot of code then to make it twice as large.
Still, sizes rather insignificant for a protected mode application.

BloodyCactus wrote:

djgpp still feels like a hack to me tho trying to get gcc+binutils all working in dos.

Well, Quake was built with DJGPP, and with few fixes you can still make it work with recent DJGPP versions.
On the other hand, Watcom has a much bigger history of commercial games using it.

Also, DJGPP makes porting existing software from Linux and the like much easier, because it uses a familiar toolchain and the headers + libraries are virtually the same.

Also, if you simply want to teach your son programming in DOS, you can also stick with Borland C++, which will come with its own IDE built in. It will not adhere to the latest C++ standards, but it might be the easiest thing to get going. I think the older versions for DOS including IDE might be free downloads on Embarcardo's website (formerly Borland). But don't count on that. Also Turbo C 2.0 should be a free download.

All those solutions will not have Intellisense like completion! This is a feature that came much later to the IDEs and requires significant amount of computing power.

root42 wrote:

Also, DJGPP makes porting existing software from Linux and the like much easier, because it uses a familiar toolchain and the headers + libraries are virtually the same.

Also, if you simply want to teach your son programming in DOS, you can also stick with Borland C++, which will come with its own IDE built in. It will not adhere to the latest C++ standards, but it might be the easiest thing to get going. I think the older versions for DOS including IDE might be free downloads on Embarcardo's website (formerly Borland). But don't count on that. Also Turbo C 2.0 should be a free download.

All those solutions will not have Intellisense like completion! This is a feature that came much later to the IDEs and requires significant amount of computing power.

i had been using borland c when i was young, but is now extremely bored with it for whatever reason. all i want is something else that is newer and can generate fastest executables.

Well, you are bored with it, becaus it is Bor(e)land! *ba-dum-tssss*

However I agree: Watcom or DJGPP are in some ways easier, due to protected mode allowing for much simpler memory management, compared to the hell that is segmented real mode. 😉

For performance, compile that with both and see what happens: https://github.com/leikareipa/dccb.

I'd probably use the visual c++ 1.5 compiler for straight-up dos in dos.

Frankly, if he wants to show his son "how tough life was in the old days", then an old, segmented real-mode environment sounds like the ideal choice. If that's the motivation, one wouldn't want support for modern C++ features, the STL or other somewhat modern niceties. In pure DOS, that is generally what we had.

640K!enough wrote:

Frankly, if he wants to show his son "how tough life was in the old days", then an old, segmented real-mode environment sounds like the ideal choice. If that's the motivation, one wouldn't want support for modern C++ features, the STL or other somewhat modern niceties. In pure DOS, that is generally what we had.

i don't really need modern c++ features, but i surely want something that generates fastest executables.

Write your code, test it with multiple compilers, and select the fastest one. Then you can show your son how fast your code is.

Personally, I prefer to be able to compile for XT and 386 Protected Mode with one compiler (watcom), vs speed. My demo coding days are years in the past and my k6-2+ 500 is so far beyond anything I had back then coding for speed is somewhat irrelevant on my existing SS7 box.. heck, even dosbox.

noshutdown wrote:

i don't really need modern c++ features, but i surely want something that generates fastest executables.

Well, back in the day we didn't have compilers that generated the fastest executables 😀
I used to use Turbo C++ 3.1 back in the days of my 386 and 486. If I look at how much faster the code generated by OpenWatcom 1.9 is, it's not exactly representative of the DOS era. OW is about twice as fast on computationally intensive stuff like my 3D code used in my 1991 Donut intro: http://www.pouet.net/prod.php?which=62165
Which also explains why games and demos used so much assembly code to optimize for speed. Or why Turbo Pascal was so popular (had much faster compile times than any C/C++ environment, and had good inline assembly and a decent debugger).
So I suppose if you REALLY want to show what it was like in those days, you'll want to use tools from that era, not modern tools that happen to target old platforms.

Scali wrote:

Well, back in the day we didn't have compilers that generated the fastest executables :) I used to use Turbo C++ 3.1 back in the […]
Show full quote

Well, back in the day we didn't have compilers that generated the fastest executables 😀
I used to use Turbo C++ 3.1 back in the days of my 386 and 486. If I look at how much faster the code generated by OpenWatcom 1.9 is, it's not exactly representative of the DOS era. OW is about twice as fast on computationally intensive stuff like my 3D code used in my 1991 Donut intro: http://www.pouet.net/prod.php?which=62165
Which also explains why games and demos used so much assembly code to optimize for speed. Or why Turbo Pascal was so popular (had much faster compile times than any C/C++ environment, and had good inline assembly and a decent debugger).
So I suppose if you REALLY want to show what it was like in those days, you'll want to use tools from that era, not modern tools that happen to target old platforms.

both watcom and gcc existed back in the 1990s, they just kept updating versions, and i won't deny something that can generate faster executables as long as it can run on my 386 machine.

i also found that they are both very hdd consuming. openwatcom takes ~100mb without any ide, and newest djgpp with gcc8.20 takes ~200mb, while older gcc4.9.4 takes ~120mb. which is a pain in the ass as i have only 2*500mb hdds on that 386 and i still need to contain windows95, office97, 3dstudio, quake...

noshutdown wrote:

both watcom and gcc existed back in the 1990s, they just kept updating versions

That's my point. With all the updates they received over the years, they are not even remotely representative of what programming C/C++ was actually like on a 386 in the early 90s.

noshutdown wrote:

and i won't deny something that can generate faster executables as long as it can run on my 386 machine.

That's something entirely different from your original question:
"i am setting up a programming environment on my 386 dos machine, to show my son how tough life was in the old days."
How tough life was in the old days depends on the tools of the old days.
Now you are talking about "any modern tool as long as it can run on my 386".

Scali wrote:

That's my point. With all the updates they received over the years, they are not even remotely representative of what programmin […]
Show full quote

That's my point. With all the updates they received over the years, they are not even remotely representative of what programming C/C++ was actually like on a 386 in the early 90s.

That's something entirely different from your original question:
"i am setting up a programming environment on my 386 dos machine, to show my son how tough life was in the old days."
How tough life was in the old days depends on the tools of the old days.
Now you are talking about "any modern tool as long as it can run on my 386".

despite updated features and improved performance, doesn't rhide work the same way as borlandc and quickbasic? not to mention that i have yet to find an ide that works with watcom.
so obviously these newer versions don't change what life looked like in the old days. a well optimized stoneware is still stoneware, not an ironware like msvc.

noshutdown wrote:

so obviously these newer versions don't change what life looked like in the old days. a well optimized stoneware is still stoneware, not an ironware like msvc.

Clearly I disagree on that point.
Newer compilers have vastly different features, less bugs, different memory requirements, compile times etc, which completely change the way you can write, build and use code.
As I said, I had a factor two performance difference between the same 16-bit code with Turbo C++ 3.1 and OpenWatcom 1.9.
That means the difference between having to hand-optimize the whole thing in assembly and just accepting the compiler output as 'good enough'.
A lot of software written in the early 90s was still full of hand-optimized assembly for exactly that reason.
Just like people rarely used C++, and stuck to basic C, in order to keep compile-times, bugs and memory usage within acceptable limits.

If you want the other extreme... A while ago I experimented with Japheth's DOS extender, which can be linked as a DOS stub into an MSVC Win32 application.
So I could build my application with fullblown Visual Studio 2010 (possibly newer now), and just run it on my 486:
https://www.youtube.com/watch?v=xE9iifKXvY4

I have on my machine Watcom 10.6, 11 (pre opensource version with all the stuff), OWC2.0. If you go back, 10.6 doesnt have things like stdint+inttypes, which make life much harder (portability wise).

OWC2.0 is only 100mb if you add all the extra stuff, if you install only the dos headers/libs/binaries, it should be way way smaller like 30mb or something.

(I also have on my box quick c, turbo c, turbo c++, bc3.1, and a bunch of other compilers for interest sake).