Make WPF cross-platform (MacOS and Linux support)

[x2bool]

Please port WPF to other platforms so we could use it to build desktop software for other operation systems.

[juanfranblanco]

Have you seen https://github.com/AvaloniaUI/Avalonia ?

[dotMorten]

It's definitely not in the current plan: https://github.com/dotnet/wpf/blob/master/Documentation/contributing.md

We also do not intend to accept contributions that provide cross-platform implementations for Windows Forms or WPF.

Considering how platform specific WPF is, this would be a major undertaking

[alexbakker]

I'm not too familiar with how WPF works, but as far as I know it relies on D3D for rendering. In the case of Linux, someone would have to (a) port it to use GL(ES)/Vulkan and (b) write an X11/Wayland backend for it.

[kekekeks]

@alexbakker
I think that could be solved by linking to Winelib, but that's more of a packaging work that has to be done on application level rather than in WPF code

[feliwir]

Exchanging the current rendering backend with something crossplatform e.g. like https://github.com/mellinoe/Veldrid would be the correct approach in my opinion. Not sure why they explicitly state that they do not want something like that.

[richlander]

Just like @dotMorten says, we are not taking cross-platform implementations, per our Contributor Guide.

We look forward to many contributions to WPF. This request is out of scope for the project.

From a technical standpoint, WPF depends on multiple Windows components: D3D (DirectX), DWrite, User32, GDI+, WISP (Touch), and several others (including Windows Runtime dependencies). The interaction with these components is complex, critical and not architected with cross-platform in mind. As a result, our focus is on completing open source of WPF and bringing it to parity with .NET Framework.

I am closing this issue as a result.

[zezba9000]

As 'feliwir' says the rendering backend could be replaced or be updated and Windows specific APIs like GDI+ or other User32 APIs are already supported by Mono. Areas that directly link to WinAPIs via DllImports or whatever would just have to be ported to use the Mono version to start with (later ported to use .NET Standard). Just my thoughts without actually looking.

Maybe there should just be a WPF subset for other platforms like WASM, Android, iOS, etc.
WPF could be made to run as a UWP app as well.

[Kryptos-FR]

Disclaimer: what follows is a rant.

@richlander closing the issue and refusing the debate is a very dick move.

Now that WPF is open source and under the .Net Foundation, it is not up to Microsoft only what the future of it should be. If the majority of the community wants it, we have to at least try.

Seems like Microsoft still has a lot to learn how open source and communities work. I understand the difficulties and implications and possibly it will not be realistic to do so. But saying "no never" and "we will reject any attempt" is not a sane way to interact with the community. You have people ready to contribute for free to the project so you need to show at least some respect for their wishes and be more open minded.

[dotMorten]

@Kryptos-FR That's not really fair. He clearly stated it's out of the scope of what they can support, and it was already documented before this issue was logged, so what's there to debate? He never said you can't go ahead and fork this repo and attempt taking things cross-plat.
And we're not talking about a small part to flip a few switches to compile it against Linux and Mac - WPF is so closely tied to the Windows APIs, it is basically a complete rewrite, and code and UI was never designed for x-plat in the first place. IMHO I'd rather they focus on using their resources on improving WPF on Windows, than go on a wild goose-chase shoehorning this onto a Mac, and instead provide something more modern built from scratch that could be such a cross-platform UI, designed for xplat from the ground up.

[richlander]

Exactly, @dotMorten. We are being clear and transparent. In fact, I think we know exactly how open source works. We are setting the rules of engagement for this particular repo, but also licensed the code very favorably and are happy to see others use this code for scenarios that are out of scope for this repo. We're also happy to take code back, should it continue to be licensed favorably and it aligns with future scenarios.

We've also learned from our experience from CoreCLR, CoreFX and other repos. We have cases where issues have stayed open for years where nothing has happened. To a degree, we've voted by not applying any effort on some of those requests. That model is potentially more friendly, but it arrives at the same product outcome. That's not a bad model, but we want to avoid it where we have a clear point of view up front. That's what's happening here. It also allows others to stake their claim if they are passionate, with a clear sense of the engagement model with upstream.

