Thank you for listening to the community feedback. I’m really excited for WinUI 3.0 (Win32 + WinUI + C++). This feels like the framework we’ve been waiting for! RIP GDI 😉

(Win32 app model) + (WinUI 3.0 UI) + (.NET or C++ language)

So this would basically be the UWP UI, but without the phone-like lifecycle and sandbox? That seems interesting for desktop apps, then – I'll be experimenting with this.

Thank you for the update, and hopefully more updates will come as WinUI 3.0's initial feature set is locked down, and any new controls or control features that have been proposed, which may make it into WinUI 3.0.

Oh and documentation about how WinUI in Desktop will work, and differ from UWP, WPF, and Win32 would be very useful to pre-empt the umpteen amount of questions that will come.

Perhaps a nice matrix of what is included with which combination of frameworks and APIs, along with the architecture diagrams we got at Build!

You guys are incredible, thanks for everything!
The xplat section made my day, especially that Uno is on the radar.

Our focus is still Windows 10 and 8.1, but we hear the feedback that some of you still have users & customers on Win7 and we'll be evaluating the market and options over time.

Assuming this implantation of the UI framework is designed with the idea in mind of portability, at least enough so its UI core (rendering / input) can function under any Windows OS that supports .NET Core 3+ what limitations on Windows 7 would there even be? Seems like most of the features people use on the desktop would just work and for special / platform specific ones that don't, maybe keep them away from being part of the core UI system and keep them in platform specific packages such as (Win10, Win8.1, Win7 Nugets etc).

Also if there was a cross-platform XAML that had the same look and feel across all devices (Win32, Android, iOS and WASM) like you can do with HTML (but not Xamarin sadly) my company would have jumped on it years ago.

Also glad you guys consider this a "marathon (great Bungie game too)". The less fragmentation in the XAML space the better for everyone and taking to many short cuts will just end you back where you started ;)

documentation about how WinUI in Desktop will work, and differ from UWP, WPF, and Win32 would be very useful

We're working on it and will share more as this develops!

Assuming this implantation of the UI framework is designed with the idea in mind of portability, at least enough so its UI core (rendering / input) can function under any Windows OS that supports .NET Core 3+ what limitations on Windows 7 would there even be?

@zezba9000 WinUI doesn't use .NET, and you don't necessarily have to use .NET Core with WinUI: it's a native framework built on OS APIs, and it relies on new functionality in Win8/Win10 that wasn't present in Win7 - in some cases for core features, not just higher-level add-on features like specific controls.

documentation about how WinUI in Desktop will work, and differ from UWP, WPF, and Win32 would be very useful

We're working on it and will share more as this develops!

Assuming this implantation of the UI framework is designed with the idea in mind of portability, at least enough so its UI core (rendering / input) can function under any Windows OS that supports .NET Core 3+ what limitations on Windows 7 would there even be?

@zezba9000 WinUI doesn't use .NET, and you don't necessarily have to use .NET Core with WinUI: it's a native framework built on OS APIs, and it relies on new functionality in Win8/Win10 that wasn't present in Win7 - in some cases for core features, not just higher-level add-on features like specific controls.

For Windows 7 compatibility - it would require some third party to build their own compatible renderer for the XAML, as well as some kind of alternative Shim for any OS level APIs needed.

Right now there is no idea if this is possible - the hope is that when the WinUI bits are removed from the OS, they are put into the open source project in a way, which will enable other platforms to provide some kind of compatibility component. Think Xamarin, Uno, or .Net Core with a custom renderer.

it's a native framework built on OS APIs, and it relies on new functionality in Win8/Win10 that wasn't present in Win7 - in some cases for core features

In my mind what constitutes a "core feature" wouldn't be something that relies on OS specifics besides of course rendering and input. Which in those cases would be abstraction layers anyone can extend. At a foundational level one in theory should be able to render the UI with a custom software-renderer and do Input with a custom XInput backend with a virtual cursor if so desired. If you can do that kind of modularity you can pretty much do anything and extending the platform support becomes extremely easy (as is done in games). You spend a little more time in this area and down the road everything takes a lot less effort. If WPF XAML was designed this way it could have just been taken and used in UWP apps. Technical debt will just become an endless loop otherwise.

Things like tray-icon support etc could be in a "WinUI Windows basic features (Win7-Win10)" package. Things like push notifications could be in a "WinUI Windows extended features (Win8-Win10)" package.

Hope that makes sense.

@mdtauk, @zezba9000 it's all theoretically possible, and we have lots of platform abstraction expertise on the team. As with anything, it just comes down to cost, schedule and expected benefit 😊

In addition to development and testing costs (which would extend into potentially non-obvious areas, for example ensuring everything works with old assistive technologies) we also have to consider support cost over long timespans.

Do you expect to have new customers on Win7 in 2020+? Feedback and definite use cases do help us prioritize.

In addition to development and testing costs (which would extend into potentially non-obvious areas, for example ensuring everything works with old assistive technologies) we also have to consider support cost over long timespans.

Do you expect to have new customers on Win7 in 2020+? Feedback and definite use cases do help us prioritize.

@jesbis I don't see much benefit in adding compatibility to Win7 for WinUI 3.0 - Linux, Android, iOS, iPadOS and MacOS however, may be beneficial for providing a cross platform solution, which does not rely on native UI frameworks.

