If you're using a more recent compiler, with a ``visual'' or graphical user interface, it will probably run in its own window (or set of windows) under Microsoft Windows. (As mentioned in the MS-DOS section above, there are also a few MS-DOS command-line compilers which bring up their own full-screen interfaces, and much of the discussion in this section will apply to them as well.) You'll typically invoke or open the compilation environment by double clicking on its icon, or perhaps by typing its name at a DOS prompt.
A visual compiler revolves around the concept of a project or program. The project or program is built from one or more modules or source files, including the ones you'll create and type in. Once you've got everything set up correctly, you'll be able to click on a ``Build'' or ``Run'' button, or make one of these selections from a menu, to have all aspects of compiling (and perhaps running) your program taken care of automatically.
The question is, of course, how do you ``get everything set up correctly''? You will probably have to open a New Project or New Program, perhaps from a Project or Program menu. You will probably have to pick a name for the project; for the first ``Hello, world!'' example, a good name would be simply ``hello''.
Step 1: entering or editing your source code
Once you've opened a new project, it will be empty, without any modules or source files to build it from. So your next step will be to add one. You'll probably request a New source file (either from the Project, Source, or File menus), and doing so will bring up a source file editing window, in which you can begin typing your source code. At some point, you'll be asked to select a name for the source file, which will be something like hello.c.
The source code editing window will work much like a text editor or word processor, except that it will be streamlined and tailored for the typing and editing of C source code. You may find that the cursor automatically indents itself on each new line, as the editor guesses the syntax and structure of the C program you're typing. It may even display different bits of the program (keywords, identifiers, comments, etc.) in different colors; perhaps this is thought to make a program easier to read.
Once you've successfully opened a source code editing window, type in the program (if it's an initial example from the class notes or from a book) exactly as shown, including all punctuation, and with the lines laid out just as they are in the code you're typing in. (Later, we'll learn what does and doesn't matter in terms of program layout: where your degrees of freedom are, what the compiler does and doesn't care so much about, which syntax you have to get exactly right and which parts allow you to express some creativity. For now, though, just type everything verbatim.)
Whether or not the compiler explicitly prompts you to, you will eventually want to do a Save or Save As, to save your work to disk. Again, you will always use a name ending in .c for source files. If you've just invoked the compiler for the first time, the default directory (or folder) where you'll first end up trying to store your own source files may end up being the compiler's installation directory. This isn't ideal, and although it would probably work, you'll be much better off creating your own directory or folder, somewhere else, where you'll keep all your own source files and programs that you've written or typed in, and where they can stay separate from all the compiler's supporting files.
The compiler may automatically add new source files (once you've typed them in, and given them a name) to the current project or program, or you may have to explicitly use an Add selection (perhaps from a source or project menu) to add them to the current project. Somewhere, there should be a window or other display which lists the ``modules'' that make up the current program. Make sure that, eventually, a name incorporating the word ``hello'' shows up on this list (assuming you've named your source file hello.c).
Later, when you have occasion to come back to an existing source file to edit it, you'll be able to open it using Open (instead of New) from a File menu, or perhaps by selecting its name from within the compiler's list of files or modules which make up the current project.
Step 2: compiling the program
Modern compilers typically include several different compilation modes, and although some of them might not end up mattering very much for the simple programs we'll be writing, it's worth paying a bit of attention to their selection, for best results. Somewhere (perhaps in the Project menu) there will probably be a menu or dialog of ``Compiler Settings''. One choice may be the ``Input Language'', and it may have options like ``ANSI C'', ``ANSI C with Extensions'', ``C++'', and ``pre-ANSI'' or ``K&R'' or ``Classic'' or ``Traditional C''. For this class, you definitely want the ``ANSI C'' option, or as close as you can get to it. (Any extensions, no matter how seductive they sound, are unnecessary and would only get in the way, besides intruding on our goal of learning portable C.)
Another selection may concern the type of program or executable or application to create--there may be selections with names like ``Windows Application'' or ``Console Application'' or ``stand-alone executable'' or ``run within compiler''. Definitely don't request a Windows Application; that would require that you learn how to open windows (from the program side) and learn the rest of the Windows API, and it would prohibit you from using our most basic library function, printf. A ``console application'', if you see a choice like that, is much more like what we want: this arranges that a window be opened automatically, in which our printf output will appear, and into which we can type any input which our program expects, all without our having to worry about the gory details of Windows. The result is a ``console'' or ``virtual terminal'' environment just like the old-fashioned ones which the C textbooks and tutorials (mine included) all still assume you're using.
If you have a choice between running your program within the compilation environment versus creating a standalone executable, you may do either, but you should understand the distinction. If you run within the compilation environment, it means that you'll ask the compilation environment to run your program, and it will open a new window to do so. Creating a standalone MS-DOS executable, on the other hand, means that the compiler will write an executable file to disk (perhaps automatically picking a name like HELLO.EXE, or perhaps prompting you for one). You'll then invoke your program yourself, by typing its name at a DOS prompt. (If you were creating a standalone Windows application, you'd invoke it by double-clicking on it, but as mentioned, we're probably not ready to create standalone Windows applications.)
Once you've made your selections of input language and output format (and any other choices which look interesting, such as how verbose you want the compiler to be about warning you of possible errors, and how hard it should work at ``optimizing'' your program--you'll probably want to choose ``very'' and ``not very'', respectively), you're ready to actually do the compiling. There may be a Compile or Build or Make button or menu selection somewhere (again, perhaps on the Project menu). Or, especially if you've selected ``run within compiler'', there may simply be a Run button (or a top-level Run menu) which first automatically compiles and builds your program and then, if everything is successful, takes you directly to step 3.
As helpful and integrated and hand-holding as these visual compilation environments try to be, they tend to let you down and leave you out in the cold in one respect, namely the automatic selection and incorporation of the standard C libraries. If, when you first try to build or run your program, you get error messages telling you that functions (or ``external references'') with names like printf are ``undefined'', this means that the compiler wants you to explicitly tell it that yes, you do want to make use of those standard library functions which your textbook and instructor assured you would be provided by the compiler vendor. (It may even want you to tell it where they are.) If so, you will have to go back to the Add Module (or perhaps Add Library or even Add Source File) menu, and tell the compiler that your project is made up of more than just the one source file you gave it. You will have to add (as a module or something) the ``Standard'' or ``ANSI'' C libraries. To do so, you may end up going through a standard file-opening dialog, and you may have to wander over to the compiler's installation directory to find the library (it may be in a subdirectory or subfolder called ``LIB''). If you find several versions of the libraries, having to do with different ``memory models'' (or beginning with different cryptic letters like S, M, C, or L), then you'll have to pick the right one somehow, although I hope you don't have to, because picking the right one depends on which memory model the compiler is compiling for, which would be another compiler setting which I didn't talk about.
(I realize that this subsection, in fact all of this section, has been pretty generic, and not very ``step by step''. Eventually, I may be able to learn enough about the popular Windows C compilation environments to provide specific instructions for each of them. Until then, if you're having trouble, you may be able to glean some hints from reading through the detailed instructions in the Macintosh section below, although the discussion there is of course of a compiler other than the one you're using.)
Step 3: running the program
Depending on the style of program or executable you've built, there will be a couple of different ways of running your program. If you're running it within the compilation environment, it will be particularly easy; you'll just select something like Run Program from the Project or Run menu. (In fact, it may be so easy that steps 2 and 3 meld together.) If you've created a standalone executable, you'll have to return to the DOS prompt (i.e. switch to a ``DOS box'') and type the program's name there, perhaps after changing to the correct directory. If you're invoking a standalone executable from the DOS prompt, you can read some notes about input and output redirection at the end of the MS-DOS section above.
Read sequentially: prev next up top
This page by Steve Summit // Copyright 1995-9 // mail feedback