Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!madd
From: madd@bu-cs.BU.EDU (Jim Frost)
Newsgroups: comp.sys.ibm.pc
Subject: Re: When will Microsoft give us a *REAL WORLD* C Compiler
Message-ID: <22790@bu-cs.BU.EDU>
Date: 22 May 88 22:58:18 GMT
References: <1466@microsoft.UUCP>
Reply-To: madd@bu-it.bu.edu (Jim Frost)
Followup-To: comp.sys.ibm.pc
Organization: Boston University Distributed Systems Group
Lines: 74

In article <1466@microsoft.UUCP> markro@microsof (or uunet!microsof!markro) writes:
|We would like to address some of the questions raised by these and similar
|recent articles appearing on the net.
[...]
|Mr. Frost states that C 5.1 is at least the 6th release of MS C.  In fact
|C 5.1 is the 4th release of this compiler. 

I thank you for correcting me and for the additional information about
the history of your compiler.

|Finally we would like to say that we are committed to producing high quality,
|high performance products and to fixing all problems reported to us in a
|timely fashion.

I'm sorry, but I just can't believe this.  Those people I've met who
are doing serious development with several of your packages tell me
that your technical support is almost never timely.  In one case, a
bug in the Fortran compiler (4.0) relating to use of the 8087 was
reported by a friend of mine.  Tech support stated (after something
like an hour on hold) that it must be because he was using a clone.
He then tried using true blue, same problem.  Tech support called back
*two weeks* later to inform him that they'd found the problem, it was
a bug, and it would be fixed in a later version of the compiler.  No
immediate bug fix or indication of just how long it will be until the
"later version".  I sure hope no one was trying to number crunch with
that version of MS Fortran.

How timely *are* your bug fixes?  Compare your response time with that
of Borland.  They had several (pretty severe) problems with their
initial release of Turbo C.  Within a week or so of hearing about the
bugs, there were patches to fix them.  Within a couple of months they
had a new release of the compiler with the bugs fixed (and lots of
enhancements to boot).  Now, you've known that there was a serious
problem with loop optimization in MS C 5.1 for quite some time.  It's
serious enough that the recent Byte review stated that "loop
optimization generated invalid results" -- it showed up even in simple
benchmarks.  *Where is the bug fix*?  Perhaps Microsoft and I have
differing opinions of "timely."

"High quality, high performance products".  Ok, I'll admit that many
of your products (MS Word, Windows, Excel) are very nice.  Your very
own C compiler comes to mind as a counterexample.  Why do you think it
is that people flame about your C compiler?  Because it doesn't work
as it's supposed to.  Worse, it doesn't even work as it's *advertised*
to.  This is "high quality"?  Not in my book.  The people who I speak
to that *must* use your product ("industry standard" and all) aren't
happy about it.  If you think I'm wrong, talk to sam@vax.ftp.com, who
you flamed in your message.  Or the people who (just a few short
months ago) were discussing the possibility of a class-action suit
against Microsoft regarding MS C.

"High performance"?  Your C compiler is nicer than most *as a
package*.  The nicest thing about it is Codeview; nobody else has
that.  The code generated by your compiler is mediocre compared to
several other compilers on the market; lucky for you that their
libraries aren't quite up to par with yours.  Many compilers produce
either smaller or faster code (although few do both, and even fewer
have nice libraries).  The compilation speed of your compiler is
horrendous; few other compilers are so slow.  I don't think I'd call
your compiler high performance; it is probably the weakest part of the
entire development package.

I'm sorry I don't share your point of view with regards to your C
compiler, but as a programmer I'd rather use a programming package
without all the bells and whistles if it *works*.  Libraries can be
written.  Debugging can be done without a fancy debugger.  But writing
a program with a broken compiler is a serious problem.

|        Dave Weil
|        Project Mgr. 
|        Microsoft C Compiler

jim frost
madd@bu-it.bu.edu