Best C++ compiler for DOS programs

[P.J. Plauger]

I'm pretty sure that although you may still be using those programs, you
aren't using them on 16 bit DOS <g>.

Wrong. They're .com files. And they're quite useful.

IAR doesn't seem to support 16 bit X86 - at least they don't list it on
their web site. Their page entitled "Extended Embedded C++" makes it
pretty clear they do not support exception handling, multiple inheritance,
or RTTI. They do support templates as well as
being "memory attribute aware", which is not elaborated.

My bet is they do support multiple inheritance, but what the heck. They
*do* support templates, code bloat and all.

I didn't say "completely unusable", though I will say it is impractical.
As evidence, no compiler (other than Digital Mars C++) seems to have
implemented it for 16 bit code. IAR is using the EDG front end, which
supports EH, but have apparently *removed* support for it for their 16 bit
targets.

Now wait, if it's impractical why do you keep boasting that you support it?

I've always considered it part of STL, after all, it is part of STLPort
(which is the STL that Digital Mars ships). If there is an official
definition of STL which excludes iostreams, so be it.

I gave it earlier -- the thing that came out of Hewlett-Packard.

Ok, but IAR doesn't support exception handling, RTTI, or multiple
inheritance for 16 bit targets (they do support templates). Do you know
anyone (besides Digital Mars C++) that does?

Like I said, I picked IAR off the top of my head as one of a dozen of
our compiler OEM customers who license the Abridged Library. It works
properly with or without exceptions, so it's up to the vendor whether
to turn exceptions on.

I checked the web site www.iar.com. They do not list X86 as a supported
target for their C/C++ compilers.

But maybe I am all wrong. If there is a demand for 16 bit X86 compilers
that support exception handling, RTTI, multiple inheritance, etc., I'd
certainly be pleased to work with Dinkumware to fill it.

Not sure how much "work" we have to do in that department. It's all
kinda there.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Alex Buell]

BTW, another big reason that C won was because the C compilers of the
day were much, much better than the compilers for other languages.
That, for example, buried Pascal. By the time Pascal compilers got
better, it was too late.

You're correct - I just tested it with TurboPascal 1.05a, TurboPascal
3.02a and TurboPascal 5.5, with 'Hello world' produces:

1.05a: 8,803 bytes
3.02a: 11,411 bytes
5.5: 1,840 bytes (quite remarkable!)

Too little, too late it would seem!

 

[Walter Bright]

You're correct - I just tested it with TurboPascal 1.05a, TurboPascal
3.02a and TurboPascal 5.5, with 'Hello world' produces:

1.05a: 8,803 bytes
3.02a: 11,411 bytes
5.5: 1,840 bytes (quite remarkable!)

Too little, too late it would seem!

There were Pascal compilers for the PC before TP, and they were
uniformly terrible even by the standards of the day. They drove a lot of
people to look at C instead.

 

[Walter Bright]

Wrong. They're .com files. And they're quite useful.

You are running build tools on a 16 bit DOS system? I'm amazed. But what
I think you meant is you're running them on Win32's DOS emulator. Long
ago, I recompiled my .com utilities to be native Win32 programs. They
run a lot better that way <g>. For example, DOS programs still suffer
from the wretched 8.3 uppercase filename limitations, and who would want
that on their Win32 system? And if they're in portable C or C++, why not
recompile them?

True .com files have a maximum of 64K of code and stack and data, total.
However, one could rename any .exe file to ".com" and it would work, and
one can even rename Win32 exe files to ".com" and they'll still work,
too, but they aren't really com files.

(I also find the Win32 DOS emulator to be rather slow, another good
reason to recompile those 16 bit programs to native 32 bits.)

My bet is they do support multiple inheritance, but what the heck. They
*do* support templates, code bloat and all.

Yes, though it would be interesting to see what use 16 bit customers
make of templates. It's often necessary for marketing reasons to support
things even if they aren't used.

