Skip to content

Commit 0a06dfe

Browse files
author
mikeblome
committed
removed redundant ../build prefix from links that were causing problems when toc nodes moved
1 parent 3001050 commit 0a06dfe

File tree

177 files changed

+633
-633
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

177 files changed

+633
-633
lines changed

docs/build/active-technology-and-dlls.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -16,4 +16,4 @@ If you are writing an Automation server and your server has no user interface, y
1616

1717
## See Also
1818

19-
[DLLs in Visual C++](../build/dlls-in-visual-cpp.md)
19+
[DLLs in Visual C++](dlls-in-visual-cpp.md)

docs/build/aggregates-and-unions.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -49,8 +49,8 @@ The following aggregate alignment rules apply:
4949

5050
- It is possible to align data in such a way as to be greater than the alignment requirements as long as the previous rules are maintained.
5151

52-
- An individual compiler may adjust the packing of a structure for size reasons. For example [/Zp (Struct Member Alignment)](../build/reference/zp-struct-member-alignment.md) allows for adjusting the packing of structures.
52+
- An individual compiler may adjust the packing of a structure for size reasons. For example [/Zp (Struct Member Alignment)](reference/zp-struct-member-alignment.md) allows for adjusting the packing of structures.
5353

5454
## See Also
5555

56-
[Types and Storage](../build/types-and-storage.md)
56+
[Types and Storage](types-and-storage.md)

docs/build/alloca.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -8,8 +8,8 @@ ms.assetid: 2b209335-e3a0-4934-93f0-3b5925d22918
88

99
[_alloca](../c-runtime-library/reference/alloca.md) is required to be 16-byte aligned and additionally required to use a frame pointer.
1010

11-
The stack that is allocated needs to include space below it for parameters of subsequently called functions, as discussed in [Stack Allocation](../build/stack-allocation.md).
11+
The stack that is allocated needs to include space below it for parameters of subsequently called functions, as discussed in [Stack Allocation](stack-allocation.md).
1212

1313
## See Also
1414

15-
[Stack Usage](../build/stack-usage.md)
15+
[Stack Usage](stack-usage.md)

docs/build/arm-exception-handling.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -733,5 +733,5 @@ Function:
733733

734734
## See also
735735

736-
[Overview of ARM ABI Conventions](../build/overview-of-arm-abi-conventions.md)<br/>
737-
[Common Visual C++ ARM Migration Issues](../build/common-visual-cpp-arm-migration-issues.md)
736+
[Overview of ARM ABI Conventions](overview-of-arm-abi-conventions.md)<br/>
737+
[Common Visual C++ ARM Migration Issues](common-visual-cpp-arm-migration-issues.md)

docs/build/arm64-exception-handling.md

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -46,7 +46,7 @@ These are the assumptions made in the exception handling description:
4646

4747
## ARM64 stack frame layout
4848

49-
![stack frame layout](../build/media/arm64-exception-handling-stack-frame.png "stack frame layout")
49+
![stack frame layout](media/arm64-exception-handling-stack-frame.png "stack frame layout")
5050

5151
For frame chained functions, the fp and lr pair can be saved at any position in the local variable area depending on optimization considerations. The goal is to maximize the number of locals that can be reached by one single instruction based on frame pointer (r29) or stack pointer (sp). However for `alloca` functions, it must be chained and r29 must point to the bottom of stack. To allow for better register-pair-addressing-mode coverage, nonvolatile register aave areas are positioned at the top of the Local area stack. Here are examples that illustrate several of the most efficient prolog sequences. For the sake of clarity and better cache locality, the order of storing callee-saved registers in all canonical prologs is in "growing up" order. `#framesz` below represents the size of entire stack (excluding alloca area). `#localsz` and `#outsz` denote local area size (including the save area for the \<r29, lr> pair) and outgoing parameter size, respectively.
5252

