Will the windows only library get open sourced too?


no every tick doesn’t “lead to megawatts”, let’s not start with exageration, and a larger Framework doesn’t mean more power consumption, unused code sitting on your disk doesn’t automagically consume cpu time / power.

Yes smaller frameworks make sense for smaller devices but we already have compact and micro for different sizes, i just don’t see the point in a “core” one removing key features just to use on hosting where the full .net does the job and having yet another .net just adds more choice / maintenance.


Even if Windows only, it would be great if WPF was open-sourced:

  • ability to trace and understand behaviors/internals better
  • easily find and fix bugs
  • add new features
  • ports to other platforms could be done by community, no need for Microsoft to do it.

I can’t agree more. Becoming cross-platform doesn’t have to be the only reason to open source code.

There are a lot of things that are internal in WPF with absolutely no extensibility point. It’s in this internal code that most current problems are located. Personally, I’d love to play with this internal code and potentially submit patches.

Moreover, if open sourcing WPF could mean talking publicly with the team inside Microsoft, that’s already a major benefit even if no contributions are made! (You can find comments in the current reference source about some public API missing because “management considered this undesirable”. Is this stil undesirable? Only a project coordinator can answer.)


In math there is simple operation called sum, so not every single tick leads to MegaWatts, but sum over all devices, servers, virtual machine instances does. Ditto. There is even more complex math operation called integral and if you integrate all those devices over time (day, week, month) it for sure leads to MegaWatts. Ditto. This is not exaggeration. Today’s datacentres consume energy for about midsize city (US measuers) or smaller conutry (3-10 M inhabitans) and this gets bigger from day to day. And according to all forecasts this increase will continue for years. This is not exaggeration - this is the fact.

Just loading into memory unnecessary data w/o processing it - tekes processor cycles and those need energy. Sum over all devices simply gets big.

I haven’t seen cloud pricing where price is bound to processor percentage or number of ticks - usually this is traffic (in Azure download), so this is the place where Microsoft can reduce price and/or increase it’s revenue. And this is logical move by Microsoft.

If you look at project.json in ASP.net 5 (vNext) some people will define runtime as “.net45” and will get N assemblies which will be equivalent to “old framework” and other people will enumerate M assemblies - assembly by assembly which they need and nothing more. If M < N the second group will get faster load times, smaller memory footprint etc.

So those “smaller” frameworks are not smaller - they are modular this is what Microsoft is doing, nothing more. Believe me you will be able to use classic framework for years, Microsoft will take care of backward compatibility, but will not hinder people that want to accept new tech. Besides what is wrong with freedom of choice? I heard nothing about killing classic .net framework au contraire, classic framework is read only - no pull requests will be accepted - just not to break backward compatibility.

.net core is not removing anything. This will be core and you can add whatever you want.

Miguel pointed out “Stop Energy” syndrome and it seems like I’ve seen one here.


The condescending remarks about basic math doesn’t change the truth and is certainly not needed to back it.

.NET is already modular and having more assemblies on disk doesn’t ammount to more assemblies in memory if they aren’t needed.

I’m certainly not on the stop energy side, but more frameworks means more ressources diverted to maintining more builds / versions means less time spend actually producing features. It’s a matter of tradeoffs and i don’t see the need for a ton of versions. This seems like the same thing as full vs client Framework, you’re only saving a few mb of disk/network initial download, aside from missing features you don’t “save” anything else.

I’m all for going forward, this doesn’t happen by diverting ressources into more versions of the same things than strictly needed but by moving each version forward, unless you have unlimited Manpower to work on .net, this seems like a waste.


IMO, having WPF open sourced for cross platform doesn’t make sense. A Desktop application is by principle very tightly coupled to OS, As @migueldeicaza mention, Client wants native components on each platform and this is not so easy to achieve ( Java tried two approaches with AWT & Swing, and they somehow failed ).

But, the real value added is definitely allowing every single dev to create PR and add features that microsoft will not do because they are now focused on WinRT (despite of the recent WPF Roadmap ).


System.Web is a good counter-example to this, you get WebForms in your memory even if you just wanted to use MVC.

The big difference with .NET Core is that the packages are much more fine-grained, shipped via NuGet and you can include the runtime as part of your app (solving the “we can’t use .NET 4.5 because it may break <legacy app> on the same machine” problem). I agree the Client Framework wasn’t a great idea, but .NET Core is completely different :slight_smile:

To get the thread on-topic again: I’d also like to see WPF, WinForms, etc. open-sourced too, even if it’s just to see and learn how they did various things.


Not all clients want native components on each Platform no, i definately don’t want that, i do want a good UI that would work on all platforms, WPF is a good UI, can skin it how you want if Platform look matters to you. I’d definately be happy with a single UI with single view and maybe some auto (size based) layout adjustments for all Platform leading to a single exe targeting no native UI anywhere, just wpf everywhere.