Let's also be crystal clear. This is a very hard project. If the cost was low, this would be a very different conversation and very likely a different outcome. We have enough trouble being compatible with OpenSSL and that's just one library.

[zezba9000]

@Kryptos-FR MS is just taking the position (from my perspective) of they're not going to spend money supporting platforms they don't 'directly' make money in or is hard for them to measure the value of short term (which is a little off as they supports macOS but only for the sake it brings in Azure developers not realizing I think people need better client side tools to even use Azure [thats a larger topic though]). Thus Its the communities responsibility to fork and port WPF and if it does have value to MS (which I would argue does) the community will have to illustrate that to MS. This is just how big companies work which sometimes don't see the value of innovation outside their bubbles / eco systems if you will.

There is a lot of value in a cross platform XAML that looks the same on every platform, is compile type checked, has a visual editor in an IDE and based around the .NET or C# eco system. MS has at least given people a starting point if they have the resources to port it (which is far more than I expected to happen tbh).

@dotMorten Many apps written in WPF would have great value on other platforms. If these apps were using Azure it would end up making MS money in the long run. People who don't see this value are a little disconnected I think. .NET Core has solved the cross platform issues in its eco system in every aspect besides the desktop and client side (no HTML is not the answer for many reasons). It is in some ways both MS's and the communities responsibility to solve that remaining client side UI issue as both parties will share the rewards. In this case I think the community has to start the trail rolling.

[dotMorten]

@zezba9000 Don't get me wrong: I'm not at all saying a cross-platform UI is a bad idea and not needed - what I'm saying is I think making WPF cross-plat would be a waste of (a lot of) resources, and we'd be better off inventing something new from scratch - also IMHO if we were to go the XAML route, we'd be better off starting with UWP as a base.

[zezba9000]

@dotMorten I agree WinUI might be a better base or something new that lives outside of the platform its running on conceptually (then platform specific APIs like .NET Core has for Windows now could be made). This would also help MS from needing to keep reinventing XAML for each new platform they create. If WPF was designed correctly to start with, they could have just had a WPF version running as a UWP app. If that makes sense.

However the gravity to use existing knowledge and code bases is probably strong for WPF. Just look at the stars on WPF vs WinUI in GitHub... people clearly want a WPF like Desktop solution more than something else. From what I can tell. Its a lot faster to dev with for sure.

[xiexin36]

Please at least be open to discuss these.

[10Dev]

Exactly, @dotMorten. We are being clear and transparent. In fact, I think we know exactly how open source works. We are setting the rules of engagement for this particular repo, but also licensed the code very favorably and are happy to see others use this code for scenarios that are out of scope for this repo. We're also happy to take code back, should it continue to be licensed favorably and it aligns with future scenarios.

We've also learned from our experience from CoreCLR, CoreFX and other repos. We have cases where issues have stayed open for years where nothing has happened. To a degree, we've voted by not applying any effort on some of those requests. That model is potentially more friendly, but it arrives at the same product outcome. That's not a bad model, but we want to avoid it where we have a clear point of view up front. That's what's happening here. It also allows others to stake their claim if they are passionate, with a clear sense of the engagement model with upstream.

Let's also be crystal clear. This is a very hard project. If the cost was low, this would be a very different conversation and very likely a different outcome. We have enough trouble being compatible with OpenSSL and that's just one library.

@richlander Perhaps you could reconsider and simply take the well worded contents of your post above to insert into this issue's "description" and then suffer the annoying situation of leaving the issue OPEN forever which you stated is a possible option.

Considering how well-loved WPF is to so many people, you might be faced with a multitude of endless repeats of this issue. By taking the current approach, it simply does not "read well" and comes off cold-hearted through no bad intent of yours, just the situation.

I'm just suggesting that it will calm everyone down and leave a "safety valve" if you just leave this open as a kind of "wisdom of the crowds" or just plain old wisdom...

[ranqn]

I think what the community want is just an open source, cross-platform XAML-based UI framework, not a cross-platform WPF. We can have an open source cross-platform XAML-based UI framework, because we now have WPF open sourced, we can take the stuff and build one, but the one we'll be building is just not WPF, it just won't exist in this repository under the name of Windows Presentation Foundation.

