Fix capitalization errors

Colin Robertson · Colin Robertson · commit f671e6a1eb06 · 2017-08-10T14:42:19.000-07:00
diff --git a/docs/build/TOC.md b/docs/build/TOC.md
@@ -63,8 +63,8 @@
 ## [Walkthrough: Creating and Using a Dynamic Link Library (C++)](walkthrough-creating-and-using-a-dynamic-link-library-cpp.md)
 ## [Kinds of DLLs](kinds-of-dlls.md)
 ### [Non-MFC DLLs: Overview](non-mfc-dlls-overview.md)
-### [regular MFC DLLs Statically Linked to MFC](regular-dlls-statically-linked-to-mfc.md)
-### [regular MFC DLLs Dynamically Linked to MFC](regular-dlls-dynamically-linked-to-mfc.md)
+### [Regular MFC DLLs Statically Linked to MFC](regular-dlls-statically-linked-to-mfc.md)
+### [Regular MFC DLLs Dynamically Linked to MFC](regular-dlls-dynamically-linked-to-mfc.md)
 ### [MFC extension DLLs: Overview](extension-dlls-overview.md)
 ## [MFC DLL Frequently Asked Questions](dll-frequently-asked-questions.md)
 ## [Link an executable to a DLL](linking-an-executable-to-a-dll.md)
diff --git a/docs/build/dll-frequently-asked-questions.md b/docs/build/dll-frequently-asked-questions.md
@@ -73,7 +73,7 @@ Multithreaded applications can access regular MFC DLLs that dynamically link to
 ## <a name="mfc_prohibited_classes"></a> Are there any MFC classes or functions that cannot be used in an MFC DLL?
 Extension DLLs use the `CWinApp`-derived class of the client application. They must not have their own `CWinApp`-derived class.  
   
- regular MFC DLLs must have a `CWinApp`-derived class and a single object of that application class, as does an MFC application. Unlike the `CWinApp` object of an application, the `CWinApp` object of the DLL does not have a main message pump.  
+Regular MFC DLLs must have a `CWinApp`-derived class and a single object of that application class, as does an MFC application. Unlike the `CWinApp` object of an application, the `CWinApp` object of the DLL does not have a main message pump.  
   
  Note that because the `CWinApp::Run` mechanism does not apply to a DLL, the application owns the main message pump. If the DLL opens modeless dialog boxes or has a main frame window of its own, the application's main message pump must call a routine exported by the DLL, which in turn calls the `CWinApp::PreTranslateMessage` member function of the DLL's application object.  
 
diff --git a/docs/build/extension-dlls-overview.md b/docs/build/extension-dlls-overview.md
@@ -57,9 +57,9 @@ An MFC extension DLL is a DLL that typically implements reusable classes derived
   
 -   [Non-MFC DLLs: Overview](../build/non-mfc-dlls-overview.md)  
   
--   [regular MFC DLLs statically linked to MFC](../build/regular-dlls-statically-linked-to-mfc.md)  
+-   [Regular MFC DLLs statically linked to MFC](../build/regular-dlls-statically-linked-to-mfc.md)  
   
--   [regular MFC DLLs dynamically linked to MFC](../build/regular-dlls-dynamically-linked-to-mfc.md)  
+-   [Regular MFC DLLs dynamically linked to MFC](../build/regular-dlls-dynamically-linked-to-mfc.md)  
   
 -   [Creating an MFC DLL](../mfc/reference/mfc-dll-wizard.md)  
   
diff --git a/docs/build/extension-dlls.md b/docs/build/extension-dlls.md
@@ -142,9 +142,9 @@ head ->   DLLHUSK.EXE   - or -   DLLHUSK.EXE
   
 -   [DLL Version of MFC](../mfc/tn033-dll-version-of-mfc.md)  
   
--   [regular MFC DLLs statically linked to MFC](../build/regular-dlls-statically-linked-to-mfc.md)  
+-   [Regular MFC DLLs statically linked to MFC](../build/regular-dlls-statically-linked-to-mfc.md)  
   
