DOS ain't dead

D based on GCC

WATCOM

CC386 by Ladsoft

TCC by Fabrice Bellard

DigitalMARS

Old Boreland "Turbo" C compiler 2.0 (closed source freeware)

Visual studio C## 2010 Ultimate by ???

----------------------------------------------------------------------------

Please discuss here and don't pollute other threads

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Nice list. What do you want?

> Please discuss here and don't pollute other threads

Sorry, no, I have to refuse your list because D.... is at the first place which it doesn't deserve at all; being placed as a footnote - because of its historical relevance - seems more appropriate IMO. OTOH, there are some compilers missing (the superior, fine and free MS VC 2003 Toolkit for example)...

---
MS-DOS forever!

> D based on GCC

It's not "D" but "DJGPP".

> WATCOM

Its name is "Open Watcom C/C++".

> TCC by Fabrice
> Bellard

Is this used by anyone except you?

> DigitalMARS

Its name is "Digital Mars C" and "C++, D".

> Old Boreland "Turbo" C compiler 2.0 (closed source freeware)

Borland isn't boring. It works fine for small tools and when you care about 8086 compatibility. Borland Turbo C++ 1.01 also supports the C language and is newer than Turbo C 2.01.

Many other small compilers, e.g., Aztec C, DeSmet C, Lattice C, LSI C, Micro C, Microsoft C, Miracle C, Small C, are missing.

---
Forum admin

> > D based on GCC
>
> It's not "D" but "DJGPP".

Anybody here not use this? It's very good, still updated, very robust in features, supports most C99 and modern C++ (ANSI 1998?). My only confusion is why people say, "Back in the day I used to use it ..." when it still exists! (I guess because certain libraries aren't ported??) Good docs, lots of useful utils, good optimizations, sometimes a bit bloated (barely). Good for porting *nix stuff (not that I have, heh). I actually wonder about that comment "Without it, DOS would be dead." because that's probably half-true, at least! Kudos big time to DJ and pals!

> > WATCOM
>
> Its name is "Open Watcom C/C++".

The only no-cost multiplatform 16-/32-bit compiler that runs natively on DOS with sourcecode. Very robust, supports lots of extenders, good docs, confusing linker, a few other nifty tools too (wdis, vi, ctags, wtouch, dmpobj). This is obviously good for HX because of its Win32 output. But the C++ support isn't quite as good/modern as G++. Oh, and no newer Fortran (95, 2003) like GCC has, only old standard F77 (not that I care, I don't understand it).

> > TCC by Fabrice
> > Bellard
>
> Is this used by anyone except you?

I have it installed on Windows but not DOS. It needs MSVCRT.DLL to run (ugh). But it's a nifty compiler (aimed to support C99, not sure how far along it is, but it's supposedly very good/compatible).

> > DigitalMARS
>
> Its name is "Digital Mars C" and "C++, D".

Never actually tried this, but I hear that the 32-bit DOS extender X32 (which is incompatible with some common setups) can access 3 GB of RAM.

> > Old Boreland "Turbo" C compiler 2.0 (closed source freeware)
>
> Borland isn't boring. It works fine for small tools and when you care
> about 8086 compatibility. Borland Turbo C++ 1.01 also supports the C
> language and is newer than Turbo C 2.01.

