• Download source files - 47.7 KB

Introduction

This article discusses the basic synchronization concepts and practices that are supposed to be useful for beginners to do multithreaded programming. By saying beginner, I don't mean those that are beginners in learning C++ language, but the people that are somewhat new in multithreaded programming. The main concentration of this article is on synchronization techniques. Thus this article is like a tutorial on synchronization.

The General View

During their execution, threads, more or less, are interoperating with each other. This interoperation may have various forms and may be of various kinds. For example, a thread, after performing the task it is assigned to, informs another thread about it. Then the second thread whose job is a logical continuation of the first thread starts operating.

All the forms of interoperations might be described by the term synchronization which can be supported in several ways. Most usable ones are those whose primary aim is to support synchronization itself. The following objects are intended to support the synchronization (this is not a complete list):

• Semaphores
• Mutexes
• Critical Sections
• Events

Each of these objects has a different special purpose and usage but the general purpose is to support synchronization. I will introduce them to you through this article later. There are other objects that can be used as synchronization mediums such as Process and Thread objects. Their usage enables a programmer to decide, for example, if a given process or thread has finished its execution or not.

To use the Process and Thread objects for synchronization purposes, we are supposed to use wait-functions. Before getting to learn these functions, you should learn a key concept, that is, any kernel object that can be used as a synchronization object can be in one of the two states; signaled state and nonsignaled state. Except for critical sections, all synchronization objects can be in either of these two states. For example, for Process and Thread objects, the nonsignaled state is encountered when they start their execution and the signaled state is encountered when they finish their execution. To decide whether a given process or thread has finished, we should find out whether their representative objects are in signaled state; to do that, we should turn to the wait-functions.

Wait-functions

The following function is the simplest wait-function amongst the other wait-functions. It has the following declaration format:

DWORD WaitForSingleObject
(
  HANDLE hHandle,
  DWORD dwMilliseconds
);

The parameter hHandle takes the descriptor of an object whose signaled or nonsignaled state is going to be examined. The parameter dwMilliseconds takes the time that the calling thread should wait until the examining object enters the signaled state. As soon as the object is signaled or the given time interval expires, the function returns the control to the caller thread. If dwMilliseconds takes INIFINITE value (-1), the thread will wait until the object becomes signaled. If it doesn't become signaled, the thread will wait forever.

For example, the following call checks whether a process [identified by hProcess descriptor] is in execution or not:

DWORD dw = WaitForSingleObject(hProcess, 0);
switch (dw)
{
   case WAIT_OBJECT_0:
      // the process has exited
      break;

   case WAIT_TIMEOUT:
      // the process is still executing
      break;

   case WAIT_FAILED:
      // failure
      break;
}

As you notice, we passed 0 to the function's dwMilliseconds parameter in which case the function instantly checks the object's state [signaled or nonsignaled] and immediately returns the control. If the object is signaled, the function returns WAIT_OBJECT_0. If it is nonsignaled - WAIT_TIMEOUT is returned. In case of failure, WAIT_FAILED is returned (a failure may occur when an invalid descriptor is passed to the function).

Next wait-function is similar to the previous one except that it takes a list of descriptors and waits until either one of them or all of them become signaled:

DWORD WaitForMultipleObjects
(
  DWORD nCount,
  CONST HANDLE *lpHandles,
  BOOL fWaitAll,
  DWORD dwMilliseconds
);

The parameter nCount takes the number of descriptors to be examined. The parameter lpHandles should point an array of descriptors. If the parameter fWaitAll is TRUE, the function will wait until all the objects become signaled. If it is FALSE, the function returns even if a single object becomes signaled [no matter what the others are]. dwMilliseconds is the same as in the previous function.

For example, the following code decides which process will exit first from the list of given HANDLEs:

HANDLE h[3];
h[0] = hThread1;
h[1] = hThread2;
h[2] = hThread3;

