DOS ain't dead - BIG "C" compiler comparison thread

DOS386

04.03.2008, 02:07

BIG "C" compiler comparison thread (Developers)

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 :hungry:

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

Steve US, 04.03.2008, 05:08 @ DOS386	BIG "C" compiler comparison thread Post reply
	Nice list. What do you want?

DOS386

09.03.2008, 02:11
(edited by DOS386, 09.03.2008, 03:03)

@ Steve

BIG "C" compiler comparison thread

Post reply

> 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. :lol:

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

Steve US, 09.03.2008, 09:40 @ DOS386	BIG "C" compiler comparison thread Post reply
	> > 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.

Japheth

Germany (South),
04.03.2008, 09:38

@ DOS386

BIG "C" compiler comparison thread

Post reply

> Please discuss here and don't pollute other threads :hungry:

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!

Berlin, Germany,
04.03.2008, 10:02

@ DOS386

BIG "C" compiler comparison thread

Post reply

> 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

Rugxulo

Usono,
04.03.2008, 14:53

@ rr

BIG "C" compiler comparison thread

Post reply

> > 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

Japheth

Germany (South),
04.03.2008, 18:32

@ Rugxulo

BIG "C" compiler comparison thread

Post reply

> 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!

Rugxulo

Usono,
04.03.2008, 18:57

@ Japheth

BIG "C" compiler comparison thread

Post reply

> > ... 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.

Japheth

Germany (South),
05.03.2008, 11:02

@ Rugxulo

No cheats please!

Post reply

> 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!

Rugxulo

Usono,
05.03.2008, 14:07

@ Japheth

No cheats please!

Post reply

> 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.)

Steve

US,
04.03.2008, 20:41

@ rr

BIG "C" compiler comparison thread

Post reply

> 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.

Rugxulo

Usono,
05.03.2008, 01:11

@ Steve

BIG "C" compiler comparison thread

Post reply

> 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.

Steve

US,
05.03.2008, 02:05

@ Rugxulo

BIG "C" compiler comparison thread

Post reply

> 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.

Berlin, Germany,
05.03.2008, 09:57

@ Steve

BIG "C" compiler comparison thread

Post reply

> > 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

Berlin, Germany,
05.03.2008, 10:01

@ Rugxulo

BIG "C" compiler comparison thread

Post reply

> Was Aztec the one by Manx or something else?

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

---
Forum admin

DOS386

09.03.2008, 02:17

@ rr

BIG "C" compiler comparison thread | evil TCC

Post reply

> > 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" :-P

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 ***

Japheth

Germany (South),
09.03.2008, 08:41

@ DOS386

BIG "C" compiler comparison thread | evil TCC

Post reply

> > > 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" :-P

rr just loves to use the "million flies..." argument ... :-D

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!

Berlin, Germany,
09.03.2008, 22:20

@ DOS386

BIG "C" compiler comparison thread | evil TCC

Post reply

> 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" :-P

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. :-P

---
Forum admin

Rugxulo

Usono,
10.03.2008, 03:29

@ DOS386

BIG "C" compiler comparison thread | evil TCC

Post reply

> 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" :-P
>
> 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.

marcov 07.04.2008, 14:30 @ rr	BIG "C" compiler comparison thread Post reply
	> Many other small compilers, e.g., Aztec C, DeSmet C, Lattice C, LSI C, > Micro C, Microsoft C, Miracle C, Small C, are missing. Tendra, TopSpeed/Clarion, Codewarrior, LCC. Iirc LLVM also has a C frontend? btw, there _is_ afaik also a gcc based D.

Rugxulo Usono, 07.04.2008, 23:57 @ marcov	BIG "C" compiler comparison thread Post reply
	> > Many other small compilers, e.g., Aztec C, DeSmet C, Lattice C, LSI C, > > Micro C, Microsoft C, Miracle C, Small C, are missing. > > Tendra, TopSpeed/Clarion, Codewarrior, LCC. Iirc LLVM also has a C > frontend? > > btw, there _is_ afaik also a gcc based D. But which of these (besides an older LCC) can run on DOS? (Probably not most.)

marcov

15.04.2008, 10:43

@ Rugxulo

BIG "C" compiler comparison thread

Post reply

> > > Many other small compilers, e.g., Aztec C, DeSmet C, Lattice C, LSI C,
> > > Micro C, Microsoft C, Miracle C, Small C, are missing.
> >
> > Tendra, TopSpeed/Clarion, Codewarrior, LCC. Iirc LLVM also has a C
> > frontend?
> >
> > btw, there _is_ afaik also a gcc based D.
>
> But which of these (besides an older LCC) can run on DOS? (Probably not
> most.)

Well, that is not the only criterium I think. Produce binaries is another one. And then most ld/as based will.

But TopSpeed has a full 16-bit range (C/C++, Pascal, Modula2 iirc) In many ways it is nicer than the BP ones, just hard to get by.

Rugxulo

Usono,
25.07.2008, 06:55

@ marcov

BIG "C" compiler comparison thread

Post reply

> > > > Many other small compilers, e.g., Aztec C, DeSmet C, Lattice C, LSI
> C,
> > > > Micro C, Microsoft C, Miracle C, Small C, are missing.
> > >
> > > Tendra, TopSpeed/Clarion, Codewarrior, LCC. Iirc LLVM also has a C
> > > frontend?
> > >
> > > btw, there _is_ afaik also a gcc based D.
> >
> > But which of these (besides an older LCC) can run on DOS? (Probably not
> > most.)
>
> Well, that is not the only criterium I think. Produce binaries is another
> one. And then most ld/as based will.
>
> But TopSpeed has a full 16-bit range (C/C++, Pascal, Modula2 iirc) In many
> ways it is nicer than the BP ones, just hard to get by.

Sorry for bumping this thread, but I found a big description of various 16-bit DOS compilers (although it's kinda old). It seems very informative.

http://compilers.iecc.com/comparch/article/91-07-041

Rugxulo

Usono,
25.07.2008, 23:15

@ Rugxulo

BIG "C" compiler comparison thread

Post reply

> Sorry for bumping this thread, but I found a big description of various
> 16-bit DOS compilers (although it's kinda old). It seems very
> informative.
>
> http://compilers.iecc.com/comparch/article/91-07-041

Found two more interesting links (although the latter seems OS/2-related but includes Borland and Watcom, which we all know about):

http://www.itee.uq.edu.au/~csmweb/decompilation/hist-c-pc.html

http://www.edm2.com/0307/compilers.html

Steve US, 26.07.2008, 00:27 @ Rugxulo	BIG "C" compiler comparison thread Post reply
	> Found two more interesting links (although the latter seems OS/2-related > but includes Borland and Watcom, which we all know about): > > http://www.itee.uq.edu.au/~csmweb/decompilation/hist-c-pc.html > http://www.edm2.com/0307/compilers.html They missed IBM's Cset/2 and C++set/2 - nice compilers, died in the market with OS/2.

Khusraw 04.03.2008, 21:51 @ DOS386	BIG "C" compiler comparison thread Post reply
	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.

Rugxulo

Usono,
05.03.2008, 01:06

@ Khusraw

BIG "C" compiler comparison thread

Post reply

> 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.

Steve

US,
05.03.2008, 01:50

@ Rugxulo

BIG "C" compiler comparison thread

Post reply

> > 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

Khusraw

05.03.2008, 08:01

@ Rugxulo

BIG "C" compiler comparison thread

Post reply

> 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.

Rugxulo

Usono,
05.03.2008, 14:04
(edited by Rugxulo, 05.03.2008, 14:27)

@ Khusraw

BIG "C" compiler comparison thread

Post reply

> 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.

Khusraw

05.03.2008, 15:46

@ Rugxulo

BIG "C" compiler comparison thread

Post reply

> 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.) :-)

Rugxulo

Usono,
06.03.2008, 04:40

@ Khusraw

BIG "C" compiler comparison thread

Post reply

> 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. ;-)

Japheth

Germany (South),
06.03.2008, 07:52

@ Rugxulo

BIG "C" compiler comparison thread

Post reply

> 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!

tom

Germany (West),
08.03.2008, 21:50

@ Japheth

BIG "C" compiler comparison thread

Post reply

> 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

Rugxulo

Usono,
09.03.2008, 00:53

@ tom

BIG "C" compiler comparison thread

Post reply

> 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

Steve US, 09.03.2008, 09:36 @ Rugxulo	BIG "C" compiler comparison thread Post reply
	> 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.

tom

Germany (West),
10.03.2008, 12:59
(edited by tom, 10.03.2008, 19:16)

@ Rugxulo

BIG "C" compiler comparison thread

Post reply

> 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

DOS386

09.03.2008, 03:02

@ Japheth

BIG "C" compiler comparison thread | WC 1.52

Post reply

> 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 :no:

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

marcov

07.04.2008, 14:39

@ DOS386

BIG "C" compiler comparison thread | WC 1.52

Post reply

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

Depending on your view with BP7 (Oct 92) or D1 (feb 95). BCC4.5 is of august that same year. Borland worked (and afaik still) alternately on a Delphi or C version. Sometimes a feature was first in the Delphi line, sometimes in the BCB line. See also http://delphi.wikia.com/wiki/Borland_Compiler_Release_Dates

D1 could only make win16 apps like BCPP4.5, but there were adapted RTLs to create 16-bit pm (286rm extender) apps.

D2+ are wdosX able. Though I don't know that many that actually used wdosx.

Rugxulo

Usono,
08.04.2008, 00:09

@ marcov

BIG "C" compiler comparison thread | WC 1.52

Post reply

> D1 could only make win16 apps like BCPP4.5, but there were adapted RTLs to
> create 16-bit pm (286rm extender) apps.
>
> D2+ are wdosX able. Though I don't know that many that actually used
> wdosx.

Doesn't FreePascal support WDOSX output (among others)? I was quite suprised recently to find out that it had so many output formats as well as many assembly output variations supported implicitly. WDOSX is very good (even if not barely updated since a long time ago and now discontinued). *sigh*

marcov

08.04.2008, 14:34

@ Rugxulo

BIG "C" compiler comparison thread | WC 1.52

Post reply

> Doesn't FreePascal support WDOSX output (among others)? I was quite
> suprised recently to find out that it had so many output formats as well
> as many assembly output variations supported implicitly. WDOSX is very
> good (even if not barely updated since a long time ago and now
> discontinued). *sigh*