@mdtauk
@jesbis I don't see much benefit in adding compatibility to Win7 for WinUI 3.0 - Linux, Android, iOS, iPadOS and MacOS however, may be beneficial for providing a cross platform solution.

Agree to that. I'd just add web-assembly, to me it's even more essential than Linux.

Do you expect to have new customers on Win7 in 2020+? Feedback and definite use cases do help us prioritize.

No my company does not. I was giving more of a design argument in an area I've seen XAML struggle with in all its iterations (from my perspective) but ya I totally see why MS wouldn't want to spend time there. However it would be cool if WinUI was capable enough for others to do this work if they needed to (which tends to happen I've noticed) without going down a rabbit hole of Windows dependencies as is the case with WPF now.

To be clear on what my company would love to see is Android and WASM support be a little more official than UNO (and 3 years ago). We make management software that governs the state of a collection of local computers and system setups usually involving a big need for Win32 APIs (UWP would never work for us but we like the UI because of compile-time errors unlike HTML build systems) and our clients + us need Win32 + Android + Browser UI experiences that have a uniform experience and feel. HTML is just a big pain point as it adds needless abstraction and complexity that otherwise not need be there as our primary code base is in C#.

Hope thats better feedback for ya.

Also yes WASM is the biggest target we would like vs any other platform. BY FAR!!
As it solves our Android / iOS / mobile issue as well as web portal stuff.

Thank you for listening to the feedback!

Desktop + WASM will be gold!

Wow, thank you for the shout out, @jesbis! Totally unexpected and very much appreciated and respected. 👍

The discussion around Windows 7 is a little distracting, as the amount of effort (not to mention cost) would cause a significant delay to WinUI 3.0. Windows 7 is end-of-life in January, and we’re encouraging all customers to upgrade to Windows 10. My customers may not align with others here, but even Windows 8.1 isn’t a platform of interest for us.

Quite happy with the update. The upcoming targets for WinUI looks very bright and promising! Even the Xplat section was something I didn't expect but is very welcomed. Will look forward to use the improvements as well as the goodies in store for WinUI.

Thank you for the team for transparency.

I would like to mention the importance of line-of-business software in helping people in solutions of various problems.

I worked for a while with the Lightswitch tool and had a significant gain in construction time. Rapid application development has been very promising for LOB applications. But with the patent wars in the USA is very taken seriously, it took the product to be terminated.

We know we have INotifyDataErrorInfo for next delivery. But It would be wonderful if WinUI had RAD resource for future deliveries like 3.x onwards.

thanks team, can't wait for the day when you pencil in webassembly. it will make my day , year and decade and will put MS at the top of the technology stack. WinUI + Xamarin + WASM + .NET => pure awesomeness !!

@jesbis Thanks for this update. Good work team :+1:. Understanding it's still early, when do you think we will see WinUI 3.0 milestone created and issues tagged against it?

when do you think we will see WinUI 3.0 milestone created and issues tagged against it?

@shaggygi Good question! I just created it:

WinUI 3.0 milestone

This is awesome guys!

Quick question: Moving Windows.UI.Composition into Microsoft.UI.Composition, is this closer to 2.2 or 3.0?
And in timeframe to expect this, would this me 2-3 months or more like, when 3.0 becomes available?

In future, when you talk about years (as in "by the end of the year") please can you be clear about calendar years and [Microsoft] financial years.
It's easy to have confusion when this isn't explicitly stated and I've known occasions when this has led to people believing things are coming 6 months earlier than was intended.

Moving Windows.UI.Composition into Microsoft.UI.Composition, is this closer to 2.2 or 3.0?

@jtorjo this will be 3.0 (at minimum). We're hoping to include an early build in the first preview of 3.0, but not 100% guaranteed yet.

In future, when you talk about years (as in "by the end of the year") please can you be clear about calendar years and [Microsoft] financial years.

@mrlacey thanks, I'll keep that in mind! All the dates we use are generally calendar time.

@jesbis That's kind of sad. So you're saying that it's possible we won't have Microsoft.UI.Composition in 3.0?

@jtorjo

We're hoping to include an early build in the first preview of 3.0, but not 100% guaranteed yet

There are often many preview releases. .NET Core 3 is on Preview 6, for example.

Our plan is to include the composition APIs in 3.0.

The Xaml framework part will be open source before the composition part though.

@jesbis Thanks, sounds good!

Fantastic roadmap, great work! The WinUI team and community rocks! I was reading all the comments in the "we need your input" discussion. But as everything important was said already, I thought I shouldn't add another comment just to repeat the parts that were already said there.

As everyone here, I love the transparency and I really look forward to WinUI 3.0. To me WinUI 3.0 is the most exciting thing since WPF was introduced in 2006.

I also still have customers running Windows 7, but I think Windows 10 support is most important and I wouldn't spent time and resources for Win7 support. Most companies I work at are switching to 10. And I think in late 2020 the only company I will know who still uses Windows 7 will probably be my dentist. And if he might ask me to write a Windows app for him, I'll migrate his PCs to Windows 10. :-)

WASM support in the future would be amazing.

Yesterday at a conference:

A little story to show @jesbis and the team that we who write and participate here are just the tip of the excited iceberg. :-)

Just yesterday I chatted at a developer conference in Germany with some .NET developers and I told them about WinUI 3.0, and they didn't know about it. I told them about the roadmap and they said:

"Wow, that's amazing".

A girl of the group asked me:

"But are you allowed to tell us all of this?"

