Well, it is quite clear actually.
https://docs.microsoft.com/en-us/windows/apps/desktop/choose...
Re:Designing a COM Library for Rust
by withinrafael on Wednesday October 09, 2019 @06:36PM
(#21208922)
These docs are outdated and incorrect, sadly. For example, nearly everything under the UWP heading can be done via traditional Windows apps. Current leadership seems to get it, "write an app, use any APIs you need" (rough paraphrasing). Just hasn't fully set internally and externally so these warts exists.
Re:Designing a COM Library for Rust
by contextfree on Wednesday October 09, 2019 @07:51PM
(#21209454)
On a technical level, there are still some apps that can get CoreWindows, respond to PLM events, receive callbacks from contracts involving CoreWindow UI like Share target, as well as go into certain UI modes involving shell participation like modern fullscreen and CompactOverlay, and some that can't (without stapling them together with one that can via Desktop Bridge) ... aren't there? Maybe that will change in the future but it hasn't yet.
And then there are some OS editions where some apps can't run or can only run in a container environment.
That said, "UWP" is confusingly also used to refer to Windows apps that tap into WinRT APIs, participate in the modern app lifecycle, are modeled and have identity, or generally tap into newer technologies such as AppContainer. You'll see this, for example, perpetuated in Visual Studio in its project templating. It's a BIG OL' MESS right now; I'm working with/pushing Microsoft to get this communicated clearly and mopped up but old habits die hard.