You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/standard/native-interop/abi-support.md
+14-26Lines changed: 14 additions & 26 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,38 +5,26 @@ ms.date: 10/25/2024
5
5
---
6
6
# Native interoperability ABI support
7
7
8
-
Application Binary Interface (ABI) is the interface which run times and operating systems express low-level binary details. This can include calling conventions (that is, how parameters are passed and results returned), exception handling, as well as symbol mangling. The below list contains the names of languages, run times and even general technologies since these names tend to represent what users will be working with when looking for guidance on interoperability.
8
+
[Application Binary Interface](https://wikipedia.org/wiki/Application_binary_interface) (ABI) is the interface which run times and operating systems express low-level binary details. This can include calling conventions (that is, how parameters are passed and results returned), exception handling, as well as symbol mangling. The below list contains the names of languages, run times and even general technologies since these names tend to represent what users will be working with when looking for guidance on interoperability.
|**COM and `IUnknown`**| ✔️ |<xref:System.Runtime.InteropServices.ComWrappers><xref:System.Runtime.InteropServices.Marshalling.GeneratedComInterfaceAttribute><xref:System.Runtime.InteropServices.Marshalling.GeneratedComClassAttribute>|
The C language represents a stable ABI across all platforms where .NET is supported. It is what most .NET interop APIs assume is the target. This is the recommended approach for most interop in .NET.
13
-
14
-
## C++
20
+
## C++ <aname="cpp"></a>
15
21
16
22
The [C++ language](https://isocpp.org/) has no defined ABI across all .NET supported platforms and C++ compiler implementations (that is, MSVC, clang, and GCC). This lack of a stable ABI makes support difficult to provide. The recommended way to interoperate with C++ is to export functions marked with `extern "C"` and then call them as C functions.
17
23
18
-
## COM and `IUnknown`
19
-
20
-
The COM and `IUnknown` style ABI was defined to align with the C language. It was specifically to support Object Oriented Programming, similar to C++, but to provide a stable ABI. .NET has a deep history with COM and `IUnknown` and as this ABI was originally designed to align with C, it is supported in all .NET platforms through the <xref:System.Runtime.InteropServices.ComWrappers> API.
21
-
22
-
## Swift
23
-
24
-
The Swift programming environment has a well-defined stable ABI that is [supported in .NET](https://github.com/dotnet/designs/blob/main/proposed/swift-interop.md). The specific APIs that support interop with Swift can be found under the <xref:System.Runtime.InteropServices.Swift> namespace.
25
-
26
-
## Objective-C
27
-
28
-
The Objective-C language follows the C language's ABI and is [supported in .NET](https://github.com/dotnet/designs/blob/main/accepted/2021/objectivec-interop.md). The specific APIs that support interop with Objective-C can be found under the <xref:System.Runtime.InteropServices.ObjectiveC> namespace.
29
-
30
-
## Java Virtual Machine (JVM)
31
-
32
-
The JVM is a virtual machine with managed memory, similar to the .NET runtime. Interoperability with the JVM is limited through tooling like [dotnet/java-interop](https://github.com/dotnet/java-interop) and comes with performance costs. The largest cost of interoperating with the JVM is the coordination between the two virtual machine's Garbage Collectors.
33
-
34
-
## golang
24
+
## golang <aname="golang"></a>
35
25
36
26
The Go programming language is not supported for in-process interoperability. The Go runtime [imposes requirements](https://pkg.go.dev/os/signal#hdr-Non_Go_programs_that_call_Go_code) on being hosted in a process with another run time. Specifically, the use of the `SA_ONSTACK` flag on threads that run signal handlers. These requirements are not currently met by .NET and meeting them would impose non-trivial costs.
37
27
38
-
It is recommended that users with golang dependencies use a cross-process communication technology to interoperate.
39
-
40
-
## ARM64EC
28
+
## ARM64EC <aname="arm64ec"></a>
41
29
42
-
There are currently no plans to add support for [ARM64EC](https://learn.microsoft.com/cpp/build/arm64ec-windows-abi-conventions)in .NET 5+.
30
+
The [ARM64EC](https://learn.microsoft.com/cpp/build/arm64ec-windows-abi-conventions)ABI is not supported.
0 commit comments