So I think the correct question should be 'Can we have an open source, cross-platform XAML-based desktop solution?'. Apparently it's not an easy one to answer.

[raffaeler]

@Ran-QUAN frankly speaking I am not sure that would be the right direction. Let me say that many years ago I asked several times to port WinRT/XAML cross-platform, but now many development shifted to web and mobile, and XAML failed to improve over the years.

Don't get me wrong, I love WPF and wrote tons of apps but there are multiple flaws in XAML.

• The inability to provide a solid designer is a major stopper for most of the developers. I stopped using a designer a long time ago but it is still a blocker for many.
• The verbosity of XAML was supposed not to be a problem because initially the designers would manage that. But in large apps, you have to take care of your XAML by hand.
• XAML in UWP and WPF is significatively different. And in UWP there are a lot of missing features that prevented porting many apps. What XAML are we talking about? Is the WPF one (the most complete) really the best? I don't think so.
• The missing lifecycle of the views (pages or simply windows) is a major problem for writing a decent MVVM support.
  Those are not the only things of course, just the first ones I had in my mind. Converters syntax and versatility can probably be easily fixed and improved but they have been a source of complains for years.

Paradoxically it's far more easier to port winforms cross-platforms (as Mono had for years using Wine) in comparison to the effort of WPF (because of DX and other components). Not the best choice at all, but definitely the fastest.

[costincaraivan]

@richlander In my opinion @10Dev is right, put part of your comment into the Contributing Guide and make that a bit softer. The soft approach could be something like this:

"We will accept contributions that make WPF cross platform provided that they come through high quality pull requests, which include:

• a detailed architectural plan justifying the decisions made
• detailed specifications of the changes made
• good test coverage for the contributed code
• widely adopted, stable and high quality dependencies."

This would kill basically all "hit-and-run" contributions I assume you're afraid of 😄

[danwalmsley]

Why not focus on existing projects already modelled from uwp and wpf like http://github.com/AvaloniaUI/Avalonia that make this already a reality, with many apps already using it.

[zezba9000]

@danwalmsley (Unless this has changed) The big issue with Avalonia is it doesn't generate C# types in a partial class for the code behind allowing for type safe / compile time checked XAML. Which both WPF and WinUI do. This is a huge advantage over HTML, Androids UI, QML etc. Without this Avalonia really isn't that different from using some other UI that relies off runtime errors instead of compile time ones.

Also companies like Telerik etc aren't supporting it like they're with WPF and WinUI. You say we should extend existing projects but why not extend the ones that already have much larger support and tools? I see nothing wrong with changing direction when new doors open is all I'm getting at.

[kekekeks]

DevExpress/Telerik products also rely on Win32 API or DirectX. We've tried to port some open-sourced Telerik controls from UWP to Avalonia and discovered that we can't because they are using custom DirectX rendering.

[worldbeater]

Glad to see .NET evolving! Hope Avalonia will also become a part of .NET Foundation someday. Really an impressive framework with poweful styling system. WPF, beloved by many developers, could borrow some ideas from that framework, like value conversion syntax, binding to async values or binding from code. Worth mentioning, that we can already create cross-platform applications using ReactiveUI or Caliburn.Micro frameworks alongside with Xamarin, WPF and Avalonia 🥇 💯

[HumanEquivalentUnit]

@Kryptos-FR

Seems like Microsoft still has a lot to learn how open source and communities work. [..] You have people ready to contribute for free to the project so you need to show at least some respect for their wishes and be more open minded

Have we learned nothing from the recent Node/NPM disaster? Communities don't get to make demands on people who give their hard work away for free. Even if it's Micrsoft and even if you hate them.

See Rich Hickey (creator of Clojure)'s comment here: https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9

The only people entitled to say how open source 'ought' to work are people who run projects, and the scope of their entitlement extends only to their own projects.

Just because someone open sources something does not imply they owe the world a change in their status, focus and effort, e.g. from inventor to community manager.

As a user of something open source you are not thereby entitled to anything at all. You are not entitled to contribute. You are not entitled to features. You are not entitled to the attention of others. You are not entitled to having value attached to your complaints.

Asking for it, asking about it, is OK. Stating that someone needs to listen to you because you have demands and you want more free things, is not OK.

