Provide Feedback on this Broadcast

Note This document is based on the original spoken WebCast transcript. It has been edited for clarity.

Zach Kramer: We'll be looking at a few basic things. Our goals today (slide 2) are to introduce the Microsoft® Visual Studio® suite in a very high-level fashion. We will learn a little bit about using Visual Studio .NET to write some basic C and C++ code. We'll also be examining what the different project types are, so you know your way around the development environment a little better. Then we'll also hit some highlights on building and debugging C and C++ code.

The first topic will be the introduction (slide 3), where we'll cover what the Visual Studio environment is and what we will be doing, what it's used for. Then we'll look a little bit at how C and C++ and Microsoft interact. Then the next thing we'll look at is the different project types in Visual Studio. Then we're going to highlight one specific project type, which is the Win32® project type. Then we'll wrap up with a few closing thoughts.

The Visual Studio .NET environment is an integrated development environment that's meant to make developing easier, quicker, faster, and more productive (slide 4). It's basically a suite of tools that helps you to build, test, and develop your application. Visual Studio .NET supports many different languages. The main languages that it supports, out of the box, are C#, Visual Basic® .NET, J#, and, of course, what we're here to talk about today, C++.

Visual Studio .NET uses the concept of solutions, which are made up of projects. Projects can be of many different types, and be of different languages, also. Visual Studio also has the ability to allow other language developers to integrate with it. So, for example, Python and other languages are also integrated into the development environment.

Visual Studio .NET has many different types of users (slide 5): people who are developing Web applications or applications for a Windows® PC, as well as academics, hobbyists, and experts. It has a variety of different types of users, which comes with many different expectations, goals, and reasons for using the environment. Today, we're here specifically to talk about people who use Visual Studio .NET to program C++ code, and we're focusing more on the standard-based C++, not any of the extensions or things like that.

With Visual Studio .NET trying to be all these things to all different people, one might think that maybe they have forgotten about the C and C++ user, and they haven't (slide 6). Visual Studio .NET provides a lot of productivity features for people who are just trying to learn C++, either for fun or as part of a class — maybe a computer science class or something — or for those users just looking to write basic, standard, focused code. So let's take a look now at how Microsoft and Visual C++ fit together (slide 7).

C and C++ are both well-defined standards that are independent of Microsoft. C was originally defined by the ANSI organization, and C++ was defined by ISO, which is the International Standards Organization. These standards are both publicly available. Basically what happens is Microsoft or the GNU compiler will implement these standards in their compiler, so you can write C++ code that their compilers will then compile for different platforms.

Microsoft's compiler is Cl.exe. The newest version of our compiler, the one that ships with Visual Studio .NET 2003, has reached 98 percent ISO standard compliance. Microsoft is very committed to standards adherence, and it's something that we've worked very hard to achieve.

With that being said, we can look at how Microsoft implements the standard (slide 8). Basically, standard code is from the C++ standard is implemented inside of our C runtime. So when you call, say, printf or something like that, underneath it's going to use the code that's in the C runtime to execute that printf command. Microsoft ships all of that source code with Visual Studio. You can find that in your Visual Studio installation directory under VC7, where you'll see a CRT directory and then an SRC directory (<VS Installation>\VC7\CRT\SRC\).

We also ship the header files that you'll include with your C++ project in the VC7\Include directory. The source code is then built into either a .dll or into your application. The .dll form of the source code is usually Msvcrt, or in the newer versions of the product it's Msvcr71.dll. Basically what will happen here is that when you build an application that uses standard code, it will compile and then load one of these .dll files to perform the operation. The compiler enforces that your code is adhering to the standard, and then uses these .dll files when you run your application.

If you're interested in more information about these CRT libraries, there are a couple of Knowledge Base articles that are very helpful. There's one with information about which C++ library you want to link with (154753), and then information about the standard C++ library (154419).

The C runtime (slide 9), as I said, implements things like printf from a C standard, and then cout, which would be from C++. There are many links and more information about our standard, and how to use these functions and different things like that, in MSDN®, and you'll see some links to some resources at the end of this presentation.

