MicrosoftDocs · nschonni · Nov 19, 2018
diff --git a/docs/atl/atl-collection-classes.md b/docs/atl/atl-collection-classes.md
@@ -96,7 +96,7 @@ For a list of the CTraits classes, see [Collection Classes](../atl/collection-cl
 
 The following diagram shows the class hierarchy for the CTraits classes.
 
-![Traits hierarchy for collection classes](../atl/media/vctraitscollectionclasseshierarchy.gif "vctraitscollectionclasseshierarchy")
+![Traits hierarchy for collection classes](../atl/media/vctraitscollectionclasseshierarchy.gif)
 
 ## Collection Classes Samples
 

diff --git a/docs/atl/atl-connection-points.md b/docs/atl/atl-connection-points.md
@@ -8,7 +8,7 @@ ms.assetid: 17d76165-5f83-4f95-b36d-483821c247a1
 
 A connectable object is one that supports outgoing interfaces. An outgoing interface allows the object to communicate with a client. For each outgoing interface, the connectable object exposes a connection point. Each outgoing interface is implemented by a client on an object called a sink.
 
-![Connection points](../atl/media/vc2zw31.gif "vc2zw31")
+![Connection points](../atl/media/vc2zw31.gif)
 
 Each connection point supports the [IConnectionPoint](/windows/desktop/api/ocidl/nn-ocidl-iconnectionpoint) interface. The connectable object exposes its connection points to the client through the [IConnectionPointContainer](/windows/desktop/api/ocidl/nn-ocidl-iconnectionpointcontainer) interface.
 

diff --git a/docs/atl/example-implementing-a-property-page.md b/docs/atl/example-implementing-a-property-page.md
@@ -51,7 +51,7 @@ Click **OK** to have the wizard generate your property page.
 
 Now that your property page has been generated, you'll need to add a few controls to the dialog resource representing your page. Add an edit box, a static text control, and a check box and set their IDs as shown below:
 
-![Editing a dialog resource](../atl/media/ppgresourcelabeled.gif "ppgresourcelabeled")
+![Editing a dialog resource](../atl/media/ppgresourcelabeled.gif)
 
 These controls will be used to display the file name of the document and its read-only status.
 

diff --git a/docs/atl/fundamentals-of-atl-com-objects.md b/docs/atl/fundamentals-of-atl-com-objects.md
@@ -8,7 +8,7 @@ ms.assetid: 0f9c9d98-cc28-45da-89ac-dc94cee422fe
 
 The following illustration depicts the relationship among the classes and interfaces that are used to define an ATL COM object.
 
-![ATL structure](../atl/media/vc307y1.gif "vc307y1")
+![ATL structure](../atl/media/vc307y1.gif)
 
 > [!NOTE]
 >  This diagram shows that `CComObject` is derived from `CYourClass` whereas `CComAggObject` and `CComPolyObject` include `CYourClass` as a member variable.

diff --git a/docs/atl/identifying-the-elements-of-the-dhtml-control-project.md b/docs/atl/identifying-the-elements-of-the-dhtml-control-project.md
@@ -18,7 +18,7 @@ A DHTML control is similar to any ATL control, except:
 
 The following graphic illustrates the relationship between your DLL, the DHTML control, the Web browser, and the HTML resource.
 
-![Elements of a DHTML control project](../atl/media/vc52en1.gif "vc52en1")
+![Elements of a DHTML control project](../atl/media/vc52en1.gif)
 
 > [!NOTE]
 >  The names on this graphic are placeholders. The names of your HTML resource and the interfaces exposed on your control are based on the names you assign them in the ATL Control Wizard.
@@ -39,7 +39,7 @@ In this graphic, the elements are:
 
 The ATL Control Wizard generates a control with default code in both the HTML resource and the .cpp file. You can compile and run the control as generated by the wizard, and then view the control in either the Web browser or the ActiveX Control Test Container. The picture below shows the default ATL DHTML control with three buttons displayed in Test Container:
 
-![ATL DHTML control](../atl/media/vc52en2.gif "vc52en2")
+![ATL DHTML control](../atl/media/vc52en2.gif)
 
 See [Creating an ATL DHTML Control](../atl/creating-an-atl-dhtml-control.md) to get started building a DHTML control. See [Testing Properties and Events with Test Container](../mfc/testing-properties-and-events-with-test-container.md) for information on how to access Test Container.
 

diff --git a/docs/c-runtime-library/stream-states.md b/docs/c-runtime-library/stream-states.md
@@ -8,7 +8,7 @@ ms.assetid: 5f28c968-f132-403f-968c-8417ff315e52
 
 The valid states, and state transitions, for a stream are shown in the following figure.
 
-![Stream](../c-runtime-library/media/stream.gif "stream")
+![Stream](../c-runtime-library/media/stream.gif)
 
 Each of the circles denotes a stable state. Each of the lines denotes a transition that can occur as the result of a function call that operates on the stream. Five groups of functions can cause state transitions.
 

diff --git a/docs/cpp/arrays-cpp.md b/docs/cpp/arrays-cpp.md
@@ -66,7 +66,7 @@ int i2[5][7];
 
 It specifies an array of type **int**, conceptually arranged in a two-dimensional matrix of five rows and seven columns, as shown in the following figure:
 
-![Conceptual layout of a multi&#45;dimensional array](../cpp/media/vc38rc1.gif "vc38RC1")
+![Conceptual layout of a multi&#45;dimensional array](../cpp/media/vc38rc1.gif)
 Conceptual Layout of Multidimensional Array
 
 In declarations of multidimensioned arrays that have an initializer list (as described in [Initializers](../cpp/initializers.md)), the constant expression that specifies the bounds for the first dimension can be omitted. For example:

diff --git a/docs/cpp/base-classes.md b/docs/cpp/base-classes.md
@@ -8,7 +8,7 @@ ms.assetid: 6e6d54d0-6f21-4a16-9103-22935d98f596
 
 The inheritance process creates a new derived class that is made up of the members of the base class(es) plus any new members added by the derived class. In a multiple-inheritance, it is possible to construct an inheritance graph where the same base class is part of more than one of the derived classes. The following figure shows such a graph.
 
-![Multiple instances of a base class](../cpp/media/vc38xn1.gif "vc38XN1")
+![Multiple instances of a base class](../cpp/media/vc38xn1.gif)
 Multiple Instances of a Single Base Class
 
 In the figure, pictorial representations of the components of `CollectibleString` and `CollectibleSortable` are shown. However, the base class, `Collectible`, is in `CollectibleSortableString` through the `CollectibleString` path and the `CollectibleSortable` path. To eliminate this redundancy, such classes can be declared as virtual base classes when they are inherited.
diff --git a/docs/cpp/casting.md b/docs/cpp/casting.md
@@ -10,12 +10,12 @@ The C++ language provides that if a class is derived from a base class containin
 
 Since a derived class completely contains the definitions of all the base classes from which it is derived, it is safe to cast a pointer up the class hierarchy to any of these base classes. Given a pointer to a base class, it might be safe to cast the pointer down the hierarchy. It is safe if the object being pointed to is actually of a type derived from the base class. In this case, the actual object is said to be the "complete object." The pointer to the base class is said to point to a "subobject" of the complete object. For example, consider the class hierarchy shown in the following figure.
 
-![Class hierarchy](../cpp/media/vc38zz1.gif "vc38ZZ1")
+![Class hierarchy](../cpp/media/vc38zz1.gif)
 Class Hierarchy
 
 An object of type `C` could be visualized as shown in the following figure.
 
-![Class C with sub&#45;objects B and A](../cpp/media/vc38zz2.gif "vc38ZZ2")
+![Class C with sub&#45;objects B and A](../cpp/media/vc38zz2.gif)
 Class C with B Subobject and A Subobject
 
 Given an instance of class `C`, there is a `B` subobject and an `A` subobject. The instance of `C`, including the `A` and `B` subobjects, is the "complete object."

diff --git a/docs/cpp/destructors-cpp.md b/docs/cpp/destructors-cpp.md
@@ -140,7 +140,7 @@ B1 dtor
 
 Destructors for virtual base classes are called in the reverse order of their appearance in a directed acyclic graph (depth-first, left-to-right, postorder traversal). the following figure depicts an inheritance graph.
 
-![Inheritance graph that shows virtual base classes](../cpp/media/vc392j1.gif "vc392J1")
+![Inheritance graph that shows virtual base classes](../cpp/media/vc392j1.gif)
 
 Inheritance Graph Showing Virtual Base Classes
 

diff --git a/docs/cpp/dynamic-cast-operator.md b/docs/cpp/dynamic-cast-operator.md
@@ -113,7 +113,7 @@ int main() {
 }
 ```
 
-![Class hierarchy that shows multiple inheritance](../cpp/media/vc39011.gif "vc39011")
+![Class hierarchy that shows multiple inheritance](../cpp/media/vc39011.gif)
 Class Hierarchy Showing Multiple Inheritance
 
 A pointer to an object of type `D` can be safely cast to `B` or `C`. However, if `D` is cast to point to an `A` object, which instance of `A` would result? This would result in an ambiguous casting error. To get around this problem, you can perform two unambiguous casts. For example:
@@ -134,14 +134,14 @@ void f() {
 
 Further ambiguities can be introduced when you use virtual base classes. Consider the class hierarchy shown in the following figure.
 
-![Class hierarchy that shows virtual base classes](../cpp/media/vc39012.gif "vc39012")
+![Class hierarchy that shows virtual base classes](../cpp/media/vc39012.gif)
 Class Hierarchy Showing Virtual Base Classes
 
 In this hierarchy, `A` is a virtual base class. Given an instance of class `E` and a pointer to the `A` subobject, a **dynamic_cast** to a pointer to `B` will fail due to ambiguity. You must first cast back to the complete `E` object, then work your way back up the hierarchy, in an unambiguous manner, to reach the correct `B` object.
 
 Consider the class hierarchy shown in the following figure.
 
-![Class hierarchy that shows duplicate base classes](../cpp/media/vc39013.gif "vc39013")
+![Class hierarchy that shows duplicate base classes](../cpp/media/vc39013.gif)
 Class Hierarchy Showing Duplicate Base Classes
 
 Given an object of type `E` and a pointer to the `D` subobject, to navigate from the `D` subobject to the left-most `A` subobject, three conversions can be made. You can perform a **dynamic_cast** conversion from the `D` pointer to an `E` pointer, then a conversion (either **dynamic_cast** or an implicit conversion) from `E` to `B`, and finally an implicit conversion from `B` to `A`. For example:

diff --git a/docs/cpp/friend-cpp.md b/docs/cpp/friend-cpp.md
@@ -220,7 +220,7 @@ Friendship is not inherited, meaning that classes derived from `YourOtherClass`
 
 The following figure shows four class declarations: `Base`, `Derived`, `aFriend`, and `anotherFriend`. Only class `aFriend` has direct access to the private members of `Base` (and to any members `Base` might have inherited).
 
-![Implications of friend relationship](../cpp/media/vc38v41.gif "vc38V41")
+![Implications of friend relationship](../cpp/media/vc38v41.gif)
 Implications of friend Relationship
 
 ## Inline friend definitions

diff --git a/docs/cpp/function-overloading.md b/docs/cpp/function-overloading.md
@@ -271,7 +271,7 @@ The sequence in which conversions are attempted is as follows:
 
    - Conversion from a pointer to a derived class, to a pointer to a base class produces a better match the closer the base class is to a direct base class. Suppose the class hierarchy is as shown in the following figure.
 
-![Preferred conversions](../cpp/media/vc391t1.gif "vc391T1")
+![Preferred conversions](../cpp/media/vc391t1.gif)
 Graph Illustrating Preferred Conversions
 
 Conversion from type `D*` to type `C*` is preferable to conversion from type `D*` to type `B*`. Similarly, conversion from type `D*` to type `B*` is preferable to conversion from type `D*` to type `A*`.
@@ -282,7 +282,7 @@ This same rule applies to pointer-to-member conversions. Conversion from type `T
 
 The preceding rule applies only along a given path of derivation. Consider the graph shown in the following figure.
 
-![Multi&#45;inheritance that shows preferred conversions](../cpp/media/vc391t2.gif "vc391T2")
+![Multi&#45;inheritance that shows preferred conversions](../cpp/media/vc391t2.gif)
 Multiple-Inheritance Graph Illustrating Preferred Conversions
 
 Conversion from type `C*` to type `B*` is preferable to conversion from type `C*` to type `A*`. The reason is that they are on the same path, and `B*` is closer. However, conversion from type `C*` to type `D*` is not preferable to conversion to type `A*`; there is no preference because the conversions follow different paths.

diff --git a/docs/cpp/functions-cpp.md b/docs/cpp/functions-cpp.md
@@ -114,7 +114,7 @@ Optional parts of a function declaration are:
 
 The following figure shows the parts of a function definition. The shaded area is the function body.
 
-![Parts of a function definition](../cpp/media/vc38ru1.gif "vc38RU1")
+![Parts of a function definition](../cpp/media/vc38ru1.gif)
 Parts of a Function Definition
 
 ## Function definitions

diff --git a/docs/cpp/initializers.md b/docs/cpp/initializers.md
@@ -517,7 +517,7 @@ Reference-type variables can be declared without initializers only in the follow
 
 When initializing a reference-type variable, the compiler uses the decision graph shown in the following figure to select between creating a reference to an object or creating a temporary object to which the reference points.
 
-![Decision graph for initialization of ref types](../cpp/media/vc38s71.gif "vc38S71")
+![Decision graph for initialization of ref types](../cpp/media/vc38s71.gif)
 Decision Graph for Initialization of Reference Types
 
 References to **volatile** types (declared as **volatile** *typename*<strong>&</strong> *identifier*) can be initialized with **volatile** objects of the same type or with objects that have not been declared as **volatile**. They cannot, however, be initialized with **const** objects of that type. Similarly, references to **const** types (declared as **const** *typename*<strong>&</strong> *identifier*) can be initialized with **const** objects of the same type (or anything that has a conversion to that type or with objects that have not been declared as **const**). They cannot, however, be initialized with **volatile** objects of that type.

diff --git a/docs/cpp/member-access-control-cpp.md b/docs/cpp/member-access-control-cpp.md
@@ -225,7 +225,7 @@ In the preceding example, calling the virtual function `GetState` using a pointe
 
 In multiple-inheritance lattices involving virtual base classes, a given name can be reached through more than one path. Because different access control can be applied along these different paths, the compiler chooses the path that gives the most access. See the following figure.
 
-![Access along paths of an inheritance graph](../cpp/media/vc38v91.gif "vc38V91")
+![Access along paths of an inheritance graph](../cpp/media/vc38v91.gif)
 Access Along Paths of an Inheritance Graph
 
 In the figure, a name declared in class `VBase` is always reached through class `RightPath`. The right path is more accessible because `RightPath` declares `VBase` as a public base class, whereas `LeftPath` declares `VBase` as private.

diff --git a/docs/cpp/multiple-base-classes.md b/docs/cpp/multiple-base-classes.md
@@ -42,12 +42,12 @@ When declaring a virtual base class, the **virtual** keyword appears in the base
 
 Consider the class hierarchy in the following figure, which illustrates a simulated lunch line.
 
-![Graph of simulated lunch line](../cpp/media/vc38xp1.gif "vc38XP1")
+![Graph of simulated lunch line](../cpp/media/vc38xp1.gif)
 Simulated Lunch-Line Graph
 
 In the figure, `Queue` is the base class for both `CashierQueue` and `LunchQueue`. However, when both classes are combined to form `LunchCashierQueue`, the following problem arises: the new class contains two subobjects of type `Queue`, one from `CashierQueue` and the other from `LunchQueue`. The following figure shows the conceptual memory layout (the actual memory layout might be optimized).
 
-![Simulated lunch&#45;line object](../cpp/media/vc38xp2.gif "vc38XP2")
+![Simulated lunch&#45;line object](../cpp/media/vc38xp2.gif)
 Simulated Lunch-Line Object
 
 Note that there are two `Queue` subobjects in the `LunchCashierQueue` object. The following code declares `Queue` to be a virtual base class:
@@ -63,17 +63,17 @@ class LunchCashierQueue : public LunchQueue, public CashierQueue {};
 
 The **virtual** keyword ensures that only one copy of the subobject `Queue` is included (see the following figure).
 
-![Simulated lunch&#45;line object, virtual base classes](../cpp/media/vc38xp3.gif "vc38XP3")
+![Simulated lunch&#45;line object, virtual base classes](../cpp/media/vc38xp3.gif)
 Simulated Lunch-Line Object with Virtual Base Classes
 
 A class can have both a virtual component and a nonvirtual component of a given type. This happens in the conditions illustrated in the following figure.
 
-![Virtual and nonvirtual components of a class](../cpp/media/vc38xp4.gif "vc38XP4")
+![Virtual and nonvirtual components of a class](../cpp/media/vc38xp4.gif)
 Virtual and Nonvirtual Components of the Same Class
 
 In the figure, `CashierQueue` and `LunchQueue` use `Queue` as a virtual base class. However, `TakeoutQueue` specifies `Queue` as a base class, not a virtual base class. Therefore, `LunchTakeoutCashierQueue` has two subobjects of type `Queue`: one from the inheritance path that includes `LunchCashierQueue` and one from the path that includes `TakeoutQueue`. This is illustrated in the following figure.
 
-![Virtual & nonvirtual inheritance in object layout](../cpp/media/vc38xp5.gif "vc38XP5")
+![Virtual & nonvirtual inheritance in object layout](../cpp/media/vc38xp5.gif)
 Object Layout with Virtual and Nonvirtual Inheritance
 
 > [!NOTE]
@@ -182,7 +182,7 @@ Explicit and implicit conversions from pointers or references to class types can
 
 - The effect of explicitly converting the pointer obtained using the address-of operator to the base-class type `A`. Note that coercing the address of the object to type `A*` does not always provide the compiler with enough information as to which subobject of type `A` to select; in this case, two subobjects exist.
 
-![Ambiguous conversion of pointers to base classes](../cpp/media/vc38xt1.gif "vc38XT1")
+![Ambiguous conversion of pointers to base classes](../cpp/media/vc38xt1.gif)
 Ambiguous Conversion of Pointers to Base Classes
 
 The conversion to type `A*` (pointer to `A`) is ambiguous because there is no way to discern which subobject of type `A` is the correct one. Note that you can avoid the ambiguity by explicitly specifying which subobject you mean to use, as follows:
@@ -198,7 +198,7 @@ If virtual base classes are used, functions, objects, types, and enumerators can
 
 The following figure shows how objects are composed using virtual and nonvirtual inheritance.
 
-![Virtual derivation and nonvirtual derivation](../cpp/media/vc38xr1.gif "vc38XR1")
+![Virtual derivation and nonvirtual derivation](../cpp/media/vc38xr1.gif)
 Virtual vs. Nonvirtual Derivation
 
 In the figure, accessing any member of class `A` through nonvirtual base classes causes an ambiguity; the compiler has no information that explains whether to use the subobject associated with `B` or the subobject associated with `C`. However, when `A` is specified as a virtual base class, there is no question which subobject is being accessed.

diff --git a/docs/cpp/overview-of-declarators.md b/docs/cpp/overview-of-declarators.md
@@ -8,7 +8,7 @@ ms.assetid: 0f2e2312-80bd-4154-8345-718bd9ed2173
 
 Declarators are the components of a declaration that specify names of objects or functions. Declarators also specify whether or not the named object is an object, pointer, reference or array.  While declarators do not specify the base type, they do modify the type information in the basic type to specify derived types such as pointers, references, and arrays.  Applied to functions, the declarator works with the type specifier to fully specify the return type of a function to be an object, pointer, or reference. (Specifiers, discussed in [Declarations and Definitions](declarations-and-definitions-cpp.md), convey properties such as type and storage class. Modifiers, discussed in this section and in [Microsoft-Specific Modifiers](../cpp/microsoft-specific-modifiers.md), modify declarators.) The following figure shows a complete declaration of `MyFunction`, and calls out the components of the declaration.
 
-![Modifiers, specifiers, and declarators](../cpp/media/vc38qy1.gif "vc38QY1")
+![Modifiers, specifiers, and declarators](../cpp/media/vc38qy1.gif)
 Specifiers, Modifiers, and Declarators
 
 **Microsoft Specific**

diff --git a/docs/cpp/results-of-calling-example.md b/docs/cpp/results-of-calling-example.md
@@ -12,21 +12,21 @@ ms.assetid: aa70a7cb-ba1d-4aa6-bd0a-ba783da2e642
 
 The C decorated function name is `_MyFunc`.
 
-![CDECL calling convention](../cpp/media/vc37i01.gif "vc37I01")
+![CDECL calling convention](../cpp/media/vc37i01.gif)
 The **__cdecl** calling convention
 
 ## __stdcall and thiscall
 
 The C decorated name (**__stdcall**) is `_MyFunc@20`. The C++ decorated name is implementation-specific.
 
-![&#95;&#95;stdcall and thiscall calling conventions](../cpp/media/vc37i02.gif "vc37I02")
+![&#95;&#95;stdcall and thiscall calling conventions](../cpp/media/vc37i02.gif)
 The __stdcall and thiscall calling conventions
 
 ## __fastcall
 
 The C decorated name (**__fastcall**) is `@MyFunc@20`. The C++ decorated name is implementation-specific.
 
-![Calling convention for &#95;&#95;fastcall](../cpp/media/vc37i03.gif "vc37I03")
+![Calling convention for &#95;&#95;fastcall](../cpp/media/vc37i03.gif)
 The __fastcall calling convention
 
 **END Microsoft Specific**