I looked at her and the others, and then I took the chance for a rethoric pause of

await Task.Delay(3000);

before I said

"Hell yes! You can read this all on GitHub".

Thanks @jesbis and everyone involved. Great times to be a windows developer ❤️

I hope first-party applications (like Word?) can make use of WinUI's layers, and developers would be happy to see that, "Hey, WinUI is a real thing can run bussiness, rather than a toy".
If they are already using it, say it out loudly. Let people know!

Acrylic for WPF, Win32, and WinUI Desktop.

Oh and perhaps reconsider the Acrylic only on active windows policy.

Yes, if you have more than 1 monitor, it just render in one window. At least in multiple monitors it should work properly....

I was thinking about the development experience implications of having two sets of UI controls available in UWP apps - when we will have access to both WinUI controls and legacy UI controls, when in C# code-behind, IntelliSense as it will always require us to correctly choose the which namespace the control should come from instead of going Alt+Enter to just add using and continue. Will it be possible to avoid this somehow?

Once WinUI3 is out for developers, the Windows 10 SDKs should consider suggesting the change of namespace for projects which are opened with a supported SDK installed. Try to move people away from the OS namspaces.

Acrylic for WPF, Win32, and WinUI Desktop.

What I'd like to see first is MS maturing Xaml Islands enough so that, as an example, acrylic in titlebar can be used for non-UWP projects basing their UI on WinUI (see last paragraph of this post). @marb2000 is probably the person to ask about this.

@MartinZikmund We want to avoid this scenario. When using WinUI 3 you should only have access to controls from the package. The idea being that we have everything you need with the latest and greatest changes.

@MartinZikmund
@LucasHaines

One fix should be, that you can exclude Windows.UI.Xaml.* WinMD references from build. Now the build targets reference only the Unified WinMD aka. Windows.winmd, add an option in the targets to also refer individual WinMDs, that way, we can include or exclude the references based on the App we're building.

Is this the way, then there's no need to change namepaces, since it behaves like a .NET dll it can work with assembly redirects to a local version inside the package rather than the system supplied ones.

I know that method is specifically for .NET Framework, but for UAP, there should be solution for these kind of scenarios. I know there is FrameworkDependency on msix/appx manifest. May be we can use that to supply the new WinUI with Windows.* namespaces rather than Microsoft.* ones.

On the dev side, we'd have less pain to upgrade our apps, since we're only changing the reference and not the code!

I'd prefer not changing the namespace at all!

Benefits:

1. Don't have to change code back and forth.

2. Once local WinUI code has been stabilized, you can merge back into windows platform, so that system apps and LOB apps can take advantage of the new improvements, on every new windows release.

3. One side it's a highly stable system framework with high compatibility like .NET Framework. And the other side it's like .NET Core, with changes at faster pace, with all the benefits of both and none of the issues.

Just watched an awesome presentation by Steve Sanderson on Blazor + (non html) UI wrapped in cross platform native app. About 52 minutes into the video. A must view for UWP , WinUI and c# fans. I'm seriously impressed with blazor !!!

https://youtu.be/uW-Kk7Qpv5U

One thing that I forgot to say in these discussions, that I find important is...
Does WinUI 3.0 itself have any performance improvements? It's XAML Rendering engine being just decoupled or is having changes? Will XAML controls use Composition mainly, and thus, off-thread and dwm driven like DirectUI?

Some controls performance, and RAM usage, could be much better, Like ListView/GridView = ItemsControl.

You see this on Windows itself. Windows 8 Start Menu (DirectUI) is way more fluid than Windows 10 XAML Start Menu.
Try to load a GridView with enough info, like Groove Albums page, and things don't go so nice. This is something that iOS and Android behave much better, and so do winforms, QT.
(WPF is even worse than UWP XAML in my opinion).

Does WinUI 3.0 itself have any performance improvements? It's XAML Rendering engine being just decoupled or is having changes? Will XAML controls use Composition mainly, and thus, off-thread and dwm driven like DirectUI?

Performance is definitely something we want to keep investing in, but I wouldn't expect any improvements for 3.0. The initial 3.0 effort is mostly focused on decoupling Xaml to ship as a NuGet package and open-sourcing.

WinUI 3.0 (like UWP Xaml today) is built on the composition layer and runs much of its rendering and animation off-thread via the DWM.

This is something that iOS and Android behave much better, and so do winforms, QT.
(WPF is even worse than UWP XAML in my opinion).

There's often a performance vs. flexibility/richness tradeoff when considering these scenarios. Xaml-based platforms (including UWP and WPF) tend to have larger, richer UI object trees for every control: that provides a lot of flexibility for changing the style and UX of any control, whereas some other platforms tend to have much flatter object trees that aren't as flexible but can sometimes be loaded faster.

That tradeoff is definitely something we think about and will keep in mind for potential future changes. The extra flexibility of complex Xaml control templates isn't necessary a lot of the time, so we could potentially simplify controls to load faster in cases when you don't need extra flexibility.

I hope Microsoft can provide a new comctl32.dll and comdlg32.dll which is based on WinUI 3.0.

Because most of Win32 apps will have the modern UI experience and it will help the developers to adapt their apps to modern UI.

Many Win32 developers needs to adapt several Windows versions. So they can't directly use WinUI today. It's excellent if Microsoft can provide a method to help them reduce the workload of modernize their apps' UI.

Also, I hope Microsoft can provide XAML designer for C++ Win32 Apps which is using WinUI.