Small memory footprint, small sized, small output, very fast compilation. Not up-to-date on latest standards (C99, C++0x) but good for 16-bit ANSI stuff. (Indeed, some legacy code won't compile without it.)

BTW, don't forget Borland 5.5, which you can WDOSX the output to run in DOS. (That also works for Delphi, supposedly.) But I haven't used that, supposedly isn't that good standards support, but it must be okay, feature-wise.

> Many other small compilers, e.g., Aztec C, DeSmet C, Lattice C, LSI C,
> Micro C, Microsoft C, Miracle C, Small C, are missing.

Micro C is good if you can work around its quirks. The output is very tiny (literally, only supports tiny or small model). But sometimes, it's better just to do straight assembly, IMO. Still, not bad to have, and it uses very little space.

Dev86/BCC is moderately good too (for its size), also only small or tiny model. Open source too, but I've never been able to cleanly recompile it (blech).

From what little I've used Small C, it's similar to Micro C (not full ANSI support, some quirks), but it's okay for really tiny programs if you can massage it enough to get it to work for your needs. Open source.

EDIT: CC386's biggest "selling points" are that it's a very small install (compared to some), fast, and supports a ton of extenders while running on a NASM backend (so no need to ever worry about or learn AT&T syntax). C only (with C99 support), but still pretty darn good. Ladsoft worked very hard on this for quite a while, so his efforts are definitely appreciated.

---
Know your limits.h

> Anybody here not use this?

It's my daily bread ...

> ... sometimes a bit bloated (barely).

My C++ "hello world" with DGPJJ v2.03 results in a 350 kB binary (with "symbols" "stripped" already). I slightly hesitate to call that "barely bloated"...

---
MS-DOS forever!

> > ... sometimes a bit bloated (barely).
>
> My C++ "hello world" with DGPJJ v2.03 results in a 350 kB binary (with
> "symbols" "stripped" already). I slightly hesitate to call that "barely
> bloated"...

I can compile PAQ8o8 to smaller than that, and it's an actually useful program! Try not using C++ streams crap, use the C-based "stdio" instead. Also, "-Os -march=i386" might help. And provide your own dummy functions for env.var. file loading and globbing (see CRT0.H). Oh, and read this.

> Many other small compilers, e.g., Aztec C, DeSmet C, Lattice C, LSI C,
> Micro C, Microsoft C, Miracle C, Small C, are missing.

Aztec, DeSmet, and Lattice were among the first Cs for microcomputers, c.1980s, so resource requirements are low. Aztec and Lattice were available for other platforms than the x86/DOS/PC, making porting from Amiga, Apple, etc. fairly easy (especially applies to Aztec for CP/M, if anybody still uses that OS). DeSmet was popular in its day, many good progs were written in it, but its power users switched to Turbo C when it got good.

Don't forget Pacific C, which is a relatively good 286 compiler. IMO better than many other old C compilers. The 486 assembler from the package is also usable.

> Don't forget Pacific C, which is a relatively good 286 compiler.

Versus Turbo C? Do you know how they compare on code generation?

> IMO better than many other old C compilers.

Well, they at one time said they'd release an improved version (open source?) and never did. I never really used it, but IIRC, it had some weird quirks in its output. Besides, ANSI C only (no C99, no C++, slightly buggy library).

> The 486 assembler from the package is also usable.

Non-standard syntax, no? And used a quite dreadful name for a debugger. But at least the IDE was fairly good.

> Aztec, DeSmet, and Lattice were among the first Cs for microcomputers,
> c.1980s, so resource requirements are low. ... but its power users
> switched to Turbo C when it got good.

Was Aztec the one by Manx or something else? I'm not even sure I know of any programs explicitly that used any of those three compilers (by Aztec: some *nix shell workalike, I forget the name). And didn't Lattice eventually get bought by MS and turned into MS C? As far as DeSmet, it's been resurrected (barely), and apparently, there was even a PCC shareware fork.

BTW, correct me if I'm wrong, but I think Turbo C was popular because of its nice IDE, low cost, and fast compilation speed.

> > Don't forget Pacific C, which is a relatively good 286 compiler.
>
> Versus Turbo C? Do you know how they compare on code generation?
>
> > IMO better than many other old C compilers.
>
> Well, they at one time said they'd release an improved version (open
> source?)

The compiler is freeware but not Open source. Package includes text-based GUI IDE, source editor, linker, assembler, Causeway DOS extender. Last version is 7.51, from 2003. If you're curious, the manual (PDF) can be downloaded separately from the compiler.

Home page: http://www.htsoft.com/products/compilers/PACIFICc.php

> Was Aztec the one by Manx or something else?

Something else.

> I'm not even sure I know of
> any programs explicitly that used any of those three compilers (by Aztec:
> some *nix shell workalike, I forget the name).

Aztec and Lattice were popular in Amiga circles, maybe Apple (i.e, they were available for Apple, but I don't know how popular they were). I can't recall seeing any DOS PC progs written in them - like DeSmet, they got wiped out early on by Turbo C for DOS, and by the end of the Amiga and Apple II.

> And didn't Lattice eventually get bought by MS and turned into MS C?

It was bought by SAS (the software company, not the airline).

> I think Turbo C was popular because of its nice IDE, low cost, and fast compilation speed.

Correct.

> Versus Turbo C? Do you know how they compare on code generation?

I'm used to look over the code generated by any compiler I test, so yes, I know. The optimized code is comparable to that of Turbo C (but as you noticed it has some weird flaws, it looks like an unfinished job), plus the compiler can pass the first two arguments in registers and has some alignment options that Turbo C lacks.

> Well, they at one time said they'd release an improved version (open
> source?) and never did. I never really used it, but IIRC, it had some
> weird quirks in its output. Besides, ANSI C only (no C99, no C++, slightly
> buggy library).

