"We will typically not accept contributions that implement support for an OS-specific technolology on another operating system. . . We also do not intend to accept contributions that provide cross-platform implementations for Windows Forms or WPF."
Microsoft seems to be actually refusing to accept contributions that could make WPF cross-platform - it's a bit beyond "no official plans for cross platform".
Not to be overly cynical, but this is kind of obvious: that means your contributions really only benefit Microsoft in the long run. Sure you might derive benefit, but Microsoft is the real beneficiary here, and they don’t even have any obligation to pay you.
PyQT can be considered a reasonable (and in many ways superior) alternative to WinForms but what about WPF? Is there a modern cross-platform non-browser declarative 2-way-binding MVVM desktop GUI toolkit? I use PyQT mysef but I really wish I could use binding instead of just handling events manually.
Open source doesn't mean open development and liability & commitments. They are different things.
I actually think MS did a great job by saying that. The purpose is to literally make the source public but they don't have resources to make a long commitment. Then it's better to not say it clearly and later got accused as not well performing.
> Open source doesn't mean open development and liability & commitments.
Right. We are stating up-front what we intend to achieve. We will sart with making WPF on .NET Core have parity with .NET Framework and then expand from there. We'll stick to Windows as the OS for the project.
> The purpose is to literally make the source public but they don't have resources to make a long commitment.
We are not saying that. We intend to continue working on WPF. In fact, we are talking about moving some of Microsoft's 1st-party apps to WPF on .NET Core, just like how we're moving 1st-party web sites/services to ASP.NET Core and .NET Core. Same playbook.
Right, by releasing the code they're saying "here's some nice code, do what you want with it", but not "oh and we're increasing our investment into this product by expanding the team" which is what adding non-Windows support to their official repository would entail.
Exactly. I think MS is a doing a gesture job to showcase their code, but they are not open sourcing the roadmap to the community, which is fine by me actually.
Nobody should be submitting pull requests for cross-platform support into WPF's main Windows repository. Instead they should branch WPF, make a platform specific version (e.g. WPF-Linux, WPF-MacOS, etc), and submit pull requests upstream that are platform agnostic (e.g. bug fixes).
It's very efficient for Microsoft. Evaluating pull requests for a different OS requires entirely different QA. At the end of the day, it's open source. Fork it.
You cannot contrast a Windows specific piece of code like WPF with projects that were created with original cross-platform support like .Net Core, it is an apples and oranges comparison.
If they were starting WPF again today they might create an agnostic master, which has a Windows specific branch. But they aren't restarting WPF, they're just open sourcing what they already have.
The difference is that with .NET Core they are committed to providing support for the cross platform implementation. With WPF they don't want to provide any official support or the idea that they might, so they're leaving the implementation up to 3rd parties that would be responsible for keeping the whole system working with any upstream changes.
They don’t intend these to be cross platform, so what they do with cross platform work isn’t really the issue.
Suppose someone came up with .NET bindings for MacOS GUI controls, or Gnome. Would you expect a Microsoft to adopt those into .Net Core?
MicroSoft have two roles here. On the one hand they are the custodians of the cross platform .NET Core system. In the second role they are the Windows platform owner and provider of .NET bindings for some platform specific features.
If you decide to contribute to .NET Core, you join them in the first effort. If you come up with Gnome bindings or such, you are in the latter role but just because you are creating those bindings you’re under no obligation to port Gnome to Windows or anywhere else. Bindings for existing platform specific features are clearly in a separate category from shared cross platform features.
Supporting cross-platform WPF (or WinForms) at this point would be a terrible idea for Microsoft.
These frameworks have been around for many years, and many (if not most) of the applications built on those frameworks make heavy use of third-party control libraries. Those libraries, whether open source or propriety, often include at least some win32-specific interop code that has also been around for many years. Most of those libraries are now in “maintenance only” mode, if they’re even being maintained at all. Realistically, most Windows GUI applications built on .NET will never run on any platform other than Windows, even if the core UI frameworks become cross-platform.
As soon as Microsoft says, “WPF is cross-platform now”, they’d get flooded with bug reports that aren’t even related to their code.
Wow, someone who makes sense for once. I love and embrace open source but I'm sure as glue that the developers who want cross platform winforms and wpf will never use it.
I agree. My thinking is that the only place where any desktop app is still actively developed is the enterprise (and even there the trend is to get everything web based), and this is predominantly a windows environment. Outside of the enterprise everything has gone mobile where wpf isn't really an option (solutions like Xamarin aren't fun to use).
My guess is that desktop apps will come back with pwa+wasm. Then you can have a rich client that is fully cross platform, single code base, same behavior everywhere, easy to deploy, written in the language of your choice. But that doesn't involve wpf...
How are they supposed to evaluate such contributions? They would need to set it up in their CI, know details about those platforms, etc. What if the first contributor uses X11 apis and then somebody else wants to use Wayland, another wants to use (whatever hardware accelerated graphics API)... are they to reject everybody who wasn't first?
Theoretically you can still get WPF running on another OS, but you'd have to do it the same way that WSL gets an Ubuntu userland running on Linux: You introduce a compatibility layer that it runs on top of.
I think I'd prefer that approach, anyway - I'd guess it's cleaner and ultimately more maintainable than introducing a whole bunch of conditional logic for handling all the cross-platform issues into an already complicated piece of software.
> it's a framework with explicit goals of being cross-platform
where did they notate their goals for wpf and winforms to be cross-platform? they specifically mentioned they open-sourced them to open up windows development.
If they gave people the illusion that they could make WPF cross-platform it would mean a lot of wasted time for both Microsoft and the contributors. So it's probably better to remove that illusion right away.
People can always fork and work on it, Microsoft is just sending the message that they won't do any work to incorporate any of it. Open-sourcing something is not an obligation to keep maintaining something.
I don't even know what the appeal of WinForms/WPF is these days. They don't really offer UI controls or a user experience that's better than well-done websites or electron apps.
I guess that this very clear positioning from Microsoft means that there is still room for someone to come up with a XAML UI kit for .NET Core, and name it it CPF (Core Presentation Foundation) instead of WPF (Windows Presentation Foundation).
I understand that the open source WPF can be freely used as a reference from where to borrow a few things.
This project collects usage data and sends it to Microsoft to help improve our products and services. Read Microsoft's privacy statement to learn more.
For more information on telemetry implementation see the developer guide.
It would be nice if we could all agree on a global environment variable to opt-out of all telemetry so we wouldn't have to keep track of the thousands of places to turn it off.
I assume that's a joke :) I agree that Do Not Track and anything that looks like that RFC are useless, but they assume bad actors and includes software that doesn't run on the users machine. What I'm talking about assumes good actors and code running only on the users machine. MS and others already have ways to disable the telemetry, usually, so they want to play nice. With open source software, it's easy enough to check the code is looking at the environment variable and doing the right thing with it. Closed software still shouldn't be trusted, nothing will fix that.
HA! And yet 'Do Not Track' was proposed in 2009 and actually put into practice. Guess they didn't get the joke either :)
What I'm proposing isn't either of those things though. It doesn't rely on just promises of other people. I can see the code I'm compiling and running on my machine and, as long as I don't let anyone else modify it arbitrarily, I can be sure it's doing what the code said. Yes, mistakes happen and sneaky code happens but, for a vendor that actually wants to play nice, too many mistakes or even a single attempt at sneaky code will ruin their reputation.
And, again, I know this won't fix closed source code or malware.
If it was opt-in, all the people who didn’t care either way wouldn’t bother to opt in, because—even if you have ideals suggesting it’d be better if they knew who used what features—satisfying that ideal isn’t worth the effort of finding and checking a box. (See also: the organ donor registry.)
Making something like this opt-in is equivalent to not having it at all. Not just because of how little pick-up there would be on the telemetry, but also because the type of people who would opt in are a skewed sample not representative of the larger user-base they wish to learn about. It’s like the bias introduced by doing an opinion poll by asking people to do a one-hour opinion poll over the phone: you filter out the average person who doesn’t have time to do a one-hour poll, and get responses only from people with too much time on their hands (= unemployed; teenagers pretending to be adults; old people who just want attention; etc.)
"Mass surveillance doesn't yield useful results unless you monitor everybody!"
You're missing the point here. I don't care about the quality of Microsoft's metrics. I care about the privacy of my data.
The results of your arbitrary one hour opinion poll don't mean anything to me. You wanted that data. It doesn't benefit me, as much as you want me to think it does. Infact, if I had the choice between not taking the poll and not having you call me in the first place guess which one I'm gonna pick.
> You're missing the point here. I don't care about the quality of Microsoft's metrics. I care about the privacy of my data.
And Microsoft only cares about the privacy of your data inasmuch as it has to, it DOES care about the quality of its metrics.
> The results of your arbitrary one hour opinion poll don't mean anything to me. You wanted that data. It doesn't benefit me, as much as you want me to think it does. Infact, if I had the choice between not taking the poll and not having you call me in the first place guess which one I'm gonna pick.
Sounds like you want to have your cake and eat it to. There's already global means to opt-out of telemetry data: don't use products that have it. Alternatively you can take the couple of minutes to turn it off yourself.
Seems you think you're entitled to this, which is fine, but that entitlement should be brought to the attention of your government.
My point was that the only useful options are “an opt-out telemetry system” and “no telemetry system.” An opt-in telemetry system is wasted effort from the point of view of gathering results with statistical power.
And no, the people who want opt-out would not generally opt in in an opt-in system. That'd be their preference, yes, but you’re underestimating people’s laziness in practice. There are things I’d grant telemetry access to, but I don’t know how and don’t have time in the day to learn how, especially since it grants very little advantage to me personally.
People keep acting like telemetry is my problem as the end-user. I don't care about your development practices. I don't care about your telemetry. All I care about is if the software works, and my privacy is protected. The problems with getting telemetry data are your problem. The burden should not be on us to have to turn off all this data-gathering to protect my data.
EDIT: The proverbial "you", not you in particular.
> I don't care about your telemetry. All I care about is if the software works
Newsflash: The latter requires the former, especially in large-userbase installations with tons of features.
I say this as a huge defender of privacy: Telemetry is not evil in and of itself and I wish people would give it a rest when it comes to yelling about opt-in telemetry, because it seriously harms the cause in cases where it matters, such as actual transmission of personal data.
Seriously, things like "Do you click the Edit menu a lot" is not useful data to anyone but the devs of the software, for development reasons.
> Newsflash: The latter requires the former, especially in large-userbase installations with tons of features.
The vast majority of computing history argues for exactly the opposite.
In fact, with it's new "all in on telemetry regardless of reputation damage" approach, MS's software often does not work. Clearly MS have taken a wrong approach, and seem completely unwilling to rethink it.
Sorry, but no. I've been using OSS for a few decades now, and often bugfixes are pretty quick. As long as you're ok reporting bugs, and doing some legwork. ;)
You are not everyone; you are in fact the extreme minority. You're exactly the kind of person who should not have a problem unticking an opt-out box.
As I said, please please focus on privacy issues that matter. Trying to be snide about inconsequential telemetry is a waste of time and of public awareness.
You want to complain about Windows 10's privacy practices instead, go ahead, because that is a good example of abusing telemetry and not respecting the user. But sometimes, "telemetry" is just "anonymous UUID + software version sent every 7 days" and people still complain about that. Then those same people will go and complain about the software vendor dropping support for an old version when "users are still using it". Again, newsflash, that's stuff you know because of that tiny bit of telemetry.
I'd highly encourage people complaining about telemetry to do actual devops for a few weeks or something and understand how blind you are without instrumentation.
One does not prevent the other. Companies do talk to their customers but data talks far better and reveals insights that customers themselves don't have.
There's wrong ways to use telemetry, but overall they are positive, especially in large apps where gaining insights on tiny percentages of your userbase is both important and impractical. That does mean Windows, Android, Chrome, Firefox, etc.
It's the same in game dev. You might see through telemetry that 80 percent of your churn is right after one specific quest. Without telemetry, this might not be something you notice, because churn rarely ever talks and when they do they're not accurate.
> ... data talks far better and reveals insights that customers themselves don't have.
I can see how that would be the case for games. They're special purpose one-offs, and aren't tools for getting a job done.
For business applications though, the concept of "data talking far better" than actually talking to customers seems very wrong headed to me.
It's very common for business application users to follow processes that are effectively workarounds for missing or broken functionality in their tool set.
When they're able to communicate with the vendor and describe what they're actually needing to do, the tools can be changed to achieve the desired result properly.
I've never heard of telemetry being able to address "how the tool should be working" rather than sending a stream of data showing what a user did. Maybe good for support issues, but pretty useless for product planning and addressing actual user needs.
Maybe if we got something in exchange for the actual value of our data (say, Microsoft paid us per machine, per user, per hour used) then it would be worth it to opt-in.
> Maybe if we got something in exchange for the actual value of our data (say, Microsoft paid us per machine, per user, per hour used) then it would be worth it to opt-in.
You get something, better software because developers can know what is being used and what it is not, what feature is bugged, etc etc.
Or you get something worse because you happened to be one of the few users of a niche feature that they decided the axe because they optimize for the telemetry data.
> Making something like this opt-in is equivalent to not having it at all.
Microsoft were doing opt-in telemetry in Office, Visual Studio and the .NET framework for a long time, so it must have provided value for them. The installer used to politely ask you to consider opting in to help improve the product.
JetBrains products still follow this approach of respecting the customer and asking politely.
Software that actively nags you at every opportunity to opt in isn’t really “opt-in” per se.
There’s a third kind of system for polling preferences, which I’ll call “opt-forced” for lack of a better make: it’s where you are required at some point to decide whether to opt in or opt out, and neither option is the default. (Picture two radio buttons, neither selected, and you can’t proceed until you click one.)
Nagging opt-in is a lot closer to opt-forced—you’re required to either press “OK” or “Cancel” to the opt-in dialog box. Except, since it just keeps asking whenever you “opt out”, you haven’t really opted out at all. Thus, this dark pattern is actually closer to the “opt-out” side of the fence, in terms of the number of people who end up in the program even though they’d actively prefer not to be (but this preference is weaker than their preference to stop being nagged.)
It's sending back arbitrary data to someone else without explicit authorization. This data can contain anything including information about the running environment, the contents of files on the computer, other running programs.
It doesn't matter that it's Microsoft instead of an Estonian teenager doing it. You own your computer. You explicitly decide what data comes from it. NO EXCEPTIONS.
> It's sending back arbitrary data to someone else without explicit authorization.
You are giving very explicit authorization by agreeing to the EULA.
> You own your computer. You explicitly decide what data comes from it. NO EXCEPTIONS.
That's still true. And by installing a product and agreeing to a EULA which includes a section on telemetry you are doing just that. Thus, your options are "don't install the software" or "opt-out".
Yes they are as long as it's clear you are agreeing to something, which is why pop-up EULA's have an I agree button and obligate you to scroll to the bottom.
GDPR does not make collecting aggregate data unlawful, so unless you can prove that the data collection is identifiable then GDPR doesn't apply.
It's impossible to 'anonymize' telemetry data. It's meaningless since it can be 'de-anonymized' usually within a few queries. Claiming that it's 'anonymized' is just a marketing word used by tech companies.
Nope. Specht v. Netscape Communications Corp. dealt exactly with this sort of click through 'telemetry'. Doesn't matter if it's in a shrinkwrap license.
Eh, not quite so clear-cut. There were some big caveats in that decision "clicking on a download button does not show assent to license terms if those terms were not conspicuous and if it was not explicit to the consumer that clicking meant agreeing to the license" [0]
It doesn't appear to say clickwraps are non-binding, only that it has to be "conspicuous" and basically that a user knew they were agreeing to something. Unfortunately that too is open to interpretation. As with most things of this nature, if someone wants to sue, they can sue, and it's a resource fight in the courts.
The privacy issue can happen in two ways that I can think of:
1. Unclear boundaries of data.
How many points of data are being collected and sent 'home'? CPU performance? OK. Device name, pc username, usage duration, times the program is opened and closed. System account email address, IP address, hostnames contacted (i.e. websites visited), WiFi-based location, webcam stream for inference of end-user mood, microphone for emotion analytics?
These are all examples of telemetry that could be argued are 'needed' for purely for product improvement.
2. Even if only a couple of data points are collected, it is very possible to identify the real name of the end user through analytics of the data. This inferred information is very valuable, and definitely is then a privacy issue.
I hope the vast majority of developers and company execs don't intend to 'do evil' with this information, but unfortunately we have seen examples of this from public companies, despite auditing etc.
I just moved into my rented house and discovered the CCTV outside my front door, in public view, but also on my property, is actually monitored by the landlord, not me.
I just entered a new mall and discovered that they monitors how many people come in and out (and at what time) in order to ensure they have enough cashier.
- you = me
- software = mall
- monitoring basic metrics in order to improve the service = counting people in/out
This is completely OK, and somehow everybody likes that they increase the number of cashier during busy time. Just like the mall, you do not own the software, you juste have the right to enter/use it.
Those aren’t exclusive attributes, either colloquially or legally. As a renter you have a variety of rights (including to “quiet enjoyment” of the property) that prevent, for example, the legal owner from entering the premises without advance notice and a legitimate reason. Similarly, while exterior cameras aren’t explicitly illegal, interior cameras are. Don’t allow simplistic maxims to occlude your tenant rights.
Ok. Totalitarian regime - there’s more than a few already - fake the telemetry domain name certificates and snoop on all your activities. Coupled to other humint they can easily trace a profile of all your whereabouts, habits, projects and relations both online and IRL. Then one day you disappear.
That's a hell of a leap. One day you're contributing to open source and the next day you're dead because of telemetry? Give me a fucking break.
Oh, I forgot, OSS contributors are vital state resources targeted by foreign governments and drug gangs alike, and both of them have access to how you use open source Winforms. I get it, now.
(Sarcasm complete. My points here are that you aren't a target of any totalitarian regime, and that totalitarian regimes don't need telemetry to make you disappear.)
Sorry, I forgot I was on the internet. I should have said "usage telemetry." I forgot that being on the internet means that people can't really follow unless everything is spelled out precisely. It doesn't matter that the whole conversation was about usage telemetry, it needs to be specified.
Are you switching the conversation topic from open source software telemetry to mobile phone tracking? That's a whole other thing, and doesn't contribute to the in-progress discussion on open source software telemetry, nor does it prove me (or anyone else) wrong.
Agreed, but that's asking way too much apparently. With a global opt-out, it should be easy enough to shame the software not honoring it and they get to keep taking advantage of the people that just don't care without pissing off the ones that do.
It's already fucked. This could be checked much easier than looking for new flags every release and figuring out those do what they should. If they fuck it up too much, we'll know they're either malicious or incompetent, both are very good reasons to stop using their code.
They are both malicious and incompetent for sure. Firstly because collecting data is more important than customer preference and secondly because when the customer did make a preference or state a preference they screwed up and told the customer to fuck off respectively.
Now after 16 years of using .Net and building a lot of massive products this is the status quo of how I have been treated all along and it hasn’t changed one little bit other than the marketing so it’s time to get off the ride.
At this point I firmly believe that the “open source” drive here is part of a new market domination strategy rather than something for altruistic good. Fair enough but I don’t have any love left to give now. If you ship some stuff on every platform it looks like you are an attractive option and once you’ve bought in you can’t get off the crack smoking schizophrenic rollercoaster. I want off.
If we make the developer, the developer's manager, and the entire org chart from there up to the CEO personally and criminally liable for any leaks and improper use of data, there would be zero need to opt out as they could not then externalize the costs of their shitty practices.
Criminalizing bugs would be insane, and would drive up the cost to create software, and probably also drive down the quality (due to pushing us into a smaller ecosystem of proprietary code). It would definitely kill open-source, because who would be stupid enough to release a source-tree that could send them to jail.
That said, statutory civil penalties (fines per occurrence) for the effects of the bug in production _would_ fix the problem. Who is going to keep giant data-lakes around when they are the business equivalent of toxic waste? The developers are still able to write code, but they are incentivized to not collect extraneous user data.
Only in the context of data gathering. There is plenty of buggy software that doesn't result in my social security number, credit report, passwords, and chat history spread across the internet.
It's no different than requiring, e.g., farmers to limit how and when they apply fertilizer and pesticides so as to limit runoff and down stream pollution.
No it is different, because this a conversation about telemetry which is exactly none of your social, credit report or passwords. Suggesting that developers should be criminally liable for your usage statics getting released is borderline insane.
I generally figure there are enough people like you that they don't need my data as well, so I opt out, if nothing else to spare my computer a bit of resources
> That means your (or my!) WPF/WinForms/WinUI apps can all use the same controls if you like, using XAML Islands. I could take the now 10 year old BabySmash WPF app and add support for pens, improved touch, or whatever makes me happy!
that's not interesting. the interesting question is: will there be a SQL Server Management Studio for GNU/Linux?
While unlikely, I hope one day that the entire Windows operating system will be made open source — I'm not sure how Microsoft would make the revenue work out, but I bet it could be done. And the world would be better for it.
I think it's probably unlikely not because of any opinions of Microsoft, but because Windows is vast and contains large volumes of code they've licensed to use in closed source code, but not bought the ability to re-licence as open source.
>, but because Windows is vast and contains large volumes of code they've licensed to use in closed source code, but not bought the ability to re-licence as open source.
This is true. A quick example would ZIP Folders in Windows - it uses third-party code Microsoft licensed (who knows if the company is still around today since it dates back to the early 2000s).
There might be better examples as that could be rewritten to use an open-source library such as InfoZip. Or simply stub-out the licensed functions and let the community fill it in. (And with something better, such as 7-zip so we get ZIP, RAR, 7z, tar, etc. folders.)
But I don't doubt there is other code that is not so easily replaced.
I’m not sure such libraries could be rewritten (in a white-box, non-IP-infringing manner) while maintaining the bug-for-bug ABI compatibility that Microsoft (mostly) guarantees their customers.
Yes - and if Microsoft announces they're open sourcing, or that information leaks, the owners of the IP will be able to name their price. Each will be trying to hold out to be that last essential component to get the highest price for the new rights.
There is, of course, always the Java approach: open source everything you can, on the assumption that that is 99% of what's needed, and allow others to fill in the gaps.
I don't know that Windows would run without the licensed code, or at least Explorer. If they didn't bother to write their own ZIP library (or use an open-source one) then they probably licensed a lot of other stuff that one would expect a first-class desktop is to have, making it unusable without a bunch of developers fixing it (when their company would probably buy them a license anyway).
If it was released without the third-party code, then it'd be a research project, which'd be pretty neat but not something most probably expect from "Windows is open source".
Java, when open sourced, couldn't run with purely open code (it relied on some binary blobs Sun provided); it's plausible MS could do similar. There would likely be a fair bit of interest in replacing the binary blobs in Windows.
Unless that piece has some sort of IP beyond a license of the code being used they run a real risk of Microsoft deciding it's cheaper and easier just to rewrite their own version of that library.
An interesting point of view is given in https://www.youtube.com/watch?v=-zRN7XLCRhc (Fork Yeah! The Rise and Development of illumos). There are some sections that briefly touch on how Solaris was open-sourced, and how incredibly difficult and time intensive it was to do because of how much code there was that belonged to other people/companies that had to be rewritten or just excised if possible. And despite all the effort they put in, it still didn't work out 100% of the way they wanted it to (thus the existence of illumos).
I vaguely remember Mark Russinovich giving a talk or something a couple of years ago (when they open sourced .Net Core, I think, but don't quote me), and somebody asked when they would open source Windows, and his reply roughly that they had no specific plans, but that it was "definitely possible": https://venturebeat.com/2015/04/03/microsofts-mark-russinovi...
I agree it is unlikely, or at least would require a huge amount of work. Then again, Sun did it with Solaris, so who knows what the future holds?
If somebody had told me ten years ago that Microsoft would open source their .Net runtime, port SQL Server to Linux, replace their proprietary browser engine with Chromium, I would have asked that person to give me some of whatever they were smoking. ;-)
There's that. But IllumOS is still around and has various derivatives that are under active development.
Last time I heard anything about Oracle Solaris, they fired more than a thousands developers at once, and some people commented that Solaris development at Oracle was more or less dead. (I have no clue if that is true, however.)
> But IllumOS is still around and has various derivatives that are under active development.
It's still an unfortunate blow. A lot of open-source projects are only as popular and widespread because of companies that effectively champion them in a way that convinces other people or companies to jump on the bandwagon. IllumOS, by way of being the pet project of some fairly unknown software company, is hiding in obscurity at this point when it could have been a serious contender as Solaris.
It is sad, yes, considering what OpenSolaris could have become. But at least Oracle was not able to completely destroy the community that had grown around it.
This probably sounds silly, but I find it sad, personally, because Solaris is probably the second coolest name ever given to an operating system, after Siemens' BS2000.
If they had first told you that in the amazing future of 2018, quality Operating Systems were a commodity that you can’t even give away, and Microsoft was now making all its money by being a B2B hosted-infrastructure (“cloud”) provider, would the other assertions become easier to swallow?
I have been using GNU/Linux and BSD on my personal machines since 2000, so the first part would not have blown my mind that much. For my needs (and Google's), quality operating systems were a commodity back then.
The second part, I don't know. Microsoft has been trying to move to a subscription-based model for a long time. Google Docs, GMail, Google Calendar were around back then, smart phones were becoming a thing. Microsoft moving away from traditional desktop and on-premises server software to a cloud-based model that would allow them collect "rent" instead of one-time license payments, that would not have sounded crazy. (Who knows - if they had tried to create a competing offer to Google's services that you did not have to pay for in sensitive data, they could have hit the Jackpot big time...)
Under those conditions, it makes much less sense for Microsoft to hold on to their code as they have done traditionally. But going from the company whose CEO publicly called FLOSS a "cancer" to a company that actively embraces it, that is a pretty huge change. When Nadella became CEO, I joked to a coworker that Microsoft was as good as dead, trying to go "cloud". I was obviously wrong on that one, and now I think if Ballmer had stayed as CEO, Microsoft would probably be much worse off.
Gmail, Docs, and Calendar weren't around in 2000. The first release of Gmail wasn't until invite-only beta in 2004[0] (invites were required until 2006/7); Google bought Upstartle (Writely -> Docs) and released Docs and Calendar in 2006[1][2].
I don't think open sourcing the entire OS is possible due to reasons raised by other posts, but maybe they could open source the kernel. This is the central part of Windows and what is actually important. Maybe they could even open source DirectX or some other proprietary library that became a standard over the years, like WPF, who knows.
How likely would open sourcing DirectX be? My understanding is that DirectX is a big reason that game developers prefer not to support other platforms. Wouldn’t that let competing platforms have a better chance?
That would be a change I’d love to see. But I think a better change would be for newer games not using DirectX and choosing Vulkan instead.
Many critical components are deep inside Windows kernel, in dxgkrnl.sys, they are very hard to unbundle from the rest of the kernel.
Other critical components are in vendor-implemented drivers, both user mode (this part compiles shaders and implements many per-game compatibility hacks) and kernel mode (this one talks to actual hardware).
Fortunately, there’re already third-party implementations of D3D on top of something else.
Gallium 9, the main downside is no Intel GPU support.
DXVK currently only supports D3D 10-11 and WPF is based on 9, but apparently some people are working on D3D9 support.
> Dropping DirectX and allowing Vulkan on the XBox would be the great move.
The sad thing is Vulkan and DX12 are not gaining traction even on PC. Very few games support these low level apis , so adding support for Vulkan on Xbox seems pointless first and foremost.
Because of legacy code issues, you're likely to just see the new parts of Windows get open sourced. When things get rewritten or ported or what-have-you (such as reimplementing these frameworks for .NET Core), it'll likely be open source. See how nothing from IE has been open sourced, but several components of Edge have been.
It's likely most of the nuts and bolts of Windows can be open sourced without threatening their business model, as competing OSes are pretty architecturally incompatible, and there will always be some closed source parts of Windows. Bear in mind, Microsoft is working heavily on shifting their revenue to being services-based as well.
IE might have lingering traces of Mosaic in it - MS licensed Mosaic from Spyglass as the basis for the original IE although more recent versions have dropped any explicit mention of that licensing deal.
And while they've dropped any explicit mention of it, it would be much easier to find any surviving evidence of it being a derivative with the code available.
Sort of. ReactOS does use large portions of code from Wine, but the ReactOS team upstreams changes to the Wine project whenever possible, so it's a two-way street.
Gross, no thank you. The trialware / bloatware that has come standard on windows from manufacturers was bad enough. Can you imagine how bad Lenovo Windows or Dell Windows would be? The Android landscape is bad enough.
At first, I was thinking that it would only be bad for the non-technical folk (i.e. other 99%) who wouldn't know how to re-install a better windows. But then, I remembered that even MS is having a hell of a time rolling out updates without breaking machines. All the different branded flavors of windows would just make getting windows updates that much harder or terrifying, I think.
>Can you imagine how bad Lenovo Windows or Dell Windows would be?
Why not just reserve the trademark Windows to Microsoft? If other OEMs want to muck up their own builds they would have to brand it their own and risk their own reputation.
The name Windows is irrelevant for a good chunk of the population. I remember helping some first year college students in the early 2000's (apparently Dell had a batch of faulty hard drives in their new computers). When they came to me for help, I asked if they had mac or windows computers, and the answer was "Um... Dell?".
It's the same with Android. A very small percentage of people buy phones with pure Android OS on them. The rest of the non-Apple crowd buy whatever looks good at the store and calls it Android.
I would absolutely love to be proven wrong on all of this. I rarely use Windows (mostly for gaming) and otherwise a linux is my daily driver, so either way I'm not likely to be impacted much. Perhaps I'm just too cynical after all of the utter nonsense Lenovo and gang have pulled with windows in the past as it is.
I could imagine some sort of scheme where home versions are free to download, but the right to redistribute is not included in that license. So OEMs still have to pay for an OEM version, and the server version still costs money.
But that would only work if it's legally possible to open source even that much of it in the first place, which may not be the case.
So the OEMs would Instead install a Linux bootstrap system that gets online and then downloads+installs Windows on behalf of the user.
Linux distros already do exactly that for other “open source but non-redistributable” things Microsoft offers, like the MS Core Fonts. The distros’ packages for the fonts don’t contain the fonts, but rather a wizard that goes and gets them from Microsoft’s servers on behalf of the user, and then installs them.
This seems legitimate enough, as an approach; nobody’s ever been sued for this. So I’m not sure there would be much difference in the legality of it if it were the whole OS.
> So the OEMs would Instead install a Linux bootstrap system that gets online and then downloads+installs Windows on behalf of the user.
I doubt it. That kind of first-time user experience would probably do more $ worth of damage to the company's reputation and sales than what OEM licensing costs.
Linux vendors may be able to do it just fine, but Linux PC vendors cater to a very different target market from Windows PC vendors.
Even if Windows is open sourced (which would be pretty cool just to peak in there), there’s no way on Earth you’d be able to compile it. I heard a full build takes over 18 hours on insane hardware, talkin 64+ cores.
How long do you think it takes to compile a full Linux desktop distribution like Debian or Arch Linux? Small communities manage to do this regularly. Maybe not so nice on an individual laptop, but there are ways.
I compiled GCC from source recently - it took several hours on an 8-core Xeon with 64GB of RAM.
Lots of projects take a long time to build, so it's not a show-stopper by any means. I imagine you could also mix precompiled parts with parts you compiled from source too.
It's going on fifteen years since I had anything to do with the Windows build, but that sounds...excessive. You could certainly take the afternoon off, though.
Or just Azure and switching to more IBM model: "you rent the hardwrae we own, so as long as you're up to date with your payments we couldn't care less what you run on it."
prediction: _if_ this happens, it will happen in such a way that you cannot meaningfully run a modified version of the Windows codebase as your OS. (i.e., they'll make it so all software must be installed through the app store and only on signed builds of the OS.)
> I'm not sure how Microsoft would make the revenue work out
Isn’t Windows 10 already more or less free? You can download it on their site, install it, skip the activation and that’s it. There is a message “Activate Windows” at the bottom right of the screen but it doesn’t matter for most people I guess.
NT's IO model gives you asynchronous wait on arbitrary event sources, including file IO — not just the network stack. It's actually quite nice if you get over the hideous type names and verbose CamelCase symbols.
In contrast, select(), from 4.2BSD through the current day, cannot be used for async IO on regular files. It simply returns immediately. If used naively this could result in a busy loop, I guess, although getting stuck in a blocking disk operation seems more likely to me.
kqueue cannot be used for async IO on files, either. Same problem.
EVFILT_READ Takes a descriptor as the identifier, and returns
whenever there is data available to read. The
behavior of the filter is slightly different
depending on the descriptor type.
Sockets
[Non-listen] socket descriptors return when there is
data to be read, subject to the SO_RCVLOWAT value
of the socket buffer.
Vnodes
Returns when the file pointer is not at the end
of file. data contains the offset from current
position to end of file, and may be negative.
There's aio(4), but support and APIs vary wildly across platforms.
The Unix async model based around fds and select was really only designed for sockets, and has been extended to socket-like objects (pipes/fifos). Linux has added support for some other sources in the form of e.g. signalfd(), eventfd(), timerfd_create(); the BSDs just added it all to kqueue/kevent. Neither supports async file operations in the fd model (basic operations like read/write; nor more complicated operations like syncing a range, renaming a file, creating a file, etc).
Both async I/O and select/poll are ways of multiplexing concurrent I/O activities onto a single thread of control. Both provide a way to initiate I/O and wait for completion without busy waiting. Both require timed-out waits if the thread must give periodic attention to something other than I/O.
Apple is in the business of selling hardware and accompanying it with software and cloud services.
They have zero interest of Mac software running elsewhere. They do have an interest for other software to be runnable under macOS / iOS without a major porting effort, but not a very great interest, I suppose.
Not while being compliant with Apple licenses? And you're beholden to Apple for a developer ID and permission to distribute applications, which they can revoke on a whim?
Given that running a Hackintosh often still requires using random unverified kexts from the net, I find it somewhat irresponsible to push applications built on such a system to your customers/users. How can you be certain that none of the kexts is backdoored and the attacker uses this as a vector to add malware to applications?
You can run Hackintosh on KVM just right away, although there are practically no 3D acceleration (unless you opt for PCI passthrough) and the performance is really tearful awful, still, it runs Simulator just fine.
No, you can compile directly in Linux. You need to build the tool chain yourself, extract the SDK from official sources, and use third party build tools.
A more realistic approach for a cross-platform WPF might be to start with Mono's Moonlight (as Silverlight and WPF have a lot in common) - this could now be speed up by using parts of WPF.
However in 10 years no one has cared enough to start a project to do this, so I'm not too optimistic.
Couldn't this be a good competitor for Electron or React native? Write code in whatever language you want that compiles to .Net, make the UI in XAML, don't run the application on Chrome and Node. Sounds like a good candidate for cross platform development.
Very excited to see WinForms and WPF especially hit open source. WinForms is still IMHO the hands-down most convenient way to quickly assemble a GUI for an app, and while Microsoft hasn't given it much love over the years, it's huge userbase will hopefully take advantage of the ability to iterate on it via GitHub.
I'm not entirely sure we're referring to the same WinForms but I distinctly remember loving C# in 2009 or so, just when WPF was coming out. But I refused to use WPF for my apps because back then you'd have to force the user to install the latest .net which I thought was too much of a bother.
So I tried using the old GUI framework and boy was it a nightmare to customize anything. I remember having to override the default Button class and add like 50 lines of code just so I could get a custom background. This and the fact that C# back then couldn't do high scalability servers were what forced me to learn C++ and in my opinion QT is a much easier library to use than the old WinForms was.
> I remember having to override the default Button class and add like 50 lines of code just so I could get a custom background.
That's mostly because you're not supposed to be doing that sort of thing in the first place. Customizing widgets = inconsistent look and feel. Custom widgets = Inconsistent LAF, inconsistent interaction, no accessibility etc.
The idea of Win32 UI, WinForms etc. is that you have a look and feel dictated by the system, not by individual app developers, with the ultimate goal being not just a consistent look and feel of the whole system (including applications) but consistently applied patterns of interaction. This in turn makes computers easier to use.
Of course, modern UI frameworks, whether in the browser (JS) or outside the browser (QML, UWP, JS, ...) run completely counter to that.
That's all well and good but in certain niches you need custom graphics. A good example is gaming, have you seen how beautiful the blizzard client is? Steam is nice too. Users of these apps don't care about a unified experience with the rest of the win32 ecosystem, in some ways these apps are a different ecosystem unto themselves.
I was trying to write a poker client so same thing, using normal buttons just wouldn't have made any sense. It would've been ugly as hell.
Modern UIs stray from a standard because standards are boring and if your app is boring then your not so boring competitor will snatch your users.
While I appreciate inclusivity, software isn't just utilitarian, it's also aesthetic. when it comes to aesthetics, slavish adherence to the lowest common denominator is a cancer... By analogy, would you like it if all books were written for a fourth grade reading level because some people can't handle more complexity? Or if the plots of all movies and television shows were simple enough for an idiot to follow?
Complexity is not an issue here, though, and in general the "boring" UIs tend to be the more complex ones, in terms of exposing more features etc. It's the custom-made ones that often trend towards fourth grade reading level...
Ironically, you got lost in the analogy. I'm not talking about interface complexity, but any intentional deviation from maximal accessibility (at least when it serves an aesthetic purpose).
> Or if the plots of all movies and television shows were simple enough for an idiot to follow?
That covers about 90% of Hollywood's output, and the reason for that is that you want a wide audience to purchase tickets. Only people that are good at navigating new interfaces appreciate novelty. That's a niche audience, but it intersects with the gamer audience (they're good at exploring new environments).
There are enough exceptions that whatever API you are using should accomodate developers in those cases. If people want custom UIs they'll get them somehow, you putting unnecessary roadblocks in the way will only annoy developers.
Managers don't care how you do it, they just want it done.
> But I refused to use WPF for my apps because back then you'd have to force the user to install the latest .net which I thought was too much of a bother.
That always puzzled me, even though I've seen some of Microsoft's reasoning and blog posts about it.
Microsoft has repeatedly stressed that you can't assume any particular version of Windows comes with a specific version of .NET preinstalled (or VC++ runtime, for that matter).
Windows already bundles various things, and the major .NET frameworks seem like the thing to bundle and preinstall, and they actually do[0], just not consistently or universally.
And, Windows Update can already update the .NET frameworks, in fact I recall that some new major .NET versions were treated as "recommended" installs by WU in the past and were automatically installed on systems that didn't already have them, but they aren't doing that consistently and universally either.
I think that’s one of the reasons that WPF never saw much use in terms of widely distributed desktop apps. You couldn’t assume the presence of a particular version of the framework on any given Windows install and (until now) you couldn’t bundle the framework with the app like you could with the JDK.
A lot of Windows applications built with .NET do a dependency check and launch the .NET Framework installer (often included in the installation package) if you are missing the minimum required version.
Of course, that is a system-level change, which can potentially break other applications on your machine (if they're written badly and/or poorly supported). .NET Core removes that by supporting side-by-side versions and versions packaged with the app, but it certainly wasn't critical to assume a given machine already had a .NET Framework version in question.
Honestly, with Windows 10 now including .NET Framework updates along with feature upgrades every six months, and the fact that pre-Windows 10 versions of Windows haven't that many more years to live, it feels like that advantage isn't as big as it used to be anyways.
My concern is .NET Core may lead to a lot of unnecessary software bloat. Where Windows has the current .NET Framework, but we still have to have six versions of .NET Core installed, and then half the programs on the computer don't use those and have their own bundled versions as well. I find .NET Framework already being on-system to be a big perk of writing my app with it: My software is a 7 MB file because most of the code is already built into Windows.
WinForms' key is the quick drag and drop and edit properties type designer. It's not really intended for you to restyle it entirely (though you can). In that it was 'the style' of apps of the day, you could simply put whatever elements you needed on a form, and then double click on them to put some code behind them.
Since WinForms' existing styling was the style of applications of the day, there was little reason to heavily restyle it. Honestly, if someone ran with the new open source WinForms and introduced a Windows 10 style that I could build with the same incredibly easy editor as the existing WinForms, I'd be set.
There was something to that style. Different application UIs were pretty predictable in use compared to what we have today. I think there is way too much work going into messing with the UI instead of real functionality.
> WinForms is still IMHO the hands-down most convenient way to quickly assemble a GUI for an app
I think Lazarus[0] is easier, especially when it comes to automatic layout stuff, but WinForms is very close. They're somewhat related as both are descendants of the classic Visual Basic RAD approach and Lazarus is basically an open source and cross platform clone of Delphi while WinForms implements a very VCL-like (VCL is Delphi's framework) API - which is natural since both Delphi and WinForms were designed by the same person :-P.
There are several ways. The simplest is setting the "Align" property of a control which is similar to the "Dock" property of WinForms in that it makes the control stick to the left/right/top/bottom edge (multiple controls stack) or fill the "client" area. It also has an "Anchor" property that again works similar to WinForms' property of the same name, allowing anchoring an edge to the location you place the control.
Beyond the above (which i think are all what WinForms provide, at least from the visual designer) the anchors can also be set so that instead of just "sticking" to a designed edge, they are set relative to some other control in the parent container with customizable gaps. For example you can configure (using a dedicated anchor editor window) that the left edge of an input box is 5 pixels away from the right side of the label control and the label control's top edge is aligned so that the label's center matches the edit box's center. Note that any control can be anchored to any other control, so if you have a form with 10 input fields you can anchor their left side to the same control (e.g. the longest label or a "guide" control) so that they align neatly.
The align property is enough for most cases and the anchor system covers almost the rest of the layout cases. Where those do not suffice, there are a few more dedicated options like the TFlowPanel container that flows controls in various formations as well as the ChildSizing property that allows for specifying some automatic layouts. TBH personaly i never had to use those though. Note that most of them can also be combined.
Finally each control also has constraints (min/max size) and spacing (margins) for each edge as well as an overall spacing.
Somewhat related, but you can also make pretty much any control dockable by setting its DragKind property to dock and DockMode property to automatic. Docking happens in "dock sites" which are basically any container (like a panel) that has its DockSite property set to true (and preferably, although not required, its AutoSize also to true) and since containers are regular controls they themselves can be laid out using any of the above options or be anchor targets for sibling controls. The framework handles the whole drag/drop, docksite resizing, creating popup windows for tearoff docks, etc. In fact the whole docking system is modular itself and there are a couple of different docking managers that provide quite advanced options.
Note that all i've mentioned so far are done with the visual designer, there is obviously more fine grained control by writing code.
WinForms also has layout panels (they showed up in 2.0+) - FlowLayoutPanel etc.
The stuff with anchors being relative to other controls, though, sounds like it should be roughly equivalent to Java GroupLayout in expressive power. Which is neat!
I do not think GroupLayout is similar as there aren't really any groups and the anchoring is done directly to the other controls. And TBH from my experience using it in NetBeans i wouldn't describe anything other than a PITA :-P (although half of it was probably NetBeans itself).
I've done a bunch of WPF in my time, but I struggle to see what I'd use it for now. For line-of-business type apps I'd do it on the web, and for anything that had to be desktop I'd need to be really, really sure that it didn't need to be cross platform.
Yes I like WPF's model, but it's not worth investing my mental energy into something that is self-obsoleting. Although you can make a career out of WPF, there is a lot of stuff that needs to be maintained, and trading companies around where I live seem to favour it. Probably because they use it to make internal software, they can dictate everyone uses Windows, and they need to build stuff fast but it also needs that native performance, flexibility and power you don't get with HTML.
Depends if you subscribe to the idea that open-sourcing something is equivalent to putting it out to pasture.
MS’ problem is that Visual Studio is the only “real” software they produce that uses WPF - which also happens to be a flagship product. They need WPF to stay up-to-date but they can’t afford to invest their own FTE resources into it either when other products are more important as far as the C-levels are concerned.
I’m curious what this means for UWP XAML - as it has its origins in WPF. Can Microsoft use open contributed WPF code in UWP?
OneNote was a flagship WPF software as well. OneNote has announced it's all in on UWP moving forward.
WinUI included in the announcement above is the UWP XAML controls and their "XAML Islands" wrappers, so Microsoft is directly taking UWP open source contributions now, too.
So far as I'm aware, Microsoft's Ink controls have never had Win32 versions. For a few years they were System.Windows.Forms-only, for many more years they were WPF-only, and now the latest versions are UWP-only. That's a pretty core component part of OneNote. I don't think OneNote was WPF for all of its history, but there was certainly a time where a large percentage of it was WPF, from what I've heard. Which is also why I've heard OneNote led the vanguard to UWP and has been the Fluent Design 2.0 test bed for where Office's Fluent Design is moving, because it was the easiest to integrate UWP controls into the fastest.
My understanding is that most everything ink-related in OneNote is custom on top of the lowest-level APIs available. That tends to be Office's MO in general.
WinForms is not windows-only, it has been implemented in Mono pretty long ago already. The major reason almost nobody develops WinForms apps on Linux is there is no visual WinForms designer (which is so good and intuitive in VisualStudio and that's a major WinForms strength) on Linux and given you are forced to code it manually other GUI toolkits can be more flexible, more powerful and look better. In fact I have developed some WinForms apps in VisualStudio on Windows specifically intending them to run on every of the 3 major OSes without modification.
> - is literally WinForms. It's a 90s era GUI toolkit.
I fail to see how this is a problem, mostly because the job it was designed to do (build guis for desktop applications) has seen little innovation since the 90s.
"The highlight of .NET Core 3 is support for Windows desktop applications, specifically Windows Forms, Windows Presentation Framework (WPF), and UWP XAML. You will be able to run new and existing Windows desktop applications on .NET Core and enjoy all the benefits that .NET Core has to offer."
WPF, Windows Forms, and UWP are listed under the Windows-Only Desktop Packs section in the diagram.
WPF (and the other UI technologies listed) still rely on a lot of the underlying Windows API. Now that they are open sourced though, someone outside MS can work on a port, though I imagine it will take a non-trivial amount of effort.
The change here is that .Net Core now supports it, but only if you reference the appropriate SDK[1]
Things are a bit more complicated than that, I guess that's specifically why Microsoft is open sourcing "the desktop pack", because it is not multi-platform.
This is where .NET Core gets confusing. They're just able to run on the .NET Core runtime (versus the "full" .NET Framework). WPF uses DirectX heavily, so it's not like Microsoft just ported DirectX to non-Windows platforms.
The code has been accessible for a while now, albeit still licensed as proprietary. I went through it a few weeks ago. The Winforms code depends heavily on GDI APIs, which AFAIK are windows only and closed source
BTW if Microsoft chooses to go opensource one day they can just start improving Wine together with CodeWeavers, ReactOS team and the community to the point when it could replace Windows completely. This is approximately the way they have chosen to go with their web browser switching to the Chromium Blink engine.
I bet Microsoft has an absolutely killer win32 regression suite. If we're devolving into pipe dreams, I'd probably want that even more than the actual win32 code.
There's an open-source implementation GDI through WINE, so it should be possible to get Microsoft's implementation of Winforms running natively on Linux.
It's not just GDI. WinForms is literally just a wrapper over stock Win32 widgets, for the most part. So you'll need the entirety of Wine, pretty much, and your app will look like a Windows app. At that point you might as well just run it via Wine.
Apache has a clear patent grant, but it's also transitive. Folks redistributing a modified library have to grant their own patents. Some customer might care about the distinction.
Also MS's lawyers may not be 100% clear about whether these libraries already include patented technology from other patent holders that MS may have licensed years ago.
MIT punts on the whole issue, so may seem "safer" to a lawyer when used with a giant existing code base. Apache is clearly the right choice for new development (for those who don't like GPLv3, anyway -- let's not get into that argument).
Real question: why is WPF worth contributing to, if it can't be made cross-platform?
I've used WPF for about a day, and I never went back to using it. Not 'hating' on it, I just want to understand WPF and the incentives to open source it (I get it for .NET though).
Are you implying that Microsoft wanted to use Github for their internal projects? Doubtful. The big strength of Github is collaboration, and there are better tools out there if you want to enforce an internal company process.
I'd be interested in any association that can be made against previous versions of such libraries, and the newly released open source libraries. Are the 'releases' between the old closed source and that of the newly open source significantly different?
If so, and either way; I'd be interested in knowing what kind of changes were applied in direct action of the source being released. Was it just cleaning/linting of the code? Were there features that were otherwise inappropriate (security? quality?) that needed attention before release.
Things like alignment with child dependency license agreements, or overall quality (in code, testing, and deployment) are things I find extremely interesting. Was there some interesting 'inappropriate' language in the source from developers long gone. Could this have effectively been the opposite spectrum of what happened with event-stream https://github.com/dominictarr/event-stream/issues/116
I'm not explicitly saying it's any of my business. I can imagine a multitude of reasons that this history would never be provided. But... as above.. I can consider reasons, perhaps; it should..?
I don't mean to discourage release. I really appreciate it. Just some thoughts..
First of all, just being open-source doesn't make Windows Forms or WPF cross-platform and in fact, that's specifically not the goal or focus here.
Secondly, Paint.NET includes quite a bit of non-WinForms/WPF code by now, talking directly to DirectWrite and Direct2D in places and probably other things as well. It's very much a Windows-only application and porting it would require rewriting a lot of important core code of the application.
If, as people here have suggested, that WPF is dead, I now wonder if desktop apps in general are being killed. I liked qt widgets quite a lot but I think that's mostly in maintenance mode. How do these companies expect the end user to interact with the next version of excel, autocad, solidworks, photoshop, etc?
There were rumors of a Winux project at Microsoft that put the Windows GUI on top of Xenix. I don't think it was true. But the idea of moving the OS to a Unix OS goes back to MacOSX. Microsoft could do worse than putting Windows on top of Linux.
There was a research project years ago that wrote an OS in C#. It wanted to be super stable, modern and no cruft. I forget the codename but was hoping it would see light of day.
I think Microsoft is aggressively trying to attract developers to use their products and this is yet another action in that direction. I think it’s a good move but I’m far from a conversion. My next OS will be a GNU/Linux
This is a pretty minor thing, but with the open sourcing of WinUI, I wonder if there's enough open-sourced that people could try and figure out how to support Dark Mode themes in non-UWP applications?
The developers of EarTrumpet figured it out, see https://github.com/File-New-Project/EarTrumpet . Their solution is based on WPF and quite complex, however there are APIs to get the current mode, and all the modern UI colors.
I myself implemented the modern black menu style for a tray icon, so that the menu looks like the native tray icons. It's "just" a matter of owner drawing everything. Unfortunately, there is no secret "make my app dark" api in WinForms / WPF.
Open-sourcing pieces of .NET code --- which is "open source enough" with a decompiler, after all... they didn't bother to obfuscate it and the ExtremelyVerboseButMostlyQuiteUsefullyDescriptive names still remain in the binaries --- seems almost a natural consequence of how the platform works.
But as a long-time Windows programmer, I would liked to see parts of Win32 open-sourced, because it's the far more interesting (and efficient) part of what makes Windows... Windows.
Currently, the linked WPF repository is almost empty. Very little code, and not a single .cpp file. WPF's native layer is huge, wpfgfx_v0400.dll, PresentationNative_v0400.dll, etc., lots of complexity between .NET and Direct3D 9.0c.
This year does not end surprising me. I have quite positive experience with development in WPF, but I noticed except the SourceTree I can't find any application which looks nice. Do you know any neat-looking application which uses WPF?
Well, let's hope they open source Silverlight next so I can finally upgrade to Visual Studio 2017 when maintaining my apps (that are still in daily use by happy customers).
Because lots of WinForms and WPF developers have been frustrated at the lack of activity on these frameworks. It holds out the promise that even if Microsoft can't be bothered to maintain them then perhaps the community will.
Personally I think it's too little and too late, Desktop development has had its day.
"We will typically not accept contributions that implement support for an OS-specific technolology on another operating system. . . We also do not intend to accept contributions that provide cross-platform implementations for Windows Forms or WPF."
https://github.com/dotnet/wpf/blob/master/Documentation/cont...
Microsoft seems to be actually refusing to accept contributions that could make WPF cross-platform - it's a bit beyond "no official plans for cross platform".