However the gravity to use existing knowledge and code bases is probably strong for WPF. Just look at the stars on WPF vs WinUI in GitHub... people clearly want a WPF like Desktop solution more than something else. From what I can tell. Its a lot faster to dev with for sure.

People are aware they can pay for Windows and get WPF .. right?

[juanfranblanco]

@worldbeater it looks that you are trying to achieve the same as me, mixing ReactiveUI + "xUIFramework" (Prism, MVVMCross, Caliburn.Micro) to create a generic set of guidelines / framework for cross platform applications (https://github.com/Nethereum/Nethereum.UI.Desktop). Your example is excellent (https://github.com/worldbeater/ReactiveMvvm).

Now although slightly off topic if we could have alignment on frameworks too (Prism, Cross, Caliburn, MvvmLight) that could support all platforms, for scenarios simple and complex (depending on the platform) for navigation, menus, good old regions, module injection, etc that will be awesome, so much knowledge, work and many lessons learnt we had with WPF, Silverlight, Xamarin, Avalonia, etc, etc and all the frameworks that have been created to support them.

[glyad]

Have you seen https://github.com/AvaloniaUI/Avalonia ?

I just want to explain, why I can't like your proposal with Avalonia.

1. Your advertisement is off topic, since we are discussing WPF here.
2. The AvaloniaUI is pretty nice project, great work, but...
3. AvaloniaUI lacks compatablity with WPF framework;
4. it's simply impossible to compile WPF-based sources (excluding platform dependend code) with Avalonia
5. it hasn't support from UI control vendors;
6. etc...

Let's think together, how to reanimate really great framework, which serves thousands of serious projects perfectly, and do not vaste community resources with to develop another Xamarin, or Silverlight, or UWP, or something another.

[ebugusey]

It's an open source project. You can fork it and do with it whatever you want.
If dev team doesn't want to support some other platform it's in their right to do so. Because being cross-platform is not easy, especially for UI components.

[the-black-wolf]

I have found AvaloniaUI (avaloniaui.net) to be a good cross-platform WPF alternative. There are some minor differences, but are easy to work eith if you know then IMO.

@minecraftchest1 I agree. But once you commit to Avalonia you are effectively in it for the full run. Which is not a bad thing, I would do it in a heartbeat and leave MS to keep its PresentationNative_cor3.dll secrets. But the problem with Avalonia is that it lacks professional grade composite controls. For example, we rely heavily on Infragistics suite to provide advanced UIx interaction with users. No such thing exists in Avalonia world, at least it didnt the last time we checked, we would have to invest heavily in building custom controls and that is very tedious and time consuming effort, best left to companies such as Telerik, DevExpress or Infragistics who are already experienced and already have a complete code base for WPF to port from.
Even the example in this thread, that 3D designer or whatever it is showcased by @kekekeks, I am like 99.999% sure the 3D scene is not part of Avalonia and that it was custom built by them and was just provided with buffer to work off of (while scene is integrated from OpenGL or Vulkan directly). I love the idea of Avalonia, but I think this might be a time for them to open some discussions with the big three control makers and try to get them onboard, maybe their windows dependencies are not so strong as everyone seems to believe.

[Ruedii]

As a note, GTKSharp does look very good on Windows if you just have the decency to ship a default skin to be used in the absence of an OS provided one.

That said, asking people to ship a skin with their application has never worked. Just look at what that did for Java.

[zezba9000]

What about funding a cross-platform strong-typed XAML UI with a source-open approach (similar to UE4).
In that its open-source and free for open-source projects but requires a subscription or something if its used commercially to fund its development.

I'm just wondering if their is a way to kick-start something. UI portability thats write once run everywhere has been an issue with C# dev since forever. MS will never offer a solution for this & other solutions have questionable longevity foundations.

[rufw91]

WPF is the best UI framework of all, from all vendors, by a long shot. It's the biggest jewel in Desktop tech crown. It's a shame it does not receive the attention it deserves.

Absolutely, I have used WPF in all my desktop applications and the look stunning, render super fast and require less UI designing and coding than other stacks to achieve good quality.

[xyun52]

In fact, only "Silverlight" is enough. I hope to restart the "Silverlight" desktop application

[the-black-wolf]

In fact, only "Silverlight" is enough.

No, actually its not. Silverlight is a reduced sandbox version of WPF used for embedded browser apps, whose closest competing technology is the now deprecated Adobe Flash (which was the main reason it became so popular among the poor devs who chose to trust MS and dove into it only to be left high and dry). It wasn't even compatible with WPF libraries or resources, we effectively had to maintain two code bases, same as we do now with web and desktop. But even for web, with the advent of web assemblies Silverlight further became entombed, which is again shame, because I think Silverlight could have been offered as industry standard instead of web assemblies, for that purpose it was way better. But, HTML prevailed and MS said something like Silverlight is not needed (which the mere existence of web assemblies proves wrong). Either way, Silverlight is no better solution for desktop than the bloated Electron is.

[AZ-X]

In fact, only "Silverlight" is enough. I hope to restart the "Silverlight" desktop application

I don't think so and perhaps we won't think so.

[tqk2811]

Just like @dotMorten says, we are not taking cross-platform implementations, per our Contributor Guide.

We look forward to many contributions to WPF. This request is out of scope for the project.

From a technical standpoint, WPF depends on multiple Windows components: D3D (DirectX), DWrite, User32, GDI+, WISP (Touch), and several others (including Windows Runtime dependencies). The interaction with these components is complex, critical and not architected with cross-platform in mind. As a result, our focus is on completing open source of WPF and bringing it to parity with .NET Framework.

I am closing this issue as a result.

Just drop directx and using opengl, remove/replace/revamp some window feature User32 GDI+

[the-black-wolf]

@tqk2811 Just drop directx and using opengl, remove/replace/revamp some window feature User32 GDI+

Lol, you answered him like you actually believed his answer. His answer is on par with the old Visual Studio BS, "we keep VS 32bit because its faster than 64bit because, you know, cache cohesion". Lol. And now we finally have VS 2022, and I am suffocating under its slowness 😆 . The problem is they think us all slow and uneducated so that we'll believe such feeble explanations devoid of engineering reason, and what's even sadder it actually passes with some people.
Of course its not a showstopper to port this to Linux and Mac, people are ready to do it, do not even need MS help, and have been offering them patches which they refuse to a point of actually dismissing them through contribution rules and keeping critical components out of open-source to prevent functional forks, hiding behind legal dubiousness of reverse engineering. Architecturally, there is no problem in rendering XAML on any platform, as is proven by Avalonia. The interaction is complex indeed, but not undoable, there is just no will. So, scrap that answer and replace with "We do not want WPF on Linux because it makes Windows looks bad as LoB platform, but we want to appear young and hip and in touch with times, so we have the 'open source' (tm), but open source 'our way'. We welcome all your invested time into improving WPF for Windows so we do not have to pay people to do it, but as far as you accept Windows is the only support platform".
There is a definite schism of what MS crowd thinks open source is and what the rest of the industry thinks it is. For MS, open source obviously means "reference source" + "free labor".

[minecraftchest1]

@tqk2811 Just drop directx and using opengl, remove/replace/revamp some window feature User32 GDI+

Lol, you answered him like you actually believed his answer. His answer is on par with the old Visual Studio BS, "we keep VS 32bit because its faster than 64bit because, you know, cache cohesion". Lol. And now we finally have VS 2022, and I am suffocating under its slowness 😆 . The problem is they think us all slow and uneducated so that we'll believe such feeble explanations devoid of engineering reason, and what's even sadder it actually passes with some people.
Of course its not a showstopper to port this to Linux and Mac, people are ready to do it, do not even need MS help, and have been offering them patches which they refuse to a point of actually dismissing them through contribution rules and keeping critical components out of open-source to prevent functional forks, hiding behind legal dubiousness of reverse engineering. Architecturally, there is no problem in rendering XAML on any platform, as is proven by Avalonia. The interaction is complex indeed, but not undoable, there is just no will. So, scrap that answer and replace with "We do not want WPF on Linux because it makes Windows looks bad as LoB platform, but we want to appear young and hip and in touch with times, so we have the 'open source' (tm), but open source 'our way'. We welcome all your invested time into improving WPF for Windows so we do not have to pay people to do it, but as far as you accept Windows is the only support platform".
There is a definite schism of what MS crowd thinks open source is and what the rest of the industry thinks it is. For MS, open source obviously means "reference source" + "free labor".

This is why I stopped using edge. M$ changed a feature, and half the userbase blew up the comments with complaints.

[madewokherd]

Anyone can fork the project and work on this. It's a matter of someone driving and maintaining that fork. Wine and wine-mono have replacements for all the "critical" closed source components, so that's not an issue, but of course those replacements target Win32 right now.

MS doesn't believe it's worth their time and effort to do this port, or to maintain it. That is a completely reasonable business decision. Being open source doesn't mean you have to provide a home for anything people want to do with your project, just that the licensing allows it.

[the-black-wolf]

Anyone can fork the project and work on this. It's a matter of someone driving and maintaining that fork. Wine and wine-mono have replacements for all the "critical" closed source components, so that's not an issue, but of course those replacements target Win32 right now.

Nope, is actually more complicated than that. There is the whole issue with PresentationNative_* and a few other libraries. You can fork it on windows and work on it, because the required blobs were licensed for windows and thus accessible to you, but not on Linux, not even with wine which does not have required libraries. Even running WPF on wine results in a terrible performance. The devil is in the details. Plus, why should we have to resort to wine to begin with if this is indeed open source? Besides, there is a whole other aspect of mono here which concerns MS official declaration of Mono being covered by Community Promise, which is not automatically extended to everyone. Me (the proverbial me, meaning anyone not directly mentioned by MCP) touching the PresentationNative or any other Windows-license-covered proprietary library to port it to Linux might very well land "me" in hot water, and nobody really wants that hassle.

MS doesn't believe it's worth their time and effort to do this port, or to maintain it. That is a completely reasonable business decision. Being open source doesn't mean you have to provide a home for anything people want to do with your project, just that the licensing allows it.

Nope, that the MS kool-aid flavor of open source, imho a very insidious attempt to establish and redefine rules in an already mature arena. Its quite known what an accepted form of "open source" is. Its defined here: https://opensource.org/docs/osd. Namely WPF project is in gross breach of items 8 and 10, and somewhat in 6 (though this could be argued against). Open source is not just access to source if you are on a non-MS platform, that is a "reference source" license. Like you used to have for Windows or Office back in the day if you were a partner, or willing to NDA yourself or sacrifice a chicken, I can't even remember what was required before to have access to holy windows code. You can tweak your license away from accepted norm without breaching it or monopolize access to main repository to repress development paths though shunning or formal contribution rules, include API protected proprietary libraries, and all sorts of other things that would make it legal and prevent judicial action, but its not really open source. If I cannot fork this repo on Linux and replace dependencies with documented alternatives, even if I have to build them myself from scratch (as you said, not wanting to invest company time in something not seen useful is a valid and reasonable business decision and we agree on that), and then use it on that platform, its not really open source. Its some exclusionary zombie version of it.
TL;DR: Not wanting to make a port, cool. Not wanting to maintain a port, cool, its a specific type of move (not named for community standard reasons), but still cool. Passively-aggressively preventing a port from happening, not cool. For further reading and empty apologies, check #2554.

[madewokherd]

On Wine we replace PresentationNative using https://github.com/madewokherd/wpf/tree/main/PresentationNative and https://github.com/madewokherd/wpf/tree/main/src/Microsoft.DotNet.Wpf/src/PresentationCore/Managed/TextFormatting, so yes we do have a replacement for that.

[the-black-wolf]

Cool. That means we are ready, or better said you are ready. So lets move a step further. Because running WPF under wine is not a linux port, its a windows port under wine. I hope you appreciate the difference, as well as a state where a Linux crew would not like employees to have wine on their workstations for variety of reasons, not least not having to deal with BSA types.

But if you have everything ready in wine/mono and you are covered nicely by MCP, why not do us all a favor in Linux community? Fork WPF, inject relevant parts from mono and produce and publish linux-64 and osx-64 builds. You'll become my new favorite person of October 2021.

[madewokherd]

Most of the native components won't currently build for Linux (the exception being Unicode classification tables in PresentationNative), while the managed parts will build but not run. WpfGfx needs to be built in clang for some msvc compatibility stuff, and parts depending on win32 need to be made conditional and/or we'll need native replacements for win32 libraries.

So I guess I could get that started and provide a home for it, but I couldn't drive the majority of the effort to make a port. I'm worried it'll just fizzle out due to lack of interest. But if there really are enough people willing to do the work, and they just need a home for it, it'd be worth the effort for me.

[the-black-wolf]

I could join the project in spring, until then, I am tied in my current contract. I am sure people who initially sent refused linux patches would show an interest. Linux definitely needs something like WPF to liven the Qt/GTK scene, so I think its a matter of getting people more interested, currently they are shunning the tech due to mistrust.
Win32 part should initially be replaceable by appropriate shims from wine, no? (again, its been too long since I looked at wine code, but this stands to reason, applicability depending on the size). Ultimately if you have PN pegged, even at reduced performance, code exists which should be a sufficiently stable starting point from which to a) first introduce dxvk and then move to native vulkan and b) drastically reduce win32 imported wine footprint to only what is needed and consolidating into few portable libraries. Once native part is covered, managed part should just start working. But that's not the biggest problem, imho, thats just a tech problem which can be solved in tech manner. What worries me most is MS starting to send cease & desists. This project can only happen under the roof of an outfit that already has explicit MCP. Without that, the mistrust will continue. I do not know what your capacity is in wine/wine-mono, but if you are all ready to give this a chance, something might just happen.