I don't think that opening the source is important (who would improve it?), the same concerning C99 and C++ support (I don't need them). What bugs has library?

> Non-standard syntax, no? And used a quite dreadful name for a debugger.
> But at least the IDE was fairly good.

Non-standard syntax, but not so different and logical enough. I don't find the debugger's name dreadful, considering its meaning. The IDE is memory hungry (both conventional and XMS) and is slow.

> > And didn't Lattice eventually get bought by MS and turned into MS C?
>
> It was bought by SAS (the software company, not the airline).

You can still buy Lattice C from http://www.lattice.com/otherdos.htm. Don't know about the prices. I asked, but didn't get any response.

---
Forum admin

> Was Aztec the one by Manx or something else?

Just have a look at Aztec-C and links from there.

---
Forum admin

> I can compile
> PAQ8o8 to
> smaller than that, and it's an actually useful program! Try not using C++
> streams crap, use the C-based "stdio" instead. Also, "-Os -march=i386"
> might help. And provide your own dummy functions for env.var. file loading
> and globbing (see CRT0.H). Oh, and read
> this.

Sorry, but it wasn't me who invented the "standard" C++ "hello, world" with io streams. And to provide dummy functions for this and that is also cheating IMO.

---
MS-DOS forever!

> I'm used to look over the code generated by any compiler I test, so yes, I
> know. The optimized code is comparable to that of Turbo C (but as you
> noticed it has some weird flaws, it looks like an unfinished job), plus
> the compiler can pass the first two arguments in registers and has some
> alignment options that Turbo C lacks.

I was looking at some asm output from TC++ 1.01 today, and it's seriously not optimized for modern cpus. "inc sp" "inc sp" via speedup option -G instead of "pop ax" (I guess? because 8086 was very slow for "pop", according to HelpPC). Still, it's a good compiler. And, as has been mentioned to me before, small changes like that don't speed up much (although I still say it's worth it, especially if you can automate the process via some text processing, e.g. sed script).

> I don't think that opening the source is important (who would improve
> it?),

I don't care (much), and I may be remembering incorrectly, but they did supposedly at one time plan / hope to release an improved version. Oh well. Strange how FreeDOS is active but some people still think nobody uses DOS. (They've probably moved on to "bigger markets", ugh.)

> the same concerning C99 and C++ support (I don't need them). What
> bugs has library?

Well, most people don't need C99, and C++ is just plain scary to me! So, I don't need 'em. (Even GCC isn't 100% C99 yet, and MSVC has no plans for such last I heard.)

But anyways, I dunno how buggy the library is, didn't mean to imply that. However, FreeDOS / Blair's MD5SUM tool generated incorrect hashes when compiled with Pacific C (vs. OpenWatcom or whatever).

> > Non-standard syntax, no? And used a quite dreadful name for a debugger.
> > But at least the IDE was fairly good.
>
> Non-standard syntax, but not so different and logical enough.