DWORD dw = WaitForMultipleObjects(3, h, FALSE, 5000);
switch (dw)
{
   case WAIT_FAILED:
      // failure
      break;

   case WAIT_TIMEOUT:
      // no processes exited during 5000ms
      break;

   case WAIT_OBJECT_0 + 0:
      // a process with h[0] descriptor has exited
      break;

   case WAIT_OBJECT_0 + 1:
      // a process with h[1] descriptor has exited
      break;

   case WAIT_OBJECT_0 + 2:
      // a process with h[2] descriptor has exited
      break;
}

As we see, the function can return different values which show the reason the function returned. You already know the meaning of the first two values. Next values are returned by the following logic; WAIT_OBJECT_0 + index is returned which shows that the object from the array of HANDLEs whose index is index, has got signaled. If fWaitAll parameter is TRUE, WAIT_OBJECT_0 will be returned [if all the objects become signaled].

A thread, if it calls a wait-function, enters the kernel mode from the user mode. This fact is both bad and good. It is bad because to enter the kernel mode, approximately 1000 processor cycles are required which may be too expensive in a concrete situation. The good point is that after entering the kernel mode, no processor usage is needed; the thread is asleep.

Let's turn to MFC and see what it can do for us. There are two classes that encapsulate calls to wait-functions; CSingleLock and CMultiLock. We will see their usage later in this article.

Each of these classes inherits a single class - CSyncObject whose most usable member is the overloaded HANDLE operator that returns the underlying descriptor of a given synchronization object. All these classes are declared in <AfxMt.h> include file.

Events

// create an auto-reset event
CEvent g_eventStart;

UINT ThreadProc1(LPVOID pParam)
{
    ::WaitForSingleObject(g_eventStart, INFINITE);

        ...

    return 0;
}

UINT ThreadProc2(LPVOID pParam)
{
    ::WaitForSingleObject(g_eventStart, INFINITE);

        ...

    return 0;
}

In this code, a global CEvent object is created of auto-reset type. In addition, there are two working threads which are waiting for that event in order to start their job. As soon as a third thread calls SetEvent for that object, one and only one thread from these two threads (note that nobody can say exactly which one) will receive the notification, and afterwards the event will enter the nonsignaled state which will not allow a second thread to catch the event. The code, though not very useful, illustrates how an auto-reset event works. Let's look at the second example:

// create a manual-reset event
CEvent g_eventStart(FALSE, TRUE);

UINT ThreadProc1(LPVOID pParam)
{
    ::WaitForSingleObject(g_eventStart, INFINITE);

        ...

    return 0;
}

UINT ThreadProc2(LPVOID pParam)
{
    ::WaitForSingleObject(g_eventStart, INFINITE);

        ...

    return 0;
}

This code differs from the previous one by only the CEvent constructor's parameters. But in sense of functionality, there is a principal difference in the way that the two threads may work. If a third thread calls SetEvent method for this object, then it will be possible to guarantee that the two threads will start working at the same (almost same) time. This is because a manual-reset event, after entering the signaled state, will not enter the nonsignaled state until a corresponding ResetEvent call is done.

Yet another method for working with events - CEvent::PulseEvent. This method first makes the event enter the signaled state and then makes it enter back into the nonsignaled state. If the event is of manual-reset type, the event enters the signaled state then all the waiting threads are getting notified, and then it enters the nonsignaled state. If the event is of auto-reset type, then only one thread will get notified even if there are many threads waiting. If no thread is waiting, the call to ResetEvent will do nothing.

Example - WorkerThreads

All the ellipses are traversing in the client area and are not leaving its boundaries

