Feedback and Suggestions on GCC

["Davis, Roy" <Roy dot G dot Davis at compaq dot com>]

My name is Roy Davis.  I currently work as a Senior Consultant at Compaq
Computer Corporation, and worked for Digital Equipment Corporation for about
20 years prior to it's being acquired by Compaq.

I was looking for a quick alternative to Microsoft's Visual C++ compiler,
and tried yours.  And I felt I should give you some feedback on it.
Unfortunately, this feedback is more negative than positive.  But I will
give you suggestions on how to address the issues I present to you.

Let me set the stage for this feedback by emphasizing the work "quick."  I
was looking for something I could install quickly and get up and running
quickly with little or no learning curve.  I have no background in any
flavor of UNIX; nor do I have any inclination to learn the UNIX environment
just to run a C++ compiler.  This is because my work is currently, and will
remain for the foreseeable future, in the Windows environment.  And I only
had about a day to get something working.

Now for the feedback.  I attempted three approaches in the order stated
here:

*	First, I attempted to following the instructions at
http://gcc.gnu.org/install/index.html.  This simply didn't work on a Windows
2000 Professional system.  I couldn't get past Step 2 (Configuration) of the
installation procedure.  After downloading and unpacking the files specified
in Step 1 (Download the source), I attempted to execute CONFIGURE.BAT as
directed in Step 2.  The chain of directory/folder references in
CONFIGURE.BAT and other batch files it calls is not consistent with what the
unpacking produced.  After tracking down this chain, I found the use of
"sed" a requirement.  I know of no Windows 2000 systems in this building
that have "sed".  I could get a copy of "sed", but then it too has set up
and has learning requirements for which I do not have time.  And the saga
continues...but I need not go any further.  Simply put, a Windows person
with no UNIX experience would find this whole process very difficult at best
(and perhaps impossible at worst).

*	Second, I was able to follow the instructions for installing the
"Cygwin" environment.  SETUP.EXE worked very well.  However, the environment
it presented was [as stated in the instructions] purely UNIX oriented.
Since Cygwin presented a command line interface, a Windows person would have
liked to just simply start using basic Windows command-line commands such as
CD, EDIT, etc.  A Windows person may not have the time or the inclination to
learn a whole host of UNIX concepts and commands as mount points just to
edit source code and run a compiler.

*	Third, I then tried the DJGPP version.  Even though DJGPP is
intended for use in the DOS environment, it was indeed easy to install,
quick to learn, and worked very well in Windows 2000.  There was no need to
learn UNIX concepts and commands since I was able to do the basic things I
needed (create and edit source code, invoke the compiler and linker, etc.)
from the command line under Windows.  The only problems are that DJGPP
(being targeted to the DOS environment) does not make use of Windows
capabilities, and that it lacks some of the modern ISO/ANSI C++ features.

Now for my suggestions on how to address these issues (if you want to have a
broader user base in the Windows environment):

*	The simplest thing is to take DJGPP and, while keeping it based on a
command line interface, update it to (1) fix any bugs since the last
release...2.03 about a year ago, (2) consider replacing DPMI and making it a
real Win32 program.  But keep the command line interface:  it's nice, and
don't waste time replacing it with a GUI.

*	Clean up CONFIGURE.  In fact, take it a step further and do away
with it.  Simply replace Step 2 and CONFIGURE as described above with a
simple unpacking procedure that generates the required directory/folder tree
with all the binaries already installed.  And then provide directions for
setting up a few environment variables such as PATH, LIB, etc.  The notion
that a typical applications programmer wants to configure and build a
compiler, linker, and other related utilities from scratch is absurd.
That's the sort of thing a systems programmer might want to do.  [I know,
because I've done both systems programming and applications development.]

*	To the extent I tried to make the Cygwin environment useful, it
appeared to really be a command line interface...not a GUI...even though it
presented itself through a "window."  That's fine, but make it quickly
useful to Windows users by having a Windows command line set as an
alternative to the UNIX command line set...perhaps by simply having invoke
COMMAND.COM or CMD.COM.  After installation, a Windows user should simply be
able to invoke Cygwin and start issuing commands like CD, EDIT, etc., and
not have a huge learning curve.  But as it is, Cygwin is frustrating and
useless to Windows people who lack UNIX background, and are not going to
take the time learn UNIX.  In short, if it runs on Windows and is supposed
to be a Windows application, then either give it a standard Windows GUI look
and feel or a standard Windows command line interface.
 
Finally, please understand that my comments and suggestions and not a
"Windows versus UNIX thing".  Having dealt with several operating systems
(IBM, CDC, General Automation, Digital Equipment, and Microsoft), I'm not a
zealot about any one operating system.  I just want to get the task at hand
done quickly, efficiently, and correctly.  And that is the basis of my
comments and suggestion.

Thank you for consideration and your time.

Roy G. Davis
Senior Consultant
Compaq North American Customer Services