1237d02d75b8
c_echo



Hello Bob - 

>> I've always used Borland's C compiler for the majority of
>> DOS coding here. I have used Pacific C (now free) but not
>> the more recent version of Pacific. 

BS> Likewise... I've put in a lot of hours with Borland
BS> compilers (I *hate* the current 5.5 product!), but only
BS> took Pacific out for a test drive some years ago. 

The older Pacific C (K&R) would fit on one 1.4meg floppy which
I thought was a hoot! Being K&R became a 'stopper' but it was
neat that you could put it on one floppy. :-) 

BS> The older Borland compilers were quite decent. My only
BS> serious complaint about them is that Borland's better
BS> compilers couldn't digest a lot of published C code written
BS> for MSC, and that their later compilers which could digest
BS> MSC code were nowhere near as good. 

I did/do appreciate the level of compatibility with existing
MSC code that Borland C can manage but, as you say, it's not
100% and some recoding is usually required although at times
very minor. 

>> My memories of the introduction of GPL by Stallman was that
>> it _reduced_ the amount of C code being freely distributed
>> and discussed rather than increased it (as people seem to
>> think it did). His insistence on licensing, even though GPL,
>> made programmers more aware their code was being used to
>> earn money by others and made them more paranoid about
>> sharing said code. 

>> > Q: Is this how you interpreted those events at the time or
>> > am I 

>> the only one who saw GPL as a 'negative' overall? 

BS> I've always viewed GPL as an abomination. It accomplishes
BS> little other than muddying the waters. 

I remember that the majority of programmers actively sharing
code at one time were very much against GPL and considered
Stallman an outsider (as primarilly a mainframe programmer) who
wasn't entitled to interject his philosophy into what he really
wasn't a part of. 

At one point GNU seemed to have died but the popularity of
Linux brought GNU back from the dead. Apparently Stallman could
smell the blood? 

BS> I bet Stallman is really popular around
BS> Christmas/birthday/anniversary/etc. times - "Here's your
BS> gift and here's the list of what you can and can't do with
BS> it." 

I like that, saved to disk. ;-) 

>> Pacific C might be another alternative for DOS? 

BS> Quite possibly, but I don't know enough about it to
BS> recommend it. 

I will try to get it installed here and see what it's like now
in a newer (too big for one floppy) version. 

>> My perspective is that using "Hello World" as a test is a
>> bit deceptive overall. Even if inclusion of stdio.h and it's
>> somewhat bloated printf() does produce large executables the
>> 'hit' happens only one time in a larger application suite of
>> C code. 

BS> The only thing you can tell from a "Hello world" program is
BS> the size of the essential C runtime components. I've found
BS> it tells you little about a compiler's overall ability to
BS> produce tight code. 

I agree that you can 'see' the size of the runtime components
but there are so many other ways a compiler can produce bloat
that it seems only relevant for embedded where they tend to
count bytes. ;-) 

The hardware we all have (even me) and the software we use
daily is so bloated that size has to double before anyone gets
uncomfortable and even then it's considered a speed bump by
most (yes, even me). 

For anyone reading this message that is truly interested in
the size of binaries this one programmer's story about how
he managed to reduce the size of a binary might be interesting
reading.  When I read this website it reminded me of similar
discussions that I followed between Unix C programmers many
many years ago.

(from a link at my tech website):

http://www.muppetlabs.com/~breadbox/software
/tiny/teensy.html


>
>        ,                          ,
>      o/      Charles.Angelich      \o       ,
>       __o/
>     / >          USA, MI           < \   __\__
 

___ * ATP/16bit 2.31 * 
... DOS the Ghost in the Machine! http://www.undercoverdesign.com/dosghost/

--- Maximus/2 3.01