Now what we'd like to look a little bit at (slide 10) are the different project types inside of Visual C++. There are many different project types that allow you to do many different tasks quickly or easily. Some of the basic project groups that we have are ATL, MFC, your managed C++, and then Win32 projects.

The ATL projects will help a user write componentized code, like a COM .dll or something, very quickly and easily. MFC allows users to write Windows code, for a Windows application, and to view it quickly and easily. Then Managed C++ is the newest project type that allows you to take advantage of our .NET Framework from the C++ environment.

The one that we're going to focus on the most today is the Win32 project. This is the simplest project type that we have. As you'll see in the next two slides, the way that Visual C++ groups these projects is a little bit different between the 2002 version, which is the first version of Visual C++ .NET, and the 2003 version, which is the most recently released version.

In Visual C++ .NET 2002 (slide 11) there was only one generic grouping, which was just Visual C++ Projects, as you can see on the left. Then on the right you would see many different project templates. You'll see MFC, Managed, and then the Win32 Project that we were talking about. This Win32 Project you see here would be the one that we would use for our application today.

In Visual C++ .NET 2003 (slide 12), they've organized it a little bit differently. So as you see on the left side, there are different folders for .NET, ATL, MFC, and Win32. And under Win32 they've added an additional project type, called a Win32 Console Project. So we'll select that.

Then you would type a name for your project, in the Name box, and then underneath that is the location where that project will be created. Visual C++ will, in the location folder, create a folder that is the same name as your application. And then it will put all of your related files in that folder. After we've selected a location, selected our Win32 project type, and typed in a name for our application, we click OK and this will create our project.

Let's take a second here to talk about Win32 projects and what they are (slide 13). Win32 projects are the most basic type of project that Visual C++ offers. They provide a few basic types of functionality, by default. They provide you support for all of the C++ standard code, like, as we were talking about before, your printf and your cout. And they also provide support for calling Win32 APIs.

A Win32 API is basically the code that makes the operating system do something specifically. Now printf is going to print to a file, but it's going to wrap the call to the API. So if you were to look in the C++ source code, down way low, you would find a call to an API like WriteFile when you made a call to printf.

So with these two basic features in a Win32 project, there are a few variations on a Win32 project. There's a console type project, a Windows project, a static library, and a dynamically linked library. The console project is the one that we'll focus on today. Basically this allows you some input and output via the command line. So you can bring up a command window with the command prompt, and you type in your program name, and it then prints something out and maybe prompts you for input. And you input that information, and it outputs some information. This is a very basic project type. Some might consider it something like an MS-DOS® project.

Then the second project type that you had was Windows, which would basically provide you with a simple "Hello World" application that displays a window on the Windows desktop. The other two add the ability for you to write functionality that will be then used later in another project.

So let's take a look at what happens when we create a console project. When you select the Win32, it will bring up an overview of the settings that are already set. On the left side you can click Application Settings, and then we want to select the Empty project option. This will create a very basic project with no source code. One of the other things that this does is it disables precompiled headers.

Precompiled headers in Visual Studio allow you, when you compile multiple times, to compile quicker. It takes commonly used files and compiles them just once, and then reuses them multiple times. Now if you're compiling a small application, like a little C++ application for a class, this is probably going to get in the way more than it's going to help for your application, so it's best that we have it disabled.

Now if you happen to enable it, and you don't include StdAfx.h in your application, you'll notice a compiler error, C1010. This will tell you, basically, that you have precompiled headers enabled, but you're not using them correctly. So there's a nice Knowledge Base article (815644) that talks about how to turn off the precompiled headers if you happen to leave them on.

Now let's look at exactly what this Application Settings window looks like (slide 15). What you'll see here is the Application Wizard, and this is what appears after you click OK to create the project. The screen shot that I have here has been switched from Overview to Application Settings. What you'll notice is that even though we've already selected Console application, we could change it here to Windows application, DLL, or Static library. Basically, what that selection does is it sets the default. So we want to make sure that Console application is selected, and then down below Application type you see a group of settings called Additional options, and this is where we select Empty project. So now that we have Console application selected, and we've selected the Empty project option, we're ready to click Finish, and allow the development environment to create the project and solution file for us.