Yes, at a point it worked. It was very trivial to do (since basically using the win32 port), so while one would generally assume it still does, in the meantime, an internal linker has been introduced, and somebody Dos-savy testing it would be great. Thanks!

Rugxulo

Usono,
08.04.2008, 16:13

@ marcov

BIG "C" compiler comparison thread | WC 1.52

Post reply

> > Doesn't FreePascal support WDOSX output (among others)? I was quite
> > suprised recently to find out that it had so many output formats as
> well
> > as many assembly output variations supported implicitly. WDOSX is very
> > good (even if not barely updated since a long time ago and now
> > discontinued). *sigh*
>
> Yes, at a point it worked. It was very trivial to do (since basically
> using the win32 port), so while one would generally assume it still does,
> in the meantime, an internal linker has been introduced, and somebody
> Dos-savy testing it would be great. Thanks!

You mean snapshots or just wait until the next official 2.x release? (Sorry, but it's hard to know what files are needed as various bits are lying around.) But there are a lot (well, >5, heh) of Pascal users on this board (although I'm not one, so I dunno how useful I'd be).

Berlin, Germany,
09.04.2008, 11:40

@ marcov

Free Pascal linking

Post reply

> Yes, at a point it worked. It was very trivial to do (since basically
> using the win32 port), so while one would generally assume it still does,
> in the meantime, an internal linker has been introduced, and somebody
> Dos-savy testing it would be great. Thanks!

Is the internal linker used for the go32v2 target too? Or does this target rely on ld.exe?

Btw: It's annoying that go32v2 executables become so much larger than in FPC 1.x. Why do stripped EXEs still contain strings from "$undefined" to "TResourceManager"? That are >12,500 bytes. "Hello world" in ~124K seems quite heavy anyway.

---
Forum admin

marcov

10.04.2008, 10:40

@ rr

Free Pascal linking

Post reply

> Is the internal linker used for the go32v2 target too? Or does this target
> rely on ld.exe?

External linker still. I see the internal linker there, but it is commented. So probably sb tried quickly, but it didn't work without additional debugging/work.

> Btw: It's annoying that go32v2 executables become so much larger than in
> FPC 1.x. Why do stripped EXEs still contain strings from "$undefined" to
> "TResourceManager"? That are >12,500 bytes. "Hello world" in ~124K seems
> quite heavy anyway.

No idea, and no dos maintainer to ask. win32 ones are 20k, but the internal linker strips/smartlinks better because it "knows" pascal.

While FPC doesn't like unnecessary bloat, functionality goes over size. So a few kb aren't considered a problem.

However if you have an analysis why this happens, bugreport it, maybe there is something that can be done about it easily. It could be that the 2.0 branch for Dos was never fully analysed for these kind of issues.

While you are at it, debugging the internal linker might also save some space!

Berlin, Germany,
10.04.2008, 12:18

@ marcov

Free Pascal linking

Post reply

> External linker still. I see the internal linker there, but it is
> commented. So probably sb tried quickly, but it didn't work without
> additional debugging/work.

OK, I see.

> No idea, and no dos maintainer to ask. win32 ones are 20k, but the

Yes, Win32 ones are small. Of course, Win32 builds can make use of existing Windows DLLs for doing a job, where DOS builds have to rely on a complete RTL in EXEs.

> internal linker strips/smartlinks better because it "knows" pascal.

Ah, that explains nearly everything. ;-) So the FPC guys did a good job then. :-)

> While FPC doesn't like unnecessary bloat, functionality goes over size. So
> a few kb aren't considered a problem.

I understand this, but disk space on DOS is a little different thing as you probably remember from the past. ;-)

> However if you have an analysis why this happens, bugreport it, maybe

Maybe I'd like to do, but I don't know where to start analyzing. I already tried to create a map file (-Xm?), but FPC didn't create one for me. :-(

> While you are at it, debugging the internal linker might also save some
> space!

Let's start easy. ;-)

---
Forum admin

Rugxulo

Usono,
11.04.2008, 06:32

@ marcov

Free Pascal linking

Post reply

> No idea, and no dos maintainer to ask. win32 ones are 20k, but the
> internal linker strips/smartlinks better because it "knows" pascal.

For sure there are more Windows machines than DOS ones. But I'm skeptical that that 20k is static (probably requires MSVCRT). I'm not saying you can't do it that small, just that most don't. (If it does, kudos!)

> While FPC doesn't like unnecessary bloat, functionality goes over size. So
> a few kb aren't considered a problem.

It's even mentioned on their wiki as a known issue. I mean, for now, "UPX is your friend" (sorry, Japheth, but it's true!). Besides, as has been mentioned before, "Hello world" is a bad example, not real world, overkill for FPC. Ideally, we should be comparing something like FreeBASIC or DJGPP (GCC) or GPC vs. FreePascal (using the same LIBC, I assume).

marcov

11.04.2008, 14:20

@ Rugxulo

Free Pascal linking

Post reply

> > No idea, and no dos maintainer to ask. win32 ones are 20k, but the
> > internal linker strips/smartlinks better because it "knows" pascal.
>
> For sure there are more Windows machines than DOS ones. But I'm skeptical
> that that 20k is static (probably requires MSVCRT).

Depends on your definition. Of course FPC doesn't use MSVCRT, since it is not a (MS) C compiler?!?!?

Nor does it use other DLLs, except for the two dlls that are effectively the interface to the kernel on windows: user32 and kernel32. However disallowing that would be like disallowing interrupts on Dos.

> I'm not saying you can't do it that small, just that most don't. (If it does, kudos!)

It does. FPC is also the compiler with the lowest memory use on the shootout, killing gcc. (though that is something different than binary size)

> > While FPC doesn't like unnecessary bloat, functionality goes over size.
> So
> > a few kb aren't considered a problem.
>
> It's even mentioned on their wiki as a known issue. I mean, for now, "UPX
> is your friend" (sorry, Japheth, but it's true!).

FPC does not recommend UPX, unless it is 100% required. And usually it is not, see http://wiki.freepascal.org/Size_Matters

> Besides, as has been
> mentioned before, "Hello world" is a bad example, not real world, overkill
> for FPC. Ideally, we should be comparing something like FreeBASIC or DJGPP
> (GCC) or GPC vs. FreePascal (using the same LIBC, I assume).

FPC doesn't use any libc. Not even on Unix. It is not a Unix/C compiler in disguise, but a multiplatform compiler. This is also why it is one of the few ones that target stuff like nokia phones, wince, classic Mac OS and (in the past) classic AmigaOS.

However FPC doesn't really train on small binary size, it just has a slight example, specially with benchmarky programs like "hello world" due to its architecture.

Rugxulo

Usono,
11.04.2008, 16:16

@ marcov

Free Pascal linking

Post reply

> > For sure there are more Windows machines than DOS ones. But I'm
> skeptical
> > that that 20k is static (probably requires MSVCRT).
>
> Depends on your definition. Of course FPC doesn't use MSVCRT, since it is
> not a (MS) C compiler?!?!?

Well, TCC (Tiny C) for Win32 outputs to PE .EXEs that depend on MSVCRT. And so does MinGW (right??). So, yes, some third-party compilers do use it.

> Nor does it use other DLLs, except for the two dlls that are effectively
> the interface to the kernel on windows: user32 and kernel32. However
> disallowing that would be like disallowing interrupts on Dos.

Sounds like an ideal candidate for HX! :-)

> It does. FPC is also the compiler with the lowest memory use on the
> shootout, killing gcc. (though that is something different than binary
> size)

I don't know how much GCC uses minimum, but I know that 4.x has much greater optimizations, so -O2 can use a lot more than 3.x ever did.

> > It's even mentioned on their wiki as a known issue. I mean, for now,
> "UPX
> > is your friend" (sorry, Japheth, but it's true!).
>
> FPC does not recommend UPX, unless it is 100% required. And usually it is
> not, see http://wiki.freepascal.org/Size_Matters

For DOS, it's perfectly fine (very small decomp stub too). For Win32, there is the "no shared pages" crudola, but that only applies if you intend to run tons of instances (e.g. make or bash). And it's plenty fast. The only time I've seen it slow down is DOS-packed stuff on Windows (only noticable when e.g. DJGPP itself is fully packed, and that may be more of an NTVDM issue) or huge (> 1 MB) LZMA-packed .EXEs on my old 486. So again, those problems are rare, and it's perfectly valid otherwise.

> > Ideally, we should be comparing something like FreeBASIC or DJGPP
> > (GCC) or GPC vs. FreePascal (using the same LIBC, I assume).
>
> FPC doesn't use any libc. Not even on Unix. It is not a Unix/C compiler in
> disguise, but a multiplatform compiler.

FreeBASIC (DOS, at least) does use DJGPP's LIBC.A although it is not a GCC frontend (although plans to dually output C are in the works). Just like FPC, the compiler proper is written in itself. It does, however, use (G)AS and LD (from BinUtils) for its dirty work. But FreeBASIC is still not quite as portable as FPC (officially only three hosts/targets).

> However FPC doesn't really train on small binary size, it just has a
> slight example, specially with benchmarky programs like "hello world" due
> to its architecture.

The real whiners about size tend to be assembly programmers because they know what can be accomplished in the comparable amount of code. Sure, nobody cares as much anymore now that multi-gigabyte HDs are universal, but some people still have the ideal that it shouldn't take 10x more space than it used to take unless there's a really good reason.

marcov

11.04.2008, 20:14

@ Rugxulo

Free Pascal linking

Post reply

(msvcrt, tcc and mingw use msvcrt)

I've no idea what mingw does. I don't use it. I use a few embedded (as in 8-bitters) C compilers, and occasionally a bit of VS 2003 to wrap a C++ dll in plain C. That's it.

The only times I'm busy with mingw is to @$@%#%)(*#*(*@ try to convince it to compile binutils cross to a bunch of platforms. (which is not one of my favourite excercises)

msvcrt doens't contain that much interesting stuff anyway.

> Sounds like an ideal candidate for HX! :-)

FPC has as a pro that it has very few dependancies. The main dependancy is the auto-dependancy. On non windows also as and ld, but no runtime requirements.

> I don't know how much GCC uses minimum, but I know that 4.x has much
> greater optimizations, so -O2 can use a lot more than 3.x ever did.