Kenji Mouri

@MouriNaruto you can use FileOpenPicker today (from Win32).

@MouriNaruto you can use FileOpenPicker today (from Win32).

I know, but I hope all modern common controls and dialogs will bring to Win32.

@MouriNaruto

Technically It's possible. But the Windows devs have to re-create not only the exact behaviors of the COMCTL and COMDLG implementations but also the known and unknown bugs that exist in the codebase.

Compatibility is our frenemy!

Even if they do it, by the time they complete it, Every software using those libs would have enough time to migrate to WinUI! The irony!! 🤨🤣

@MarkIngramUK

FYI: FileOpenPicker is not a native WinRT Dialog/Control. It's essentially a wrapper of ExplorerFrame which is itself written in DirectUI (developed by ATG Team and based on DirectX) and COM!

Technically It's possible. But the Windows devs have to re-create not only the exact behaviors of the COMCTL and COMDLG implementations but also the known and unknown bugs that exist in the codebase.
Compatibility is our frenemy!
Even if they do it, by the time they complete it, Every software using those libs would have enough time to migrate to WinUI! The irony!! 🤨🤣

I don't think it's easy for many projects to migrate to WinUI without that because of the reality.

You have said "Compatibility is our frenemy!". Yes, it's also one of reasons of my suggestions. The irony!! 🤨🤣

I would just be happy for a XAML WinUI version of the common dialogs, even if WPF and WinForms would have to opt in to use the new versions.

The WinUI 3 target sounds very exciting and I'm looking forward to it. I have some questions concerning distribution/deployment, in the context of a classic Win32 application using WinUI 3

1. Does every app need to bring it's WinUI library with it or is sharing between apps possible, maybe even automatically through Windows mechanims
2. Will it be possible to statically link WinUI?
3. Let's say I have to redistribute it, how large will WinUI roughly be in MB?

Does every app need to bring it's WinUI library with it or is sharing between apps possible, maybe even automatically through Windows mechanims

We're planning to primarily distribute WinUI 3 through NuGet, which has mechanisms to automatically cache and share packages - there's more info available here:

https://docs.microsoft.com/nuget/what-is-nuget#what-else-does-nuget-do

https://docs.microsoft.com/nuget/consume-packages/managing-the-global-packages-and-cache-folders

Will it be possible to statically link WinUI?

This isn't something we were currently planning - do you have a scenario in mind where this would be a benefit?

Let's say I have to redistribute it, how large will WinUI roughly be in MB?