Basic math remark was necessary to point out the truth about energy consumption problem in Datacentres and the fact that I was not exaggerating as you stated.

Like @akoeplinger already stated classic .net framework was not modular, because there was no need for that.

Currently the team/project that uses .net core is the ASP.net vNext team and there are plenty resources whre they explain why they have taken this approach copying good ideas from other technologies like node.js and it’s npm package manager. And they still have classic framework for those reluctant to use core framework.

OK. You have 2 options:

  1. HTML, CSS, javascript
  2. java

This is almost impossible to achieve. Java technology tried and failed - it did not look good on all platforms. HTML, CSS, JS combination proved the same - the biggest players in mobile world turned back to native from this combination.

Xamarin (mono) team worked cross-platfrom .net for 14-15 years and they realised that this almost impossible to achieve - cross platform UI that looks nice on all platforms.

Xamarin.Forms are for line of business (enterprise apps) where function is more important than form (look and feel), but it helps you to hit 3 platforms really fast, to develop proof-of-concepts and when you need “UI that looks good” you’ll need to invest a lot of time and knowledge.

All xplat frameworks are some kind of abstraction which remove some functionality to achieve portability - it is tradeoff.

WPF on non-windows platforms? I would like to see it too, but this is not that easy. WPF is very platform specific (DirectX). Check what C++ team had to say on Connect(); last week about open sourcing DirectX and embracing OpenGL. Both - not excluded, but not likely - yet.

Some people went this road and did not come too far. This seems like a nice dream at this moment.


No the silly math remark was useless, i was pointing you’re just wrong on the orders of magnitude and you replied wrongly (basic troll level answer, i don’t understand the comment so i’ll assume the person commenting doesn’t understand the subject). I perfectly see the economy of scale there, and i still think you’re grossly overestimating it, just as i did at the start, i didn’t need to learn how to add 1 and 1 from you to figure it out thanks. Since you taught me addition i’ll teach you division, you can add 1 virtual dollar 1 000 000 times, it’s still going to be a tiny amount of money if each of those virtual dollars is Worth 0.00000000000000000000001 cent. You don’t need to add anything but only to figure out the % gain, if you’re saving 1 cycle per second, you’ve saved about 1 / 3 000 000 00 of your cpu time, which is also only a fraction of your machine’s power. The savings are meaningless so it’s either quite a bit more than that saved, or other reasons to push this (modularity can have other uses than power saving).

I see nothing wrong with a modular .net, i just see something wrong with “more Frameworks”, i’d be plenty fine if it was a replacement, i just hate to see issues in the Framework / language untreated due to “lack of time and ressources” and more of it diverted to alternatives. It also doesn’t have the upside of the current .net which is tiny by today’s standards (a core os Framework at 200MB is hardly a problem, we have GAMES that are 50GB in size!) that is to know that everything is available on every machine. As a dev i like to know there will be 0 prerequisite / installation issue on a modern Windows version if i target a .net version on which it comes preinstalled for example.

Java didn’t try and fail, for that matter java managed pretty good before .net came, and i also don’t remember it tried to do anything like wpf, just cater to classical LoB apps. HTML CSS and js proved a good alternative because java looked just as bad as they do, they’re all primitive UI compared to WPF.

It doesn’t HAVE to be a tradeoff, as i said open sourcing WPF and porting it to support OpenGL just removes the tradeoff, you get the real wpf, binary compatible, as is , on all platforms, that would be a massive step up in UI tech and there’s no question about the looks that can be achieved as we already know what WPF can do. Add the maturity of WPF on top as a nice bonus feature too.

WPF on non Windows could work just fine, just make an OpenGL backend instead of directx one just like most game engines support multiple renderers. And wpf doesn’t “look like Windows”, it looks like you gave a designer a canva and he could do what he wanted, which is just what i want in a UI tech, not something that looks like the target Platform, but something i can make look as i wish.


In a sense you are right, XAML ( not WPF ) might be a portable UI Description Language (Java didn’t have such things, but firefox tried with XUL ). Maybe Silverlight is more easy to port to other OS, as it was ( let’s say ) “by design” more portable than WPF :-).

BTW, the good new is : We all agree that MS should outsourced WPF ! And every one can try new stuff on it ( port WPF to other platform, fix bug, etc.) ! isn’t the goal in the end ?

So let’s push for this, if possible.