It's a fairly useless comparison. In FPC less stuff like locale is initialised for each binary, and the datasegment is by default a bit smaller. So it is really about startup memory (and less aggressive heapgrowing) rather than real differences. However because so many languages use glibc for everything, the difference is suddenly very pronounced.

Note that if you have a somewhat sane compiler (FB/FPC/gcc c/c++), the memory manager and the speed of primitives like memcpy() are more likely to impact performance, than this or that odd ball optimization.

> > > It's even mentioned on their wiki as a known issue. I mean, for now,
> > "UPX
> > > is your friend" (sorry, Japheth, but it's true!).
> >
> > FPC does not recommend UPX, unless it is 100% required. And usually it
> is
> > not, see http://wiki.freepascal.org/Size_Matters
>
> For DOS, it's perfectly fine (very small decomp stub too).

If you are interested in binary size, maybe. I lost that in about 1998 when I threw out the last 100MBish HD. You need to compress an awful lot of binaries to make room for a handful mp3's.

Even when I was on dialup I never used UPX. Real compressors compressed better, and I didn't have to transfer a stub with it.

> For Win32,
> there is the "no shared pages" crudola, but that only applies if you
> intend to run tons of instances (e.g. make or bash).

No, the fact that compressed pages also add to the commit charge, while memory mapped do not is still there. And memory is more expensive than disk by about a factor 1000.

> The only time I've seen it slow down is DOS-packed stuff on Windows (only
> noticable when e.g. DJGPP itself is fully packed, and that may be more of
> an NTVDM issue) or huge (> 1 MB) LZMA-packed .EXEs on my old 486.

Well, I never had a harddisk size problem that was solved by compressing a few binaries.

> > > Ideally, we should be comparing something like FreeBASIC or DJGPP
> > > (GCC) or GPC vs. FreePascal (using the same LIBC, I assume).
> >
> > FPC doesn't use any libc. Not even on Unix. It is not a Unix/C compiler
> in
> > disguise, but a multiplatform compiler.
>
> FreeBASIC (DOS, at least) does use DJGPP's LIBC.A although it is not a GCC
> frontend (although plans to dually output C are in the works). Just like
> FPC, the compiler proper is written in itself. It does, however, use (G)AS
> and LD (from BinUtils) for its dirty work.

FPC also uses as and ld on most platforms (though not on windows) including Dos, but that is perfectly possible without using libc.a

> But FreeBASIC is still not quite
> as portable as FPC (officially only three hosts/targets).

FB seems to have chosen a different direction. Not as independant as FPC, but also not as dependant as full gcc ports as GPC. I'm curious how this works out, and such issues are one of the reasons why I monitor the FB fora.

> > However FPC doesn't really train on small binary size, it just has a
> > slight example, specially with benchmarky programs like "hello world"
> due
> > to its architecture.
>
> The real whiners about size tend to be assembly programmers because they
> know what can be accomplished in the comparable amount of code.

I daily program microcontrollers with 4-8kb of memory and 32kb of flash. This is perfectly fine in plain C, until you really ship a million of these devices and a bit of asm optimizing can get you a slightly smaller flash size.

But even there the difference between 32kb and 64kb is getting lower and lower, and even that will end.

> Sure,
> nobody cares as much anymore now that multi-gigabyte HDs are universal,
> but some people still have the ideal that it shouldn't take 10x more space
> than it used to take unless there's a really good reason.

Ah well, there are also people that think they should live as cavemen, and that think that anything beyond carving into a rock with another rock should be done unless there is a really good reason.

Loonies are everywhere.

Rugxulo

Usono,
12.04.2008, 01:13

@ marcov

compression / size wars

Post reply

> You need to compress an awful lot of binaries to make room for a
> handful mp3's.

MP3 files are already compressed, and the size depends on the quality of the original recording. (If size weren't an issue, everybody would use uncompressed .WAV files for audio. And that's obviously ridiculous. My bro's iPod "only" has 8 GB, so I don't think he wants to do that.)

You can either buy a new HD every year, or you can compress that which is compressible.

You don't have tons of .ZIPs, .7z, .tar.gz, .tar.bz2, etc. files on your HD? If not, I'd be quite surprised.

BTW, DOS' FATs have file size limitations (unlike more "robust" OSes), so we're more compelled to optimize for size than otherwise. ;-)

> Even when I was on dialup I never used UPX. Real compressors compressed
> better, and I didn't have to transfer a stub with it.

Better than real compressors that are commonly used (deflate-based)? I don't think so. And 7-Zip is pretty much close to the best (or maybe PAQ8). But UPX has supported LZMA since 2.90 (currently 3.02), so it's indeed very good compression these days. And like I said, the stub is very very small (assembly, heh). With a real compressed archive, you have to unpack before being able to run it. With UPX it works as normal. (And it currently outpacks 95% of previous packers except in very rare cases.)

> > For Win32,
> > there is the "no shared pages" crudola, but that only applies if you
> > intend to run tons of instances (e.g. make or bash).
>
> No, the fact that compressed pages also add to the commit charge, while
> memory mapped do not is still there. And memory is more expensive than
> disk by about a factor 1000.

<sarcasm> Yes, that's why everybody is so memory-conscious. </sarcasm>

Every version of Windows uses more memory than the last. And Linux ain't much better (depending on distro ... one recently I saw required 1 GB RAM, meh). People don't care anymore, they just eat it all up.

> Well, I never had a harddisk size problem that was solved by compressing a
> few binaries.

There's also jump drives, floppies, ZIP drives, tape drives, CDs, DVDs, etc. You can either use a compressed file system or archivers or something like UPX. Eventually, you have to take notice of things like this (unless you don't mind making your distro use 6 CDs or several DVDs ... which some people obviously don't).

> > But FreeBASIC is still not quite
> > as portable as FPC (officially only three hosts/targets).
>
> FB seems to have chosen a different direction. Not as independant as FPC,
> but also not as dependant as full gcc ports as GPC. I'm curious how this
> works out, and such issues are one of the reasons why I monitor the FB
> fora.

They are actively working on trying to integrate it as an official GCC backend, add OOP support, make an optional C emitter (for better optimization and maybe portability), add better QB compatibility, etc. That's a lot to take on, but so far it's been pretty impressive. (And yes, FPC supporting Win64 and other non-mainstream targets is an impressive achievement too!)

> > The real whiners about size tend to be assembly programmers because
> they
> > know what can be accomplished in the comparable amount of code.
>
> I daily program microcontrollers with 4-8kb of memory and 32kb of flash.
> This is perfectly fine in plain C, until you really ship a million of
> these devices and a bit of asm optimizing can get you a slightly smaller
> flash size.

What chip / family? What compiler? Is there a RTL involved or not? C is always "good enough" until it isn't. And assembly is always "easy enough" until it isn't. That's why people still use both. :-P

> But even there the difference between 32kb and 64kb is getting lower and
> lower, and even that will end.

It's never enough. What was once acceptable is now laughable. And the cycle continues. (BTW, even SSD drives are smaller than normal and yet much more expensive. So you can't count on always having tons of space.)

> > Sure,
> > nobody cares as much anymore now that multi-gigabyte HDs are universal,
> > but some people still have the ideal that it shouldn't take 10x more
> space
> > than it used to take unless there's a really good reason.
>
> Ah well, there are also people that think they should live as cavemen, and
> that think that anything beyond carving into a rock with another rock
> should be done unless there is a really good reason.
>
> Loonies are everywhere.

One man's lunacy is another's genius. Some programmers even consider themselves artists (e.g. demo sceners or FASM dude). And they like to see how small, fast, elegant (or obfuscated, in the case of IOCCC) they can make it. It's all in good fun. ;-)

DOS386

01.05.2008, 04:49

@ Rugxulo

compression / size wars

Post reply

> need to compress an awful lot of binaries to make room for a handful mp3's.