Now wait, if it's impractical why do you keep boasting that you support it?

Because:

1) At the time, a lot of customers said they wanted it. It certainly was
worth implementing as it's not so easy to see in advance how things will
work out.

2) It's easy to support (given the support for it for DOS32, where it is
very useful).

3) There's no reason to go in and break it. Support for it can be turned
on and off with a switch.

4) Whether a customer wants it is up to them. I see no reason to make
the decision for them. Sometimes I do provide some advice to those who
don't realize the tradeoffs involved with 16 bit code. After all, I like
to see them succeed with their projects.

5) Having an existing implementation means we aren't having a
hypothetical discussion here. You disagree with me and believe it is
practical. At some point it is useless to discuss this anymore; if you
want to use it in your next 16 bit DOS project, it's there for you to
try out.

6) I'm proud of the implementation, even if it turned out to be less
useful than I'd hoped.

7) I try to be realistic about it. If I was just some boasting marketing
droid, why would I say that a Standard C++ feature exclusively
implemented by Digital Mars is not so practical? I'd be saying it's the
greatest thing ever!

-Walter Bright
www.digitalmars.com C, C++, D programming language compilers

 

[Alex Buell]

There were Pascal compilers for the PC before TP, and they were
uniformly terrible even by the standards of the day. They drove a lot
of people to look at C instead.

Unfortunately DMC 8.47 loses out to OpenWatcom C/C++ 1.4. Here's a
simple test compiling a 16 bit DOS program ("Hello World!")

dmc -msd hello.c gives: 12,362 bytes
wcl -bcl=dos -ms gives: 8,702 bytes

Sorry, pal...

 

[Steve]

Have you heard of Linux? Solaris? Um, MIPS? Do you mean the only
Microsoft product that can give you accurate timing and access to low
level hardware? You can get access to low level hardware (registers,
buses, etc) with windows languages, like C and C++. I'm actually
confused, perhaps I misunderstood the lessons I learned over the last
ten years...Could you explain?