1. You should have an SDI application open. Assume the project name is WorkerThreads.
2. Let's have a WM_LBUTTONDOWN message handler for launching our threads.
3. Declare the controlling function. A controlling function may be declared in any file; the point is that it should have global access. Assume we have a Threads.h/Threads.cpp file in which the controlling function is declared/defined as follows:

   // Threads.h
   #pragma once
   
   struct THREADINFO
   {
       HWND hWnd;
       POINT point;
   };
   
   
   UINT ThreadDraw(PVOID pParam);
   

   Collapse

   // Threads.cpp
   extern CEvent g_eventEnd;
   
   UINT ThreadDraw(PVOID pParam)
   {
       static int snCount = 0;
       snCount ++;
       TRACE("- ThreadDraw %d: started...\n", snCount);
   
       THREADINFO *pInfo = reinterpret_cast<threadinfo /> (pParam);
   
       CWnd *pWnd = CWnd::FromHandle(pInfo->hWnd);
   
       CClientDC dc(pWnd);
   
       int x = pInfo->point.x;
       int y = pInfo->point.y;
   
       srand((UINT)time(NULL));
       CRect rectEllipse(x - 25, y - 25, x + 25, y + 25);
   
       CSize sizeOffset(1, 1);
   
       CBrush brush(RGB(rand()% 256, rand()% 256, rand()% 256));
       CBrush *pOld = dc.SelectObject(&brush);
       while (WAIT_TIMEOUT == ::WaitForSingleObject(g_eventEnd, 0))
       {
           CRect rectClient;
           pWnd->GetClientRect(rectClient);
   
           if (rectEllipse.left < rectClient.left || 
               rectEllipse.right > rectClient.right)
               sizeOffset.cx *= -1;
   
           if (rectEllipse.top < rectClient.top || 
               rectEllipse.bottom > rectClient.bottom)
               sizeOffset.cy *= -1;
   
           dc.FillRect(rectEllipse, CBrush::FromHandle
               ((HBRUSH)GetStockObject(WHITE_BRUSH)));
   
           rectEllipse.OffsetRect(sizeOffset);
   
           dc.Ellipse(rectEllipse);
           Sleep(25);
       }
   
       dc.SelectObject(pOld);
   
       delete pInfo;
   
       TRACE("- ThreadDraw %d: exiting.\n", snCount --);
       return 0;
   }
   

   This function takes a single object via its PVOID parameter, that is, a struct whose fields are the handle of the view, in order to be able to draw on its client area, and the point from where to start the cycle. Note that we should pass the very handle and not a CWnd pointer to let each thread create a temporary C++ object over the handle and use it. Otherwise all of them would share a single C++ object which is a potential danger in sense of safe multithreaded programming. In its core, the controlling function renders a moving circle in the client area of the view. Besides, include <Afxmt.h> file in "StdAfx.h" file to make CEvent visible.

   Another key point here is that we prepare a structure THREADINFO to pass to the thread. This technique is mostly used when there is a need to pass more than one value to a thread (or get them from a thread). We need to pass the window handle of the view and the initial point of the cycle that is going to be created. Each thread deletes the THREADINFO object passed to itself. Beware that this deletion is done in regard to our convention; that is, the primary thread should reserve a heap memory for a THREADINFO object and the targeting thread should delete it. The idea is that the primary thread doesn't know when to do deletion as the object will have been owned by the secondary thread itself.

4. Declare an array variable in CWorkerThreadView class. We should store the pointer to CWinThread objects to use them later:

   private:
       CArray<CWinThread *, CWinThread *> m_ThreadArray;
   

   Besides, include <AfxTempl.h>; file in "StdAfx.h" file to make CArray visible.

5. Change the file WorkerThreadsView.cpp. First define a global CEvent manual-reset variable somewhere at the beginning of the file:

   // manual-reset event
   
   CEvent g_eventEnd(FALSE, TRUE);
   

   Now add code to the WM_LBUTTONDOWN message handler:

   void CWorkerThreadsView::OnLButtonDown()
   {
       THREADINFO *pInfo = new THREADINFO;
       pInfo->hWnd = GetSafeHwnd();
       pInfo->point = point;
   
       CWinThread *pThread = AfxBeginThread(ThreadDraw, 
       (PVOID) pInfo, THREAD_PRIORITY_NORMAL, 0, CREATE_SUSPENDED);
       pThread->m_bAutoDelete = FALSE;
       pThread->ResumeThread();
       m_ThreadArray.Add(pThread);
   }
   

   Be aware that we exclude the auto-deletion property of a newly created thread but instead we store the pointer to that CWinThread object in our array. Note that we create an instance of THREADINFO in the heap and let the thread delete it after it finishes working with the structure. To make ThreadDraw and THREADINFO visible in WorkerThreadsView.cpp file, include "Threads.h " file.