MP3 sucks :-(

> You can either buy a new HD every year, or you can compress that which is compressible.

Or delete some useless bloat :hungry:

> BTW, DOS' FATs have file size limitations (unlike more "robust" OSes)

NO. Please fix up your facts.

> we're more compelled to optimize for size than otherwise.

YES, but for other reasons.

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

Rugxulo

Usono,
01.05.2008, 05:32

@ DOS386

compression / size wars

Post reply

> > need to compress an awful lot of binaries to make room for a handful
> mp3's.
>
> MP3 sucks :-(

.OGG is more "free", but otherwise isn't nearly as popular.

> > You can either buy a new HD every year, or you can compress that which
> is compressible.
>
> Or delete some useless bloat :hungry:

The only bloat is that which doesn't work or isn't used or useful.

> > BTW, DOS' FATs have file size limitations (unlike more "robust" OSes)
>
> NO. Please fix up your facts.

I assume you refer to FAT+? I meant generic FAT16/FAT32 are inherently somewhat limited. Not a deal breaker, just a known issue.

DOS386

01.05.2008, 05:44

@ Rugxulo

FAT OGG

Post reply

> .OGG is more "free"

Actually it's Vorbis.

> but otherwise isn't nearly as popular.

But this is a really bad reason to avoid it :clap:

> meant generic FAT16/FAT32 are inherently somewhat limited.

The most famous limits are limits of M$, not limits of FAT. Anyway, I'm developing an idea of a new filesystem removing the FAT weaknesses:

- LFN support but with rules and without hacks
- Volumes 4 KiB...4 PiB with no need of 12/16/32/64 subversions
- No "journalism"
- No 4 GiB file size limit

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

Japheth

Germany (South),
11.04.2008, 16:39

@ marcov

Free Pascal linking

Post reply

> > It's even mentioned on their wiki as a known issue. I mean, for now,
> "UPX
> > is your friend" (sorry, Japheth, but it's true!).
>
> FPC does not recommend UPX, unless it is 100% required. And usually it is
> not, see http://wiki.freepascal.org/Size_Matters

I'm going to love FPC :-D . Very reasonable page! Anyways, I appreciate any sunbeam of reason in this forum.

---
MS-DOS forever!

Steve US, 12.04.2008, 05:19 @ marcov	Free Pascal linking Post reply
	> FPC does not recommend UPX, unless it is 100% required. In their download packages, EXEs are compressed with an old UPX, including UPX with an older version of itself. 100% required?

marcov 12.04.2008, 14:41 @ Steve	Free Pascal linking Post reply
	> > FPC does not recommend UPX, unless it is 100% required. > > In their download packages, EXEs are compressed with an old UPX, including > UPX with an older version of itself. > > 100% required? What maintainers do, and what the stand of the core developers is can differ. The dos release building script are probably (literally) last century. I doubt they were revisited in recent years.

Steve

US,
12.04.2008, 16:09

@ marcov

Free Pascal linking

Post reply

> What maintainers do, and what the stand of the core developers is can
> differ.

True. But clever? I'm one of those who thinks that compression is critical for download packages, less important for EXEs (and for those, best left to users to do or not - anybody who can use a compiler should be able to handle UPX).

> The dos release building script are probably (literally) last century. I
> doubt they were revisited in recent years

They don't need to do much more than get the current UPX. Seriously - don't they know that other progs get updated too?

marcov

13.04.2008, 23:42

@ Steve

Free Pascal linking

Post reply

> > What maintainers do, and what the stand of the core developers is can
> > differ.

(should have been, "what maintainers did in the past")

> True. But clever?

Well, there is no maintainer anymore for several years, so can't ask them why they thought it was useful.

> I'm one of those who thinks that compression is critical
> for download packages,

Sure. But everything is already ZIPed. Better donate a Pascal bzip2 decompressor, and the dl sizes will decrease more, and it can be included with FPC, so other FPC programmers also benefit from it.

Moreover, we don't have to distribute UPX anymore then, so that further decreases download size.

Another thing that is coming is net installers (is that useful at all for Dos?)

> > The dos release building script are probably (literally) last century.
> I
> > doubt they were revisited in recent years
>
> They don't need to do much more than get the current UPX. Seriously -
> don't they know that other progs get updated too?

Who? Read the thread, there is no dos maintainer that does such things. The upx decision is actually from win32 related discussions.

Steve

US,
14.04.2008, 06:27

@ marcov

Compression

Post reply

> > I'm one of those who thinks that compression is critical
> > for download packages,
>
> Sure. But everything is already ZIPed. Better donate a Pascal bzip2
> decompressor, and the dl sizes will decrease more, and it can be included
> with FPC, so other FPC programmers also benefit from it.

bzip2 is available for DOS & Windows. 7-Zip can do bzip2 compression. Info-ZIP 3 will have bzip2 compression (could have it now if somebody wants to compile the beta code). And so on.

> Another thing that is coming is net installers (is that useful at all for
> Dos?)

Useless for me, irrespective of OS. I like to have the whole archive, for inspection before unpacking, and as a backup for offline use.

> > They don't need to do much more than get the current UPX. Seriously -
> > don't they know that other progs get updated too?
>
> Who? Read the thread, there is no dos maintainer that does such things.
> The upx decision is actually from win32 related discussions.

I've read it, and the situation is still weird. Somebody has been putting DOS packages together - what's the big deal about getting the current UPX before running the stupid script? Or even using 7-Zip to zip tighter than they do with an obviously old archiver.

marcov

14.04.2008, 11:03

@ Steve

Compression

Post reply

> > > I'm one of those who thinks that compression is critical
> > > for download packages,
> >
> > Sure. But everything is already ZIPed. Better donate a Pascal bzip2
> > decompressor, and the dl sizes will decrease more, and it can be
> included
> > with FPC, so other FPC programmers also benefit from it.
>
> bzip2 is available for DOS & Windows.

I know. And in lib form for djgpp, so linking compat with FPC too. But we in generally don't use external codebases in base. Hence the "in pascal" remark.

> > Another thing that is coming is net installers (is that useful at all
> for
> > Dos?)
>
> Useless for me, irrespective of OS. I like to have the whole archive, for
> inspection before unpacking, and as a backup for offline use.

We want to significantly increase the distribution, and also with cross purposes. On Dos that is not a problem, but there is a _lot_ of cross stuff and other packages for win32.

> I've read it, and the situation is still weird. Somebody has been putting
> DOS packages together - what's the big deal about getting the current UPX
> before running the stupid script? Or even using 7-Zip to zip tighter than
> they do with an obviously old archiver.

What will you use to decompress? The archive decompressor is integrated into the installer.

Anyway the people that package dos, used to do that already as a favour, and it hasn't been always the same person. And I'd rather like them to strip upx all together, which involves the removing of the file from the distro and passing UPXPROG=echo to make.

Steve

US,
14.04.2008, 13:32

@ marcov

Compression

Post reply

> >... using 7-Zip to zip tighter than
> > they do with an obviously old archiver.
>
> What will you use to decompress? The archive decompressor is integrated
> into the installer.

I meant using 7-Zip to make *.zip archives. It packs tighter than Info-ZIP and others (except on very small, or already compressed original files like JPEGs, which are not an issue here). Unpacking works with any current unzipper, .

There are other solutions too, easy to apply and needing really only a few minutes preparation. How hard is it to download an archiver/compressor and look up its commands for insertion into a script?

This might seem trivial, compared to all the other work of building a package, but reduced download time might go a long way in encouraging users to get the product.

Rugxulo

Usono,
14.04.2008, 20:00

@ Steve

Compression

Post reply

> > >... using 7-Zip to zip tighter than
> > > they do with an obviously old archiver.
> >
> > What will you use to decompress? The archive decompressor is integrated
> > into the installer.
>
> I meant using 7-Zip to make *.zip archives. It packs tighter than Info-ZIP
> and others (except on very small, or already compressed original files like
> JPEGs, which are not an issue here). Unpacking works with any current
> unzipper.

Yes, that's all correct. Or you could even use AdvanceComp to recompress any .ZIP in memory using 7-Zip's improved Deflate. It does remove .ZIP comments and extra field info, but almost nobody needs those anyways. Yes, any unzipper can unpack 'em. The only real downside is that 7-Zip / advzip run slower than normal ZIP.

Anyways, since FPC needs 386+ anyways, it might be best to just transition to 7-Zip entirely (for the distribution archives) since it compresses better (and even DOS supports it now). It has plenty of options, so it's very very flexible and still being tweaked. ;-)

> There are other solutions too, easy to apply and needing really only a few
> minutes preparation. How hard is it to download an archiver/compressor and
> look up its commands for insertion into a script?
>
> This might seem trivial, compared to all the other work of building a
> package, but reduced download time might go a long way in encouraging
> users to get the product.

<insert obvious remark about fast speeds these days>

I agree re: reduced download time, but I think some people won't. :-/
(Also, I still fully support UPX as useful in most cases.)

Steve

US,
14.04.2008, 20:16

@ Rugxulo

Compression

Post reply

> > This might seem trivial, compared to all the other work of building a
> > package, but reduced download time might go a long way in encouraging
> > users to get the product.
>
> <insert obvious remark about fast speeds these days>

Some people have broadband, some still have dialup. and it never hurts to shrink disk space requirements. Yes, I know we al have hu-u-u-ge disks now, but I still have the old-fashioned attitude - and less space used also translates into lower defrag times, an issue that gets annoyingly larger along with the disks.

> I agree re: reduced download time, but I think some people won't. :-/

But nobody will complain about smaller files, so there is no downside.

> (Also, I still fully support UPX as useful in most cases.)

Well, bro', we know that :lol: . But you know how to do it for yourself, and some people hate it, so it seems to me making it a user option is a good move.

marcov

15.04.2008, 10:40

@ Steve

Compression

Post reply

> > <insert obvious remark about fast speeds these days>
>
> Some people have broadband, some still have dialup.

Which is another subject altogether. The space savings of a different compression are relative peanuts (though specially for source archives worth the effort sometimes), compared to the natural growth of the distribution.

Let's forget about compression for a minute, and delve deeper into the dialup issue.

FPC release zips of the 1.0.x generation where 5MB, currently they are 30MB, and only because we forcedly put a break on it. If we were lax they would already be 60 MB +.

How long do you think it is responsible to hold everything up, and stop packaging new stuff, because a few remaining dialup users are holding you hostage ?

Note that these kinds of reasons are the main reasons why more and more large OSS projects are going the netinstaller direction, even though that has additional problems too.

Steve

US,
15.04.2008, 12:24

@ marcov

Compression

Post reply

> Let's forget about compression for a minute, and delve deeper into the
> dialup issue.
>
> FPC release zips of the 1.0.x generation where 5MB, currently they are
> 30MB, and only because we forcedly put a break on it. If we were lax they
> would already be 60 MB +.
>
> How long do you think it is responsible to hold everything up, and stop
> packaging new stuff, because a few remaining dialup users are holding you
> hostage ?

Not long. But nobody is holding anybody hostage either. There is still the question, How many users are you willing to leave behind?

> Note that these kinds of reasons are the main reasons why more and more
> large OSS projects are going the netinstaller direction, even though that
> has additional problems too.

Yeah, like if/when your server goes down, all your users will hate you.

Actually, the dialup thing wasn't my main concern, but I'll note a few solutions anyway.

1) Big parts of release packages are old. Build small packages with updates only (actually good for any users).

2) Sell CDs with the full kit. Easy, might make some real money too. Even people who have fast connections can appreciate the time and work they save by not having to burn and test their own CDs.

No need to reinvent wheels - others have considered the issue, and found usable solutions.

marcov

15.04.2008, 15:43

@ Steve

Compression

Post reply

> > How long do you think it is responsible to hold everything up, and stop
> > packaging new stuff, because a few remaining dialup users are holding
> you
> > hostage ?
>
> Not long. But nobody is holding anybody hostage either. There is still the
> question, How many users are you willing to leave behind?

Dial-uppers? both of them :-)

Seriously, if it turns out to be a problem, they can turn to distributions on magazine CDs (e.g. the German language area is already covered that way, and nearly any higher educational system has it somewhere anyway (due to Informatics Olympiad using it).

I believe they used to be on sale at some global site too, but haven't checked that in a while, since that is in generally better left to local initiatives (since otherwise postage will be larger than actual costs)

If it then still is a problem, I assume the dial-upers will set up a cut down distribution. But as said, we don't have any indications that it is a problem, otherwise we would have lobbyed cheapbytes and clones more.

> > Note that these kinds of reasons are the main reasons why more and more
> > large OSS projects are going the netinstaller direction, even though
> that
> > has additional problems too.
>
> Yeah, like if/when your server goes down, all your users will hate you.

Not really. Most open source installsystems work with a local dir. This also avoids redownload since you can simply place that on a network share, and all pkgs are versioned, so only new ones are updated. By using http protocol you minimize proxy/firewall problems anyway.

In an emergency network situation you can install entirely from local pkgs, at the small expense of the risk of installing outdated stuff.

See e.g cygwin.

> Actually, the dialup thing wasn't my main concern, but I'll note a few
> solutions anyway.
>
> 1) Big parts of release packages are old. Build small packages with
> updates only (actually good for any users).