Now that we have our project, we can take a little tour of some of the very basic features that are offered right now (slide 16). One of the features is Solution Explorer, which allows you to look at the files that you have in your solution. One thing that we can also do is look at the properties of our project. This is where all of the different settings for your project are controlled from. This can be accessed in two different ways. One way is from the Solution Explorer. You can right-click your project, move down the menu, and select the Properties option on the shortcut menu. Or from the Project menu inside the development environment, you can also select Properties.

This will bring up a window that looks similar to this (slide 17). Basically this allows you to control all of the details of your project. There's a group of different folders; one is C/C++. This is basically where all the different settings that get set for your compiler are controlled. Then underneath that, there's a Linker folder, which contains all the different settings that are set for your linker. There's also the ability to control build events, pre-build and post-build. This allows you to control your command lines. If you need more information on what these settings do, the MSDN covers these in much more detail.

Now that we know where we can set different settings on our project, we know that we need to add a source file to our project, so that we can type in the code that we have. The easiest way to do this is to just right-click your project again in the Solution Explorer, select Add from the shortcut menu, and then select Add New Item. This brings up the Add New Item dialog (slide 18).

Inside the Add New Item dialog you can select many different types of files, but the one that we're going to select here is the C++ File. This allows you to create both a C and a C++ file by just setting the extension when you type in the name. So in the Name box we'll type main.c. This will create a C file for us. As you'll notice in the Location box at the bottom of this dialog, it's going to save it in the folder with the rest of our application.

After you've typed in a name, you can click Open, and this will open our C file for us. Then we can simply add the following text to this new file. And this is just a very simple Hello World (slide 19). We basically have the #include of <stdio.h>, which is our standard input and output for C programs. Then we have our int main(), and we simply do a printf to print out the phrase Hello World.

Now the reason we made sure to add this file with the .c extension is because when the Microsoft compiler compiles this C code, for this file with the .c extension, it will force it, all the code in that file, to only be C standard code. If you try to use a C++ function like cout or something, you will get compiler errors, because the compiler is using the C version of the standard to compile this code.

Now what if we wanted to add a C++ file to a project? We do the same thing. We bring up the Add New Item dialog (slide 20) by going through the Solution Explorer and selecting Add New Item. We still select C++ File, but this time we would type main.cpp. The .cpp is going to tell the compiler to use the C++ standards when we compile. So after we have added this file, we can then add some code to that main.cpp. Now this code (slide 21) is similar in function to the code that we added to the C file, but it has some different syntax. So, basically, instead of including <stdio.h>, we include <iostream>, and notice that there is no .H on the end of that.

We add a call to using namespace std, and then instead of printf we have cout << HelloWorld and then the end line. Basically we've done the same function as the C code, but this time we've done it in C++. One little note here is that C++ code files with the .cpp extension can also contain C code. So you could have also written printf and included <stdio.h> here, and that would have worked as well.

Something that you may have noticed is that the <iostream>, as I mentioned before, did not have a .H on it (slide 22). In previous versions of Visual Studio you used #include <iostream.h>. Well this isn't strictly standard-compliant. So Microsoft, in its push for standard adherence, has moved this new version of the standard header file. So basically you include <iostream> or <iomanip>, or any of these other different standard header files, and all of their functionality is contained inside of a namespace now. So that is why we have the call to using namespace std;. Or you could simply qualify your calls into the standard header files by using the output that we have there, where it's like std::cout or std::endl.

Basically what this does is it provides a hierarchy where all of the functionality from these multiple header files is contained inside of one namespace. The call to using namespace std; says that you won't need to fully qualify those name anymore.

Now with Visual Studio .NET 2002 and Visual C++ 6.0, both the non-.H versions and the version of the standard header files with the .H shipped with the product. But in Visual Studio .NET 2003, we no longer ship the .H version, so you're forced to use the non-.H versions, which are the standard adherent versions of the standard header files.