6. Take care to destroy the threads properly. As all threads are related to the view object (they are working with it), it will be reasonable to destroy them in the view's WM_DESTROY message handler:

   void CWorkerThreadsView::OnDestroy()
   {
       CView::OnDestroy();
   
       // TODO: Add your message handler code here
       g_eventEnd.SetEvent();
       for (int j = 0; j < m_ThreadArray.GetSize(); j ++)
       {
       ::WaitForSingleObject(m_ThreadArray[j]->m_hThread, INFINITE);
       delete m_ThreadArray[j];
       }
   }
   

   This function first makes the event become signaled to notify the working threads about their death, and then it uses WaitForSingleObject to make the primary thread wait for each worker thread until the later is destroyed fully. To do this we should have a valid CWinThread pointer even when the corresponding thread is destroyed; that is why we removed the auto-deletion property from CWinThread objects in the previous step. As soon as a worker thread exits, the second line of the for loop destroys the corresponding C++ object. Note that in each iteration a call to WaitForSingleObject is done which simply results in entering the kernel mode from the user mode. For example, for 10 iterations there will be wasted ~10000 processor cycles. To overcome this moment, we might use WaitForMultipleObjects. In this case we will need a C-array of thread descriptors. So, the above for loop could be replaced with the following code:

   //second way (comment in 'for' loop above)
   
   int nSize = m_ThreadArray.GetSize();
   HANDLE *p = new HANDLE[nSize];
   
   for (int j = 0; j < nSize; j ++)
   {
       p[j] = m_ThreadArray[j]->m_hThread;
   }
   
   ::WaitForMultipleObjects(nSize, p, TRUE, INFINITE);
   
   for (j = 0; j < nSize; j ++)
   {
       delete m_ThreadArray[j];
   }
   delete [] p;
   

   As the previous code executes only once and in addition at the end of the application, such improvements could hardly be valued much.

7. This is all. You can test it.

Critical Sections

Unlike other synchronization objects, critical sections are working in the user mode unless there is a need to enter the kernel mode. If a thread tries to run a code that is caught be a critical section, it first does a spin blocking and after a specified amount of time, it enters the kernel mode to wait for the critical section. Actually, a critical section consists of a spin counter and a semaphore; the former is for the user mode waiting, and the later is for the kernel mode waiting (sleeping). In Win32 API, there is a CRITICAL_SECTION structure that represents critical section objects. In MFC, there is a class named CCriticalSection. Conceptually, a critical section is a sector of source code that is needed in integrated execution, that is, during the execution of that part of the code it should be guaranteed that the execution will not be interrupted by another thread. Such sectors of code may be required in cases when there is a need to grant a single thread the monopoly of using a shared resource. A simple case is using global variables by more than one thread. For example:

int g_nVariable = 0;

UINT Thread_First(LPVOID pParam)
{
    if (g_nVariable < 100)
    {
       ...
    }
    return 0;
}

UINT Thread_Second(LPVOID pParam)
{
    g_nVariable += 50;
    ...
    return 0;
}

This is not a safe code as no thread has a monopoly access to g_nVariable variable. Consider the following scenario; assume the initial value of g_nVariable is 80, the control is passed to the first thread which sees that the value of g_nVariable is less than 100 and thus it tries to execute the block under the condition. But at that time the processor switches to the second thread which adds 50 to the variable, so it becomes greater than 100. Afterwards, the processor switches back to the first thread and continues executing the if block. Guess what? Inside the if block the value of g_nVariable is greater than 100 though it is supposed to be less than 100. To cover this gap, we may use a critical section like so:

CCriticalSection g_cs;
int g_nVariable = 0;

UINT Thread_First(LPVOID pParam)
{
    g_cs.Lock();
    if (g_nVariable < 100)
    {
       ...
    }
    g_cs.Unlock();
    return 0;
}

UINT Thread_Second(LPVOID pParam)
{
    g_cs.Lock();
    g_nVariable += 20;
    g_cs.Unlock();
    ...
    return 0;
}

Here, two methods of CCriticalSection class are used. A call to Lock function informs the system that the execution of underlying code should not be interrupted until the same thread makes a call to Unlock function. In response to this call, the system first checks whether that code is not captured by another thread with the same critical section object. If it is, the thread waits until the capturing thread releases the critical section and than captures it itself.

If there are more than two shared resources to be protected, it would be a good practice to use a separate critical section per resource. Do not forget to match Unlock to each Lock. When using critical sections, one should be careful not to prepare mutual blocking situations for collaborating threads. This means that a thread could wait for a critical section to be freed by another thread, which in turn, waits for a critical section that is captured by the first thread. It is obvious that in such a case the two threads will wait forever.

There is a practice to embed critical sections into C++ classes and thus make them thread-safe. This kind of trick might be needed when the objects of a specific class are supposed to be used by more than one thread simultaneously. The big picture looks like this:

class CSomeClass
{
    CCriticalSection m_cs;
    int m_nData1;
    int m_nData2;

public:
    void SetData(int nData1, int nData2)
    {
        m_cs.Lock();
        m_nData1 = Function(nData1);
        m_nData2 = Function(nData2);
        m_cs.Unlock();
    }

    int GetResult()
    {
        m_cs.Lock();
        int nResult = Function(m_nData1, m_nData2);
        m_cs.Unlock();
        return nResult;
    }
};

It's possible that at the same time two or more threads call SetData and/or GetData methods for the same object of CSomeClass type. Therefore, by wrapping the content of those methods, we will prevent the data from getting distorted during those calls.

Mutexes

Mutexes, like critical sections, are designated to protect shared resources from simultaneous accesses. Mutexes are implemented inside the kernel and thus they enter the kernel mode to operate. A mutex can perform synchronization not only between different threads but also between different processes. Such a mutex should have a unique name to be recognized by another process (such mutexes are called named mutexes). MFC represents CMutex class for working with mutexes. A mutex might be used in this way:

CSingleLock singleLock(&m_Mutex);
singleLock.Lock();  // try to capture the shared resource
if (singleLock.IsLocked())  // we did it
{
    // use the shared resource ...

    // After we done, let other threads use the resource
    singleLock.Unlock();
}

Or the same by Win32 API functions:

// try to capture the shared resource
::WaitForSingleObject(m_Mutex, INFINITE);

// use the shared resource ...

// After we done, let other threads use the resource
::ReleaseMutex(m_Mutex);

A mutex can also be used to limit the number of running instances by a single one. The following code might be placed at the beginning of InitInstance method (or WinMain):

HANDLE h = CreateMutex(NULL, FALSE, "MutexUniqueName");
if (GetLastError() == ERROR_ALREADY_EXISTS)
{
    AfxMessageBox("An instance is already running.");
    return(0);
}

To guarantee a globally unique name, use a GUID instead.

Semaphores

In order to limit the number of threads that use shared resources we should use semaphores. A semaphore is a kernel object. It stores a counter variable to keep track of the number of threads that are using the shared resource. For example, the following code creates a semaphore by the MFC CSemaphore class which could be used to guarantee that only 5 threads at a maximum would be able to use the shared resource in a given time period (this fact is indicated by the first parameter of the constructor). It is supposed that no threads have captured the resource initially (the second parameter):

CSemaphore g_Sem(5, 5);