(yes, off topic, but I'm really confused).

My main focus is hardware, servicing PC computers. Target for these programs
is PC with some kind of problem. It can be corrupted OS or hardware. First,
you must find which of those two is it, ideally with some other software,
not your original OS. That is the first place you need hardware test
independent of OS. Than, if it is hardware, what is wrong with it and where?
OS usually can't boot, and if it can, you have to boot it vast number of
times while you are replacing suspect components. If you do it with some
general purpose OS, that is extremely long and unpleasant experience. OS is
unstable, configuration is constantly changing, you have number of
meaningless errors, and you are never sure at which point you have finally
corrupted your OS (registry or configuration data). That means that at some
point you may have two or more independent errors at the same time, which
destroys replacement procedure logic, and you may never know when you have
replaced bad component. Moral of the story is that any high level OS is
almost completely useless.

So, I do not need Microsoft. I can use free DOS clone Actually, I be
happier to write programs at the bios level, or even to avoid bios also
(except boot). But that is overkill, and I loose some useful software,
hardware drivers and test flexibility. DOS level of complexity, small size
(bad memory locations case!), and nonmultitasking design is ideal.
That was target platform OS considerations.

If we talk about development platform OS, that depend on what OS you know
and have at home and various places where you work, or will work in the
future. At all those places I have only Windows. Because of that, I know it
(and must know it) well, and I know much less about Linux. Working in two
different sets of high-level software environments, and some low level,
would be too much. Windows is most common OS and that basically determines
everything else. It is not the question of OS performance or my preference.

Steve

 

[Chris Giese]

We use mingw with our libraries as a convenient test bed. It offers
a free, reasonably current gcc that lets us compile large-model programs
under DOS.

Doesn't MinGW run under Windows and produce Win32 executables?

Did you really get it to make DPMI (32-bit DOS) executables?
Like DJGPP? How?

 

[Jerry Coffin]

<[email protected]>,
(e-mail address removed) says...

[ ... ]

dmc -msd hello.c gives: 12,362 bytes
wcl -bcl=dos -ms gives: 8,702 bytes

cl -AT hello.c gives: 5,532 bytes

If memory serves, when I was doing this regularly, I
could manage something like 1300 bytes, but I'm afraid
I've forgotten quite a few of the old DOS tricks...

 

[P.J. Plauger]

Doesn't MinGW run under Windows and produce Win32 executables?

Did you really get it to make DPMI (32-bit DOS) executables?
Like DJGPP? How?

I didn't. I misspoke. Sorry.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Benry]

Steve,

All I mean is that while Windows 95 and previous boot DOS first before
Windows, the OS was really DOS. That's the same with Linux and BSD.
You have a text based, low level OS, which isn't preconfigured to be
"high level" like WinXP. In fact, if you wanted, you can install just
the linux kernel, and whatever libraries you need to do your work, and
that's it. It's a tiny footprint in that case. The good thing is,
that linux kernel is still supported, updated, and more secure than any
close of anything. There are known and current C++ compiliers for
linux kernel. In fact, if you got ambitious enough about it, you could
create your own Linux distro just for troubleshooting hardware issues.
I don't think the learning curve is too hard, since you're familiar
with DOS, linux shell isn't too much different.

However, I just realized that I'm replying to a DOS newsgroup as well
as a c++ one.

I can't offer advice for DOS users, so good luck .

 

[Diego Martins]

do you know C++ compilers that generates Z80 binaries?

 

[Benry]

nope. But if you get rid of your classes and start writing "extern" in
various locations, you can use http://tack.sourceforge.net/

I don't know though. Not familiar wiht z80.

-Benry

 

[Default User]

do you know C++ compilers that generates Z80 binaries?

A quick Google search turns up a number of C compilers that
cross-compile to Z80. I'm sure if I looked long enough there'd be a C++
one in there.



Brian

 

[William J. Leary Jr.]

A quick Google search turns up a number of C compilers that
cross-compile to Z80. I'm sure if I looked long enough there'd be a C++
one in there.

If not, and you don't need full (current) C++, using CFRONT to output to your
Z80 targeted C compiler might do the job.

- Bill

 

[Chris Hills]

do you know C++ compilers that generates Z80 binaries?

No.

They found it wasn't practical. A cut down version of C++ has been
used on some 8 bit micros but it is not very effective.

Why do you want C++ on the Z80 anyway. C is far better suited.

There are several C compilers for the Z80

 

[Michal Necasek]

A few misc notes...

Walter is right, there is no interest in commercial DOS compilers
these days. I know that several large and well known hardware and
software vendors still develop DOS applications, mostly for custom
'close to the metal' applications. But they're not about to actually pay
money to get some compiler development done.

Digital Mars and Open Watcom support both 16-bit and 32-bit
development, which may be extremely helpful on DOS.

Open Watcom C++ support isn't as good as it could be, but it's better
than it used to be and probably perfectly adequate for an app developed
from scratch.

Open Watcom comes with several DOS extenders: DOS/4GW is old and
unsupported but works and is royalty-free. CauseWay is public domain,
works well and complete source code is available. DOS/32A is very good,
also free and with source code available. There is a bunch of other DOS
extenders that can be used with Open Watcom (HX-DOS, PMODE/W, etc.).

Don't know about the other compilers but Open Watcom also has a pretty
good DOS debugger - it's actually also easy to cross debug from other
platforms (Windows, OS/2, with a little bit of hand holding Linux).
Personally, I'd go for a cross compiler - DOS sucks to develop on,
though it has advantages as a specialized application platform.

Whether the DOS app works in a NT DOS box is entirely a function of
the application, not the compiler. Some things just won't work in a VDM
and after all, if you could run the app in Windows, you wouldn't be
developing a DOS program.


Michal