Btw, something else intrigues me as well, the claim you made about having a replacement in wine/wine-mono for PresentationNative. I cannot seem to correlate that claim with the link you sent. PN has almost 200 native function it exports to managed WPF via P/I (exports), and yet I do not see anything correlating to those functions in your repo. How exactly did you implement PN in wine-mono?

[rufw91]

Haha "that's the MS kool-aid flavor of open source"

[madewokherd]

We can't load Wine code into a process that's not started by wineloader. Any libraries we need from Wine would have to be ported to native Linux APIs before we can use them.

PresentationNative isn't fully replaced, but most of the replacement is in the other link. The primary user of PresentationNative is MS.Internal.TextFormatting. I chose to replace those parts on the managed side instead, as the API provided by PresentationNative seemed to be more complex than needed.

The TextFormatting replacement is not complete, and the parts used by System.Windows.Documents are still unimplemented.

[darkdragon-001]

Will WPF work in WSL when Microsoft exposes DirectX APIs in the Linux kernel / Mesa?

[the-black-wolf]

Will WPF work in WSL when Microsoft exposes DirectX APIs in the Linux kernel / Mesa?

If you are referring to Microsoft's EEE implementation of vGPU/DX that they are trying to push into kernel, don't get your hopes up just yet. Linux team will not allow either to go into graphics section of Linux kernel until its fully open sourced and thus usable on all Linux distributions and not only on WSL. And they shouldn't allow them, WSL is bad enough EEE push against Linux without making it easy for MS to subjugate it further. Technically, if they fix some issues they could get the vGPU into hyperv section of the kernel (so in /drivers/hv and not /drivers/gpu), which was specifically created to allow MS to run Linux under HyperV (and by extension under a hidden HyperV called WSL2), and that would be fine. But getting DirectX into Linux, so that it can only work on WSL? Hell, no, that would mean that any software made for "Linux" under WSL would only run under WSL and not under any other bare-metal Linux distro. Linus and the rest of the Linux community would really have to be stupid to allow that. Your question pretty much summarizes the EEE effect WSL already has on Linux, allowing you to usurp hard work of thousands of people contributing to Linux without actually taking a time to learn how to use Linux, and thus helping MS maintain desktop market dominance.
If you wonder why there is so much resentment and distrust towards MS, it would be this example, and what goes on here in WPF with active repression against porting to Linux, its just part of a wider agenda. People are generally very annoyed at the way MS considers and abuses open source and open source licenses as free labor to usurp without giving anything back to community it poached from, and even when they post something its always a self-serving push. But that is a wider topic.

