Need step-by-step procedure to create CppWinRT project with UI

[VikingExplorer]

I decided to make a copy of one of the samples (Blocks), and add it to my solution. On two different days, it's hanging on that. (spinning blue circle for an hour) Is there something with the cppwinrt samples that is not compatible with my solution? I'm running VS 2015 update 3.

[VikingExplorer]

Well, no takers? Why was I trying to do this? There is no step-by-step procedure for creating a working UWP application using this apparently awesome technology. I was forced to try this:

Visual Studio Pro, Update 3:

1. Add new project to solution, blank App, Universal Windows, Anniversary edition
2. Build & run <== success
3. Remove & delete app.xaml,cpp,h & main.xaml,cpp,h
4. add App.cpp from winrt Blocks sample
5. add Assets from winrt Blocks sample
6. replace pch.cpp,h with those from winrt Blocks sample
7. Add winrt folder to  Configuration Properties – VC++ Directories
8. Add to C++ Additional Cmd Line options: /await /std:c++latest /d1permissive-
9. Clean Build: <== failure

1>c:\dev\couloir\generic\ref\refapp.winu\app.cpp(5): error C2872: 'Windows': ambiguous symbol
1> c:\program files (x86)\microsoft visual studio 14.0\vc\include\vccorlib.h(2893): note: could be 'Windows'
1> c:\dev\couloir\3plibs\cppwinrt\10.0.14393.0\winrt\windows.ui.input.h(3034): note: or 'winrt::Windows'
1>c:\dev\couloir\generic\ref\refapp.winu\app.cpp(6): error C2872: 'Windows': ambiguous symbol

There are additional references that are not in the Blocks project, but I don't see how that could cause compiler errors.

Where did I go wrong?

[tim-weis]

Since you had to remove app.xaml.* files, I'm assuming that you created a C++/CX project. By default, this has the /ZW (Windows Runtime Compilation) compiler option set. This option is not compatible with C++/WinRT, and needs to be removed for every C++/WinRT compilation unit.

[VikingExplorer]

That worked, but I hope you can see the need for a step-by-step procedure for creating a CppWinRT project. The requirement to have /ZW turned off is not mentioned in the "getting started" document. It's also counter intuitive because other docs talk a lot about mixing CppWinRT and CX code.

[kennykerr]

C++/WinRT is compatible with /ZW but it is certainly simpler without it. Creating UWP projects is non-trivial. The easiest approach today is simply to copy one our samples and use that as a starting point. We plan to provide Visual Studio project templates in a future update.

[VikingExplorer]

@kennykerr , right, that's what I was trying to do. Anyways, thanks.

Now, I'm trying to add a TextBox:

	  Windows::UI::Xaml::Controls::TextBox tb;

This builds, but crashes when executed. I need to figure out how to add controls to the canvas.

[kennykerr]

This sample is a good starting point for experimenting with XAML.

[VikingExplorer]

I tried adding void OnLaunched( LaunchActivatedEventArgs const & )
to the Blocks Sample, but it never got called.

How about an example creating a simple UI?

I'm concerned when you say "experimenting" with XAML. I'm not using XAML (xml grammar). The controls I need are located in the Xaml namespace.

I can think of no other reason to use UWP than to create a UI, and be able to draw things. Therefore, the Blocks sample should suffice.

Are you saying that a UWP UI application is not yet fully supported?

[kennykerr]

The Blocks sample you're referring to is a Windows.UI.Composition sample. Although this is an API for building UI applications, it is more complex since you are expected to render visuals directly. The XamlCode sample I suggested is a Windows.UI.Xaml sample that can support things like XAML controls that you can simply create, size, style, and display. No need to write any XML markup.

[bigdimboom]

following the steps from above. And it works fine with the XamlCode example. But it shows a lot of error after I add "#include <robuffer.h>" in the header in order to access raw buffer.

[KevinWelton]

To get past that you'll need to remove the /d1permissive- flag in the project settings. By including robuffer.h in this sample, though, you'll also be causing ambiguity in the namespace declarations in App.cpp and will need to prepend all the using statements with winrt::.

[VikingExplorer]

I'm a long time Windows developer (~25+ years), working on cross platform project using C++. I have at times been very excited about getting into UWP development. I spent some amount of time trying to build one of my libraries to target Universal. To my surprise, it was more difficult than either Android or iOS.