As soon as a thread gets access to the shared resource, the counter variable of the semaphore is decremented by one. If it becomes equal to zero, then any further attempt to use the resource will be rejected until at least one thread that has captured the resource leaves it (in other words, releases the semaphore). We may turn to CSingleLock and/or CMultiLock classes to wait/capture/release a semaphore. We could also use the API functions as shown below:

// Try to use the shared resource

::WaitForSingleObject(g_Sem, INFINITE);
// Now the user's counter of the semaphore has decremented by one

//... Use the shared resource ...

// After we done, let other threads use the resource
::ReleaseSemaphore(g_Sem, 1, NULL);
// Now the user's counter of the semaphore has incremented by one

Communication between Secondary Threads and the Primary Thread

If a primary thread wants to inform a secondary thread about some action, it is convenient to use an event object. But doing vice-versa will be inefficient and not convenient for users since stopping the primary thread to wait for an event may (and mostly does) slow down the application. In this case it would be correct to use user-defined messages to interact with the primary thread. Such a message should be addressed to a specific window which means that the descriptor of such a window should be visible to callers (secondary threads).

To create a user-defined message, we firstly should define an identifier for that message (more correctly - define the message itself). Supposedly, such an identifier should be visible to both the primary thread and secondary threads:

#define WM_MYMSG WM_USER + 1

WM_USER+n messages are supposed to be unique through a window class but not through the application. A more secure [in sense of its uniqueness] way is to use WM_APP+n messages like so:

#define WM_MYMSG WM_APP + 1

Next, a handler method should be declared for the message inside the window class declaration to which (window) the message is going to be addressed:

afx_msg LRESULT OnMyMessage(WPARAM , LPARAM );

Of course, there should be some definition of the method:

LRESULT CMyWnd::OnMyMessage(WPARAM wParam, LPARAM lParam)
{
    // A notification got
    // Do something ...
    return 0;
}

And finally, to assign the handler to the message identifier, ON_MESSAGE macro should be used inside BEGIN_MESSAGE_MAP and END_MESSAGE_MAP pairs:

BEGIN_MESSAGE_MAP(CMyWnd, CWnd)
    ...

    ON_MESSAGE(WM_MYMSG, OnMyMessage)
END_MESSAGE_MAP()

Now a secondary thread having a window handle [that lives in the primary thread], can notify it by the user-defined message as follows:

UINT ThreadProc(LPVOID pParam)
{
    HWND hWnd = (HWND) pParam;

    ...

    // notify the primary thread's window
    ::PostMessage(hWnd, WM_MYMSG, 0, 0);

    return 0;
}

History

This text was first written more than three years ago. At that time I was a two-year old programmer. My intention was to write a book about MFC. Funny? But I was too young to write a book, and thus my chapters have stayed in my computer only. Now I've rewritten a text from there and submitted it to you. And of course, any note you think is worth suggesting about this essay would be appreciated very much.

About Arman Z. Sahakyan

This page provides instructions for manually installing an Express Edition.

Installation Options

• The recommended option for installing Express Editions is to use the bootstrapper installer that is available via the "Download Now" link on each Express Edition page.
• If the bootstrapper installer fails to install on your computer because of networking problems, or if you want to download a full copy of an Express Edition to burn on CD, then please follow the manual installation instructions listed below.
• After following the manual installation instructions, please be sure to register your copy of Express. You'll get a lot of free stuff such as royalty-free images from Corbis, icons from IconBuffet, and e-books from Microsoft Press. Learn more about registration benefits.

File Packaging and Download Paths

Each Express Edition is packaged in its entirety, including all optional components, as an image (img or iso) file. Below are links to the individual image files for each Express Edition.

Manual Installation Options

• Manually Installing an Express Edition on a local machine
• Burning a Visual Studio 2005 Express Edition to a CD
• Installing an Express Edition from CD

Manually Installing an Express Edition on a local machine

Below are the steps required to manually install an Express Edition:

Note: The steps below use the img file as an example

