Merge pull request #5579 from MicrosoftDocs/main

Auto Publish – main to live - 2025-07-10 05:02 UTC

Author: learn-build-service-prod[bot]

uwp/get-started/universal-application-platform-guide.md

@@ -154,8 +154,8 @@ For more introductory material, see [An Introduction to Building Windows Apps fo
 ## How the Universal Windows Platform relates to Windows Runtime APIs
 If you're building a Universal Windows Platform (UWP) app, then you can get a lot of mileage and convenience out of treating the terms "Universal Windows Platform (UWP)" and "Windows Runtime (WinRT)" as more or less synonymous. But it *is* possible to look under the covers of the technology, and determine just what the difference is between those ideas. If you're curious about that, then this last section is for you.
 
-The Windows Runtime, and WinRT APIs, are an evolution of Windows APIs. Originally, Windows was programmed via flat, C-style Win32 APIs. To those were added COM APIs ([DirectX](/windows/desktop/directx) being a prominent example). Windows Forms, WPF, .NET, and managed languages brought their own way of writing Windows apps, and their own flavor of API technology. The Windows Runtime is, under the covers, the next stage of COM. At the actual application binary interface (ABI) layer, its roots in COM become visible. But the Windows Runtime was designed to be callable from a great range of different programming languages. And callable in a way that's very natural to each of those languages. To this end, access to the Windows Runtime is made available via what are known as language projections. There is a Windows Runtime language projection into C#, into Visual Basic, into standard C++, into JavaScript, and so on. Furthermore, once packaged appropriately (see [Desktop Bridge](/windows/msix/desktop/source-code-overview)), you can call WinRT APIs from an app built in one of a great range of application models: Win32, .NET, WinForms, and WPF.
+The Windows Runtime, and WinRT APIs, are an evolution of Windows APIs. Originally, Windows apps were writen using flat, C-style Win32 APIs and to those were added COM APIs—[DirectX](/windows/desktop/directx) being a prominent example. Later technologies such as Windows Forms, WPF, .NET, and managed languages also providing a unique way of writing Windows apps with their own flavor of API technology. Under the covers, the Windows Runtime is the next stage of COM. At the actual application binary interface (ABI) layer, its roots in COM become visible. But unlike COM, the Windows Runtime was designed to be callable from a wide variety of programming languages in a more natural way. As a result, access to the Windows Runtime is made available via what are known as language projections. A projection hides the COM details, and provides a more natural programming experience for a given language. There is a Windows Runtime language projection into C#, Visual Basic, standard C++, JavaScript, and so on. Furthermore, once packaged appropriately—see [Desktop Bridge](/windows/msix/desktop/source-code-overview)—you can call WinRT APIs from an app built in a variety of application models: Win32, .NET, WinForms, WPF, and UWP.
 
-And, of course, you can call WinRT APIs from your UWP app. UWP is an application model built on top of the Windows Runtime. Technically, the UWP application model is based on [CoreApplication](/uwp/api/windows.applicationmodel.core.coreapplication), although that detail may be hidden from you, depending on your choice of programming language. As this topic has explained, from a value proposition point of view, the UWP lends itself to writing a single binary that can, should you choose, be published to the Microsoft Store and run on any one of a great range of device form factors. The device reach of your UWP app depends on the subset of Windows Runtime APIs that you limit your app to calling, or that you call conditionally.
+UWP is an application model built on top of the Windows Runtime. Technically, the UWP application model is based on [CoreApplication](/uwp/api/windows.applicationmodel.core.coreapplication), although that detail may be hidden from you depending on your chosen programming language. The UWP lends itself to writing a single binary that can, should you choose, be published to the Microsoft Store and run on a wide range of device form factors as covered above. The device reach of your UWP app depends on the subset of Windows Runtime APIs that you limit your app to calling, or that you call conditionally.
 
 Hopefully, this section has been successful in describing the difference between the technology underlying Windows Runtime APIs, and the mechanism and business value of the Universal Windows Platform.