my hypothesis about ease of development (from easiest to most difficult): Android, iOS, WinU

So, even though it appears that @kennykerr has done something amazing by keeping WinU in the game by enabling the use of standard C++, it's possible that the complexities of the underlying winU development are a barrier to entry that will doom Windows the dust bin of history.

Seeing how easy it was to cause an exception with these samples supports this hypothesis.

Seeing how much difficulty MS has had creating UWP apps supports the hypothesis.

[nvictor]

Umm, @VikingExplorer don't give up? : ) (I was reading all the comments when you closed the ticket).

I ran into those issues you mentioned above when creating my own UWP project. I know the samples work though. Every single one I tried worked. I am going to start afresh using one of sample projects tonight.

On a side note, I noticed a bunch of "references" included in a "blank UWP" project. That's odd because all the samples have only a single reference entry. Some references are getting in the way in my opinion (not sure one can remove them either...)

[VikingExplorer]

@nvictor Don't worry. I won't ever give up.

I'm just saying that MS may have engineered themselves into a corner. Their zeal to control the language may be their undoing. (CL, C#, CX). Last year, the UWP calculator app stopped working for some users. It came back some months later. It speaks to the reliability of the technology. I had two kids using Windows Phones. One has switched. MS stores seems to be de-emphasizing Phones. That was the whole reason for UWP.

[walbourn]

@VikingExplorer : To be fair to @kennykerr and @BrentRe , the initial production version of C++/WinRT has to work with the constraints of what's supported by the Visual C++ 2015 compiler to meet the immediate needs of game developers who need an easy to way to consume Windows Runtime interfaces and types. The challenge is that to use XAML (which most games do not use), you really need to be able to author Windows Runtime interfaces and types as well. With the release of VS 2017, the C++/WinRT team has some new compiler functionality to leverage. IOW: give them a little time to address the XAML scenario.

[VikingExplorer]

@walbourn I've haven't been unfair to those gentlemen. "XAML" is vague. I have no interest in using XAML the xml grammar. I do have an interest in developing 3D UIs, including games. All games that I know of also have 2D UIs to interact with the user. These are required to control settings, etc. Therefore, I have an interest in the controls in the Xaml namespace. According to Kenny, these are fully supported.

So, not sure what you are talking about.

[walbourn]

@VikingExplorer: There are three basic 'app models' for UWP applications:

• XAML with C++ or C# code-behind
• Direct3D with C++ (or C# using 3rd party managed assemblies like SharpDX, Xamarin, Unity3D, etc.)
• XAML+Direct3D with C++ or C# code-behind (with the Direct3D rendering portion in C++ or C# using 3rd party managed assemblies)

The XAML controls in UWP are a specific UI technorlogy that leverages the XAML xml layouts created by Visual Studio Blend et al. Using the XAML Windows Runtime types in the Xaml namespace requires your application provide the system Windows Runtime types, i.e. your application actually authors and publishes Windows Runtime types.

Games (even 2D games) typically render everything with Direct3D and do not use Direct2D or XAML, and instead use sprite-based UI. There are some common 'middleware' solutions for vector-based UI for high-quality scaling (such as Scaleform), but the end result is still pushed to the display as a bitmap.

The Direct3D scenario works great with C++/WinRT today because again such applications only need to consume Windows Runtime APIs, not author them. See this repo for fully-functional Direct3D only C++ templates that use C++/WinRT.

While I realize "phone" gets a lot of attention from the technical press, UWP was not created solely for the purpose of targeting phones. Today we have UWP on desktop, UWP on Xbox One, UWP on mobile, UWP on Hololens, and UWP on IoT.

[bigdimboom]

I'm actually very excited about @kennykerr and @BrentRe 's attempt.

[VikingExplorer]

walbourn, the controls in the Xaml namespace work just fine and do not need to be driven by xml. I'm never going to author Win RunTime types. Your comments are not helpful.

[walbourn]

@VikingExplorer : I'm sorry you do not find my comments helpful. I was attempting to shed light on the engineering tradeoffs at play here. Using Xaml namespace controls programmatically without using xml seems to fall into the category of 'off-label' use. As such, perhaps your experience of the relative difficulty of creating a UWP is specific to your approach. In any case, best of luck.

[VikingExplorer]

What's most annoying about your comments walbourn is that you didn't read what this thread was about and proceeded to lecture me.

MS has been saying since Vista that all of Windows is now running through DirectX. (For example, https://msdn.microsoft.com/en-us/magazine/jj991975.aspx)

I'm saying that it's been 4 years since that article came out. It's well past time to realize that although it's technically feasible (e.g to render damn buttons and text boxes in direct3d by rolling our own), it's not a recipe for success going forward. Based on what people are doing, It's apparently TOO DAMN DIFFICULT to create a normal app using UWP.

How many app makers created Android & iOS apps, but left WinU out?

You say that UWP wasn't about phones (with the huge volumes), but you mention "Mobile". Windows is almost out of the picture for tablets as well: http://www.techradar.com/news/mobile-computing/tablets/10-best-tablet-pcs-in-the-world-today-1113985

Why is UWP so complicated? COM. Why do they insist on using COM even though it's ugly and stupid?Because MS wants to control the language people use and created COM to support multiple incompatible languages. Hence, the ABI layer.

My "experience of the relative difficulty" had nothing to do with the Xaml namespace. As I said, it was based on trying to get a library written in standard C++ to build for UWP. It was so difficult, that I moved it to the bottom of the list, after Android & iOS.

Please mind your own business.

[VikingExplorer]

As for programmatic usage being "off label", take a look at the documentation.

For example, https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.controls.textbox

Everywhere that XAML is shown, there is C# right next to it. The implication is that programmatic access is a first class use case.

[kennykerr]

Just a reminder to keep comments civil. Everyone monitoring this forum is doing so on a volunteer basis. @walbourn in particular is very knowledgeable about C++/WinRT and the platform in general. We are all just trying to help.

[nikobarli]

One vote to seeing the integration of XAML feature into C++/WinRT flow.

[KHofer]

@nikobarli you are right. The missing UI part is THE thing that actually prevents us from switching to winrt. We can't (don't want to) make Windows Store Apps. The restriction of a new elegant API to this sandbox approach is a bit disappointing.

[VikingExplorer]

@KHofer the UI part is not missing from CppWinRT. We just can't write code in XAML (xml grammar). IMO, this wouldn't make sense anyways. The only reason for COM is to enable this type of late loading object instantiation.

CppWinRT is about C++, not xml. It's encapsulating the COM ugliness for us. If you want that back, you should just use C++ / CX. Just my opinion.

[sylveon]

The XAML designer can somewhat provide a drag/drop UI builder, but the C++/WinRT codegen of the designer is plagued with bugs, unfortunately.

[kennykerr]

C++/WinRT doesn't really have any direct support for UI development. It merely provides access to the APIs including UI APIs. Any specific UI support would have to come either from an IDE or specific APIs like:

https://github.com/Microsoft/microsoft-ui-xaml

[tim-weis]

Though none of this is actually related to this repository, let me just share my experiences developing a UWP application with a XAML UI using C++/WinRT. Development started in early 2019, straight from a template of the C++/WinRT VSIX (Blank App (C++/WinRT)).

Out of the box, the template worked as advertised. It compiled all target platforms (x86, x64, ARM), and allowed for creation of an AppX package, ready for submission to the Microsoft Store. Submission subsequently failed WACK certification due to default logo assets. Replacing those made WACK happy, and the application is published ever since.

The whole process took less than an hour, with the majority of time spent on waiting for Store submission to report a result.

Now for a few surprises: Targeting the UWP was a conscious decision, as the application was intended to be used primarily on mobile devices. So I took out my Lumia phone, went to the Store, installed the application and launched it. I wasn't expecting much of anything, and was surprised to see it working, out of the box.

I later moved from the OS-provided XAML control stack to WinUI2. That was as simple as adding a NuGet reference, and replacing some namespace declarations (in XAML and C++ source code). C++/WinRT didn't mind generating the new bindings from the WinUI winmd, the application still compiled, Store submission still succeeded, and the application still runs on a Windows 10 Mobile device.

Likewise, I frequently moved to newer C++/WinRT tooling (again, just a NuGet reference) to benefit from improvements and fixes. I don't recall those updates to ever break anything.

In all, the development experience was pretty solid.

XAML authoring, though, was fairly tedious. Making a change often meant updating an IDL file, recompiling to have it generate the stubs, copying those stubs over into the source tree, and compiling again. The XAML preview in Visual Studio frequently failed, and many useful features simply didn't work (reliably, anyway). Those issues would need to be addressed by tooling/IDEs; it's not something that C++/WinRT can fix.

---

Anyway, here's the TL;DR version of the step-by-step procedure to create a C++/WinRT project with XAML UI:

1. Install Visual Studio 2019 (or 2017)
2. Install the C++/WinRT VSIX
3. Create a new project using the Blank App (C++/WinRT) template
4. [optional] Switch to WinUI2 by adding a reference to the WinUI NuGet package

[VikingExplorer]

I still have high hopes of creating a UWP UI app in std c++ & using CppWinRT to completely avoid COM, which is "Ugly & Stupid" (Don Box). (https://twitter.com/search?q=COM%20Ugly%20(from%3AGunnarSkogsholm)&src=typed_query).

Developers need to be able to directly use the new WinUI 3 controls (in XAML or whatever namespace), as well as being able to use the XAML xml grammar.

I've been following project Reunion for some time, and wondering how WinRT fits in with WinUI 3 & Project Reunion desktop app development.

As Tim says, XAML authoring is difficult. I don't want to do that b/c I never want to mess with IDL EVER, EVER again. There should no reason to. That's why WinRT was created, IMO.

Vision looks great: https://docs.microsoft.com/en-us/windows/apps/winui/

"WinUI 3 is the path forward for all Windows apps—you can use it as the UI layer on your native UWP or Win32 app, or you can gradually modernize your desktop app, piece by piece, with XAML Islands."

What would be the procedure for creating a WinUI-3 -> WinRT? -> C++ app ?

[sylveon]

Most project reunion APIs and all of WinUI 3 use WinRT to make their APIs cross language compatible.

The WinUI 3 VSIX provides templates using C++/WinRT, which also supports authoring XAML files. IDL is still present and won't go away until we get a standard compatible solution to generate WinRT metadata directly from source code.

[VikingExplorer]

Again, I don't want to author new controls that can be driven by XAML xml.

XAML xml is a layer on top of the actual Controls.

I want to write code using the actual WinUI 3 controls.

[tim-weis]

What would be the procedure for creating a WinUI-3 -> WinRT? -> C++ app ?

Create a WinUI 3 desktop app with C++. If you want to be using XAML markup to author your UI, you will be writing IDL. Not the end of the work, considering how slim MIDL v3 has gotten.

Though again, that's nothing that C++/WinRT has any control over changing. Support for bridging XAML and C++/WinRT would need to be provided by IDE's.

[sylveon]

XAML xml is a layer on top of the actual Controls.
I want to write code using the actual WinUI 3 controls.

There's nothing stopping you from doing this - instantiating and laying out controls manually works as well, here from code behind:

FrozenFancyYamask.mp4

I haven't been able to get rid of App.xaml, since it's essential to some support infrastructure for WinUI (resource loading, Application singleton, etc.), but you can leave that file alone and just manually lay out controls in App::OnLaunched and work your way from there:

void App::OnLaunched(LaunchActivatedEventArgs const&)
{
    Button button;
    button.Content(box_value(L"Click Me"));
    button.Click([](IInspectable const& sender, RoutedEventArgs const&)
        {
            sender.as<Button>().Content(box_value(L"Clicked"));
        });

    window = {};
    window.Content(button);
    window.Activate();
}

[VikingExplorer]

@sylveon that looks ok. Is that Win UI 3?

I'm not sure that's using WinRT, b/c IInspectable is COM

https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/boxing

[sylveon]

The Windows Runtime ABI is based on COM, IInspectable is the base interface of all WinRT objects, it is to WinRT as object is to C#.

[VikingExplorer]

WinRT is supposed to hide the COM interface. If that has changed, then I'll probably abandon any thought of WinUI 3 development.

A long time ago, @kennykerr had side-by-side comparisons of C# and C++/WinRT and they were similar. C# developers are not exposed to the ugliness of COM. If that's changed, I need to know.

[sylveon]

IInspectable is a WinRT interface, you access it with winrt::Windows::Foundation::IInspectable. It's the base of all WinRT objects. Consider it like C#'s object but in WinRT.

Because WinRT is based on COM, there is a raw COM version, but C++/WinRT hides it away.

[VikingExplorer]

Yea, this has a comparison of the two: https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/move-to-winrt-from-csharp

[omatai]

With all due respect to Tim, I think his 1-2-3-4 step-by-step misses the point. To me it may as well be:

1. Conceive and birth a child
2. Feed the child good food
3. Point to the sky
4. Land on the moon.

There is a lot missing between steps 3 and 4. Now if you happen to raise the child in a NASA environment, maybe the step from 3 to 4 happens kinda automatically. But I would challenge anyone to find a competent programmer unfamiliar with the Microsoft universe, and make any sense of that step-by-step. To me that's the problem.

The great thing about MFC and it's readily available UI widgets and drag-drop UI building was that it was WYSIWYG. What you see when UI meets C++/WinRT is a steep learning curve, and what you get (I fear) is low uptake and withdrawal of Microsoft support after a short time. :-(

How do I get a simple UI of buttons and boxes on a window on a (desktop) screen with no desire to appear on any other platform? That's the step-by-step that is missing for me. The gap between hello world and an app, whether in the MS Store or not, is way too large at present.

That my comment has generated this much comment in and of itself sums up the problem neatly. There should have been a single answer: "here's how you do it: -> link" That there is not a simple answer speaks volumes to me :-(

[omatai]

Just to be clear: I REALLY REALLY REALLY want C++/WinRT to be a success. And I think it will be if there is investment in bridging that gap around UI issues. All application development I've done in the past 20 years starts with a user-centric focus on how the app will behave. So it's always (a) UI sketch then (b) code behind then (c) refinement. It starts with (a). Until that step clearly matches the WYSIWYG simplicity of MFC, I fear that C++/WinRT will be a terrific idea that fails to gain developer support, and risks coming to a premature end, costing companies like mine money we can't afford to spend. Until it's clear to me that this assessment is false, I'm not prepared to gamble on investing in climbing up the steep learning curve. We made the same assessment with C#, with COM, with CX/CLI and everything since MFC came out. I don't feel we're alone in that. I don't want to tell Microsoft that this is an issue of strategic importance to them, but it is certainly an issue of strategic importance to my company.

[VikingExplorer]

@omatai is right. I've been a MS developer since 1988. At some point, MS lost the plot. It all started to go wrong when they created COM to make their Office Products extensible. However, people eventually decided extending Office was an anti-pattern. MS made a religion out of COM. Then they created .NET (97-2000) & suddenly admitted: COM was ugly & stupid & that OO was ok again. Everyone in the world stopped authoring COM objects & forgot about it.

Problem was MS themselves were still locked in a COM death spiral. Internally, they couldn't admit it was a mistake & reverse direction. DirectX suffers from COM-itus, so OpenGL is generally preferred. UWP suffers from the same problem. At first, Big app makers created UWP versions of their software, but didn't take long for them to drop UWP support. At one point, there was a UWP apps for Netflix, Napster, Hulu, etc. It was just too difficult to work with.

UWP apps are generally feature-poor & buggier. MS couldn't even do the Calculator app w/o it crashing. The only UWP app I'm using might be MS Teams. I have no idea what tech was used for MS Teams, but it's feature-poor & buggy & slow as all get-out. Therefore, I assume it's UWP. See the problem?

Like I said 4 years ago. It's easier to create a Android, Linux or even a MacOS app than it is to work with UWP. The fact that nothing has really improved in 4 years is the problem.

MS has forgotten how to create software. Office apps are taking forever to load. Windows 10X was announced in October 2019 and then delayed in April 2020. Now it has been cancelled. They may claim otherwise, but I believe that it didn't work well enough to release.

Again, the Vision looks great: https://docs.microsoft.com/en-us/windows/apps/winui/

"WinUI 3 is the path forward for all Windows apps—you can use it as the UI layer on your native UWP or Win32 app, or you can gradually modernize your desktop app, piece by piece, with XAML Islands."

Based on this image, I should be able to create a Windows UI app, & seamlessly mix & match MFC & WinUI 3 controls.

"All new XAML features will eventually ship as part of WinUI. The existing UWP XAML APIs that ship as part of the OS will no longer receive new feature updates"

Just to be clear: I REALLY REALLY REALLY want to be able to easily create a modern Windows UI app. However, if the only way is 10x harder than it should be, resulting in buggy & slow app, then I'll stick with Win32/MFC/BCG.

[sylveon]

DirectX suffers from COM-itus, so OpenGL is generally preferred

DirectX only uses IUnknown for resource management (AKA nano-COM: no apartment, no BSTRs, etc.), so doesn't suffer from many of the issues that normal COM has, and many developers appreciate that aspect because it makes resource management much easier. The reason OpenGL/Vulkan is generally preferred is mostly cross-plat.

The only UWP app I'm using might be MS Teams. I have no idea what tech was used for MS Teams, but it's feature-poor & buggy & slow as all get-out. Therefore, I assume it's UWP. See the problem?

It's Electron, which is used to write apps using a web stack (HTML/JS/CSS). You might be interested in it.

seamlessly mix & match MFC & WinUI 3 controls.

This can't be achieved ATM, because WinUI 3 renders to a DirectX swapchain while MFC is a bunch of windows, so there is significant airgap issues. There are existing feature requests that could make this easier, see microsoft/microsoft-ui-xaml#4670 and microsoft/microsoft-ui-xaml#3859.

[omatai]

I disagree (strongly) with @VikingExplorer that COM is a/the problem. Yes: it's something that is worth hiding as much as possible, but any developer worth an ounce of salt asks "how do I get any of N applications to interop with any of N applications without creating an N^2 problem?" and the answer is COM, or something like it - you define an interface that you can query to discover the capabilities of an app, and proceed from there.

That's not to say that the simple concept doesn't quickly get bogged down in the intricacies of the implementation, and for that reason (and the fact that interop is not the slightest bit on our list of needs), we've never touched COM here.

But I would say that Win32 had the same intricacies, and the (ongoing) success of MFC lies in robustly abstracting those intricacies away behind a really usable UI builder that generated a ton of boilerplate code for the developer. I'd suggest that there is a valuable lesson in that - one that speaks to how to give a platform longevity by boosting developer uptake.

[VikingExplorer]

DirectX ... doesn't suffer from many of the issues that normal COM

It does, b/c the main problem with COM interfaces are that they are too difficult to work with.

reason OpenGL/Vulkan is generally preferred is mostly cross-plat

Right b/c COM is Windows ONLY. MS has always arrogantly assumed they were the only game in town.

It's Electron

Right, another technology that sucks big time. Firms who use Electron don't care that much about UXD (https://www.nngroup.com/articles/response-times-3-important-limits/)

This can't be achieved ATM, because WinUI 3 renders

So, the WinUI 3.0 architecture diagram/description is deceptive vaporware...

any developer worth an ounce of salt asks "how do I get any of N applications to interop with any of N applications without creating an N^2 problem?" and the answer is COM

interop is not the slightest bit on our list of needs

The 2nd quote completely undermines the 1st. No Software Engineer worth an ounce of salt asks questions devoid of user focus & insists on solving a generic problem that no one actually has.

COM was a mistake b/c

1. Overly broad & generic. It solves a problem that only MS actually had, and it was a problem of their own making.
2. In reality, interop was always an anti-pattern.  Hence the failure of C++/CLI
3. Windows ONLY, transparent vendor lock-in strategy
4. Part of legacy RPC story, only of historical interest (https://en.wikipedia.org/wiki/Remote_procedure_call)
5. RPC "fell in popularity with the rise of the internet" & networking protocols.
6. two very popular languages solved the "interop problem" w/o COM (Python & NodeJS)

Windows mobile failed b/c UWP was a hot mess. XBox is now in 3rd place & fading slowly, failing to become a family entertainment device.

Smart TV platforms utilized by vendors: https://en.wikipedia.org/wiki/List_of_smart_TV_platforms
market share: Roku 30% (Linux), Amazon Fire TV 12% (Android fork), Samsung Tizen 11% (Linux fork), Android 9%

As for targeting XBox, HoloLens & Surface Hub, I believe that one will be able to use a win32 app. Lots of indication that the Windows Store will be revamped to allow win32 apps. If not, these products will die. & the Store will be ignored & forgotten.

Vibe vs. Google Jamboard vs. MS Surface Hub vs. Samsung Flip...

Surface Duo runs Android...

IOW, UWP/WinUI 3 appears to have no point...

Thank you folks, closing this ticket. You cured me of this sentimental attachment to WinUI 3 / WinRT.

[VikingExplorer]

[sylveon]

The store already allows win32 apps

[Gavin-Williams]

"The reason OpenGL/Vulkan is generally preferred is mostly cross-plat." - I think that's a myth that tries to explain why people choose OpenGL. There really is no cross-platform, games are not made for mac or linux, they are made for Windows. And if you're targeting mobile, then you're already drinking the koolaid and not thinking about desktop anyway.

And I do understand that Consoles are a thing. But 99% of game developers start out on Windows and their first programs and often, all of their programs, will be running on Windows. Very few developers start out targeting consoles and needing cross-platform api's.

If people are choosing OpenGL because of x-plat, they are making that choice from a position of ignorance due to the general propaganda around the importance of cross platform. It's not important at all in game development. If you're writing a desktop game, you'll be primarily targeting Windows and therefore, should be using DirectX.

If there is a technical reason why one hardware api is chosen over the other, OpenGL must be much easier to get into, DirectX must be more difficult to get going. Though many developers do say that Dx the superior API, always look at the entry level to see why people are using one system over another.

C++/WinRT - terrible, just so bad. I'm not going to go over it's issues, because experienced engineers will just try to counter what I say, or suggest that it's not C++/WinRT's fault, it's Visual Studios fault and the tooling etc. So nothing ever gets fixed. It's been about 6 years now, and C++/WinRT is still unusable - I just added C++/WinRT component to a project and although I've referenced it, it's completely invisible to my code. That kind of stuff is just typical for C++/WinRT, the system doesn't work. And it still requires a lot of tooling and further development to work, there is always the promise that ease of use will arrive in an ephemeral future scenario - something to do with the C++ committee - lol.

[Gavin-Williams]

We will get a better language option I guess (Rust or C^) before C++/WinRT is ever easy to use.

Or maybe MS will come out with a new cross language solution, but if they once again forget to include a new hardware graphics api to replace directx, it will also fail, because until they work out graphics, they are missing half of all development scenarios - games!

[VikingExplorer]

Thanks @Gavin-Williams for the thoughtful response. DirectX lives.

Absolutely right that C++/WinRT is too difficult to work with. Doesn't seem to be worth the effort.

Now that UWP has been dropped (rightfully), not really sure what the point of "reunion" or "WinUI" would be...
(https://www.theregister.com/2021/07/02/uwp_microsoft_winui3/)

It's no longer to get into the MS Store, b/c "win32" apps are officially in...
(https://www.theverge.com/2021/7/5/22563638/microsoft-windows-11-app-store-microsoft-store-apps-desktop-win32)

[Gavin-Williams]

I just want to note that UWP hasn't been dropped, MS will not be bringing WinUI 3 to UWP for the foreseeable future. But WinUI 2.X will continue to be developed at least through 2.7, 2.8, 2.9. So that's good at least. MS are still saying that if you don't need legacy API's, so if you're a greenfield project, you can target UWP. But I still see the following issues as barriers for UWP:

1. No modern C# support
2. No container-less deployment
3. No true full-screen without an overlay suspension mechanism
4. Missing API's

Without those features, people will simply choose legacy app models and runtime along with .Net 5 or C++. I mean, MS talk about UWP being great for XBox, but do they mean cross-plat with Windows? Because UWP is terrible for Windows as long as there is not containerless deployment and Steam support. I won't go into that too much more, it's off-topic and to lay it out more clearly I would need preparation and some facts checking.

[VikingExplorer]

If one reads the link, UWP is defacto "dropped" & is dead code:

"Microsoft tried to get Windows developers to adopt its UWP model but too many of them refused – for all sorts of reasons. The result is that Redmond has had to backtrack"

The list of barriers is missing:
5. Way too difficult to work with
6. No particular reason to mess with UWP (easier alternatives exist)

#6 implies there is no reason to mess with CppWinRT.

"C++/WinRT is a C++ language projection for Windows Runtime (WinRT)".. Well, the WinRT should never have required a language projection.

As for XBox, we'll just use DirectX.

There never really was a use case where XBox users wanted to run UWP apps anyways. XBox never became a family entertainment platform. As I said above, family entertainment market was won by:

Smart TV platforms market share: Roku 30% (Linux), Amazon Fire TV 12% (Android fork), Samsung Tizen 11% (Linux fork), Android 9%