• Before you get started, make sure to uninstall all pre-release (beta) Express software from your computer.
  You must uninstall all Visual Studio 2005 and Express betas before installing a final release of any Visual Studio 2005 Edition, including an Express Edition . You must also uninstall the beta version of the .NET Framework 2.0 before installing any Express Edition final release.
• Download the Express Edition Image (img) file using the hyperlinks provided in the File Packaging and Download Paths section.
• To install the image directly from your hard drive you will need to install 3rd party software that is capable of understanding *.img file extensions. Popular software programs like Roxio's Easy Media Creator include a Disk Image Loader application that enables you to mount disc image files in a virtual drive as if they were physical discs in a physical drive. For the example below, we will use Smart-Projects.net IsoBuster 1.8.
• Be sure to set the tool to handle long file names. The default setting for many third party tools does not handle long file names. Some tools extract using the 8.3 file convention. Visual Studio 2005 setup requires the files to be in their long filename format or else setup will fail. This feature can usually be found in the Advanced settings. If you can not find the setting, please refer to the ISO extraction tool help documentation or contact the software vendor for assistance.
• In the IsoBuster setup, make sure to select the "(*.IMG) Image files" file extensions to associate IsoBuster with img file extensions.
  
  IsoBuster setup options for associating file extensions.
• After installing IsoBuster, you will notice that files with a .img extension are now associated to open with IsoBuster as shown below:
  
  Visual Web Developer 2005 Express Image file.
• Double click on the img file to start IsoBuster. You should see something similar to the screenshot below with a list of files contained inside the img file in the right hand pane.
  
  List of files in the Visual Web Developer .img image.
• Select all the files in the right hand side by clicking CTRL+A:
  
  Select all files in the Visual Web Developer .img image.
• Right click on the selected files and you will see a context menu to extract the selected objects. Click the "Extract Objects" option in the context menu.
  
  Context menu for extracting files.
• Next, select the folder to extract the contents of the image file as shown below and click OK.
  
  Browse for Folder dialog.
• This will start the extraction process of the image files as shown below. Extracting the contents from the image file typically takes five minutes.
  
  Image extraction progress dialog.
• After the extraction process is complete, navigate to the directory you chose to extract the files in the previous step and click the setup.exe file to begin the Express Edition installer.
  
  Setup icon to start Express installation.

If you encounter issues installing a Visual Studio Express Edition, please visit the Express Forums for more help.

Burning a Visual Studio 2005 Express Edition to a CD

Below are the steps required to burn an Express Edition to a CD.

• Before you get started, make sure to uninstall all Express beta software from your computer.
  You must uninstall all Visual Studio 2005 and Express betas before installing a final release of any Visual Studio 2005 Edition, including an Express Edition . You must also uninstall the beta version of the .NET Framework 2.0 before installing any Express Edition final release.
• Download the Express Edition Image (img or iso) file using the hyperlinks provided in the File Packaging and Download Paths section above.
• To burn the image directly to a CD, you will need to install 3rd party software that is capable of understanding and burning image (img or iso) files. Most popular CD burning software include support for burning images, as do popular CD burning software such as Nero 6 Ultra Edition and Roxio Easy Media Creator 7.5.
• Follow the vendor-specific instructions to burn the image onto a CD.

Installing an Express Edition from CD

• After following the CD burning process above, you are ready to install the Express Edition on another computer.

  Important: Before getting started, you will need to perform a series of preparation steps on your machine if you ever installed a pre-release of Visual Studio 2005 (such as Beta 2) on your machine. Please follow these important instructions prior to installation.

• Now simply insert the CD created above into the computer to which you plan to install and click the setup.exe file to begin the installer.
  

If you encounter issues installing the Express Editions, please visit the Express Forums and report your issue for more assistance.

1.检测程序中的括号是否匹配

把光标移动到需要检测的括号（如大括号{}、方括号[]、圆括号（）和尖括号<>）前面，键入快捷键"Ctrl＋]"。如果括号匹配正确，光标就跳到匹配的括号处，否则光标不移动，并且机箱喇叭还会发出一声警告声。

