Hacker News Reader

Comment by Someone1234 | Hacker News Reader

Just a painful reminder that they scrapped Midori[0] their managed Operating System based on Microsoft Research's Singularity project[1].

Even if it only replaced Windows LTSB/Embedded, I'd still prefer an ATM, checkout, or gas station terminal I was using was running on managed code. Doubly so for the next generation of Nuclear Powered submarines[3].

Plus between virtualisation and silo-ed software management ("Apps") it seems entirely plausible to move the PC/Laptop to the next generation.

[0] https://en.wikipedia.org/wiki/Midori_(operating_system)

[1] https://en.wikipedia.org/wiki/Singularity_(operating_system)

[3] https://mspoweruser.com/uks-nuclear-submarines-runs-windows-...

View on HN

I'd strongly prefer that my ATM had no start menu, file picker, online help system, interactive parts of update system, or any of the thousands of other UI apps which could be exploited via touchscreen if accidentally activated.

Singlularity would be cool, but I'd prefer smaller footprint to begin with.

Microsoft already have what you're talking about; it's called Windows IoT Core.

(This is in contrast to Windows IoT Enterprise, which is the more traditional "Windows Embedded" experience with many of the features you're complaining about. This is mostly because Enterprise customers want to be able to slap their coded-for-a-desktop apps onto a kiosk and declare the job done.)

I have never heard about IoT Core before, only IoT enterprise and LTSC. This would actually have been an interesting choice for the project I am working on right now.

It's really infuriating how many versions MS is cranking out without clear differentiation between them and even when you talk to MS reps they know nothing about the options.

IoT core is not new, not a secret, and Microsoft makes no effort to hide it.

Your MS reps need to be fired if they do not know about IoT Core, or chose not to tell you.

Also, I personally find it best to never rely on a rep from any company to give me the truth about their product line. I will make time to do preliminary research (at least) myself.

Microsoft will ALWAYS push IoT Enterprise over IoT Core because IoT Core costs nothing, and generates no revenue for Microsoft (other than the associated Azure revenue that they hope you spend connecting those IoT Core devices to infrastructure.)

All that said, I recommend looking into IoT Core if it interests you. It is very well suited for certain kinds of use cases.

Our reps wanted to push us into enterprise. We went with LTSC against their advice because the upgrade cycle is much better.

IoT Core looks interesting but I am not sure if we are ready for App Store only. Does it even support WPF or only UWP?

There is NO graphical Win32 stuff; UWP only. There are some non-graphical Win32 APIs but not like full Windows.

It's basically .net core and UWP and all the old familiar Windows stuff is gone.

IoT Core is either the best possible Windows or the worst possible Windows, depending on your point of view.

For some things, it's a perfect fit. If you can't fit into a .net core & UWP ecosystem entirely then it won't be a good fit if you need a GUI.

UWP is a no-go already. No way we can port our WPF code.

Well, UWP and WPF are close cousins, so it probably isn't as bad as one would think if they didn't know that. They're both XAML, though they are not quite the same.

The main thing is that with WPF you can use the same Win32-type logic you've always been using. UWP is it's own API entirely. It's not all that different, but it is different. Things are organized better and APIs make more sense in UWP-land to me.

So the gui would probably port over relatively easily. The application logic probably wouldn't.

The GUI would be the easy part but our applications have a lot of background logic. Going to UWP would be almost a complete rewrite without actually improving anything. From what I have seen so far UWP is just different but not really better than WPF.

Can't argue with any of that.

Presumably, at some point in the future UWP support will extend beyond WPF's support window, and right now they are both supported, so it would be silly to switch solely for the sake of making IoT Core a viable deployment platform for you.

Midori was a victim of the WinDev vs DevDiv political wars.

The most recent example is Kenny Kerr complaining that although they made a big effort to migrate from C++/CX into C++/WinRT, the large majority prefers to code in .NET nowadays.

https://kennykerr.ca/2019/01/25/the-state-of-cpp-on-windows/

However many of the Midori outcomes have landed in .NET, namely .NET Native, async/await, TPL, span, blittable structs, immutable data on Rosyln, so not everything was completly lost. As side note WP8 Bartok AOT compiler also comes up in Singularity.

So fortunely not everything gets lost.

Was it? How do you know that?

As far as I am aware the only public information on Midori comes from Joe Duffy's blog which didn't discuss why it got cancelled.

Beyond the general issue of the well known managed vs unmanaged wars within MS, it would appear to be the case that Midori sucked up massive investment within MS and had little to show for it in the end - a nearly 10 year effort to build a fully managed OS, but one that focussed entirely on trying to be competitive performance-wise with Windows, rather than providing entirely new functionality and new ideas. So they spent years doing things like hand-optimising libraries to get rid of vtables and ended up with something that wasn't really .NET (it eschewed threading and .NET compatibility), and wasn't Windows, and whose primary strength was "it's written in a managed language" which isn't very interesting to actual users.

Joe Duffy has made a few mentions to it in his keynotes and some tweets.

At Rustconf he clearly mentions that in spite of having the system running in front of them, WinDev wasn't willing to believe in them.

Which given how WinDev sabotaged Longhorn to reboot .NET ideas into COM and getting COM Runtime reborn as WinRT, I would believe him.

Midori, as cool as it was, was Microsoft's "no output division" (see https://archive.computerhistory.org/resources/text/DEC/dec.b... for context). It existed so that very senior engineers wouldn't go elsewhere and cause trouble for Microsoft. It had fullfilled its purpose in that regard. I strongly suspect that some of Google's more ambitious endeavors serve the same purpose.

I hadn't seen that memory before. Turn out there's some previous discussion re: "No Output Division": https://news.ycombinator.com/item?id=10587124

Were they placed there because of negative productivity (as implied from the DEC memo), or so they wouldn't become someone else's competitive advantage? (even at the cost of not letting their unvested shares return to the pool when they left)

I don't think is is actually true since they actually did run some production services at MS like the speech service which did voice recognition for windows phones.

> Midori, as cool as it was, was Microsoft's "no output division"

Considering you have absolutely no proof of that it seems rather disrespectful to act like that's a fact rather than your supposition.

It always cracks me up when people demand "proof" of something like this. I mean, I know some of the people from there from way back, and the project was eventually canceled, so there literally was "no output". And they had pretty much complete carte blanche on everything and could bikeshed over the most inane and inconsequential things for months on end. It was a fun "job" while it lasted, though.

Now I'm starting to wonder if you even read the "No Output" letter and understand its implication? You essentially called a bunch of Microsoft employees productivity drains on the rest of the company.

The fact that you think a cancelled project means it is the same as DEC's "No Output" team likely means you don't understand what the "No Output" team even was at DEC or the implication for the people within it.

You absolutely do need to present proof of what you're saying, because it is a serious charge for both Microsoft and those employees alike.

Surely there was output.

Async/await, TPL, Span<>, blittable structs, safe stackalloc, .NET Native, and a couple of other minor features come from M# (System C#) usage.

Based on knowing and being firsthand friends with several Midori devs, I’m going to assert that this is simply not true. The majority of them were just reassigned when the project was cancelled.

Many of the innovations from Midori were included in other projects. The project may have “failed” but it was far from a failure.

Reply on news.ycombinator.com