[pjmlp]

The whole Longhorn/Vista debacle, with .NET components being rewritten in COM for Vista, followed up by the increasing the COM usage in Windows 7 and then bringing up WinRT as .NET replacement under Synofsky's leadership is another example of those political internal wars.

[stupidcar]

Yeah, I think this was a far bigger contributor to the failure of .NET to achieve dominance. Silverlight was only ever a slightly weird sideline intended to compete with Flash, which became DOA the moment the iPhone launched and Jobs killed Flash overnight by saying the iPhone would never support it.

Microsoft's biggest internal teams turning against .NET during Longhorn created a schism that the company has never resolved. I often wonder what might have happened if they'd had the requisite leadership to force the change through organisation-wide, and MS had spent the last 15 years with a single, rational dev story.

[jasode]

>Microsoft's biggest internal teams turning against .NET during Longhorn created a schism that the company has never resolved.

From the fragments of leaks I read about the internal strife, the .NET code had huge performance problems and the C++ team was frustrated that "DevDiv" couldn't solve them. ("DevDiv" is Developer Division that owned NET Framework.) Therefore, they ripped a lot of "managed code" out and redid it in native code.

I hope that one day, an ex-Microsoft programmer or product manager writes a tell-all book of this period. It would be a fascinating case study.

[stupidcar]

Yeah, that's my understanding as well. But what I wonder is what would have happened if someone at the top had brought the C++ and .NET teams in and made some Jobsian declaration like "this isn't negotiable, the company is switching to .NET. All of your jobs depend on finding a way to make it work." Were those performance problems really insoluble, if all the engineering ability of the company were brought to bear on them? I get the impression that a lot of the C++ old hands were never pleased with .NET to begin with, and were all too happy to chuck it.

[WorldMaker]

Right, it certainly sounded from the outside that a lot of the Longhorn performance issues were various sorts of sandbagging by one side or the other. There's an interesting leadership question there too if some of the worst sandbagging was intentional or just ADHD-style distractions due to a lack of a singular, focused vision for the product. (The biggest example being letting so much of the WinFS team get sucked into the never-ending "semantic web" rabbit hole of trying to "schematize the world"; it's hard to focus on performance when you are busy trying to catalog all the different ways that people store data.)

[pjmlp]

At RustConf 2017 keynote presented by Joe Duffy regarding Midori at a certain moment, he mentions that even with Midori running in front of them, WinDev guys were still not open to the idea of such kind of system being possible.

"Safe Systems Software and the Future of Computing"

https://www.youtube.com/watch?v=CuD7SCqHB7k

Sorry a bit lazy to track down the exact moment.

[pjmlp]

The thing is, if they actually collaborated with each other, the outcome would surely look quite different.

[ASalazarMX]

> Jobs killed Flash overnight by saying the iPhone would never support it.

I think it was a forced choice. Even if Flash had been supported, most flash sites and games would not have worked well on a phone.

[pjmlp]

Yep, they were forced to sort out the mess introduced with WinRT, UAP, UWP, by making UWP .NET Standard 2.0 compliant, and now making Forms, WPF and EF 6 runnable on top of .NET Core 3.0.

However given the last Office related announcements, it appears that the reorganization did little to sort out those political issues.

[mariusmg]

Next stop, making UWP crossplatform :))

Regarding the political issues, the Silverlight/WinRT clusterfuck also helped with WindowsPhone downfall. Release 1.0 and next major update offered a API incompatible with 1.0, what a clusterfuck....

[hackerfromthefu]

This exists - UWP code and UI - deployed to iOS, Android, and WebAssembly.

It's called UNO, check out https://platform.uno/ and https://platform.uno/#Comparison

!! By the way to anyone who wants to build a system in UNO - I would like to build one. !!

I'm a .NET developer with the perfect experience to leverage this system. I've been doing full stack and front end on various platforms for 20 years, and .NET for 15 years (version 1) and thus can leverage UNO to provide rapid and quality development.

I've already done advanced XAML in Silverlight and WPF with MVVMLight and PRISM application architectures based on TDD/CI/CD, animations, transforms, control templates, control building, designing products.

I'm also good with Blend and do the roundtrip Blend designer to Visual Studio developer workflow, or do both parts myself to design a full front end UX, UI, and code, and well as the rest of the full stack.

If you're interested to build a system or product built on UNO with me, get in touch!

[merb]

> Next stop, making UWP crossplatform :))

they do not need. they have xaml over xamarin.forms, which supports all major platforms (including desktopn and mobile) it still says that its in preview however the only things that did not work well is when you need some kind of file interaction with the os, you need to create native views for all your OSs (i.e. NSFilePicker, OpenFileDialog, etc..) since there is no Xamarin.Forms widget for that. besides that it is already really mature.

[Mertax]

Xamarin.Forms has to manage a lot of friction interfacing with the native UI controls. It's both an advantage and a disadvantage to it's approach. It has to conform to the common denominator of the native platforms, but gets to leverage the native look and feel. But this seems much harder to maintain long term. It would actually make sense if they created a XAML platform (like cross-platform UWP) that used its own rendering stack (similar to Flutter's approach) that wasn't beholden to the design decisions of an externally developed platform and having to reconcile the differences between different platform paradigms.

[WorldMaker]

To further tangent: I don't think the last Office related announcement says anything about UWP that people think it does.

From my understanding, the Office apps that were killed were supposedly forked from the web apps and actually ran as UWP HTML/JS.

Meanwhile, Office has also announced plans to move forward with more UWP XAML Islands to integrate more Fluent Design in the UX starting soon after the Windows October release, and part of why the Office 2019 LTS was shipped where it was and arguably why Office 365 pushed to align to only support latest Windows releases so they could move forward on Fluent Design dogfooding.

They did sunset the non-UWP OneNote with this LTS release, and the UWP XAML app is supposed to be the only Windows version of OneNote moving forward.

[pjmlp]

Lets see, I watched the Office sessions at BUILD, so that was my understanding until the announcement came last week.

[WorldMaker]

Yeah, BUILD's where most of where my impressions come from, especially from how pleasantly happy that the Fluent Design Team was with finally merging in some of Office's design resources and working to align Office towards dogfooding Fluent controls directly.

The implication I take from the UWP "Office Mobile" app shutdowns is that Office is now confident that if UWP returns to mobile it will do so with "real" Office, which was my takeaway from BUILD that that was the strategy they were pursuing.

I think it's another case of Microsoft not being able to properly spin "nuance" in a press release, because they don't want to comment on future plans or publicly commit to things still in flux/prototyping/development.