But what updates exactly? There is btw also still a public SVN server (when I was on dialup I used CVS mostly too)

> 2) Sell CDs with the full kit. Easy, might make some real money too. Even
> people who have fast connections can appreciate the time and work they
> save by not having to burn and test their own CDs.

See above. That and more already done. We don't want to sell CDs ourselves currently, since there is no webshop knowledge in core. But the main point is that we don't have any indications that this is currently an huge problem.

Steve

US,
16.04.2008, 11:32

@ marcov

Compression

Post reply

> > Not long. But nobody is holding anybody hostage either. There is still
> the
> > question, How many users are you willing to leave behind?
>
> Dial-uppers? both of them :-)

In the US, millions, and for a lot of reasons. How many would get FPC if it were easier? I don't know, and neither do you. So the question stands, How many users are you willing to leave behind?

> Seriously, if it turns out to be a problem, they can turn to distributions
> on magazine CDs (e.g. the German language area is already covered that
> way,

Again, different in the very large US.

> and nearly any higher educational system has it somewhere anyway (due
> to Informatics Olympiad using it).

Fine for students, but which most users are not.

> > Actually, the dialup thing wasn't my main concern, but I'll note a few
> > solutions anyway.
> >
> > 1) Big parts of release packages are old. Build small packages with
> > updates only (actually good for any users).
>
> But what updates exactly?

Small updates that are now held until major release packages can be put together.

> There is btw also still a public SVN server

This is something to put in the webpage. And make binaries, not source only, available. Why should users be required to compile the compiler?

> > 2) Sell CDs with the full kit. Easy, might make some real money too. Even
> > people who have fast connections can appreciate the time and work they
> > save by not having to burn and test their own CDs.
>
> See above. That and more already done.

Also something for the webpage.

> We don't want to sell CDs ourselves
> currently, since there is no webshop knowledge in core.

Making/selling CDs can be outsourced, with info on the FPC webpage - consider, e.g., FreeDOS.

> But the main point is that we don't have any indications that this is
> currently an huge problem.

How could you? That is my point. But you might conduct an experiment - offer CDs for a while, and see if anybody buys them.

Rugxulo

Usono,
14.04.2008, 19:55

@ Steve

Compression

Post reply

> > > I'm one of those who thinks that compression is critical
> > > for download packages,
> >
> > Sure. But everything is already ZIPed. Better donate a Pascal bzip2
> > decompressor, and the dl sizes will decrease more, and it can be
> included
> > with FPC, so other FPC programmers also benefit from it.
>
> bzip2 is available for DOS & Windows. 7-Zip can do bzip2 compression.
> Info-ZIP 3 will have bzip2 compression (could have it now if somebody
> wants to compile the beta code). And so on.

Actually, you can use DJTAR from DJDEV204.ZIP (C src: DJLSR204.ZIP) to unpack .tar, .tar.gz, .tar.bz2, .tar.Z, or .zip (Deflate only). Of course, I guess that's out because it's not Pascal code, but it does work (and is pretty small).

> > Another thing that is coming is net installers (is that useful at all
> for
> > Dos?)
>
> Useless for me, irrespective of OS. I like to have the whole archive, for
> inspection before unpacking, and as a backup for offline use.

You mean like this?

http://www.freedos.org/cgi-bin/lsm.cgi?mode=lsm&lsm=util/fdupdate.lsm

> > > They don't need to do much more than get the current UPX. Seriously -
> > > don't they know that other progs get updated too?
> >
> > Who? Read the thread, there is no dos maintainer that does such things.
> > The upx decision is actually from win32 related discussions.

Yes, obviously we all know there is no DOS maintainer anymore. (Even OpenWatcom has none, last I heard.) For FPC, the OS/2 dude (thanks!) does the DOS releases.

Steve

US,
14.04.2008, 20:44

@ Rugxulo

Compression

Post reply

> Actually, you can use DJTAR from
> DJDEV204.ZIP (C
> src: DJLSR204.ZIP) to unpack .tar, .tar.gz, .tar.bz2, .tar.Z, or .zip
> (Deflate only). Of course, I guess that's out because it's not Pascal
> code, but it does work (and is pretty small).

7-Zip handles all those formats, packing and unpacking. So does bsdtar, which is available for Windows. Just today, GNU tar 1.20 was released, with support for 7-Zip's LZMA compression/decompression added to gzip and bzip2. With those options, and still others, there must be at least one that the Pascal gang can be happy with for archiving/compressing on any convenient OS.

> > > Another thing that is coming is net installers (is that useful at all
> > for Dos?)
> >
> > Useless for me, irrespective of OS. I like to have the whole archive,
> > for inspection before unpacking, and as a backup for offline use.
>
> You mean like this?
>
> http://www.freedos.org/cgi-bin/lsm.cgi?mode=lsm&lsm=util/fdupdate.lsm

Something like that would, I am sure, please a lot of users.

> Yes, obviously we all know there is no DOS maintainer anymore. (Even
> OpenWatcom has none, last I heard.) For FPC, the OS/2 dude (thanks!) does
> the DOS releases.

Arkady is still making his nice DOS packages for OW - a bit slow, but he's doing it. If he, or somebody, could get around to automating updates...

marcov

15.04.2008, 09:59

@ Rugxulo

Compression

Post reply

> Actually, you can use DJTAR from
> DJDEV204.ZIP (C
> src: DJLSR204.ZIP) to unpack .tar, .tar.gz, .tar.bz2, .tar.Z, or .zip
> (Deflate only). Of course, I guess that's out because it's not Pascal
> code, but it does work (and is pretty small).

Tar is no problem, there is a tar comp/decompressor in src, so is gzip (but it compresses worse then zip).