@@ -181,7 +181,7 @@ The .pdata records are an ordered array of fixed-length items which describe eve
181181
182182
Each .pdata record for ARM64 is 8 bytes in length. The general format of the each record places the 32-bit RVA of the function start in the first word, followed by a second with that contains either a pointer to a variable-length .xdata block, or a packed word describing a canonical function unwinding sequence.
183183
184-
![.pdata record layout](../build/media/arm64-exception-handling-pdata-record.png ".pdata record layout")
184+
![.pdata record layout](media/arm64-exception-handling-pdata-record.png ".pdata record layout")
185185
186186
The fields are as follows:
187187
@@ -197,7 +197,7 @@ The fields are as follows:
197197
198198
When the packed unwind format is insufficient to describe the unwinding of a function, a variable-length .xdata record must be created. The address of this record is stored in the second word of the .pdata record. The format of the .xdata is a packed variable-length set of words:
199199
200-
![.xdata record layout](../build/media/arm64-exception-handling-xdata-record.png ".xdata record layout")
200+
![.xdata record layout](media/arm64-exception-handling-xdata-record.png ".xdata record layout")
201201
202202
This data is broken into four sections:
203203
@@ -328,7 +328,7 @@ For functions whose prologs and epilogs follow the canonical form described belo
328328

329329
The format of a .pdata record with packed unwind data looks like this:
330330

331-
![.pdata record with packed unwind data](../build/media/arm64-exception-handling-packed-unwind-data.png ".pdata record with packed unwind data")
331+
![.pdata record with packed unwind data](media/arm64-exception-handling-packed-unwind-data.png ".pdata record with packed unwind data")
332332

333333
The fields are as follows:
334334