--   [regular MFC DLLs dynamically linked to MFC](../build/regular-dlls-dynamically-linked-to-mfc.md)  
+-   [Regular MFC DLLs dynamically linked to MFC](../build/regular-dlls-dynamically-linked-to-mfc.md)  
   
 -   [Using Database, OLE, and Sockets MFC extension DLLs in regular MFC DLLs](../build/using-database-ole-and-sockets-extension-dlls-in-regular-dlls.md)  
   
diff --git a/docs/build/kinds-of-dlls.md b/docs/build/kinds-of-dlls.md
@@ -52,9 +52,9 @@ This topic provides information to help you determine the kind of DLL to build.
   
 -   [Non-MFC DLLs: Overview](../build/non-mfc-dlls-overview.md)  
   
--   [regular MFC DLLs statically linked to MFC](../build/regular-dlls-statically-linked-to-mfc.md)  
+-   [Regular MFC DLLs statically linked to MFC](../build/regular-dlls-statically-linked-to-mfc.md)  
   
--   [regular MFC DLLs dynamically linked to MFC](../build/regular-dlls-dynamically-linked-to-mfc.md)  
+-   [Regular MFC DLLs dynamically linked to MFC](../build/regular-dlls-dynamically-linked-to-mfc.md)  
   
 -   [MFC extension DLLs: Overview](../build/extension-dlls-overview.md)  
   
@@ -73,15 +73,15 @@ This topic provides information to help you determine the kind of DLL to build.
   
  If your DLL dynamically links to MFC, the MFC DLLs might be redistributed with your DLL. This architecture is particularly useful for sharing the class library between multiple executable files to save disk space and minimize memory usage.  
   
- Prior to version 4.0, Visual C++ only supported two kinds of DLLs that used MFC: USRDLLs and AFXDLLs. regular MFC DLLs statically linked to MFC have the same characteristics as the former USRDLL. MFC extension DLLs have the same characteristics as the former AFXDLLs.  
+ Prior to version 4.0, Visual C++ only supported two kinds of DLLs that used MFC: USRDLLs and AFXDLLs. Regular MFC DLLs statically linked to MFC have the same characteristics as the former USRDLL. MFC extension DLLs have the same characteristics as the former AFXDLLs.  
   
 ### What do you want to know more about?  
   
 -   [Non-MFC DLLs: Overview](../build/non-mfc-dlls-overview.md)  
   
--   [regular MFC DLLs statically linked to MFC](../build/regular-dlls-statically-linked-to-mfc.md)  
+-   [Regular MFC DLLs statically linked to MFC](../build/regular-dlls-statically-linked-to-mfc.md)  
   
--   [regular MFC DLLs dynamically linked to MFC](../build/regular-dlls-dynamically-linked-to-mfc.md)  
+-   [Regular MFC DLLs dynamically linked to MFC](../build/regular-dlls-dynamically-linked-to-mfc.md)  
   
 -   [MFC extension DLLs: Overview](../build/extension-dlls-overview.md)  
   
diff --git a/docs/build/module-states-of-a-regular-dll-dynamically-linked-to-mfc.md b/docs/build/module-states-of-a-regular-dll-dynamically-linked-to-mfc.md
@@ -57,7 +57,7 @@ AFX_MANAGE_STATE(AfxGetStaticModuleState( ))
   
 -   [Managing the state data of MFC modules](../mfc/managing-the-state-data-of-mfc-modules.md)  
   
--   [regular MFC DLLs dynamically linked to MFC](../build/regular-dlls-dynamically-linked-to-mfc.md)  
+-   [Regular MFC DLLs dynamically linked to MFC](../build/regular-dlls-dynamically-linked-to-mfc.md)  
   
 -   [MFC extension DLLs](../build/extension-dlls-overview.md)  
   