TL;DR No, even if MS manages to push this into kernel, and DX is not a crippled version geared towards ML use only, WPF would not work under it as its still missing a lot of "glue" proprietary code that connects WPF visual tree with DX.

[GitClickOk]

WPF is the best UI framework of all, from all vendors, by a long shot. It's the biggest jewel in Desktop tech crown. It's a shame it does not receive the attention it deserves.

@popcatalin81 I think the same! But I stopped thinking in WPF because of Avalonia. It is simply the evolution we expected and never received from MS. I recommend you read all these docs and I dare you to find one reason to don't use it instead of WPF.

[the-black-wolf]

@GitClickOk I recommend you read all these docs and I dare you to find one reason to don't use it instead of WPF.

Sadly, third party libraries. We have essentially given up on WPF on Linux and already ported a lot of things to Avalonia, but we inherited a ton of LoBs and they are all functionally dependent on Infragistics (mostly advanced grid scenarios and charting). Switching to vanilla would not be met with welcome and would do more harm than good in Linux workstation conversion in terms of human adoption, and we simply do not have the time nor the desire (nor probably sufficient skill) to become a new Infragistcs for Avalonia . They, and other 3rd party makers we could port to without losing functionality, simply do not support Avalonia nor do they have any plans to do so (that we know of). As I said here, and everywhere else, the Avalonia team has made a very good and stable commercial grade product, its time for the head team to leave the grease pit and start promoting, including getting at least one of the top commercial component makers onboard.