To give some information about the parts of wpf that are dependent on windows, it uses win32 event loop and handle to window (hwnd)and nothing more from win32, which is already implemented by mono for winforms, then it renders everything using an api built on top of directx,this api sits in the milcore.dll a native shared library, wpf controls are not win32 controls, everything except for the main window is rendered by wpf itself, using its own renderer which is built using an api in milcore.dll which is build on top of directx, directx 9 to be specific. Now if microsoft open sourced wpf one will have to implement alternative to milcore build on top of opengl maybe or any other graphics system. Which is not easy but not that difficult too.
So the argument that people want native controls or UI dies here, because no one would have adopted wpf in the first place because it emulates native controls means they look and feel like native but they are simply not native.

But still i think it is not going to be open sourced main reason is milcore.dll

milcore.dll is major part of windows and since windows vista it is used for everthing UI in windows the old legacy gdi and gdi+ is supported only for legacy apps.And to add more millcore’s api is not public, if microsoft is to open source wpf they will have to atleast make the milcore’s api public too, which is i am afraid not going to happen, because microsft simply do not want us to use milcore’s api even on windows let alone cross platform probably because they are too low level, i do not know the reason.

Their are people who have reverse engineered the milcore ant they say it is not complex and it has a small set of api’s.


ehm, and Mouse and Keyboard and Keyboard Layouts (based on Culture) and Sound stuff and probably much more, which I don’t remember right now. :smile:


Mouse and keyboard is already in what he stated (event loop), i don’t see how sound is relevant in wpf, culture is already a .net concept so no there too. WPF is very un tied to win32 compared to something that would be more “Windows ish” as none of it’s look comes from the OS itself, it’s all WPF itself.


mouse and keyboard is covered in event loop which is already implemented in mono winforms,And sound is in milcore using direct audio milcore is short for media integration layer core. so media includes both sound and visuals, but most of the people do not care about sound in wpf. Look up in mono source code on github, the native parts of WindowsBase.dll are already done, WindowsBase.dll uses win32 HWND handle and event loop which is already done in mono’s WindowsBase.dll, now other two major assemblies , PresentationCore.dll and PresentationFramework.dll needs to be implemented. among these two PresentationCore.dll uses milcore’s api and to be more specefic, Visual and Visual3d are two classes among all that uses the milcore api and work as basis for the wpf rendering system. PresentationFramework is all managed,PresenationFramework.Aero.dll is also all managed. So if wpf were to be open source one will need implement the milcore’s api used by Visual and Visual3d , Visual was implemented by xamarin using cairo and opengl for moonlight which was all native and Visual3d was not needed for moonlight, By all this i mean this is not difficult for the community to implement the missing pieces of wpf if it was to be open source but again the problem is not this, the problem is those missing peaces or one of those missing peaces is core part of windows.


OK fair enough bout mouse and keyboard, if you count it in event loop. I see in WPF code that Mouse and Keyboard device are lil bit more complicated than that, but let’s settle on that for now. SoundPlayerAction (trigger) is actually using winmm.dll to play sounds. There are many other unmanaged dll’s used in WPF afaik.

BTW I never said it’s bad idea to make it open source, just pointing out it’s not “copy/paste/use mono easy” task. :slight_smile:


No one said it’s copy/paste/use easy, but it was getting overestimated a lot, it requires some porting work but a lot of the feature set doesn’t require unmanaged code, for example SoundPlayerAction, how often is this used? How often is this critical? How many other UI Framework support “sound” which isn’t a UI concept? I think porting WPF without that is fairly good already. And really if you’re abstracting the rendering engine abstracting the sound too is a very small task in comparison.

There is work to do to get WPF to be cross-platformable, but it’s not “that” big compared to porting something that would be a lot more tied into the OS nor compared to having to write for, if i may say, “lesser” UI solutions simply giving you a few controls but not an actual HW accelered UI Framework where you can do well, pretty much what you want.

For even a midsize application it may be more cost effective to port WPF to a second Platform than to support 2 platforms the traditional way, so i’m sure we’ll find takers to port it if it’s open sourced, i certainly will participate.


Yes you are correct SoundPlayerAction(trigger) uses a class SoundPlayer which uses win32 internally. But you know what is intresting ??? SoundPlayer is already implemented in mono. have a look please

and if you look in the System.Media in mono all the things are related to win32 related sounds.
Yes it will not be copy/paste/copy/paste thing to implement it , it is an entire gui system and a very fine one too. But most of its missing pieces are already done and it is not as tightly coupled with windows as winforms is.


Whether or not WPF goes cross-platform is less of a concern to me than whether it becomes open-source.

Certain circular memory references (and the severe corresponding leaks) took over 3 years to be fixed.

We need pull requests on WPF, ASAP.


This post was flagged by the community and is temporarily hidden.


This makes absolutely no sense, everyone has a clear view in this thread of what it requires to port it and you come here out of the blue claiming no one can do it (while people with a very good knowledge of it stated the contrary) out of the blue without any arguments. Are you just there to promote a solution?

.NET Foundation Website | Blog | Projects | Code of Conduct