We're still working out what the final dependency graph will look like, but for the UI pieces it'll likely be similar to the relevant existing system32 dll sizes (10's of MBs).

We're planning to primarily distribute WinUI 3 through NuGet, which has mechanisms to automatically cache and share packages

I thought nuget is just for development or am I missing something? As far as I'm aware nuget based packages have to be deployed by every app individually and cannot be shared. Thats why there are dedicated installers for a shared dotnet core runtime, otherwise it wouldn't be necessary considering that dotnet core packages are already on nuget ...

You shouldn't have to install any development tools or SDKs just to share the UI framework packages. WPF and WinForms for .NET Core were having the same problem and invested into building a shared bundle so people don't have to install the SDK on end user machines, thats probably worth to do for WinUI as well once you get there (maybe even get yourself included in the WindowsDesktop bundle)

In particular there are already build options in VS for framework dependent deployment and WinUI should leverage these to ensure the packages are shared. Of course they have to provide a shareable package first.

For apps delivered by the Microsoft Store, release package contents should automatically be shared at deployment as well.

For win32 apps deployed through other means, it's on our todo list to investigate options like what you mentioned 😊

Will it be possible to statically link WinUI?

This isn't something we were currently planning - do you have a scenario in mind where this would be a benefit?

I think I need to clarify: will it be possible to use WinUI in a statically linked EXE (which statically links the VC-Runtime)? I assume that shouldn't be a problem because of C++/WinRT but I just wanted to be sure ...

Let's say I have to redistribute it, how large will WinUI roughly be in MB?

We're still working out what the final dependency graph will look like, but for the UI pieces it'll likely be similar to the relevant existing system32 dll sizes (10's of MBs).

Thank you for the information.

Awesome transparency btw for such a huge undertaking, I like it very much.

I think I need to clarify: will it be possible to use WinUI in a statically linked EXE (which statically links the VC-Runtime)? I assume that shouldn't be a problem because of C++/WinRT but I just wanted to be sure

This should be possible (in theory) but as @jesbis said, we are still working out the story for how unpackaged apps will get at the shared framework. We might have to have a redist installer, like how .NET Core is doing it.

The discussion around Windows 7 is a little distracting, as the amount of effort (not to mention cost) would cause a significant delay to WinUI 3.0. Windows 7 is end-of-life in January, and we’re encouraging all customers to upgrade to Windows 10. My customers may not align with others here, but even Windows 8.1 isn’t a platform of interest for us.

You are right. But we can not control my customer and there are more than 60% system is win7 in China. And we can not give up this market, so we can not use any technology that not support win7.

The data is from baidu, see https://tongji.baidu.com/data/os

But we can not control my customer and there are more than 60% system is win7 in China

TBH I would just stick with .NET Framework 4.8 + WPF if you're stuck on Win7.

But we can not control my customer and there are more than 60% system is win7 in China

TBH I would just stick with .NET Framework 4.8 + WPF if you're stuck on Win7.

But the Win7 Sp1 can install .NET Framework 4.8 and the win7 without sp1 can not install it.

.NET Framework system requirements | Microsoft Docs

If you don’t even have SP1 then you’re already 6 years past end-of-life.

Support for Windows 7 RTM without service packs ended on April 9, 2013.

https://support.microsoft.com/en-gb/help/13853/windows-lifecycle-fact-sheet

If you want Windows 7 support you should use a technology that already supports Windows 7, and not expect Microsoft to solve this problem for you.

@MarkIngramUK It’s not that Microsoft solved this problem for me, but I can’t support my customers who using win7 without sp1. I can not control our customers to use any system, but they who using win7 without sp1 will abandon our application and it means that we lost this market. But my competitors who do not use the new technology can support win7 without sp1 and my competitors will win this market.

Sad but true, too many customers do not care what technology we use but they care the application can run well in all of their devices.

This is the status quo of my industry, and the above conclusions may not be suitable for other industries.

@lindexi like I say, you can’t expect new technology to be ported to an OS that is already 6 years past end-of-life. If you want to target old OS then you need old technology.

@lindexi I think if the customer does not want to use supported technology and prefers something out of date, then they can't reasonably expect having modern UI. Those two requirements are purely mutually exclusive...

@MarkIngramUK Sad. I think when I can use today's new technology, this new technology has become old technology.

@lindexi that’s literally the opposite of what’s happening. You can’t call new tech “old tech” just because it’s not being ported to an ancient OS. If you want Win7 (no SP1) support, use WinForms or MFC or something.

@MartinZikmund You are right. In fact, almost no our users understand computer technology, even win7 and win10 can not tell. They not care what technology we use.

@jesbis I would love to get my hands dirty with the new WinUI using C++. I tried my best by using UWP and C++/Cx in the past, but besides the PhotoEditor App and some samples you always ended up in scratching your head and trying to find some good documentation e.g. for binding XAML with Platform::Collections and stuff like that. That was one of the reason I switched back to C# for UWP and Qt for C++ development on Windows. Please, show more love to C++.

On my customers I used a USB Stick (PenDrive) with the Windows 10 Media, and simply upgraded it from Windows 7 to the latest Windows 10 for free. They got the benefit of a modern OS, with Antivirus, Windows Updates, Edge WebBrowser and supports GUI technologies from older like WinForms, WPF, to more recent ones including UWP and beyond (WinUI). Also, instead of Shutdown, I set the Windows to Hibernate, and taught the users to simply push the power button to start working with the PC, and to press the Power Button when finished using the PC.
Also I put a ISO on the Network, to easily install / upgrade machines.

And they have the benefit of having Candy Crush preinstalled on their computers too!

Opinion

I thought WPF's controls implementations can be merged in WinUI for old version Windows support. (For example, Windows 7.) But it is too hard for Microsoft to make it come true because of the office politics, lol.

Replies

@lindexi
I know that there are lots of outdated Windows version users in China today. But I think it's necessary to abandon Windows NT 5.x users today and I know it's hard.

@MartinZikmund

I think if the customer does not want to use supported technology and prefers something out of date, then they can't reasonably expect having modern UI. Those two requirements are purely mutually exclusive...

Both modern UI and old platform support are necessary in China if you don't want your work to be served for minority. So one of my friends, a Chinese developer, port Blink and V8 to Windows XP without any updates installed, lots of developers use it to implement their modern app experiences. In China, the minimum operating system version requirement is equal to a version without any updates installed. For example, if you know the operating system version requirement of an app from China is Windows 7, it tells you can use the app under "Windows 7 RTM" or "6.1.7600.16385 (win7_rtm.090713-1255)". Even in the Android world, many apps still support Android 4.4 today.

This is why most apps made by non-Chinese developers can't be majority choice in China.

P.S. We can use the latest Visual Studio 2019 to build apps for Windows XP RTM without any updates installed, with the latest Windows 10 SDK and the latest C++17 standard or trying C++20 now. Because of VC-LTL(https://github.com/Chuyu-Team/VC-LTL) and YY-Thunks(https://github.com/Chuyu-Team/YY-Thunks).

Note about myself

In most of my time, I use the latest stable Windows build. (I use 10.0.18362 today. I am using 19H1 and 19H2.) But my Win32 projects designed for Windows Vista RTM without any updates installed, and my UWP projects designed for Windows 10, version 1703 without any updates installed or later because the conditional XAML support is introduced in RS2. (I love conditional XAML. Why it is not exist on Windows 10 Build 14393?)

Kenji Mouri

Please, please, consider un-sealing all WinUI 3.0 control classes!

As per my understanding, Microsoft decided to seal all UWP control classes, because JavaScript (which does not know inheritance) caused problems when used with inherited classes. Now that JS/HTML is deprecated, there is no need anymore for the new UI framework to still seal all classes. Un-selaing would make it a lot easier to customize UWP controls, like it was always possible in WPF. It would also help a lot when writing custom virtualizing list controls or panels, to have an un-sealed virtualizing base class to inherit from. Neither C#, nor C++/CX or C++/WinRT have problems with inheritance. It was only the failure called JS/HTML which forced this upon us.

So please remove this unneccessary restriction when creating WinUI 3.0.

@gisfromscratch thanks for the feedback! We definitely want to support C++ development (specifically with C++/WinRT).

What would make it easier to use C++? Have you tried C++/WinRT instead of CX?

Would more sample apps help?

You mentioned that it was hard to find documentation on binding: were there any other specific features that need better documentation?

Please, please, consider un-sealing all WinUI 3.0 control classes!

@lukasf this is something we're likely going to do 🙂 There's some related discussion ongoing in #780

@jesbis I have to get my hands dirty using the C++/WinRT much more. I just followed the Photo Editor C++/WinRT sample application. But when you read through the provided links like Data binding in depth you end up in a lot of C# snippets and just some side notes like "For C++/WinRT, any runtime class that you declare in your application that derives from a base class is known as a composable class. And there are constraints around composable classes …". This page is targeting 95% C# and only 5 % C++.

@gisfromscratch thanks! We'll keep that in mind as we work on updating the docs for WinUI 3.

If it helps, that databinding page you mentioned also links to some separate pages specifically about databinding with C++/WinRT, e.g.:

XAML controls; bind to a C++/WinRT property

XAML items controls; bind to a C++/WinRT collection

There are a number of other C++/WinRT-specific topics in that section as well.

Thanks for your great jobs! Very glad to see Xaml Island is removed from WinUi 3.0.
Btw: I just wonder if the low-level implementation of language projection in WinUi 3.0 will be different from WinRT component. The implementation of language projection of WinRT component seems have huge performance hit in .NET UWP project both in compile time and run time. Since WinUi 3.0 is decoupled completely from UWP, I hope there can be some improvement in the language interop implementation.

@zenjia XAML Islands is not removed from WinUI 3. WinUI 3 will contain the APIs that allow WPF/WinForms/MFC apps host WinUI 3 controls.

I've been trying to keep up on the progress in WinUI. I've tried writing UWP apps in the past with C# but found it was an uphill battle. But I'm eager to try again after winui 3.0.

I do have questions about the winui roadmap. Here are four. Sorry if they have been covered elsewhere. I haven't found the answers, despite a lot of searching... let me know if there is a better forum for asking these types of questions.

• Are the .net wrappers for the native controls also going to be open-sourced? It is not clear that this is the github repro that is responsible for the .Net side of winui, considering that the only c# code that I seem to find is for automated tests. I'm looking for things like Microsoft.UI.Xaml.UIElement but cannot find that code anywhere.

• When we get to the release of winui 3.0, will the UWP appmodel and win32 appmodel be running the same .Net Core runtime ? I've never quite figured out what version of .Net core is used by UWP applications. I imagine that it is something that is built into windows itself , and that the Windows 10 SDK's are allowing VS 2019 to target the correct version of the .Net core that is available in UWP.

• A question about Xaml islands. Is there any chance that WPF and UWP could share the same airspace? I don't look forward to having to deal with airspace issues like we did between winforms and WPF. Given that WPF and UWP are both built on direct-X, it would be awesome if they could share pixels with each other. For example, if I were to have a backstage menu on a ribbon (in WPF) that will need to overlay a UWP xaml island, it would be wonderful if that could happen seamlessly. It doesn't seem like I should have to jump thru tons of hoops for something like that. ... I remember that in the early days of WPF, they tried to solve airspace issues for client applications that wanted to use the "WebBrowser" winforms control. They did a trial of a feature of the web browser called "WebBrowser.CompositionMode" and it was supposed to allow the WebBrowser to play nice with WPF. ... But I think that strategy was eventually abandoned. Perhaps the interoperability between UWP and WPF could be so seamless that they could even share pixels with each other (unlike winforms and WPF). One potential advantage of this would be to allow WPF to enhance a UWP control's functionality. For example WPF could overlay a xaml island with additional visuals in a way that is analogous to an adorner layer. This could become handy in a pinch.

• Any chance that a WPF app with xaml islands (say 50% WPF and 50% WINUI) might be compiled natively to ARM64 some day? Targeting ARM is possible with applications that are 100% UWP, and it would be nice if WPF dependencies would not force us to abandon our native ARM64 targeting. (The alternative would be to run the app in x86 emulation - but that is slower and limits the available memory that can be used).

Hopefully these questions are all relevant to the roadmap of winui. Any advice would be appreciated.

Are the .net wrappers for the native controls also going to be open-sourced? It is not clear that this is the github repro that is responsible for the .Net side of winui, considering that the only c# code that I seem to find is for automated tests. I'm looking for things like Microsoft.UI.Xaml.UIElement but cannot find that code anywhere.

UIElement isn't in WinUI 2 so it isn't currently in the repo. It will be in WinUI 3 which isn't released or open sourced yet, but we're working on it!

You can see examples in the repo of other native controls exposed to .NET via WinRT projections, e.g. the WinUI 2.2 controls documented here. They mostly don't require preexisting per-language wrapper files which is why you're not finding .cs files in the repo.

@marb2000 could best comment on the islands/desktop questions.

Q: _Will WinUI 3 UWP and Desktop use the same .NET runtime?_
A: Yes, this is the plan. UWP and Desktop will use .NET Core 3. Managed WinRT libraries will use .NET Core 3 instead of .NET Native.

Q: _Will WPF and UWP share the same airspace?_
A: Although WPF and WinUI (and XAML UWP) seem similar, they aren't. WPF uses DirectX9, and WinUI/XAML UWP uses the Windows.UI.Composition for XAML's composition, rendering, and animation needs (besides a modern version of DirectX11). Sadly, this causes that the interop is very complicated. Your proposal about WPF adorners is interesting. In theory, the adopter can create a popup to place the WinUI/XAML content over the WPF content. Or it can inform to the WPF visual tree that a re-layout is required, but everything based on HWnds.
@dbeavon This is a good proposal, can you create a feature request for this?

Q: _Will a WPF app with Xaml Islands compile to ARM64?_
A: If .NET Core 3 for Windows supports ARM64 for sure. Today it supports ARM32 in Windows. However, in Linux supports ARM64. I think it is on the .NET Core roadmap to support ARM64 in Windows as well. Although AFAIN, there is no date yet. @richlander, any news?

@marb2000

Q: Will WPF and UWP share the same airspace?

Can UWP use Windows.UI.Composition to create a layer which can get the render from a DirectX bitmap? And then the WPF render the windows to this layer like win2d. Maybe it can share the same airspace. But it hard to make WPF to render to a layer.

@lindexi I guess that could be heaven :D

Can UWP use Windows.UI.Composition to create a layer which can get the render from a DirectX bitmap?

UWP Xaml has a number of ways to render DirectX bitmaps or swap chains in Xaml and composite them with Windows.UI.Composition so they share the same airspace, including SurfaceImageSource, VirtualSurfaceImageSource and SwapChainPanel - more info is available in here:

https://docs.microsoft.com/windows/uwp/gaming/directx-and-xaml-interop

You can also insert a Windows.UI.Composition visual into a UWP Xaml UI tree and draw DirectX content to it, e.g. using ICompositorInterop, ICompositionDrawingSurfaceInterop and ICompositionGraphicsDeviceInterop as outlined here:

https://docs.microsoft.com/windows/uwp/composition/composition-native-interop

Those approaches should work similarly with WinUI.

A UWP desktop app will be able to reference a WPF/WinForm DLL and open a WPF/WinFrom window? This would allow me to migrate gradually.

@marb2000 -- .NET Core for Windows ARM64 is on our roadmap. I'm working on a plan for that now.

With WinUI 3.0, will it be possible to compile win2d on top of it?
(thus, decoupling it from UWP)
If so, that would be insanely awesome!

We're still working out details on DirectX integration but hopefully it will be possible to update Win2D to use WinUI base classes instead of UWP Xaml base classes.

fingers crossed :D

sorry if this is off topic: bug reports on UWP - do I add an issue on https://github.com/microsoft/microsoft-ui-xaml/ or elsewhere?

sorry if this is off topic: bug reports on UWP - do I add an issue on https://github.com/microsoft/microsoft-ui-xaml/ or elsewhere?

@jtorjo great question! This repo is the best spot to file any issues related to:

• the UWP UI framework APIs (e.g. Windows.UI.Xaml)
• Fluent design
• WinUI

In general there should be a "Send feedback about this product" link at the bottom of most documentation pages on docs.microsoft.com that will tell you the best way to provide feedback on a specific feature or API.

For most aspects of UWP aside from the above, that will be to file bugs under the Developer Platform category in the Feedback Hub which has a number of relevant subcategories.

Will WinUI 3 include the UWP SemanticZoom control? I think it's the coolest control of them all.

@jesbis Thanks! Just posted a discussion about System.IO

Even Microsoft doesn't drop Windows 7 support for Office, why would WinUI 3 do? I mean, almost all serious softwares have Windows 7 support (Photoshop, Office, Visual Studio 2019, VSCode, ...) If WinUI does not support Windows 7...

Even Microsoft doesn't drop Windows 7 support for Office, why would WinUI 3 do? I mean, almost all serious softwares have Windows 7 support (Photoshop, Office, Visual Studio 2019, VSCode, ...) If WinUI does not support Windows 7...

Office will probably drop support soon, as Microsoft's support for Windows 7 ends very very soon. But it is built upon a code base that already supported Windows 7.

WinUI was built upon Windows 10, and so would need to be back ported to Windows 7. The effort to do that makes no sense with the OS entering End Of Life, and so people will have to upgrade to Windows 10.

Q: Will WinUI 3 UWP and Desktop use the same .NET runtime?
A: Yes, this is the plan. UWP and Desktop will use .NET Core 3. Managed WinRT libraries will use .NET Core 3 instead of .NET Native.
Q: Will WPF and UWP share the same airspace?
A: Although WPF and WinUI (and XAML UWP) seem similar, they aren't. WPF uses DirectX9, and WinUI/XAML UWP uses the Windows.UI.Composition for XAML's composition, rendering, and animation needs (besides a modern version of DirectX11). Sadly, this causes that the interop is very complicated. Your proposal about WPF adorners is interesting. In theory, the adopter can create a popup to place the WinUI/XAML content over the WPF content. Or it can inform to the WPF visual tree that a re-layout is required, but everything based on HWnds.
@dbeavon This is a good proposal, can you create a feature request for this?
Q: Will a WPF app with Xaml Islands compile to ARM64?
A: If .NET Core 3 for Windows supports ARM64 for sure. Today it supports ARM32 in Windows. However, in Linux supports ARM64. I think it is on the .NET Core roadmap to support ARM64 in Windows as well. Although AFAIN, there is no date yet. @richlander, any news?

So are we getting rid of the UWP sandbox? Which in turn implies UWP in it's current form is also going away, and with it the protected sandbox of the App Store as we know it?

So are we getting rid of the UWP sandbox? Which in turn implies UWP in it's current form is also going away, and with it the protected sandbox of the App Store as we know it?

getting rid of the UWP sandbox would be insanely awesome!

That definitely doesn't mean that UWP is going away. The Universal Windows Platform is the only way to natively build for the full spectrum of Windows devices (PC, Xbox, HoloLens, etc.) and is where Windows is focusing its native platform investments. RE: sandboxing in particular: appcontainer isolation continues to provide a lot of important benefits for apps and users of both UWP and desktop apps.

The main changes are:

• we're growing the scope of the UX platform (i.e. WinUI) so that it can also be used with a desktop (win32) app model
• we're decoupling WinUI from Windows so that we can update it more frequently, make new features backward-compatible, and more easily open source it

That means for new apps you'll be able to choose between UWP and desktop app models depending on what makes sense for your app, and if you have existing desktop apps (e.g. WPF, WinForms, MFC) then you can incrementally update them with modern WinUI functionality using Xaml Islands.

So are we getting rid of the UWP sandbox? Which in turn implies UWP in it's current form is also going away, and with it the protected sandbox of the App Store as we know it?

UWP will be one of the options for building a WinUI 3.0 app. Using the UWP will allow your app to run on Xbox, Hololens, etc.

But you can also build a Win32 app with WinUI 3.0 and access UWP APIs - but where your app can run will be more limited.

@mdtauk @jesbis I'm totally for UWP, but at this time:

1. compilation times are insanely slow! (pretty much, 6 times slower that WPF - i'm using target version build 1809 - build 17783)
2. I know StorageFolder file enumeration API is not part of UWP, but that is insanely slow. The UWP sandbox (at least on Windows Desktop) is hurting more than helping.
3. Sure, async programming is fun, but in UWP, when an exception happens, it's somehow eaten by the UWP code, and then later break in debugger, with all the stack context lost. Sometimes, I do have the stack context inside the thrown exception itself, but not always.
4. Profiling UWP code is close to impossible. Event dotTrace instantly breaks when trying to do it.

(It took me over a month to port my code from WPF to UWP, since I insanely need win2d, so there's no way for me to avoid UWP.)

@mdtauk @jesbis I'm totally for UWP, but at this time:

1. compilation times are insanely slow! (pretty much, 6 times slower that WPF - i'm using target version build 1809 - build 17783)
2. I know StorageFolder file enumeration API is not part of UWP, but that is insanely slow. The UWP sandbox (at least on Windows Desktop) is hurting more than helping.
3. Sure, async programming is fun, but in UWP, when an exception happens, it's somehow eaten by the UWP code, and then later break in debugger, with all the stack context lost. Sometimes, I do have the stack context inside the thrown exception itself, but not always.
4. Profiling UWP code is close to impossible. Event dotTrace instantly breaks when trying to do it.

(It took me over a month to port my code from WPF to UWP, since I insanely need win2d, so there's no way for me to avoid UWP.)

It would be useful for this to be posted in this thread #1517 and hopefully you can include in a name of someone from the SDK team

@jtorjo

compilation times are insanely slow! (pretty much, 6 times slower that WPF

Are you using C++/WinRT? If so, are you using pre-compiled headers?

@mdtauk just posted there

@MarkIngramUK It's c# code

Closing - please direct roadmap and alpha feedback to: #1531

Right now there is no idea if this is possible - the hope is that when the WinUI bits are removed from the OS, they are put into the open source project in a way, which will enable other platforms to provide some kind of compatibility component. Think Xamarin, Uno, or .Net Core with a custom renderer.

Is this something really on the roadmap or was just an assumption?

@mdtauk, @zezba9000 it's all theoretically possible, and we have lots of platform abstraction expertise on the team. As with anything, it just comes down to cost, schedule and expected benefit 😊

Just maybe abstracting it in a way which would make it possible for a third party to make it work on Android or iOS would be huge. I am sure the community can do this. I'd definitely contribute to it.

@andreinitescu Sorry for the rant and complaints but just my thoughts from what I understand: While I'll use WinUI 3 to replace WPF for Windows / Win32 only stuff... Because WinUI on Windows uses a Windows only rendering API and not an agnostic one, WinUI seems to be relying off 3rd parties to re-implement / fragment (ugg) WinUI on other platforms (like the UNO proj, which is cool but it like Mono to .NET is a unnecessary and time wasting fragmentation if things were only designed right to begin with). Instead of using a portable one like Skia, or creating a MS one. Also don't understand the need to support the 1% of people who wont be using C# with WinUI, making C# a second class target in a sense and more importantly making dev time take a lot longer. Just like Android uses Java + post-AOT for many core apps, so should Windows use C# + pre-AOT. Because it saves time. 70% of bugs using C++ are using deallocated ptrs after all.

The lack of communication between groups in a company for the long term use cases when its going to become more and more of an issue when they release their Android OS flavor for mobile platforms (which I plan on using) and more people want to target it with MS tools... feel its just going to be another WinPhone7 like situation again in a way. Windows as a term shouldn't be so tied to the WinNT kernel anymore. An eco system is more than a single platform or one companies frameworks its built on.

To bad MS can't/wont do what Apple did almost 20 years ago with the move from OS9 to OSX. In that you rip the band-aid off by moving to a UNIX/LINUX kernel BUT having an emulator/simulator built into the OS for legacy software for the next 5-10 years while people migrate software and dev tools over to run natively. (Think what you will of this but I can dream)