The 7z on the compression side only could be done if sb really cared. Make a nice report, test as much you can on all systems (including network drives, unix drives without full permissions, LFN, LFN on older systems, don't forget OS/2 and check availability for BeOS, AmigaOS etc), and submit it to the bugrepo, maybe sb will pick it up.

Steve

US,
15.04.2008, 11:55

@ marcov

Compression

Post reply

> The 7z on the compression side only could be done if sb really cared. Make
> a nice report, test as much you can on all systems (including network
> drives, unix drives without full permissions, LFN, LFN on older systems,
> don't forget OS/2 and check availability for BeOS, AmigaOS etc), and
> submit it to the bugrepo, maybe sb will pick it up.

Not necessary. 7-Zip's zip/bzip2/gzip compression ratios are very good, and formats are all standard.

7-Zip is released by its author only for Windows. However p7zip has been ported to a bunch of platforms - a partial list is at the 7-Zip home site. Here are a few more:

Amiga
http://amiga.sourceforge.net/?sfcontent=/project/showfiles.php?group_id=48010

OS/2
ftp://weird.da.ru/moveton/

There are also OS/2 file managers that open .7z archives.

And so on.

marcov

15.04.2008, 15:24

@ Steve

Compression

Post reply

> Not necessary. 7-Zip's zip/bzip2/gzip compression ratios are very good,
> and formats are all standard.
>
> 7-Zip is released by its author only for Windows. However p7zip has been
> ported to a bunch of platforms - a partial list is at the 7-Zip home site.
> Here are a few more:
>
> Amiga
> http://amiga.sourceforge.net/?sfcontent=/project/showfiles.php?group_id=48010
>
> OS/2
> ftp://weird.da.ru/moveton/
>
> There are also OS/2 file managers that open .7z archives.
>
> And so on.

You don't understand. If you want this, than make sure that this "in theory it should work" really works, and then submit it to FPC. Open source works through own responsibility.

So e.g.
- verify which fpc targets use zip as distribution method. (can be done from makefile)
- verify that the zip unpackers used (including several built-ins) can actually decompress the p7ziped zips. Maybe not all methods are supported. (I'm sure that one had problems with stream zipped ones).
- verify that p7zip works in the build process of said releases, including possible difficult scenario's (network, lfn on all windows and several dos versions) are tested, with the appropriate fixes to the buildsystem etc.

You can submit the patches to the buildsystems (and the chose builds for the relevant platforms) to the bugtracker.

Rugxulo

Usono,
16.04.2008, 01:13
(edited by Rugxulo, 16.04.2008, 01:25)

@ marcov

Compression

Post reply

> You don't understand. If you want this, than make sure that this "in
> theory it should work" really works, and then submit it to FPC. Open
> source works through own responsibility.

The way you describe it sounds like it's impossible to do anything! And certainly we're only talking hypothetical here, you don't have to do any of this.

> - verify that the zip unpackers used (including several built-ins) can
> actually decompress the p7ziped zips. Maybe not all methods are supported.

7-Zip usually compresses .ZIPs using "Deflate" (i.e. PKZIP 2.x), which is method 8. There's also Deflate64 (which Info-Zip UNZIP 5.5x supports) and Bzip2 (which neither PKZIP/DOS nor Info-Zip currently support ... yet). You have to explicitly tell it to use something other than standard "Deflate" if you want something else. But yes, p7zip .ZIP output is 100% compatible with other tools.

> (I'm sure that one had problems with stream zipped ones).

I'm confused here: "stream zipped" as in "data descriptor" or multi-volume? The former is rare (but used in Java .JAR files) and the latter is unavailable in current Info-Zip tools (though being heavily worked on for the next major release).

PKWARE's APPNOTE 6.3.2 (September 28, 2007)

> - verify that p7zip works in the build process of said releases, including
> possible difficult scenario's (network, lfn on all windows and several dos
> versions) are tested, with the appropriate fixes to the buildsystem etc.

The p7zip compile by DJGPP works fine in DOS and Windows (though I think it's semi-incomplete as some things weren't truly ported, only assumed to work due to no compiler errors: -w requires LFN, and on rare occasion I've had to use "/dev/c/mydir" instead of "c:\mydir" because it didn't accept it (not sure if that's because it got confused by something like C:\ZIP or not).

Also, no idea if it works on network drives, but it does work on all DOSes (with or w/o DOSLFN) and Windows by default (although Win NT needs the NTLFN TSR).

Steve

US,
16.04.2008, 10:54

@ marcov

Compression

Post reply

> You don't understand. If you want this, than make sure that this "in
> theory it should work" really works, and then submit it to FPC. Open
> source works through own responsibility.

Don't understand what? That it's my job to convince FPC that they should make life easy for more users, and show exactly how? No thanks. The wheel has been invented - if they don't want to roll along that's their choice, which they certainly have the right to make. But there are no purely technical obstacles.

marcov

16.04.2008, 16:24

@ Steve

Compression

Post reply

> > You don't understand. If you want this, than make sure that this "in
> > theory it should work" really works, and then submit it to FPC. Open
> > source works through own responsibility.
>
> Don't understand what? That it's my job to convince FPC that they
> should make life easy for more users,

There is no "fpc" and "users". It is opensource, and all responsibility is shared between all interested parties. As said, it is no priority, and if you want to speed up the priority, the only solution is to put in some work.

> The wheel has been invented

No. To stay in the analogy, it is more that somebody has drawn a rough sketch of a wheel, and then says "the problem is solved", and leaves it to others to implement and fit it under a series of cars.

Reuse of software is often portrait as easy, while it isn't.

> if they don't want to roll along that's their
> choice, which they certainly have the right to make. But there are no
> purely technical obstacles.

How do you know that if you haven't researched it? Is your knowledge of OS/2 and BeOS that well? :-)

Steve

US,
16.04.2008, 21:27

@ marcov

Compression

Post reply

> There is no "fpc" and "users". It is opensource, and all responsibility is
> shared between all interested parties.

No project really works that way. If everybody is responsible, then nobody is responsible and nothing gets done. But there is a core group that does take real responsibility and makes the serious decisions, like what will be in a package, when it will be released, etc.

> As said, it is no priority,

That's obvious.

> and if you want to speed up the priority, the only solution is to put in some work.

It is not one of my priorities. Sorry.

> > The wheel has been invented
>
> No. To stay in the analogy, it is more that somebody has drawn a rough
> sketch of a wheel, and then says "the problem is solved", and leaves it to
> others to implement and fit it under a series of cars.

A good description of how a large engineering project works, at least in the US - we have a division of labor between design and construction departments.

> Reuse of software is often portrait as easy, while it isn't.

Sometimes it's easy, sometimes it's not. Depends on how a project is organized.

> > if they don't want to roll along that's their
> > choice, which they certainly have the right to make. But there are no
> > purely technical obstacles.
>
> How do you know that if you haven't researched it? Is your knowledge of
> OS/2 and BeOS that well? :-)

OS/2, not too bad. BeOS, forget it - I hardly know what it is.

marcov

16.04.2008, 23:38

@ Steve

Compression

Post reply

> > There is no "fpc" and "users". It is opensource, and all responsibility
> is
> > shared between all interested parties.
>
> No project really works that way. If everybody is responsible, then nobody
> is responsible and nothing gets done. But there is a core group that does
> take real responsibility and makes the serious decisions, like what will
> be in a package, when it will be released, etc.

True, but those decisions have already been made. Of course compromises and sacrifices are made all the time, but in general the direction is pretty long term.

> > As said, it is no priority,
>
> That's obvious.

Maybe I was a bit rash and brusque, sorry.

It is not really an option now, but a review of the entire packaging and buildsystem is being prepared. The validation of that system could coincide with other postponed changes to the system. But that won't make the upcoming 2.2.2 versions

> > and if you want to speed up the priority, the only solution is to put in
> some work.
>
> It is not one of my priorities. Sorry.

I'm not surprised. OTOH if you don't ask, you'll never get pleasant surprises :-)

> A good description of how a large engineering project works, at least in
> the US - we have a division of labor between design and construction
> departments.

Because corporations are top down. The more grassroots forms of Open Source that FPC belongs too (despite its more centralistic core team model) isn't.

> > Reuse of software is often portrait as easy, while it isn't.
>
> Sometimes it's easy, sometimes it's not. Depends on how a project is
> organized.

There are many sides of it, but the popular blackbox model for external components without many strings or hidden costs is fatally flawed.

And that was what this was about. Research for those hidden costs.

> OS/2, not too bad. BeOS, forget it - I hardly know what it is.

Keep it that way, and forget the former.

Steve

US,
17.04.2008, 12:10

@ marcov

Compression

Post reply

> Maybe I was a bit rash and brusque, sorry.

No problem - we all get snippy sometimes.

> > A good description of how a large engineering project works, at least
> > in the US - we have a division of labor between design and construction
> > departments.
>
> Because corporations are top down.

True, but not necessarily the reason. It's more a difference between US and European customs, and notions of how many skills one person can be expected to have.

> > OS/2, not too bad. BeOS, forget it - I hardly know what it is.
>
> Keep it that way, and forget the former.

Forget the "better DOS than DOS"? Not yet. :-D

Khusraw

06.03.2008, 10:41
(edited by Khusraw, 06.03.2008, 14:03)

@ Rugxulo

BIG "C" compiler comparison thread

Post reply

> 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.

DOS386

09.03.2008, 02:49

@ DOS386

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

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 :no:

> 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 :hungry:
+ "D makes life easier" - reportedly, OTOH, at least, it makes video playing in DOS easier, see above, this is a "scientific" fact :clap:

- 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 :crying:
- 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 ***

Japheth

Germany (South),
09.03.2008, 08:56

@ DOS386

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

> - It's OBSOLETE
> :crying:

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... :-D

---
MS-DOS forever!

Steve US, 09.03.2008, 12:40 @ DOS386	BIG "C" compiler cmp \| the "scientific" facts ore out DW Post reply
	> > It's not "D" but "DJGPP". > > NO. "NO" what? You give links to djgpp.

Japheth

Germany (South),
10.03.2008, 09:04

@ Steve

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

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

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

---
MS-DOS forever!

Steve US, 10.03.2008, 13:52 @ Japheth	BIG "C" compiler cmp \| the "scientific" facts ore out DW Post reply
	> You've fallen into this little trap. Shame on you! Ich verstehe nicht.

Japheth

Germany (South),
10.03.2008, 14:43

@ Steve

Ich nix verstehen - andere Baustelle!

Post reply

> 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!

Steve US, 11.03.2008, 10:17 @ Japheth	Ich nix verstehen - andere Baustelle! Post reply
	> -> "Könnten Sie sich bitte etwas deutlicher ausdrücken!" Nein, bin kein Zug.

marcov 07.04.2008, 14:44 @ Japheth	Ich nix verstehen - andere Baustelle! Post reply
	> > 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" "ich spreche nur Platt"

Steve US, 08.04.2008, 01:43 @ marcov	Ich nix verstehen - andere Baustelle! Post reply
	> "ich spreche nur Platt" Auf Hochdeutsch geschrieben. Interessant.

marcov 08.04.2008, 14:36 @ Steve	Ich nix verstehen - andere Baustelle! Post reply
	> > "ich spreche nur Platt" > > Auf Hochdeutsch geschrieben. Interessant. Usually you say such things with a heavy accent. P.s. Het kan ook in Nederduits als dat moet: "Ik spreek alleen plat" of it kin auch in plat. Maar det is lestiger want wem witt precies wie man det schrieft. En welk plat bedoelt werd. "Ich sprek allein plat".

Berlin, Germany,
09.03.2008, 22:10

@ DOS386

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

> - 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
> :crying:

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

> - 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

Rugxulo

Usono,
10.03.2008, 03:39

@ rr

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

> > - 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
> > :crying:
>
> Many people call DOS obsolete, but you still use it. So why do you care
> about? :confused:

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.

DOS386

10.03.2008, 09:08

@ rr

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

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

See below :hungry:

> > - 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 :clap:

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

Because you didn't read my post carefully :lol3: 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 :clap:

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

Berlin, Germany,
10.03.2008, 12:31

@ DOS386

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

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

Did you ever hear about "deltree"?

---
Forum admin

DOS386

01.05.2008, 04:32

@ rr

BIG "C" compiler cmp | DELTREE

Post reply

rr wrote:

> > 3. Can be deleted easily if someone doesn't like them :clap:
> Did you ever hear about "deltree"?

YES. I know that this thing is supposed to exist ...but I have no idea how to use it :crying: But it's definitely irrelevant here since it obviously won't help you to get rid of all the Registry Crap your D installs on your "DOS" Registry :lol3:

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

Berlin, Germany,
02.05.2008, 16:20

@ DOS386

BIG "C" compiler cmp | DELTREE

Post reply

> > > 3. Can be deleted easily if someone doesn't like them :clap:
> > Did you ever hear about "deltree"?
>
> YES. I know that this thing is supposed to exist ...but I have no idea how
> to use it :crying:

RTFM or do "deltree /?".

> But it's definitely irrelevant here since it obviously
> won't help you to get rid of all the Registry Crap your
> D installs on your
> "DOS" Registry :lol3:

To write it once again today: What the hell are you talking about?

---
Forum admin

Steve

US,
10.03.2008, 06:24

@ DOS386

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

[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. :rotfl:

RayeR

CZ,
10.03.2008, 11:39

@ DOS386

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

> - 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.

DOS386

10.03.2008, 12:07

@ RayeR

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

> 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 :lol:

> 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 ***

Steve US, 10.03.2008, 13:58 @ DOS386	BIG "C" compiler cmp \| the "scientific" facts ore out DW Post reply
	So when are we going to see your compiler? Will you be writing it in FASM?

DOS386

01.05.2008, 05:30

@ Steve

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

Steve wrote:

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

NO. I won't create a compiler, and at least for you !!! So far you created over 400 posts in 9 months, and I've seen not a single line of code inside them. You posts are 100% troll crap. Just cross-copying announcements, posting stupid "answers" to all my posts (sort of "love" for me ? :-D Did you miss me in last 50 days ? ), and of course generous participation in all famewars. Actually, it's you who is fueling them most :surprised: I should create a compiler for Steve, and then Steve just answers "it's crap", because he can't do differently ? You don't need any compiler, like you don't have and don't use DOS !

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

Steve

US,
02.05.2008, 00:47

@ DOS386

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

> Steve wrote:
>
> > when are we going to see your compiler? Will you be writing it in
> FASM?
>
> NO. I won't create a compiler, and at least for you !!!

I'm hurt.

> So far you created over 400 posts in 9 months,

You counted? Now I'm flattered.

> and I've seen not a single line of code inside them.

Can't see what's not there. It doesn't need to be - it's not a requirement for membership in this forum.

> You posts are 100% troll crap.

Now I'm hurt again.

> Just cross-copying announcements,

Is that wrong?

> posting stupid "answers" to all my posts (sort of "love" for me ?

I try my best, sorry if it doesn't meet your intelligence standard. But it is all really because I do love you, and want to help you to be even better than you are.

> Did you miss me in last 50 days ? ), and of course generous participation in
> all famewars.

Absolutely.

> I should create a compiler for Steve,

For the world.

> and then Steve just answers "it's crap", because he can't do differently ?

That's basically your method. Assemblers are crap, editors are crap, compilers are crap...

> You don't need any compiler

You don't know one way or the other. And even if I don't, so what?

> you don't have and don't use DOS !

Wrong on both counts. We've had this discussion before, and repeating your silly claim now doesn't make it any more true than it was earlier.

Berlin, Germany,
02.05.2008, 16:22

@ Steve

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

> > and then Steve just answers "it's crap", because he can't do
> differently ?
>
> That's basically your method. Assemblers are crap, editors are
> crap, compilers are crap...

You forgot: MP3 is crap. :-p

---
Forum admin

Steve

US,
03.05.2008, 08:16

@ rr

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

> > > and then Steve just answers "it's crap", because he can't do
> > differently ?
> >
> > That's basically your method. Assemblers are crap, editors are
> > crap, compilers are crap...
>
> You forgot: MP3 is crap. :-p

You're right, I forgot that one. So let's get everything into the mix, by citing Sturgeon's Law, formulated by Theodore Sturgeon, the sc-fi writer:
90% of science fiction is crap, because 90% of everything is crap.

RayeR

CZ,
10.03.2008, 17:55

@ DOS386

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

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

Mean CS,.. descriptor base is 0 so then program must be loaded to some higher address to not destroy lowmem.

> ZERO:
> + Easy access to whole memory, incl. low memory and VESA LFB

I don't see this as big problem. DJGPP has functions like dosmemget(?) and movedata which do it for me.

> + Better compatible with DeLL-hell ???

What's wrong with dell?

> - Faulty C pointers can damage low memory

Understand.

> NON-ZERO:
> - Need hacks to access low memory and VESA LFB

what hacks? there are regular function for this.
1) DPMI allocate selector/descriptor
2) fill base&limit with LFB address&size-1
3) use movedata for copying offscreen buffer

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

Why do you need allocate physical memory? The usual thing is you need to use
existing memory mapped buffer in hardware to access from your program. Then you create descriptor to this area.

> With ZERO-base, accessing VGA or VESA is as easy as:
>
> [code] ; Assume DS=ES , ZERO based

Nice example. But DJGPP also has a functions for acessing VGA VRAM with near pointers so it is fast as possible.

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

Rugxulo Usono, 10.03.2008, 20:49 @ RayeR	BIG "C" compiler cmp \| the "scientific" facts ore out DW Post reply
	> > + Better compatible with DeLL-hell ??? > > What's wrong with dell? He means "DLL hell". IMO, any app using more than a few .DLLs that change often should strongly be considered to be statically built. It's just easier than trying to keep track of a billion external files. (At least, these days it's not that hard to recompile something.)

RayeR

CZ,
10.03.2008, 21:41

@ Rugxulo

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

> He means "DLL hell". IMO, any app using more than a few .DLLs that change
> often should strongly be considered to be statically built.

Oh yes, I though he mean incompatability with Dell computers :) A use Dell PC and look on Dell DFP at work, maybe a subliminary message came in my mind when I read it :P

> It's just
> easier than trying to keep track of a billion external files. (At least,
> these days it's not that hard to recompile something.)

I agree. And DJGPP already supports DXE - kinda DLLs. But I didn't saw any program which use it except coprocessor emulator.

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

marcov

07.04.2008, 14:52

@ Rugxulo

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

> > > + Better compatible with DeLL-hell ???
> >
> > What's wrong with dell?
>
> He means "DLL hell". IMO, any app using more than a few .DLLs that change
> often should strongly be considered to be statically built. It's just
> easier than trying to keep track of a billion external files. (At least,
> these days it's not that hard to recompile something.)

How does the non-zero segment change this? I doubt 32-bits DLLs have an own segment, since that would effectively create an HUGE 32-bit model.

Khusraw

10.03.2008, 16:00
(edited by Khusraw, 10.03.2008, 16:11)

@ RayeR

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

> 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.

RayeR

CZ,
10.03.2008, 17:42

@ Khusraw

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

> 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.

Khusraw 10.03.2008, 17:50 @ RayeR	BIG "C" compiler cmp \| the "scientific" facts ore out DW Post reply
	> 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.

RayeR

CZ,
10.03.2008, 17:56

@ Khusraw

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

> 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.

Aha, OK, good to know...

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

marcov

07.04.2008, 14:55

@ RayeR

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

> > 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.

I'm not sure (I don't know it), but maybe not having to backport debugging info to an own file format? One could lift on the base ELF/Dwarf support.

Or is LE/LX already dwarf? PE (mingw)is with 6.8 dwarf afaik.

Rugxulo

Usono,
08.04.2008, 00:02

@ marcov

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

> > But for what is ELF output usefull in DOS? For linux I rather use linux
> > gcc.
>
> I'm not sure (I don't know it), but maybe not having to backport debugging
> info to an own file format? One could lift on the base ELF/Dwarf support.

For sure ELF is more prevalent (Linux, BSD) than COFF is. The DJGPP/ELF can share with others better, I suppose.

> Or is LE/LX already dwarf? PE (mingw)is with 6.8 dwarf afaik.

OpenWatcom supports three kinds of debugging info: Watcom, DWARF (default since 11.0), or CodeView. And DJGPP now uses STABS (I think?) unless you type "-gcoff" or "-gdwarf-2", and I dunno if RHIDE supports other than COFF (but RHIDE is dead so ...).

Rugxulo

Usono,
11.03.2008, 19:29

@ DOS386

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

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

There's a D (compiler) port to Linux as well as the typical Win32 version. However, DJGPP doesn't support it.

> + GCC core produces less bad code ("optimization") than others

Intel is still better (supposedly, esp. for SSEs) but not free (except for Linux??). Nevertheless, I think GCC is easily "good enough".

> + Offers Loonix "emulation at source level", occasionally useful for
> porting

POSIX, not Linux, and even that isn't the most recent POSIX standard (which is much more complex).

> - Offers Loonix "emulation at source level", ON by default, difficult to
> get rid of

Well, DJGPP is primarily a port of GCC, so it's going to have lots of GCC-isms. Even though "GNU's Not Unix", it might as well be.

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

Actually, it's quite easy, but you have to read the FAQ for more in-depth answers.

> - No 16-bit RM support

Unavoidable since GNU targeted only 32-bit machines. Plus, 16-bit RM caps out a 1 MB, so DJGPP doesn't have that limitation.

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

GO32 was DJGPP v1, and v2 is much much improved in almost every way (more features, more compatible, more powerful). v2 is like 12 years old (at least), so surely they could do it differently, but I doubt they want to start from scratch and make v3.

> - Both inline ASM and output ASM are supported, but GAS/ATT
> syntax only

I dunno about that. "-masm=intel" seems to work in my simple tests, but I don't use it much.

> - Can't compile itself on DOS

Well, LFNs are a b**ch that people take for granted these days. I'm more annoyed by the fact that newer GCCs aren't compatible with each other (e.g. need specific GCC, even to compile itself!), even more than the annoying fact of needing a bunch of auxiliary tools just to build something simple.

> - It's OBSOLETE

You can't (easily?) access the Win32 APIs with it, I guess, which is what most people prefer these days. Also, Windows is no longer DOS-based, so interest has waned (due to compatibility bugs). But also, it's not "cool" anymore. :-/

> -- Startup code and libraries are bloated, messy, and full on XP hacks :-(
> :-(

Unavoidable, I guess, unless you want to exclude it (unwise, since XP is ubiquitous, at least for now).

> + Both DPMI32 and 16-bit RM

But no 16-bit DPMI (286) stuff. In fact, almost nobody bothers with that (probably because they don't know how). Not that I really care, though.

> + Compiler core produces less bad code ("optimization") than some other
> compilers

Yeah, but I don't think it really targets specific cpus like GCC does. Even "-6" still runs on a 386.

> + Since 1.6 DOS is supported again

Not really sure what that means (WLINK bugs fixed?). AFAIK, it has always worked on DOS.

> + Comes with WASM, a free "unusable toy" clone of MASM

Not unusable, but not quite perfect. You can't necessarily expect all your old MASM code to assemble without problems.

> + Supports DOS/32A and D3X extender

The version of DOS/32A included is 7.xx, which is obsolete. D3X is not included (although it does work).

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

Well, I dunno why they removed the (unfinished) DOS installer from the server. Also, I dunno why they don't just make a DOS .ZIP. At least I tried to make a small (6.5 MB) DOS install package (1.7a-RC1) on my site (needs UNUHARC and 24 MB to unpack, though). That's better than having to download 60 MB, IMO. (Unless you want all the other targets, e.g. Win32).

> - Supports C++, but bad compatibility with GCC and VCC ?

Not bad compatibility, just not as modern. C++ is so complex and always being extended (it's alliiiiiive!).

> - Has IDE's for all platforms except DOS

DOS has their VI editor. I'm not sure it qualifies as an IDE, but it does work.

> - No inline ASM, no ASM output :-(

I haven't messed with inline asm on OpenWatcom, but I think that's what WASM is for. At the very least, I know "#pragma aux" is how they used to do inline. So, it's indeed possible.

BTW, OpenWatcom targets .OBJ directly (I think), so you need WDIS to convert to assembly source. This is what "OWCC -S" (GCC compiler driver clone) does.

> - WASM is bad and not really progressing

That's true, nobody is officially working on it. Then again, interest is probably low. There are other assemblers (e.g. NASM or LZASM) that support .OBJ, though.

---
Know your limits.h

Steve

US,
12.03.2008, 08:01

@ Rugxulo

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

> Intel ... not free (except for Linux??)

There are both commercial (expensive) and non-commercial (free) packages for Linux. Free evaluation versions of commercial packages are however available for all OSes.

All Intel compilers for Windows, Linux, Mac:
http://www.intel.com/cd/software/products/asmo-na/eng/compilers/284132.htm

BTW, if you want programs to run on AMD CPUs, it's best to avoid Intel compilers altogether.

Rugxulo

Usono,
12.03.2008, 20:13

@ Steve

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

> > Intel ... not free (except for Linux??)
>
> There are both commercial (expensive) and non-commercial (free) packages
> for Linux. Free evaluation versions of commercial packages are however
> available for all OSes.

All OSes? Even DOS? ;-) (Did they ever support DOS?)

Last I heard, it was $129 for the student/home version (Win32). And the evaluations are one time only. Blech. God bless DJ Delorie! :-D

> BTW, if you want programs to run on AMD CPUs, it's best to avoid Intel
> compilers altogether.

I think that was due to them not testing AMD chips at all, only their own. And I think it was buggy (or completely disabled) SSE support only. (I can't remember, but it's something like Athlon XP that finally had SSE, and all AMD64 have SSE2). That was old version 9.0, though, so they supposedly have improved since then. (Besides, there were unofficial patches for the Linux version.)

But FYI, all that's second-hand info, I've never used any Intel compiler.

---
Know your limits.h

Steve US, 13.03.2008, 04:10 @ Rugxulo	BIG "C" compiler cmp \| the "scientific" facts ore out DW Post reply
	> All OSes? Even DOS? I meant for all the OSes they support - Win, Linux, Mac. > (Did they ever support DOS?) Probably once upon a time, but not now (not for public release, anyway).

DOS386

01.05.2008, 04:43

@ Steve

BIG "C" compiler cmp | INTEL

Post reply

> All Intel compilers for Windows, Linux, Mac:
> http://www.intel.com/cd/software/products/asmo-na/eng/compilers/284132.htm
> BTW, if you want programs to run on AMD CPUs, it's best to avoid Intel

It's best to avoid INTEL since it doesn't run on DOS.

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

Steve US, 02.05.2008, 00:51 @ DOS386	BIG "C" compiler cmp \| INTEL Post reply
	> > BTW, if you want programs to run on AMD CPUs, it's best to avoid Intel > > It's best to avoid INTEL since it doesn't run on DOS. Irrelevant.

marcov 07.04.2008, 14:58 @ Rugxulo	BIG "C" compiler cmp \| the "scientific" facts ore out DW Post reply
	(annoy mode on) > Unavoidable since GNU targeted only 32-bit machines. Plus, 16-bit RM caps > out a 1 MB, so DJGPP doesn't have that limitation. To my best knowledge it also supports 64-bit fine and some near models in 64-bit mode

Rugxulo

Usono,
07.04.2008, 23:38

@ marcov

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

> To my best knowledge it also supports 64-bit fine and some near models in
> 64-bit mode :-)

Yes, I know. I was mainly referring to this:

> (quoting DJ Delorie):
>
> DJGPP was born around 1989 [...], when Richard Stallman spoke at a meeting
> of the Northern New England Unix Users Group (NNEUUG) at Data General,
> where I then worked. I asked if the FSF ever planned on porting gcc to
> MS-DOS [...], and he said it couldn't be done because gcc was too big
> and MS-DOS was a 16-bit operating system. Challenge in hand, I began.

The FSF specifically didn't even try to port GCC etc. to DOS, so it had to be done independently.

---
Know your limits.h

marcov

10.04.2008, 10:22

@ Rugxulo

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

> > (quoting DJ Delorie):
> >
> > DJGPP was born around 1989 [...], when Richard Stallman spoke at a
> meeting
> > of the Northern New England Unix Users Group (NNEUUG) at Data General,
> > where I then worked. I asked if the FSF ever planned on porting gcc to
> > MS-DOS [...], and he said it couldn't be done because gcc was too big
> > and MS-DOS was a 16-bit operating system. Challenge in hand, I began.
>
> The FSF specifically didn't even try to port GCC etc. to DOS, so it had to
> be done independently.

Sounds to me that RMS (probably the one mostly working on gcc at that time) had no time or interest, or easier platforms to port too (a free extender didn't exist then either).

The way you present it sounds like a conspiracy theory. I don't read that in DJD's words however. They just didn't plan it AT THAT POINT.

Rugxulo

Usono,
11.04.2008, 06:27

@ marcov

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

> Sounds to me that RMS (probably the one mostly working on gcc at that
> time) had no time or interest, or easier platforms to port too (a free
> extender didn't exist then either).
>
> The way you present it sounds like a conspiracy theory. I don't read that
> in DJD's words however. They just didn't plan it AT THAT POINT.

I'm not trying to skew the words, but it sure sounds like they never intended or wanted to port to DOS at all. I don't think they ever pretended to want to do so. They considered DOS inferior and wanted to write their own OS (HURD?). They basically said something like, "While *nix is imperfect, it's as good as we've found so far." It was what RMS was familiar with.

DJGPP is a huge achievement, and we're lucky someone had the guts and skill to do it. For sure, it was a huge amount of work. I'm not denying that. It just wasn't ever planned or desired by the FSF (AFAICT). Especially since DOS (at the time) was a proprietary OS with no "free" compatible alternative. I do know that CDs ("back in the day") with DJGPP on them sold quite well, raising lots of money for the FSF to continue their goal. And the FSF did (last I checked) have a link to FreeDOS on their site (well, it is GPL, how could they not like it?).

marcov

11.04.2008, 20:18

@ Rugxulo

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

> > The way you present it sounds like a conspiracy theory. I don't read
> that
> > in DJD's words however. They just didn't plan it AT THAT POINT.
>
> I'm not trying to skew the words, but it sure sounds like they
> never intended or wanted to port to DOS at all.

Well, I don't read that there. I was actually using unix at that time, and it was before extenders were available, and before the avg PC user had a 386 (there were only some in research institutes, typically not running dos) No wonder that they thought it was impossible.

> They considered DOS inferior and wanted
> to write their own OS (HURD?).

They said similar stuff about Linux, and FreeBSD was considered even more evil since it was free.

> I'm not denying
> that. It just wasn't ever planned or desired by the FSF (AFAICT).

So? They probably didn't plan a port to 64-bit windows either. Or to linux, since it didn't exist at that time.

> it is GPL, how could they not like it?).

I'm actually not that fond about the GPL.

DOS386

01.05.2008, 04:41

@ Rugxulo

BIG "C" compiler cmp | the "scientific" facts ore out DW

Post reply

> You can't (easily?) access the Win32 APIs with it

T.R.N. & Co. should just switch to MinGW, problem vanished :hungry:

> Unavoidable, I guess, unless you want to exclude it (unwise, since XP is
> ubiquitous, at least for now).

Why not, MenuetOS apps don't work "natively" in XP either, and nobody cries :-)

> Not really sure what that means (WLINK bugs fixed?). AFAIK, it has always
> worked on DOS.

IIRC 1.5 didn't.

> > + Comes with WASM, a free "unusable toy" clone of MASM
> Not unusable, but not quite perfect. You can't necessarily expect all your
> old MASM code to assemble without problems.

Obsolete problem :-)

> > + Supports DOS/32A and D3X extender
> The version of DOS/32A included is 7.xx, which is obsolete.

NO. 7.xx is fine besides 9.xx. OTOH complete DOS/32A using the WATCOM design could be considered as obsolete in favor of LOADPEX.

> BTW, OpenWatcom targets .OBJ directly (I think), so you need WDIS to
> convert to assembly source. This is what "OWCC -S" (GCC compiler driver
> clone) does.

OK ... I'll check. Still, direct NASM/FASM output is ways better.

> > - WASM is bad and not really progressing
> That's true, nobody is officially working on it.

No longer. :-)

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

DOS386

01.05.2008, 04:30

@ DOS386

BIG "C" compiler cmp | new facts ore out: OW TCC CC386

Post reply

Some additional / newer info:

TCC:

+ Very tiny
+ Mostly C99 compatible
+ Low additive bloat
+ No external linker needed

- Seems to have some severe bugs (crashes on it's own source, EBP+xxx vs EBP-xxx gets messed up in some cases ?)
- Additive bloat is low, but code generation very inefficient
- Source badly-hacked to Win32, "of course can compile itself" no longer valid ?

WATCOM:

+ Good DOS support again (except extender so far)
+ LOADPEX support in 1.8 ?
+ Good warnings
+ Less bugs in compiler core
+ Very great JWASM ASAP ? :-)

- Horrible packages (both installers and ZIP's)
- Can't compile itself on DOS
--- DOS version still uses DOG/4SW for both host and target, 13 years after it's death, 8 years after Cause Way was released into Public Domain, and 6 years after PMODE/W and DOS/32A got available !!!

CC386:

+++ Can compile itself on DOS (unique)
+ Inline ASM with NASM syntax
+ ASM output in NASM/FASM syntax
+ Tiny
+ LOADPEX support
+ Comes with VALX and INFOPAD

- Bad warnings
- Severe bugs in compiler core :crying:
- Now not under development

Although it has bugs and is now "dropped" I still highly appreciate it. It has been under development for 10 years, and dropped for 3 months so far. So no final death, nor waste of time.

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

Rugxulo

Usono,
01.05.2008, 05:27

@ DOS386

BIG "C" compiler cmp | new facts ore out: OW TCC CC386

Post reply

> TCC:
>
> - Source badly-hacked to Win32, "of course can compile itself" no longer
> valid ?

Right, I tried and failed too. I guess you really need MinGW + MSYS. (If anybody here builds statically and gets it working under HX, please post here!)

> - Horrible packages (both installers and ZIP's)

Well, I'll admit, some of those .ZIPs are really small and have like two (useless by themselves) files. So, I'm not exactly sure why they don't just lump some of them together (e.g. all DOS extenders) into one .ZIP. But I'm not exactly volunteering (yet).

> - Can't compile itself on DOS

A lot of DOS packages don't build on DOS (esp. re: DJGPP). LFN issue? Other?? (How hard is it, really, to support both?)

> --- DOS version still uses DOG/4SW for both host and target, 13
> years after it's death, 8 years after Cause Way was released into Public
> Domain, and 6 years after PMODE/W and DOS/32A got available !!!

I dunno, maybe some tools (\BINW\vi.exe ??) rely on it for some odd reason? (At least, Alt+M reports very inaccurate !negative! numbers with other extenders, at least CWSTUB or DOS/32A.)