So we've added a source file, either a .cpp or a .c file, and now we need to be able to build our project (slide 23). Building basically takes our files, compiles them, and links them together in an executable that we can then run, test, or use for our purposes. The Visual Studio environment provides two basic operations. You can either build or rebuild.

To build an application is to basically compile each of the different source files into intermediate files, and then link them all together. A build, if you have already compiled before, will only build the files that have changed, and then re-link all of the intermediate files.

Now a rebuild, basically what it does is it cleans all the intermediate files, and then builds everything from the beginning. Basically it does a clean first.

So to build your project, you can either right-click an individual file and select Compile, which would generate the intermediate version of that file, or you can right-click your whole project and select Build. From the Build menu you can select Build and your project name, or there's even a shortcut: CRTL+SHIFT+B.

To rebuild is similar. You right-click the project, and instead you select Rebuild, or you go to the Build menu and select Rebuild and your project name.

Now the Build menu also contains options for building and rebuilding solutions. Because a solution is a group of projects, you can say, "I want to rebuild every project in this solution." Now if your solution, as with most simple projects, contains only one project, then doing a build or rebuild for the solution is the same, basically, as doing a build or rebuild for the project.

Now that we have our project build, Visual Studio provides you with a way, from the environment, to run your project and see what happens (slide 24). You can do this in two different, basic ways. You can go to the Debug menu and say, Start without debugging, or you can simply press CTRL+F5. This will bring up a command window and run your application within that command window. When your application is done running, it will pause the command window and not let it close, so that you can examine the output.

Now we said we wanted to start without debugging, that was what we just did by pressing CTRL+F5 or selecting the menu option, which brings up the question what exactly is debugging, and what would happen if we started with debugging? First off, a debugger (slide 25) basically is a way of allowing you to interact with your code as it runs. So you can pick a certain line of code and say, "I want you to pause when the execution reaches here." Or you can say, "When a certain variable reaches this value, I want you to pause the loop." Or any number things to help you troubleshoot your application if there's a problem at run time.

So a simple way to show this would be in the main file that we created, either main.cpp or main.c. We could go to the line that says return 0. You can simply press the F9 key; that will set a breakpoint. A breakpoint says, "When running this application and we reach this particular line, I want you to pause and wait for me to tell you to continue." So if we press the F5 key or go to the Debug menu and select Start, it will start our program, running under the debugger.

But you'll notice that the program never completes its execution, and this is because it has paused right at that return 0 where we set the breakpoint. If you have some variables defined, you can look at the values of the variables. Then when you're ready to continue running, you can press the F5 key, which will start your program up again, and continue running.

Now we have a couple of closing thoughts (slide 26). Basically, you may notice that there are two different types of builds that you can do: debug and release build. A debug build is simply designed for troubleshooting during your development. There are no compiler optimizations or anything, and basically everything is left as you wrote it.

The release build optimizes your code to make it faster, smaller, or more lightweight, for example, but this can make it slightly harder to troubleshoot, because the compiler may have changed your code a little bit to get it to execute faster.

The default, when you create a project, is it will build a debug build. Now you may also want to add additional projects to your solution, and this can be done simply by clicking the File menu with your solution open, selecting Add Project, and then clicking the New Project option, and then you can add either another Win32 project or other types of projects that you wish.

Finally, when we build our application, where do these binaries end up, the .exe that Visual Studio was running? Well, it's very convenient. It puts it in the project directory where your files are saved, and then it creates a folder based on the type of build that you're doing, either debug or release. Then all of the files that are generated during the compile, and the final built .exe is placed in these directories.

The final slide that we have is some additional resources, if you want some more information. There's a new KB article that was just written (829488). This contains most of the steps that we covered in this WebCast, in a very easy-to-reference format. Then also, there are three other links, which contain information about standards, the Microsoft implementation of the standards, and other references. So that about wraps up what we have here today.

Otto Cate: Great. Thank you very much for the presentation. I'm going to jump into the Q&A section here in a couple of minutes.

