Skip to content

Repo sync for protected branch #5571

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 14 commits into from
Jul 23, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 13 additions & 14 deletions docs/assembler/masm/dot-fpo.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,35 +4,34 @@ title: ".FPO"
ms.date: "11/05/2019"
f1_keywords: [".FPO"]
helpviewer_keywords: [".FPO directive"]
ms.assetid: 35f4cd61-32f9-4262-b657-73f04f775d09
---
# .FPO (32-bit MASM)

The **.FPO** directive controls the emission of debug records to the .debug$F segment or section. (32-bit MASM only.)
The `.FPO` directive controls the emission of debug records to the `.debug$F` segment or section. Use this directive with 32-bit MASM only.

## Syntax

> **.FPO** (*cdwLocals*, *cdwParams*, *cbProlog*, *cbRegs*, *fUseBP*, *cbFrame*)
> `.FPO` (*`cdwLocals`*, *`cdwParams`*, *`cbProlog`*, *`cbRegs`*, *`fUseBP`*, *`cbFrame`*)

### Parameters

*cdwLocals*\
Number of local variables, an unsigned 32 bit value.
*`cdwLocals`*\
Number of local variables, an unsigned 32-bit value.

*cdwParams*\
Size of the parameters in DWORDS, an unsigned 16 bit value.
*`cdwParams`*\
Size of the parameters in DWORDS, an unsigned 16-bit value.

*cbProlog*\
Number of bytes in the function prolog code, an unsigned 8 bit value.
*`cbProlog`*\
Number of bytes in the function prolog code, an unsigned 8-bit value.

*cbRegs*\
*`cbRegs`*\
Number registers saved.

*fUseBP*\
Indicates whether the EBP register has been allocated. either 0 or 1.
*`fUseBP`*\
Indicates whether the EBP register is allocated. Use either 0 or 1.

*cbFrame*\
Indicates the frame type. See [FPO_DATA](/windows/win32/api/winnt/ns-winnt-fpo_data) for more information.
*`cbFrame`*\
Indicates the frame type. For more information, see [`FPO_DATA`](/windows/win32/api/winnt/ns-winnt-fpo_data).

## See also

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -2,32 +2,31 @@
description: "Learn more about: Choosing the Format of .netmodule Input Files"
title: "Choosing the Format of .netmodule Input Files"
ms.date: "11/04/2016"
ms.assetid: 4653d1bd-300f-4083-86f5-d1a06f44e61c
---
# Choosing the Format of .netmodule Input Files
# Choosing the format of .netmodule input files

An MSIL .obj file (compiled with [/clr](clr-common-language-runtime-compilation.md)) can also be used as a .netmodule file. .obj files contain metadata and native symbols. .netmodules only contain metadata.
You can use an MSIL `.obj` file (compiled with [`/clr`](clr-common-language-runtime-compilation.md)) as a `.netmodule` file. `.obj` files contain metadata and native symbols. `.netmodules` only contain metadata.

You can pass an MSIL .obj file to any other Visual Studio compiler via the /addmodule compiler option (but be aware that the .obj file becomes part of the resulting assembly and must be shipped with the assembly). For example, Visual C# and Visual Basic have the /addmodule compiler option.
Pass an MSIL `.obj` file to any other Visual Studio compiler with the `/addmodule` compiler option. The `.obj` file becomes part of the resulting assembly and must be shipped with the assembly. For example, Visual C# and Visual Basic have the `/addmodule` compiler option.

> [!NOTE]
> In most cases, you will need to pass to the linker the .obj file from the compilation that created the .net module. Passing a .dll or .netmodule MSIL module file to the linker may result in LNK1107.
> In most cases, you need to pass to the linker the `.obj` file from the compilation that created the .net module. Passing a `.dll` or `.netmodule` MSIL module file to the linker might result in LNK1107.