@@ -621,4 +621,4 @@ Note: EpilogStart Index [4] points to the middle of Prolog unwind code (partiall
621621
## See also
622622

623623
[Overview of ARM64 ABI conventions](arm64-windows-abi-conventions.md)<br/>
624-
[ARM Exception Handling](../build/arm-exception-handling.md)
624+
[ARM Exception Handling](arm-exception-handling.md)

docs/build/arm64-windows-abi-conventions.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -197,7 +197,7 @@ The default kernel mode stack in Windows is six pages (24k). Pay extra attention
197197

198198
## Stack walking
199199

200-
Code within Windows is compiled with frame pointers enabled ([/Oy-](../build/reference/oy-frame-pointer-omission.md)) to enable fast stack walking. The upshot of this is that x29 (fp) in general points to the next link in the chain, which is an {fp,lr} pair indicating the pointer to the previous frame on the stack and the return address. Third-party code is encouraged to enable frame pointers as well in order to allow for improved profiling and tracing.
200+
Code within Windows is compiled with frame pointers enabled ([/Oy-](reference/oy-frame-pointer-omission.md)) to enable fast stack walking. The upshot of this is that x29 (fp) in general points to the next link in the chain, which is an {fp,lr} pair indicating the pointer to the previous frame on the stack and the return address. Third-party code is encouraged to enable frame pointers as well in order to allow for improved profiling and tracing.
201201

202202
## Exception unwinding
203203

@@ -215,5 +215,5 @@ Note that the cycle counter here is a true cycle counter, not a wall clock, and
215215

216216
## See also
217217

218-
[Common Visual C++ ARM Migration Issues](../build/common-visual-cpp-arm-migration-issues.md)<br/>
219-
[ARM64 exception handling](../build/arm64-exception-handling.md)
218+
[Common Visual C++ ARM Migration Issues](common-visual-cpp-arm-migration-issues.md)<br/>
219+
[ARM64 exception handling](arm64-exception-handling.md)

docs/build/automation-in-a-dll.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -24,4 +24,4 @@ When you choose the Automation option in the MFC DLL Wizard, the wizard provides
2424

2525
## See Also
2626

27-
[DLLs in Visual C++](../build/dlls-in-visual-cpp.md)
27+
[DLLs in Visual C++](dlls-in-visual-cpp.md)

docs/build/bitfields.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -10,4 +10,4 @@ Structure bit fields are limited to 64 bits and can be of type signed int, unsig
1010

1111
## See Also
1212

13-
[Types and Storage](../build/types-and-storage.md)
13+
[Types and Storage](types-and-storage.md)

docs/build/building-c-cpp-isolated-applications-and-side-by-side-assemblies.md

Lines changed: 7 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -14,19 +14,19 @@ This section discusses how you can build your C/C++ application as an isolated a
1414

1515
## In This Section
1616

17-
[Concepts of Isolated Applications and Side-by-side Assemblies](../build/concepts-of-isolated-applications-and-side-by-side-assemblies.md)
17+
[Concepts of Isolated Applications and Side-by-side Assemblies](concepts-of-isolated-applications-and-side-by-side-assemblies.md)
1818

19-
[Building C/C++ Isolated Applications](../build/building-c-cpp-isolated-applications.md)
19+
[Building C/C++ Isolated Applications](building-c-cpp-isolated-applications.md)
2020

21-
[Building C/C++ Side-by-side Assemblies](../build/building-c-cpp-side-by-side-assemblies.md)
21+
[Building C/C++ Side-by-side Assemblies](building-c-cpp-side-by-side-assemblies.md)
2222

23-
[How to: Build Registration-Free COM Components](../build/how-to-build-registration-free-com-components.md)
23+
[How to: Build Registration-Free COM Components](how-to-build-registration-free-com-components.md)
2424

25-
[How to: Build Isolated Applications to Consume COM Components](../build/how-to-build-isolated-applications-to-consume-com-components.md)
25+
[How to: Build Isolated Applications to Consume COM Components](how-to-build-isolated-applications-to-consume-com-components.md)
2626

27-
[Understanding Manifest Generation for C/C++ Programs](../build/understanding-manifest-generation-for-c-cpp-programs.md)
27+
[Understanding Manifest Generation for C/C++ Programs](understanding-manifest-generation-for-c-cpp-programs.md)
2828

29-
[Troubleshooting C/C++ Isolated Applications and Side-by-side Assemblies](../build/troubleshooting-c-cpp-isolated-applications-and-side-by-side-assemblies.md)
29+
[Troubleshooting C/C++ Isolated Applications and Side-by-side Assemblies](troubleshooting-c-cpp-isolated-applications-and-side-by-side-assemblies.md)
3030

3131
## Related Sections
3232

docs/build/building-c-cpp-isolated-applications.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -8,9 +8,9 @@ ms.assetid: 8a2fe4fa-0489-433e-bfc6-495844d8d73a
88

99
An isolated application depends only on side-by-side assemblies and binds to its dependencies using a manifest. It is not required for your application to be fully isolated in order to run properly on Windows; however, by investing in making your application fully isolated, you may save time if you need to service your application in the future. For more information on the advantages of making your application fully isolated, see [Isolated Applications](/windows/desktop/SbsCs/isolated-applications).
1010

11-
When you build your native C/C++ application using Visual C++, by default the Visual Studio project system generates a manifest file that describes your application's dependencies on Visual C++ libraries. If these are the only dependencies your application has, then it becomes an isolated application as soon as it is rebuilt with Visual Studio. If your application is using other libraries at runtime, then you may need to rebuild those libraries as side-by-side assemblies following the steps described in [Building C/C++ Side-by-side Assemblies](../build/building-c-cpp-side-by-side-assemblies.md).
11+
When you build your native C/C++ application using Visual C++, by default the Visual Studio project system generates a manifest file that describes your application's dependencies on Visual C++ libraries. If these are the only dependencies your application has, then it becomes an isolated application as soon as it is rebuilt with Visual Studio. If your application is using other libraries at runtime, then you may need to rebuild those libraries as side-by-side assemblies following the steps described in [Building C/C++ Side-by-side Assemblies](building-c-cpp-side-by-side-assemblies.md).
1212

1313
## See Also
1414

15-
[Concepts of Isolated Applications and Side-by-side Assemblies](../build/concepts-of-isolated-applications-and-side-by-side-assemblies.md)<br/>
16-
[Building C/C++ Isolated Applications and Side-by-side Assemblies](../build/building-c-cpp-isolated-applications-and-side-by-side-assemblies.md)
15+
[Concepts of Isolated Applications and Side-by-side Assemblies](concepts-of-isolated-applications-and-side-by-side-assemblies.md)<br/>
16+
[Building C/C++ Isolated Applications and Side-by-side Assemblies](building-c-cpp-isolated-applications-and-side-by-side-assemblies.md)

0 commit comments

Comments
 (0)