[glyad]

WPF is the best UI framework of all, from all vendors, by a long shot. It's the biggest jewel in Desktop tech crown. It's a shame it does not receive the attention it deserves.

@popcatalin81 I think the same! But I stopped thinking in WPF because of Avalonia. It is simply the evolution we expected and never received from MS. I recommend you read all these docs and I dare you to find one reason to don't use it instead of WPF.

I appreciate the excellent work of Avalonia developers, but Avalonia isn't WPF, WPF != Avalonia, and the thread isn't about Avalonia, but about to make WPF cross-platform. Probably in future, when I'll be able to run any WPF based project on Avalonia runtime without to port the code, I will advocate Avalonia, but not now...

Please stop to advertise Avalonia here!

[the-black-wolf]

Please stop to advertise Avalonia here!

@glyad People come here expecting a solution for their need (cross platform WPF). Which will never happen, not because its impossible, but because MS wants to corner this specific segment of the market. So we help people by advocating a viable solution for their problem, I don't see your problem with it, this thread is dead for its intended purpose anyway, its not like we are preventing cross platform WPF by going off a narrow topic.
Btw, there is no future in which you will be able to run WPF project on Avalonia without porting because Avalonia does not use the same styling mechanisms thus a port would always be required. So, I guess you will never advocate Avalonia...