.obj files, along with their associated .h files, which you reference via #include in source, allow C++ applications to consume the native types in the module, whereas in a .netmodule file, only the managed types can be consumed by a C++ application. If you attempt to pass a .obj file to #using, information about native types will not be available; #include the .obj file's .h file instead.
`.obj` files, along with their associated `.h` files, which you reference via #include in source, allow C++ applications to consume the native types in the module. In a `.netmodule` file, only the managed types can be consumed by a C++ application. If you attempt to pass a `.obj` file to #using, information about native types isn't available. Instead, #include the `.obj` file's `.h` file.

Other Visual Studio compilers can only consume managed types from a module.

Use the following to determine whether you need to use a .netmodule or a .obj file as module input to the MSVC linker:
Use the following guidance to determine whether you need to use a `.netmodule` or a `.obj` file as module input to the MSVC linker:

- If you are building with a Visual Studio compiler other than Visual C++, produce a .netmodule and use the .netmodule as input to the linker.
- If you're building with a Visual Studio compiler other than Visual C++, produce a `.netmodule` and use the `.netmodule` as input to the linker.

- If you are using the MSVC compiler to produce modules and if the module(s) will be used to build something other than a library, use the .obj files produced by the compiler as module input to the linker; do not use the .netmodule file as input.
- If you're using the MSVC compiler to produce modules and if the modules are used to build something other than a library, use the `.obj` files produced by the compiler as module input to the linker. Don't use the `.netmodule` file as input.

- If your modules will be used to build a native (not a managed) library, use .obj files as module input to the linker and generate a .lib library file.
- If your modules are used to build a native (not a managed) library, use `.obj` files as module input to the linker and generate a `.lib` library file.

- If your modules will be used to build a managed library, and if all module input to the linker will be verifiable (produced with /clr:safe), use .obj files as module input to the linker and generate a .dll (assembly) or .netmodule (module) library file.
- If your modules are used to build a managed library, and if all module input to the linker is verifiable (produced with `/clr:safe`), use `.obj` files as module input to the linker and generate a `.dll` (assembly) or `.netmodule` (module) library file.