diff --git a/docs/build/non-mfc-dlls-overview.md b/docs/build/non-mfc-dlls-overview.md
@@ -50,9 +50,9 @@ A non-MFC DLL is a DLL that does not use MFC internally, and the exported functi
   
 ## What do you want to know more about?  
   
--   [regular MFC DLLs statically linked to MFC](../build/regular-dlls-statically-linked-to-mfc.md)  
+-   [Regular MFC DLLs statically linked to MFC](../build/regular-dlls-statically-linked-to-mfc.md)  
   
--   [regular MFC DLLs dynamically linked to MFC](../build/regular-dlls-dynamically-linked-to-mfc.md)  
+-   [Regular MFC DLLs dynamically linked to MFC](../build/regular-dlls-dynamically-linked-to-mfc.md)  
   
 -   [MFC extension DLLs: Overview](../build/extension-dlls-overview.md)  
   
diff --git a/docs/build/regular-dlls-dynamically-linked-to-mfc.md b/docs/build/regular-dlls-dynamically-linked-to-mfc.md
@@ -1,5 +1,5 @@
 ---
-title: "regular MFC DLLs Dynamically Linked to MFC | Microsoft Docs"
+title: "Regular MFC DLLs Dynamically Linked to MFC | Microsoft Docs"
 ms.custom: ""
 ms.date: "11/04/2016"
 ms.reviewer: ""
@@ -36,7 +36,7 @@ translation.priority.ht:
   - "zh-cn"
   - "zh-tw"
 ---
-# regular MFC DLLs Dynamically Linked to MFC
+# Regular MFC DLLs Dynamically Linked to MFC
 A regular MFC DLL dynamically linked to MFC is a DLL that uses MFC internally, and the exported functions in the DLL can be called by either MFC or non-MFC executables. As the name describes, this kind of DLL is built using the dynamic-link library version of MFC (also known as the shared version of MFC). Functions are usually exported from a regular MFC DLL using the standard C interface.  
   
  You must add the `AFX_MANAGE_STATE` macro at the beginning of all the exported functions in regular MFC DLLs that dynamically link to MFC to set the current module state to the one for the DLL. This is done by adding the following line of code to the beginning of functions exported from the DLL:  
diff --git a/docs/build/regular-dlls-statically-linked-to-mfc.md b/docs/build/regular-dlls-statically-linked-to-mfc.md
@@ -1,5 +1,5 @@
 ---
-title: "regular MFC DLLs Statically Linked to MFC | Microsoft Docs"
+title: "Regular MFC DLLs Statically Linked to MFC | Microsoft Docs"
 ms.custom: ""
 ms.date: "11/04/2016"
 ms.reviewer: ""
@@ -37,7 +37,7 @@ translation.priority.ht:
   - "zh-cn"
   - "zh-tw"
 ---