2.查看一个宏（或变量、函数）的宏定义
把光标移动到你想知道的一个宏上，就比如说最常见的DECLARE_MAP_MESSAGE上按一下F12(或右键菜单中的Go To Defition Of …),如果没有建立Browse files，会出现提示对话框，确定，然后就会跳到定义那些东西的地方。

3.格式化一段乱七八糟的源代码
选中那段源代码，按ATL+F8。

4.在编辑状态下发现成员变量或函数不能显示
删除该项目扩展名为.ncb文件，重新打开该项目。

5.如何整理ClassView视图中大量的类
可以在classview 视图中右键新建文件夹（new folder），再把具有相近性质的类拖到对应的文件夹中，使整个视图看上去清晰明了
.

6.定位预处理指定
在源文件中定位光标到对称的#if, #endif,使用Ctrl+K.

7.如何添加系统中Lib到当前项目
在Project | Settings | Link | Object/library modules：输入Lib名称，不同的Lib之间用空格格开.

8.如何添加系统中的头文件(.h)到当前项目.
#include <FileName.h>,告诉编译到VC系统目录去找;使用#include "FileName.h"，告诉编译在当前目录找.

9.如何在Studio使用汇编调试
在WorkBench的Debugger状态下按CTRL+F7.

10.怎样处理ClassZiard找不到的系统消息
如果要在ClassWizard中处理WM_NCHITTEST等系统消息，请在ClassWizard中Class Info页中将Message filter改为Window就有了.

11.如何干净的删除一个类
先从Workspace中的FileView中删除对应的.h和.cpp文件,再关闭项目，从实际的文件夹中删除对应的.h和.cpp文件与.clw文件。

12.如果让控制台应用程序支持mfc类库
可以在控制台应用程序中include 来引入mfc库，但是控制台应用程序缺省是单线程的，mfc是多线程的，为解决该矛盾，在project setting->c/c++ 选项，选择code generation,在use run-time library 下拉框中选择debug multithread。

13.如何汉化只有可执行代码的.exe 文件
在nt 下利用vc open file 以resources方式打开*.exe 文件，直接修改资源文件，然后保存即可。

附：VC项目文件说明
.opt 工程关于开发环境的参数文件。如工具条位置等信息；
.aps (AppStudio File),资源辅助文件,二进制格式,一般不用去管他.
.clw ClassWizard信息文件,实际上是INI文件的格式,有兴趣可以研究一下.有时候ClassWizard出问题,手工修改CLW文件可以解决.如果此文件不存在的话,每次用ClassWizard的时候绘提示你是否重建.
.dsp (DeveloperStudio Project):项目文件,文本格式,不过不熟悉的话不要手工修改.DSW(DeveloperStudio Workspace)是工作区文件,其他特点和DSP差不多.
.plg 是编译信息文件,编译时的error和warning信息文件（实际上是一个html文件）,一般用处不大.在Tools->Options里面有个选项可以控制这个文件的生成.
.hpj (Help Project)是生成帮助文件的工程,用microsfot Help Compiler可以处理.
.mdp (Microsoft DevStudio Project)是旧版本的项目文件,如果要打开此文件的话,会提示你是否转换成新的DSP格式.
.bsc 是用于浏览项目信息的,如果用Source Brower的话就必须有这个文件.如果不用这个功能的话,可以在Project Options里面去掉Generate Browse Info File,可以加快编译速度.
.map 是执行文件的映像信息纪录文件,除非对系统底层非常熟悉,这个文件一般用不着.
.pch (Pre-Compiled File)是预编译文件,可以加快编译速度,但是文件非常大.
.pdb (Program Database)记录了程序有关的一些数据和调试信息,在调试的时候可能有用.
.exp 只有在编译DLL的时候才会生成,记录了DLL文件中的一些信息.一般也没什么用.
.ncb 无编译浏览文件(no compile browser)。当自动完成功能出问题时可以删除此文件。build后会自动生成。