- If your modules will be used to build a managed library, and if one or more modules input to the linker will be produced with just /clr, use .obj files as module input to the linker and generate a .dll (assembly). If you want to expose managed types from the library and if you also want C++ applications to consume the native types in the library, your library will consist of the .obj files for the libraries component modules (you will also want to ship the .h files for each module, so they can be referenced with #include from source code).
- If your modules are used to build a managed library, and if one or more modules input to the linker are produced with just `/clr`, use `.obj` files as module input to the linker and generate a `.dll` (assembly). If you want to expose managed types from the library and if you also want C++ applications to consume the native types in the library, your library consists of the `.obj` files for the libraries component modules. You also want to ship the `.h` files for each module, so they can be referenced with #include from source code.

## See also

Expand Down
21 changes: 10 additions & 11 deletions docs/build/reference/ln-create-msil-module.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,11 +4,10 @@ title: "/LN (Create MSIL Module)"
ms.date: "11/04/2016"
f1_keywords: ["/LN"]
helpviewer_keywords: ["-LN compiler option [C++]", "/LN compiler option [C++]"]
ms.assetid: 4f38f4f4-3176-4caf-8200-5c7585dc1ed3
---
# /LN (Create MSIL Module)

Specifies that an assembly manifest should not be inserted into the output file.
Specifies that the compiler shouldn't insert an assembly manifest into the output file.

## Syntax

Expand All @@ -18,27 +17,27 @@ Specifies that an assembly manifest should not be inserted into the output file.

## Remarks

By default, **/LN** is not in effect (an assembly manifest is inserted into the output file).
By default, `/LN` isn't in effect, and the compiler inserts an assembly manifest into the output file.

When **/LN** is used, one of the [/clr (Common Language Runtime Compilation)](clr-common-language-runtime-compilation.md) options must also be used.
When you use `/LN`, you must also use one of the [/clr (Common Language Runtime Compilation)](clr-common-language-runtime-compilation.md) options.

A managed program that does not have an assembly metadata in the manifest is called a module. If you compile with [/c (Compile Without Linking)](c-compile-without-linking.md) and **/LN**, specify [/NOASSEMBLY (Create a MSIL Module)](noassembly-create-a-msil-module.md) in the linker phase to create the output file.
A managed program that doesn't have assembly metadata in the manifest is called a module. If you compile with [/c (Compile Without Linking)](c-compile-without-linking.md) and `/LN`, specify [`/NOASSEMBLY `(Create a MSIL Module)](noassembly-create-a-msil-module.md) in the linker phase to create the output file.

You may want to create modules if you want to take a component-based approach to building assemblies. That is, you can author types and compile them into modules. Then, you can generate an assembly from one or more modules. For more information on creating assemblies from modules, see [.netmodule Files as Linker Input](netmodule-files-as-linker-input.md) or [Al.exe (Assembly Linker)](/dotnet/framework/tools/al-exe-assembly-linker).
Create modules if you want to take a component-based approach to building assemblies. You can author types and compile them into modules. Then, you can generate an assembly from one or more modules. For more information on creating assemblies from modules, see [`.netmodule` Files as Linker Input](netmodule-files-as-linker-input.md) or [`Al.exe `(Assembly Linker)](/dotnet/framework/tools/al-exe-assembly-linker).

The default file extension for a module is .netmodule.
The default file extension for a module is `.netmodule`.

In releases before Visual Studio 2005, a module was created with **/clr:noAssembly**.
In releases before Visual Studio 2005, you created a module with `/clr:noAssembly`.

The MSVC linker accepts .netmodule files as input and the output file produced by the linker will be an assembly or .netmodule with no run-time dependence on any of the .netmodules that were input to the linker. For more information, see [.netmodule Files as Linker Input](netmodule-files-as-linker-input.md).
The MSVC linker accepts `.netmodule` files as input. The output file produced by the linker is an assembly or `.netmodule` with no run-time dependence on any of the `.netmodule`s that you input to the linker. For more information, see [`.netmodule `Files as Linker Input](netmodule-files-as-linker-input.md).

### To set this compiler option in the Visual Studio development environment

- Specify [/NOASSEMBLY (Create a MSIL Module)](noassembly-create-a-msil-module.md) in the linker phase to create the output file.
- Specify [`/NOASSEMBLY` (Create a MSIL Module)](noassembly-create-a-msil-module.md) in the linker phase to create the output file.

### To set this compiler option programmatically

- This compiler option cannot be changed programmatically.
- You can't change this compiler option programmatically.

## See also

Expand Down
28 changes: 13 additions & 15 deletions docs/extensions/safe-cast-cpp-component-extensions.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,11 +5,10 @@ ms.date: "10/12/2018"
ms.topic: "reference"
f1_keywords: ["safe_cast", "safe_cast_cpp", "stdcli::language::safe_cast"]
helpviewer_keywords: ["safe_cast keyword [C++]"]
ms.assetid: 4fa688bf-a8ec-49bc-a4c5-f48134efa4f7
---
# safe_cast (C++/CLI and C++/CX)

The **safe_cast** operation returns the specified expression as the specified type, if successful; otherwise, throws `InvalidCastException`.
The **`safe_cast`** operation returns the specified expression as the specified type. If the operation isn't successful, it throws an `InvalidCastException`.

## All Runtimes

Expand All @@ -23,7 +22,7 @@ The **safe_cast** operation returns the specified expression as the specified ty

## Windows Runtime

**safe_cast** allows you to change the type of a specified expression. In situations where you fully expect a variable or parameter to be convertible to a certain type, you can use **safe_cast** without a **try-catch** block to detect programming errors during development. For more information, see [Casting (C++/CX)](../cppcx/casting-c-cx.md).
Use **`safe_cast`** to change the type of a specified expression. If you expect a variable or parameter to be convertible to a certain type, use **`safe_cast`** without a **try-catch** block to detect programming errors during development. For more information, see [Casting (C++/CX)](../cppcx/casting-c-cx.md).

### Syntax

Expand All @@ -41,15 +40,15 @@ An expression that evaluates to a handle to a reference or value type, a value t

### Remarks

**safe_cast** throws `InvalidCastException` if it cannot convert *expression* to the type specified by *type-id*. To catch `InvalidCastException`, specify the [/EH (Exception Handling Model)](../build/reference/eh-exception-handling-model.md) compiler option, and use a **try/catch** statement.
**`safe_cast`** throws `InvalidCastException` if it can't convert *expression* to the type specified by *type-id*. To catch `InvalidCastException`, specify the [/EH (Exception Handling Model)](../build/reference/eh-exception-handling-model.md) compiler option, and use a **try/catch** statement.

### Requirements

Compiler option: `/ZW`

### Examples

The following code example demonstrates how to use **safe_cast** with the Windows Runtime.
The following code example demonstrates how to use **`safe_cast`** with the Windows Runtime.

```cpp
// safe_cast_ZW.cpp
Expand Down Expand Up @@ -83,7 +82,7 @@ Caught expected exception: InvalidCastException

## Common Language Runtime

**safe_cast** allows you to change the type of an expression and generate verifiable MSIL code.
**`safe_cast`** changes the type of an expression and generates verifiable MSIL code.

### Syntax

Expand All @@ -93,30 +92,29 @@ Caught expected exception: InvalidCastException

### Parameters

*type-id*<br/>
*`type-id`*\
A handle to a reference or value type, a value type, or a tracking reference to a reference or value type.

*expression*<br/>
*`expression`*
An expression that evaluates to a handle to a reference or value type, a value type, or a tracking reference to a reference or value type.

### Remarks

The expression `safe_cast<`*type-id*`>(`*expression*`)` converts the operand *expression* to an object of type *type-id*.

The compiler will accept a [static_cast](../cpp/static-cast-operator.md) in most places that it will accept a **safe_cast**. However, **safe_cast** is guaranteed to produce verifiable MSIL, whereas a **`static_cast`** could produce unverifiable MSIL. See [Pure and Verifiable Code (C++/CLI)](../dotnet/pure-and-verifiable-code-cpp-cli.md) and [Peverify.exe (PEVerify Tool)](/dotnet/framework/tools/peverify-exe-peverify-tool) for more information on verifiable code.
The compiler accepts a [`static_cast`](../cpp/static-cast-operator.md) in most places that it accepts a **`safe_cast`**. However, **`safe_cast`** always produces verifiable MSIL, whereas a **`static_cast`** might produce unverifiable MSIL. For more information on verifiable code, see [Pure and Verifiable Code (C++/CLI)](../dotnet/pure-and-verifiable-code-cpp-cli.md) and [`Peverify.exe` (PEVerify Tool)](/dotnet/framework/tools/peverify-exe-peverify-tool).

Like **`static_cast`**, **safe_cast** invokes user-defined conversions.
Like **`static_cast`**, **`safe_cast`** invokes user-defined conversions.

For more information about casts, see [Casting Operators](../cpp/casting-operators.md).

**safe_cast** does not apply a **`const_cast`** (cast away **`const`**).
**`safe_cast`** doesn't apply a **`const_cast`** (cast away **`const`**).

**safe_cast** is in the cli namespace. See [Platform, default, and cli Namespaces](platform-default-and-cli-namespaces-cpp-component-extensions.md) for more information.
**`safe_cast`** is in the cli namespace. For more information, see [Platform, default, and cli Namespaces](platform-default-and-cli-namespaces-cpp-component-extensions.md).

For more information on **safe_cast**, see:
For more information on **`safe_cast`**, see:

- [C-Style Casts with /clr (C++/CLI)](c-style-casts-with-clr-cpp-cli.md)

- [How to: Use safe_cast in C++/CLI](../dotnet/how-to-use-safe-cast-in-cpp-cli.md)

### Requirements
Expand All @@ -125,7 +123,7 @@ Compiler option: `/clr`

### Examples

One example of where the compiler will not accept a **`static_cast`** but will accept a **safe_cast** is for casts between unrelated interface types. With **safe_cast**, the compiler will not issue a conversion error and will perform a check at runtime to see if the cast is possible
One example of where the compiler doesn't accept a **`static_cast`** but accepts a **`safe_cast`** is for casts between unrelated interface types. With **`safe_cast`**, the compiler doesn't issue a conversion error and performs a check at runtime to see if the cast is possible.

```cpp
// safe_cast.cpp
Expand Down
Loading