1. You can also set project dependencies. Setting project dependencies guarantees two things. First, it ensures that projects are built in the right order so that a project can always find the dependent files it needs. Second, it implicitly adds the dependent project’s output directory to the path so that files can be found easily at link-time.

To customize your program’s command line arguments and debugging instructions, right-click on the executable in **Solution Explorer** and select **Debug and Launch Settings**. This will open an existing *launch.vs.json* file, or if none exists, it will create a new file with a set of minimal launch settings. First you are given a choice of what kind of debug session you want to configure. For debugging a MinGw-w64 project, we choose **C/C++ Launch for MinGW/Cygwin (gdb)**. This creates a launch configuration for using *gdb.exe* with some educated guesses about default values. One of those default values is `MINGW_PREFIX`. You can substitute the literal path (as shown below) or you can define a `MINGW_PREFIX` property in *CppProperties.json*:

It is also strongly recommended to generate debug symbols, even with optimized release builds. It doesn’t affect the generated code, and it makes it a lot easier to debug your application, if need be.

There are also several useful pragmas for helping optimize code. The first one we’ll discuss is `#pragma optimize`:

Stack unwinding during exception handling is enabled by the use of unwind codes. The unwind codes are a sequence of bytes stored in the .xdata section of the executable image. They describe the operation of the function prologue and epilogue code in an abstract manner, so that the effects of a function’s prologue can be undone in preparation for unwinding to the caller’s stack frame.

These forms are the only legal ones for an epilog. It must consist of either an `add RSP,constant` or `lea RSP,constant[FPReg]`, followed by a series of zero or more 8-byte register pops and a `return` or a `jmp`. (Only a subset of `jmp` statements are allowable in the epilog. The subset is exclusively the class of `jmp` statements with ModRM memory references where ModRM mod field value is 00. The use of `jmp` statements in the epilog with ModRM mod field value 01 or 10 is prohibited. See Table A-15 in the AMD x86-64 Architecture Programmer’s Manual Volume 3: General Purpose and System Instructions, for more info on the allowable ModRM references.) No other code can appear. In particular, nothing can be scheduled within an epilog, including loading of a return value.

The target `reverse.exe` has one dependent, `retro.obj`. The brace-enclosed list specifies two directories. NMAKE searches for `retro.obj` in the current directory first. If it isn’t there, NMAKE searches the `\src\omega` directory, then the `e:\repo\backwards` directory.

We recommend that you not link objects compiled by using **/EHa** together with objects compiled by using **/EHs** or **/EHsc** in the same executable module. If you have to handle an asynchronous exception by using **/EHa** anywhere in your module, use **/EHa** to compile all the code in the module. You can use structured exception handling syntax in the same module as code that's compiled by using **/EHs**, but you can’t mix the SEH syntax with **try**, **throw**, and **catch** in the same function.

You can use \@*ordinal* to specify that a number, and not the function name, goes into the DLL's export table. Many Windows DLLs export ordinals to support legacy code. It was common to use ordinals in 16-bit Windows code, because it can help minimize the size of a DLL. We don’t recommend exporting functions by ordinal unless your DLL’s clients need it for legacy support. Because the .LIB file will contain the mapping between the ordinal and the function, you can use the function name as you normally would in projects that use the DLL.