[JakeSays]

@GitClickOk The reason to not use avalonia is painfully obvious: none of my existing wpf code will run on it, nor will any of the 3rd party wpf libraries I use.

[GitClickOk]

@JakeSays and @glyad. If someone is starting something new and doesn't rely on any 3rd party libraries Avalonia will be perfect and it is highly recommended instead of WPF, with great advantages like Android, iOS and WASM support. If you have something old, does not matter what you choose, you will get some pain in upgrading and conversion.

WPF is amazing and lives in my heart, but MS does not care and it will not evolve anymore. If we want the spirit of WPF to go on, we as a community should support alternatives. I don't see MS or 3rd party like Infragistics as villains, they just don't see demand, market works like that. I think we should be more proactive and independent here.

[JakeSays]

@GitClickOk "pain in upgrading" of course - there's always pain, but avalonia does nothing to protect investment in existing code. they made a conscious decision to not be wpf compatible, so there isn't much of a compelling reason to choose avalonia over something else.

[ShalokShalom]

That this thread is commented on 3 years and literally over 300 posts after it got closed, does say something about it all.

I suspect that this decision is done more in isolation and without the awareness of higher level executives, since the rest of the Microsoft developer oriented toolkits get ported and receive much more affection to go cross platform.

How scientifically correct is the statement, that this can't be ported?

[handicraftsman]

@ShalokShalom everything can be ported.
It's just a matter of effort, and MS did everything to vendor lock WPF on Windows platform.