Using Visual Studio 2010 and the C Programming Language
Writing C programs and building them with MAKE was fun back in the days of DOS 3.3 and Borland's Turbo C. Although I would have liked to have found an employer who would pay me to write C programs all day, it was not to be. I started out in a small I.T. department where there were support-related tasks, hardware and software installation and maintenance, user administration and training, and every other task my bosses wanted done. This was fine, as it gave me a broad range of experience. This was in the days of the 8088, 286, and 386. Lotus 123, Word Perfect, and a company called Ashton-Tate. I was more than happy to take on any task they asked me to do, even if it was spending an hour with a person who had spent her entire career using a typewriter and now had to understand how to save a "file" in a "directory". One of my biggest regrets was the way I taught these concepts. Terrible teacher. I should never have used the word "directory" in the first place; it sounds too much like a phone book. I could see the look of confusion on the person's face when I tried to describe how to save files on a disk and store them in different directories (this was before Microsoft had the good sense to start calling them "folders", but that was only after Windows came out and you had the luxury of showing little pictures of file folders on the screen). Instead, I should have used simpler terms. They already knew how to give a document a name (only 8 characters, remember?) and I should have just said "from now on just type another name in front of it and use the back slash to separate them. Backslash? What's a "backslash". "Oh, it's this key over here, see, it kind of leans backwards... err.. to the left, whatever."
Sometimes the manager would ask me to solve a problem that required custom programming. That gave me the chance to write some Lotus macros and dBASE III programs. Programming! Yay! But there was not enough time in the day to develop a database system in C, so I had to use RAD ("rapid application development") tools and say goodbye to C. I did find a C database library called CodeBase that was very well regarded in magazines like PC Magazine and Doctor Dobbs Journal, but I did not have enough confidence in my C programming skills to be certain that the purchase of this library was going to pay off for my employer. In addition, I am not a confident, persuasive person to begin with, so I just never got around to having that meeting with my boss where I try to talk her into spending $500 (in 1988) on software. I just said, forget it, I'll learn dBASE III+, which I found to be as much fun as C. Other locations within the company were using FoxBase, with which I was not familiar. When the disaster known as dBASE IV came out (oh agony), I tried what was then called FoxPro and found I could live with it.
Now fast-forward to today. I'm retired, so now it's all for fun. So nice setting up Ubuntu Server with no GUI, just a command prompt. The vi editor is built to be loved. Using make and the GNU C libraries is an absolute joy.
But I'm pathologically restless, and after a few week of this GNU pleasure I decided (subconciously seeking pain?), to see what it was like writing command-line C programs on Windows 7
On Windows, MAKE is called NMAKE. The compiler is called CL.EXE and the linker is called LINK.EXE. The first thing I tried was opening a command window and typing NMAKE and got 'NMAKE' is not recognized as an internal or external command. On my computer, there are two versions of NMAKE:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\nmake.exe
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64\nmake.exe
You have to add one of these directories to your PATH, which then allows you to simply type NMAKE on the command line. Which directory you choose depends on your target architecture, 32-bit Windows or 64-bit Windows.
Command Prompt
Windows 7 has a main menu item called Command Prompt. When you open a command window you get a session; when you close the window the session ends.
The default command window's environment variables can be viewed by entering the SET command. You can create your own environment variables. For example, entering SET ZPATH=C:\ creates an environment variable named ZPATH with a value of C:\. You can then type SET and see your environment variable listed along with all the others. Why have environment variables? Environment variables can be read by command line programs; they are a way for you to communicate some information to a program.
If you close your command window, open it again, and type SET, you will see that ZPATH is gone. Environment variables you create on the command line during a session exist only for the life of the session; when you end the session any environment variables you created during that session vanish.
Permanent Environment Variables
You can create environment variables that persist from session to session.
If you right-click on Computer on the Start Menu and choose Properties from the pop-up menu, you get a dialog box. Click on Advanced system settings and then Environment Variables. This gives you a dialog box that lets you set permanent environment variables, which persist even if you restart the computer.
Session Environment Variables
There is another approach you can take. You can create all of your environment variables in a batch file and run that batch file every time you open a command window. The environment variables created this way still disappear when you close the command window, but you don't care, because they will be created by the batch file every time you open the command window. You can also create your own shortcuts to the command line and customize each one with different environment variables. To see how this is done, go to the Start menu and select Microsoft Visual Studio and Visual Studio Tools. You will see three menu options that open special Visual Studio command windows:
- Visual Studio Command Prompt
- Visual Studio x64 Cross Tools Command Prompt
- Visual Studio x64 Win64 Command Prompt
The difference between these special Visual Studio command prompts and the regular command prompt is the addition of the environment variables INCLUDE, LIB, and LIBPATH and the path to NMAKE.
You can then use a text editor to create the makefile and the source code and build the executable in the command window.
Using the Visual Studio IDE
Another approach is to do all of your work in Visual Studio. I used Visual Studio for about two years developing C# applications for my last employer and really enjoyed it a lot. The debugging power of Visual Studio is impressive.Unfortunately, I failed to configure Visual Studio to be the simple C development environment (with debugger, of course!) that was satisfactory to me.
You are supposed to be able to use the Empty Project and Makefile Project templates, and I did spend some time trying to get them to work, but I found the process convoluted and confusing. I couldn't get the debugger to work (which is my main reason for using the IDE in the first place) and gave up in frustration. No matter what configuration options I tried (and I tried many of them) the IDE still presented my C projects with a C++ project "look and feel", even when I was able to turn off all the C++ stuff (there are compiler options to ignore C++ and just use C) it still displayed remnants of C++. As this was several months ago, I don't remember all the details, but my mind is made up: I gave up on using Visual Studio for C.