Just a reminder, the PowerPoint® slides, if they were difficult to view in your browser today, or if you'd like to simply have a copy of those slides, are available for download, in the same location as the on-demand streaming archive. All that's available on www.support.microsoft.com/webcasts. Simply click today's event.

The Q&A portion of the Support WebCast is intended to encourage further discussion of the topic that Zach has addressed today. In addition, one-on-one product support issues are outside the scope of what we're able to address during the Support WebCast session. So if you do find that you need some more complex technical assistance, perhaps on a particular issue, feel free to contact Product Support Services directly in that case, either on the Web or by phone.

Just a reminder, this is the only time that you'll be able to ask Zach questions.

It looks like we did just get a question here: Will you continue to offer some beginner training for programming, such as for Visual Basic 6.0 or .NET?

Zach: I know there will be training out there. I don't know specifically what Microsoft will be offering. I know that we try and provide some things through WebCasts, and then if you have specific questions about a task or something you're trying to get started with, Product Support Services is always there to give you a hand with that.

I know that there are some WebCasts out there. If you have specific questions about something, there is Dr. GUI and other resources that you can submit questions to, through MSDN. But as far as specific training that we will be offering to get started, it would probably be more along the lines of articles and stuff like that inside MSDN.

Otto: We have a request to review the .H again, in Visual Studio .NET 2002.

Zach: This note about the header files only applies to the standard header files, like <iostream> and <iomanip> and things like that. So it doesn't apply if you're using your own .H file. Basically in C++, in Visual Studio .NET 2002, they provided you both the old versions of the standard header files, which would be like <iostream.h> or <iomanip.h>, and the new versions of the header files, which don't have the .h extension.

So basically, if you look in your Include directory, you'll see a file with no extension. If you use the .H version, like <iostream.h>, you'll get a compiler warning that warns you that these are deprecated and getting ready to be pulled from the product. So when you use it in 2003, the support for those .H versions of the standard header files — and this is just the standard header files again — has been pulled.

Basically, the new versions of the header files provide almost the same functionality. It's just written differently, and in a more standard, adherent format. So you can still do cout and cin and everything that you would have been familiar with before, but it's just a different implementation underneath, that is more standards-adherent and more stable.

Otto: About the debug system, can I set a breakpoint with a condition? If that's possible, how do we do that?

Zach: You can set a breakpoint with a condition. So you could have, say, a for loop that would have counter variables, int i. So this i counter variable would move and change value. So you could say, "I want to break when that counter variable reaches 10," or something like that. There's a Breakpoint menu option under the View menu. So from the View menu you would select Debug, and then Breakpoint. And then you can create a breakpoint for a specific variable.

There's Debug Windows under the View menu, and you can select the breakpoints. And this is where you could add information about your breakpoints and say, "I want this to be conditional, and to only occur when it reaches a certain value."

Otto: It looks like we have a long question here: Concerning project dependencies, I'd like to make a project dependent on an .H file, but Visual Studio only allows you to make it dependent on either an .exe or a .dll. My .H is generated as an output from a message compiler project used to build .dll messages for the Event Viewer. A goal is to have the .dll project rebuild when the dependent project is built, if the .MC source file of the .dll project is out of date. Is that possible?

Zach: If you're doing #include on the .H file that is generated, I believe — and I would have to check on this, and we can maybe deal with this a little offline — that should be where your dependency is set up. So if you change the .H file, it would cause it to rebuild. We can maybe follow up offline, because I would need to check into that a little more, Otto. Does that sound fair?

Otto: Absolutely. We'll mark that one for offline follow-up there, and make sure that we get that information.

Zach: Yes, we'll get that posted up with everything.

Otto: With that being the final question, I'm going to wrap up our session here. I wanted to thank you, Zach, for coming out and giving us a great presentation and a lot of really good information. I wanted to thank our audience for coming out and giving us a listen. We hope this information was useful to you.

Feel free to send us any feedback at www.support.microsoft.com/servicedesks/webcasts/feedback.asp. I certainly appreciate that feedback.

I hope that everyone has the opportunity to tune in again soon. Thank you, and have a great day.