-# regular MFC DLLs Statically Linked to MFC
+# Regular MFC DLLs Statically Linked to MFC
 A regular MFC DLL statically linked to MFC is a DLL that uses MFC internally, and the exported functions in the DLL can be called by either MFC or non-MFC executables. As the name describes, this kind of DLL is built using the static link library version of MFC. Functions are usually exported from a regular MFC DLL using the standard C interface. For an example of how to write, build, and use a regular MFC DLL, see the sample [DLLScreenCap](https://github.com/Microsoft/VCSamples/tree/master/VC2010Samples/MFC/advanced/DllScreenCap).  
   
  Note that the term USRDLL is no longer used in the Visual C++ documentation. A regular MFC DLL that is statically linked to MFC has the same characteristics as the former USRDLL.  
@@ -96,7 +96,7 @@ extern "C" __declspec(dllexport) MyExportedFunction( );
   
 -   [Creating an MFC DLL](../mfc/reference/mfc-dll-wizard.md)  
   
--   [regular MFC DLLs Dynamically Linked to MFC](../build/regular-dlls-dynamically-linked-to-mfc.md)  
+-   [Regular MFC DLLs Dynamically Linked to MFC](../build/regular-dlls-dynamically-linked-to-mfc.md)  
   
 -   [MFC extension DLLs](../build/extension-dlls-overview.md)  
   
diff --git a/docs/build/using-database-ole-and-sockets-extension-dlls-in-regular-dlls.md b/docs/build/using-database-ole-and-sockets-extension-dlls-in-regular-dlls.md
@@ -157,9 +157,9 @@ BOOL CYourRegularDLL::InitInstance()
   
 -   [MFC extension DLLs](../build/extension-dlls.md)  
   
--   [regular MFC DLLs Statically Linked to MFC](../build/regular-dlls-statically-linked-to-mfc.md)  
+-   [Regular MFC DLLs Statically Linked to MFC](../build/regular-dlls-statically-linked-to-mfc.md)  
   
--   [regular MFC DLLs Dynamically Linked to MFC](../build/regular-dlls-dynamically-linked-to-mfc.md)  
+-   [Regular MFC DLLs Dynamically Linked to MFC](../build/regular-dlls-dynamically-linked-to-mfc.md)  
   
 -   [Using MFC as Part of a DLL](../mfc/tn011-using-mfc-as-part-of-a-dll.md)  
   
diff --git a/docs/dotnet/how-to-compile-mfc-and-atl-code-by-using-clr.md b/docs/dotnet/how-to-compile-mfc-and-atl-code-by-using-clr.md
@@ -17,7 +17,7 @@ helpviewer_keywords:
   - "mixed assemblies [C++], ATL code"
   - "/clr compiler option [C++], compiling ATL and MFC code"
   - "interoperability [C++], /clr compiler option"
-  - "regular MFC DLLs [D++], /clr compiler option"
+  - "regular MFC DLLs [C++], /clr compiler option"
   - "interop [C++], /clr compiler option"
   - "extension DLLs [C++], /clr compiler option"
 ms.assetid: 12464bec-33a4-482c-880a-c078de7f6ea5
diff --git a/docs/mfc/exported-dll-function-entry-points.md b/docs/mfc/exported-dll-function-entry-points.md
@@ -49,7 +49,7 @@ For exported functions of a DLL, use the [AFX_MANAGE_STATE](reference/extension-
   
  Problems with resources in DLLs will occur if the `AFX_MANAGE_STATE` macro is not used. By default, MFC uses the resource handle of the main application to load the resource template. This template is actually stored in the DLL. The root cause is that MFC's module state information has not been switched by the `AFX_MANAGE_STATE` macro. The resource handle is recovered from MFC's module state. Not switching the module state causes the wrong resource handle to be used.  
   
- `AFX_MANAGE_STATE` does not need to be put into every function in the DLL. For example, `InitInstance` can be called by the MFC code in the application without `AFX_MANAGE_STATE` because MFC automatically shifts the module state before `InitInstance` and then switches it back after `InitInstance` returns. The same is true for all message-map handlers. regular MFC DLLs actually have a special master window procedure that automatically switches the module state before routing any message.  
+ `AFX_MANAGE_STATE` does not need to be put into every function in the DLL. For example, `InitInstance` can be called by the MFC code in the application without `AFX_MANAGE_STATE` because MFC automatically shifts the module state before `InitInstance` and then switches it back after `InitInstance` returns. The same is true for all message-map handlers. Regular MFC DLLs actually have a special master window procedure that automatically switches the module state before routing any message.  
   
 ## See Also  
  [Managing the State Data of MFC Modules](../mfc/managing-the-state-data-of-mfc-modules.md)
diff --git a/docs/mfc/reference/application-settings-mfc-dll-wizard.md b/docs/mfc/reference/application-settings-mfc-dll-wizard.md
@@ -40,10 +40,10 @@ Use this page of the MFC DLL wizard to design and add basic features to a new MF
 ## DLL type  
  Select the type of DLL you want to create.  
   
- **regular MFC DLL using shared MFC DLL**  
+ **Regular MFC DLL using shared MFC DLL**  
  Select this option to link the MFC library to your program as a shared DLL. Using this option, you cannot share MFC objects between your DLL and the calling application. Your program makes calls to the MFC library at run time. This option reduces the disk and memory requirements of your program if it is composed of multiple execution files that use the MFC library. Both Win32 and MFC programs can call functions in your DLL. You must redistribute the MFC DLL with this type of project.  
   
- **regular MFC DLL with MFC statically linked**  
+ **Regular MFC DLL with MFC statically linked**  
  Select this option to link your program statically to the MFC library at build time. Both Win32 and MFC programs can call functions in your DLL. While this option increases the size of your program, you do not need to redistribute the MFC DLL with this type of project. You cannot share MFC objects between your DLL and the calling application.  
   
  **MFC extension DLL**  
diff --git a/docs/mfc/tn033-dll-version-of-mfc.md b/docs/mfc/tn033-dll-version-of-mfc.md
@@ -52,7 +52,7 @@ This note describes how you can use the MFCxx.DLL and MFCxxD.DLL (where x is the
  If you are interested in building a DLL using MFC that can be used with non-MFC applications (this is called a regular MFC DLL), refer to [Technical Note 11](../mfc/tn011-using-mfc-as-part-of-a-dll.md).  
   
 ## Overview of MFCxx.DLL Support: Terminology and Files  
- **regular MFC DLL**: You use a regular MFC DLL to build a stand-alone DLL using some of the MFC classes. Interfaces across the App/DLL boundary are "C" interfaces, and the client application does not have to be an MFC application.  
+ **Regular MFC DLL**: You use a regular MFC DLL to build a stand-alone DLL using some of the MFC classes. Interfaces across the App/DLL boundary are "C" interfaces, and the client application does not have to be an MFC application.  
   
  This is the version of DLL support supported in MFC 1.0. It is described in [Technical Note 11](../mfc/tn011-using-mfc-as-part-of-a-dll.md) and the MFC Advanced Concepts sample [DLLScreenCap](../visual-cpp-samples.md).  
   
diff --git a/docs/mfc/tn058-mfc-module-state-implementation.md b/docs/mfc/tn058-mfc-module-state-implementation.md
@@ -94,7 +94,7 @@ AFX_MANAGE_STATE(AfxGetStaticModuleState())
   
  Problems with resources in DLLs will occur if the `AFX_MODULE_STATE` macro is not used. By default, MFC uses the resource handle of the main application to load the resource template. This template is actually stored in the DLL. The root cause is that MFC's module state information has not been switched by the `AFX_MODULE_STATE` macro. The resource handle is recovered from MFC's module state. Not switching the module state causes the wrong resource handle to be used.  
   
- `AFX_MODULE_STATE` does not need to be put in every function in the DLL. For example, `InitInstance` can be called by the MFC code in the application without `AFX_MODULE_STATE` because MFC automatically shifts the module state before `InitInstance` and then switches it back after `InitInstance` returns. The same is true for all message map handlers. regular MFC DLLs actually have a special master window procedure that automatically switches the module state before routing any message.  
+ `AFX_MODULE_STATE` does not need to be put in every function in the DLL. For example, `InitInstance` can be called by the MFC code in the application without `AFX_MODULE_STATE` because MFC automatically shifts the module state before `InitInstance` and then switches it back after `InitInstance` returns. The same is true for all message map handlers. Regular MFC DLLs actually have a special master window procedure that automatically switches the module state before routing any message.  
   
 ## Process Local Data  
  Process local data would not be of such great concern had it not been for the difficulty of the Win32s DLL model. In Win32s all DLLs share their global data, even when loaded by multiple applications. This is very different from the "real" Win32 DLL data model, where each DLL gets a separate copy of its data space in each process that attaches to the DLL. To add to the complexity, data allocated on the heap in a Win32s DLL is in fact process specific (at least as far as ownership goes). Consider the following data and code:  