Use it if you like it, but others are faster, more modern, more popular syntax, and less buggy perhaps. There are lots of assemblers out there (unless you're Japheth, heh).

> I don't find the debugger's name dreadful, considering its meaning.

There is no worse name, IMO.

> The IDE is memory hungry (both conventional and XMS) and is slow.

I prefer using a normal text editor anyways and doing a manual compile (or make). But their IDE at least seemed logical and intuitive, IIRC.

> Sorry, but it wasn't me who invented the "standard" C++ "hello, world"
> with io streams.

Me either. At this point, I can't imagine anyone saying C++ is easier than anything. (Ah, abstraction, whoopee.)

> And to provide dummy functions for this and that is also
> cheating IMO.

Not really, they aren't needed here (or in most instances, probably). If DOS had native LFN support and super long cmdlines like more bloated OSes, then it wouldn't need to support the old and new way of doing things. But since it does, it's bloated unless you tell it to explicitly remove it. (Most people don't care because it's not a big .EXE size these days.)

> I was looking at some asm output from TC++ 1.01 today, and it's seriously
> not optimized for modern cpus. "inc sp" "inc sp" via -G instead of
> "pop ax" (I guess because 8086 was very slow for "pop", according to
> HelpPC ?).

It is a 8086-80286 compiler, so it optimizes for 80286 at best, but I find useful these old C/C++ compilers. Turbo C is the best IMO, I still use it sometimes. I wouldn't use Open Watcom or Digital Mars for writing 16-bit C code. I have no arguments, is just a question of habitude.

> But anyways, I dunno how buggy the library is, didn't mean to imply that.
> However, FreeDOS / Blair's MD5SUM tool generated incorrect hashes when
> compiled with Pacific C (vs. OpenWatcom or whatever).

I used Pacific C for compiling some small projects (just to see how it works) and I had no problems. Did you try to compile MD5SUM with it yourself? There was no warning message? Did you inform the developers?

> Use it if you like it, but others are faster, more modern, more popular
> syntax, and less buggy perhaps. There are lots of assemblers out there
> (unless you're Japheth, heh).

I know about them, and I don't use as86. But it is usable and if you need a 16-bit C compiler+80486 assembler package, Pacific C remains an option. Surely not the best, but this is another problem.

> There is no worse name, IMO.

Perhaps you know what "lucifer" means in Latin, but I'm almost sure you don't know that we inherited the word in Romanian language under the form "luceafar". The word "luceafar" never meant the devil, it was used for the planet Venus and other less important bright stars, but now is mostly used in its figurative meaning of paragon, brilliant person, genius. If it recalls you the devil before its fall, for me it simply means something bright("a luci" means "to shine" in Romanian.)

> It is a 8086-80286 compiler, so it optimizes for 80286 at best

Even Turbo C++ (which I use a lot) has a -2, but does it do anything useful?? (Haven't checked the asm output on that, maybe I should.)

> , but I find
> useful these old C/C++ compilers. Turbo C is the best IMO, I still use it
> sometimes. I wouldn't use Open Watcom or Digital Mars for writing 16-bit C
> code. I have no arguments, is just a question of habitude.

I don't use OpenWatcom exclusively, but I do think (hope?) it's better at code generation than old Borland. Then again, I haven't tested enough to know for sure. I'm just glad for the alternative.

> I used Pacific C for compiling some small projects (just to see how it
> works) and I had no problems. Did you try to compile MD5SUM with it
> yourself? There was no warning message? Did you inform the developers?

No, I didn't try with Pacific C, so I dunno if it had warnings. The developer eventually released a recompiled version done by OpenWatcom, so everything is fine. (Try recompiling MD5SUM yourself if you're curious, and report back what you discover.)

> > Use it if you like it, but others are faster, more modern, more popular
> > syntax, and less buggy perhaps. There are lots of assemblers out there
> > (unless you're Japheth, heh).
>
> I know about them, and I don't use as86. But it is usable and if you need
> a 16-bit C compiler+80486 assembler package, Pacific C remains an option.
> Surely not the best, but this is another problem.

To each his own, I guess.

> > There is no worse name, IMO.
>
> Perhaps you know what "lucifer" means in Latin,

"Light bearer", right?

> but I'm almost sure you
> don't know that we inherited the word in Romanian language under the form
> "luceafar". The word "luceafar" never meant the devil, it was used for the
> planet Venus and other less important bright stars, but now is mostly used
> in its figurative meaning of paragon, brilliant person, genius.

"Wow, that Linus Torvalds sure is a Lucifer for his hard work! God bless him!"

(Talk about a weird example sentence to put in a dictionary.)

At least where I'm from (southern U.S.), I never hear it used, proper or common noun. Meh, I just don't like it. I just find it hard to believe they couldn't just have called it "PDEBUG" or whatever.

> If it
> recalls you the devil before its fall, for me it simply means something
> bright("a luci" means "to shine" in Romanian.)

"Lucy" to me is my aunt. So I have no problem with that.

> I don't use OpenWatcom exclusively, but I do think (hope?) it's better at
> code generation than old Borland. Then again, I haven't tested enough to
> know for sure. I'm just glad for the alternative.

Yes, OW's 16bit code generator is significantly better than Turbo's one. However, it is beaten by MS VC 1.52, which most likely is the best 16bit C++ compiler of all times, past and future.

---
MS-DOS forever!

> I don't use OpenWatcom exclusively, but I do think (hope?) it's better at
> code generation than old Borland. Then again, I haven't tested enough to
> know for sure. I'm just glad for the alternative.

Surely that Open Watcom is better than Turbo/Borland C/C++, no one doubted this. But it's not as good as it could be. E. g. write a program which uses far pointer arithmetics, pass it to wcc with register calling convention and optimization enabled and then look over the assembly output and you'll understand what I mean. If you still have reasons to write 16-bit code and you are so concerned with code optimization, better use an assembler.

> No, I didn't try with Pacific C, so I dunno if it had warnings. The
> developer eventually released a recompiled version done by OpenWatcom, so
> everything is fine. (Try recompiling
> MD5SUM
> yourself if you're curious, and report back what you discover.)

Hard to belive, but I tried. Pacific C doesn't like fixed size arrays passed as parameters and it has a poor <dos.h>, but these are lack of features, not bugs. I don't think that the library is buggy, the developers would have provided some patches until now if this was a known thing.

> At least where I'm from (southern U.S.), I never hear it used, proper or
> common noun. Meh, I just don't like it. I just find it hard to believe
> they couldn't just have called it "PDEBUG" or whatever.

Actually I consider the name very suggestive for a debugger. It sheds light upon your code. About the Romanian word, you can see this (it's a Romanian explicative and etymologic dictionary, but the names of the stars are transparent in English too) and this (how the word can be translated into English). In conclusion no devil, only bright things.

> Yes, OW's 16bit code generator is significantly better than Turbo's one.
> However, it is beaten by MS VC 1.52, which most likely is the best 16bit
> C++ compiler of all times, past and future.

In about 2002, we compared the codesize for the FreeDOS kernel
produced by TC 2.01, TC++, Watcom, MS VC 1.52, Digital Mars

TC/TC++ were largest, then MS VC (~85%), then Watcom (~80%)
Digital Mars didn't compile straight due to some crazy macros/far pointer arithmetik, but would probably ended up at ~88%

Watcom allows also some funny inline assembler functions, so with a couple of #ifdefs the watcom kernel is now a few percent smaller.

If only size matters, Watcom is the best compiler around for DOS Kernel type of project.
OTOH MS VC 1.52 produces better code for 386 CPUs and DWORD operations; so your milage may vary

> In about 2002, we compared the codesize for the FreeDOS kernel
> produced by TC 2.01, TC++, Watcom, MS VC 1.52, Digital Mars

TC 2.01, TC++, and MS VC 1.52 haven't changed a lick since then (five or six years). But Digital Mars, Watcom (now OpenWatcom) are still developed (although I dunno if they really worked on the C++ much, still not nearly as compliant as G++, but 1.8 beta does have someone heavily tweaking it, supposedly). I actually heard someone claim that Digital Mars (or Zortech, whatever) was the first native C++ (PC?) compiler (i.e., not a front-end?). So, it should be good at C++, but I dunno how compatible it is in 16-bit DOS land (meh).

> If only size matters, Watcom is the best compiler around for DOS Kernel
> type of project.

Here's what Eric's latest kernel ("fat security") compile is:

Watcom sizes: 386/16 41280 /32 45857 86/16 43517 /32 46174
TurboC sizes: 186/16 42720 /32 45132 86/16 42861 /32 45267

> Nice list. What do you want?

Wanted just an overpolite, exhaustive and useful 6 words answer from Steve. Now I got exactly such, so it's now safe to F.O.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > TCC by Fabrice Bellard
> Is this used by anyone except you?

Don't know ... but it's sufficiently good to be mentioned here ... plus you are in the wrong community with your "argument" of "but only one person uses this"

And, IIRC 1 or 2 bugs of CC386 got fixed after testing against TCC

> Many other small compilers, e.g., Aztec C, DeSmet C, Lattice C, LSI C,
> Micro C, Microsoft C, Miracle C, Small C, are missing.

YES, but most of them can't compile anything recent / useful.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

D based on GCC

> refuse your list because D.... is at the first place which it doesn't deserve

The placing is random ... 1st place is not the best

> It's not "D" but "DJGPP".

NO.

++ MPLAYER got ported to DOS with it and works. No space for neglection here

+ GCC core produces less bad code ("optimization") than some other compilers
+ GCC is still under development and actively competes against VCC
+ Supports C++
+ Offers Loonix "emulation at source level", occasionally useful for porting
+ "without D, DOS would be dead" - reportedly, evidence pending
+ "D makes life easier" - reportedly, OTOH, at least, it makes video playing in DOS easier, see above, this is a "scientific" fact

- The excessive dominance / exclusivity of D prevents people from taking notice of other compilers
- Offers Loonix "emulation at source level", rarely useful, ON by default, difficult to get rid of it
- Supports C++
- Bloats executables, especially from C++
- Itself bloated and messy, not easy to download, install and use
- No 16-bit RM support
- Bad design of the "GO32" extender with outsourced CWSDPMI and non-ZERO-based memory model
- Both inline ASM and output ASM are reportedly supported, but GAS/ATT syntax only, "MASM INTEL" supposed to work but doesn't
- Can't compile itself on DOS
- It's OBSOLETE
- No project goal, 2.04 beta has been pending for 5 years, nobody knows when 2.04 final will get out, if ever, and what it should offer then
-- Startup code and libraries are bloated, messy, and full on XP hacks

> WATCOM

++ Used for FreeDOS kennel and utils

+ Both DPMI32 and 16-bit RM
+ Compiler core produces less bad code ("optimization") than some other compilers
+ Since 1.6 DOS is supported again
+ Comes with WASM, a free "unusable toy" clone of MASM
+ Supports DOS/32A and D3X extender
+ HX / LOADPEX also supported (?)
+ Supports C++

- Itself bloated and messy, not easy to download, install and use
- Supports C++, but bad compatibility with GCC and VCC ?
- Has IDE's for all platforms except DOS
- No inline ASM, no ASM output
- WASM is bad and not really progressing

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Yes, OW's 16bit code generator is significantly better than Turbo's one.
> However, it is beaten by MS VC 1.52, which most likely is the best 16bit
> C++ compiler of all times, past and future.

OK ... Lucho said the same ... Tom and Rugxulo neglect - seems to depend of source coding style and some settings

BTW, at what version did Borland drop 16-bit RM ? IIRC it was much later then in PASCAL compilers

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > > TCC by Fabrice
> Bellard
> > Is this used by anyone except you?
>
> Don't know ... but it's sufficiently good to be mentioned here ... plus
> you are in the wrong community with your "argument" of "but only
> one person uses this"

rr just loves to use the "million flies..." argument ...

However, TCC is used by more than just one person. For example, see http://www.winasm.net/forum/index.php?showtopic=2058

---
MS-DOS forever!

> - It's OBSOLETE
>

btw, the problems of DGPJJ on WinXP which are mentioned in the wiki article were to a large part due to its usage of the non-zero-based memory model. So the argument that the memory model is just relevant for low-level stuff isn't convincing.

> - WASM is bad and not really progressing

I soon shall make it progress a little...

---
MS-DOS forever!

> I actually heard someone claim that Digital Mars (or Zortech,
> whatever) was the first native C++ (PC?) compiler (i.e., not a front-end?).

Walter Bright's Zortech C++ was the first native compiler - earlier ones first expanded C++ code to C, then did the real compiling. It was available for several 80386 PC OSes & for Mac/68030.

> > Nice list. What do you want?
>
> Wanted just an overpolite, exhaustive and useful 6 words answer from
> Steve. Now I got exactly such,

I'm pleased to serve.

> so it's now safe to F.O.

Please do.

> > It's not "D" but "DJGPP".
>
> NO.

"NO" what? You give links to djgpp.

> - The excessive dominance / exclusivity of D prevents people from taking
> notice of other compilers

Duh?! It's "evil", because it's successful?

> - Supports C++

Why is this a minus? If you don't like C++, don't use it.

> - Itself bloated and messy, not easy to download, install and use

Sorry, but the DJGPP Zip File Picker is easy to use and you just have to unzip files to get DJGPP installed.

> - No 16-bit RM support

There's (outdated) experimental 8086 support at http://www.delorie.com/djgpp/16bit/.

> - It's OBSOLETE
>

Many people call DOS obsolete, but you still use it. So why do you care about?

> - No project goal, 2.04 beta has been pending for 5 years, nobody knows
> when 2.04 final will get out, if ever, and what it should offer then

OK, but djdev204 works fine. DJGPP just lacks man power to lever a 2.04 final.

> + Supports C++

Why is this a plus for OW, but a minus on DJGPP?

---
Forum admin

> Don't know ... but it's sufficiently good to be mentioned here ... plus
> you are in the wrong community with your "argument" of "but only
> one person uses this"

Please learn to set correct links! I don't see TCC mentioned in message 1024.

> > Many other small compilers, e.g., Aztec C, DeSmet C, Lattice C, LSI C,
> > Micro C, Microsoft C, Miracle C, Small C, are missing.
>
> YES, but most of them can't compile anything recent / useful.

That just depends on your point of view. If you target your project directly on one of these compilers, you would be able to produce something more useful than your "strange" FASM hacks, which are definitely not useful to me.

---
Forum admin

> Don't know ... but it's sufficiently good to be mentioned here ... plus
> you are in the wrong community with your "argument" of "but only
> one person uses this"
>
> And, IIRC 1 or 2 bugs of CC386 got fixed after testing against TCC

TCC can compile a modified Linux kernel without an external linker or assembler. Also, it's (mostly) C99 compliant. Plus, it's faster than GCC. (Granted, it could be better, but what can't?)

> > Many other small compilers, e.g., Aztec C, DeSmet C, Lattice C, LSI C,
> > Micro C, Microsoft C, Miracle C, Small C, are missing.
>
> YES, but most of them can't compile anything recent / useful.

There are a few FreeDOS utils that compile with Micro C (though less so now that OpenWatcom exists). But something like DeSmet C is more useful because it's (supposedly) more or less ANSI. Micro C and Small C are very very limited but good for some rare uses. It's more accurate to say that 16-bit anything is deprecated (deservedly or not) by most people.

> > - The excessive dominance / exclusivity of D prevents people from taking
> > notice of other compilers
>
> Duh?! It's "evil", because it's successful?

It's successful because it's GCC, it's free, it's open source, and it's stable, as well as having many support libraries (e.g. Allegro). Oh, and PM stability plus being able to access most of your RAM doesn't hurt either.

> > - Supports C++
>
> Why is this a minus? If you don't like C++, don't use it.

Agreed. I mean, GCC 4.2.3 supports C, C++, Fortran, Ada, Obj C, and Obj C++. That's quite a lot. (More if you count assembly via GAS.) Nothing wrong with that, even if I don't personally use it all.

> > - Itself bloated and messy, not easy to download, install and use
>
> Sorry, but the DJGPP Zip File Picker is easy to use and you just
> have to unzip files to get DJGPP installed.

DJDEV204.ZIP, BNU217B.ZIP, GCC423B.ZIP is the bare bare minimum. "md DJGPP" and "unzip *.zip -d \DJGPP" plus "set DJGPP=C:\DJGPP\djgpp.env" and you're set.

> > - No 16-bit RM support
>
> There's (outdated) experimental 8086 support at
> http://www.delorie.com/djgpp/16bit/.

Somebody recently submitted real 8086 patches for use in embedded work. But, 16-bit anything is frowned upon (esp. by Linux 31337).

> > - It's OBSOLETE
> >
>
> Many people call DOS obsolete, but you still use it. So why do you care
> about?

Not trendy anymore perhaps, but it still works. Just because it isn't popular doesn't mean it sucks. It's quite robust. But people follow top dogs, not the little guys. (BTW, it's completely false that it's unstable on XP or any Windows anymore. That was a long, long time ago. And that was partially due to NTVDM bugs. Nobody switched to MinGW or Cygwin because of that. Heck, those have much older GCCs than DJGPP! People may have done it for other reasons [DirectX?].)

> > - No project goal, 2.04 beta has been pending for 5 years, nobody knows
> > when 2.04 final will get out, if ever, and what it should offer then
>
>
> OK, but djdev204 works fine. DJGPP just lacks man power to lever a 2.04
> final.

Yeah, well, DJ just is really slow at updating, that's all. He's overwhelmed, probably. Besides, he has a family to support, etc.

> > + Supports C++
>
> Why is this a plus for OW, but a minus on DJGPP?

16-bit support, perhaps?? (Dunno.) They really aren't as good as G++. But it's good enough for some reasonable use, at least. I don't understand the idea that you have to code everything in only the latest, greatest standard. "Whatever works" should usually be good enough.

[djgpp]
> - It's OBSOLETE

From that article:
"While DJGPP has been widely used for OS development in the past, it's [sic] close connection to MS-DOS and compatibility problems with Windows XP have caused most Windows users to shift to Cygwin or MinGW. DJGPP must be considered obsolete by now."

The author doesn't know what djgpp is for - it is not obsolete for its actual purpose. The reference to Cygwin and MinGW is, in proper context, irrelevant.

But if it's written, it must be true - so I withdraw my comments, above.

> "NO" what? You give links to djgpp.

You've fallen into this little trap. Shame on you!

---
MS-DOS forever!

> > - Supports C++
> Why is this a minus? If you don't like C++, don't use it.

See below

> > - No 16-bit RM support
> There's (outdated) experimental 8086 support at

OK ... outdated / experimental / incomplete

> Many people call DOS obsolete, but you still use it.

YES.

> So why do you care about

Indeed no need to care too much

> > + Supports C++
> Why is this a plus for OW, but a minus on DJGPP?

Because you didn't read my post carefully I prefixed "C++" with both "+" and "-" for both D and WATCOM

> If you target your project directly on one of these compilers,
> you would be able to produce something more useful

Probably YES, to some degree (memory limits ) ...

> than your "strange" FASM hacks, which are definitely not useful

This statement is not useful , but, at least, my "strange hacks" :

1. Don't take hours to download
2. Don't pressure anybody to buy a bigger HD
3. Can be deleted easily if someone doesn't like them

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> - Bad design of the "GO32" extender with outsourced CWSDPMI and
> non-ZERO-based memory model

Could you someone explain to me what mean zero/nonzero based memory model? Resp. what are the advantages and issues of this? Why DJ decided to use it if it is SO BAD?

I use C (mostly DJGPP) because I don't want to mess with memory management and let compiler to do it for me. And I think DJGPP serves enough functions for accessing real and entire physical memory. So I don't feel bad that I have something like nonzero based model if it can properly work under common DPMI server in DOS and Windows.

---
DOS gives me freedom to unlimited HW access.

> Could you someone explain to me what mean zero/nonzero based memory model?

ZERO-based: base of CS, DS and SS is ... yeah ... ZERO 0

Non-ZERO-based: base is <>0 ... or !=0 for you ... mostly it is > 0 , but who knows, could be also < 0 maybe

> are the advantages and issues of this?

ZERO:

+ Easy access to whole memory, incl. low memory and VESA LFB
+ Better compatible with DeLL-hell ???
- Faulty C pointers can damage low memory

NON-ZERO:

+ Faulty pointers can do less damage
- Need hacks to access low memory and VESA LFB

> Why DJ decided to use it

C pointers, I guess

> I use C (mostly DJGPP) because I don't want to mess with memory management
> and let compiler to do it for me.

We know

> And I think DJGPP serves enough functions
> for accessing real and entire physical memory.

entire: YES , there are some

physical: NO , not even DPMI supports this fully: map: YES , allocate: NO

With ZERO-base, accessing VGA or VESA is as easy as:

         ; Assume DS=ES , ZERO based
         mov edi,$A0000
         mov esi,qqbuffer
         mov ecx,16000
         rep movsd

         ; Assume DS=ES , ZERO based
         mov edi,qqphys ; Physical
         ...
         blah, blah, call INT $31/$0800 to "map"
         ...
         ; Now EDI has "linear" possibly paged/mapped address
         mov esi,qqbuffer
         mov ecx,qqvesasize ; In 32bit units
         rep movsd

NO NEED to change segment registers or create a mess of selectors

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> 3. Can be deleted easily if someone doesn't like them

Did you ever hear about "deltree"?

---
Forum admin

> Here's what Eric's latest kernel ("fat security") compile is:
>
> Watcom sizes: 386/16 41280 /32 45857 86/16 43517 /32 46174
> TurboC sizes: 186/16 42720 /32 45132 86/16 42861 /32 45267

these are the sizes after compression.
if comparing codesize, you should compare before compression
(the duller the compiler is, the easier it is to compress later)
for instance the output of the dull TC code generator is much better
compressable then the output of the smart WC code generator

> You've fallen into this little trap. Shame on you!

Ich verstehe nicht.

So when are we going to see your compiler? Will you be writing it in FASM?

> Ich verstehe nicht.

Don't worry, that doesn't matter. Most people don't understand what I'm talking about. OTOH, your German is good. You can even improve it by using variations:

"ich verstehe nicht"

-> "Verstehe nur Bahnhof."
-> "Ich habe nicht die leiseste Ahnung wovon du da faselst."
-> "Was?"
-> "Könnten Sie sich bitte etwas deutlicher ausdrücken!"

---
MS-DOS forever!

> Could you someone explain to me what mean zero/nonzero based memory model?
> Resp. what are the advantages and issues of this? Why DJ decided to use it
> if it is SO BAD?

Let's don't forget that nevertheless a DJGPP ELF port exists. ELF executables are zero memory based. I know that it is not officaly supported and I don't know how much it is used, but it works, I tested it. People who complain that DJGPP executables are not zero memory based could have been more involved with my compatriot Daniel Borca's project.

> Let's don't forget that nevertheless a DJGPP ELF port exists. ELF
> executables are zero memory based. I know that it is not officaly
> supported and I don't know how much it is used, but it works, I tested it.

But for what is ELF output usefull in DOS? For linux I rather use linux gcc.

---
DOS gives me freedom to unlimited HW access.

> But for what is ELF output usefull in DOS? For linux I rather use linux
> gcc.

I was talking about Daniel Borca's DJGPP ELF port. It is about stubed ELF executables (i.e. they have appended a DOS loader), so they work in DOS.
The port is valuable by providing zero based memory model and easy to use dynamic loadable modules with DJGPP.