6 ms·

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 repla

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) https://en.wikipedia.org/wiki/Midori_(operating_system) [1] https://en.wikipedia.org/wiki/Singularity_(operating_system) https://en.wikipedia.org/wiki/Singularity_(operating_system) [3] https://mspoweruser.com/uks-nuclear-submarines-runs-windows-xp-submarines/ https://mspoweruser.com/uks-nuclear-submarines-runs-windows-...

theamk 8y ago
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.
- derefr 8y ago
  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.)
  - maxxxxx 8y ago
    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.
    - naikrovek 8y ago
      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.
      - maxxxxx 8y ago
        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?
        naikrovek 8y ago
        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.
        maxxxxx 8y ago
        UWP is a no-go already. No way we can port our WPF code.
        naikrovek 8y ago
        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.
m0zg 8y ago
Midori, as cool as it was, was Microsoft's "no output division" (see https://archive.computerhistory.org/resources/text/DEC/dec.bell.no_output_division_C-I_TF;productivity_review.1982.102630376.pdf 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.
- EvanAnderson 8y ago
  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 https://news.ycombinator.com/item?id=10587124
- chiph 8y ago
  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)
- dtrailin 8y ago
  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.
- Someone1234 8y ago
  > 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.
  - m0zg 8y ago
    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.
pjmlp 8y ago
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/ 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.
- mike_hearn 8y ago
  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.
  - pjmlp 8y ago
    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.

theamk 8y ago

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.

derefr 8y ago
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.)
- maxxxxx 8y ago
  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.
  - naikrovek 8y ago
    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.
    - maxxxxx 8y ago
      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?
      - naikrovek 8y ago
        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.
        maxxxxx 8y ago
        UWP is a no-go already. No way we can port our WPF code.
        naikrovek 8y ago
        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.

m0zg 8y ago

Midori, as cool as it was, was Microsoft's "no output division" (see https://archive.computerhistory.org/resources/text/DEC/dec.bell.no_output_division_C-I_TF;productivity_review.1982.102630376.pdf 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.

EvanAnderson 8y ago
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 https://news.ycombinator.com/item?id=10587124
chiph 8y ago
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)
dtrailin 8y ago
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.
Someone1234 8y ago
> 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.
- m0zg 8y ago
  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.

pjmlp 8y ago

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/ 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.

mike_hearn 8y ago
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.
- pjmlp 8y ago
  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.