Singularity – Microsoft’s Experimental OS | Hacker News Reader

Singularity – Microsoft’s Experimental OS

codingkaiser.blog

199 pointsdevev105 comments

The follow up MS project Midori has one of my favourite series of blog posts written about it http://joeduffyblog.com/2015/11/03/blogging-about-midori/

And unaware to many, did actually power the Asian servers for Bing as production test.

Why Midori was discontinued?

The usual politics, from .NET vs C++ at Microsoft.

Here Joe Duffy mentions towards the end that even with Midori running in front of them, the Windows team was sceptical of it.

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

Since .NET's introduction, Microsoft seems to lack the same kind of culture that Apple and Google have towards into steering their platforms into safer languages (e.g. how constrained NDK happens to be, or first class bindings to all OS APIs in Swift).

It appears that every attempt to do so ends up being sabotaged in some way to assure C++'s reign at Microsoft and Windows subsystems.

Note that Windows is the only desktop/mobile OS where the GUI stack is still fully C++ aware, and they even make a point out of it.

https://microsoft.github.io/microsoft-ui-xaml

> WinUI is powered by a highly optimized C++ core that delivers blistering performance, long battery life, and responsive interactivity that professional developers demand. Its lower system utilization allows it to run on a wider range of hardware, ensuring your sophisticated workloads run with ease.

Perhaps due to a pervasive desire to maintain backwards compatibility, bugs and all?

That doesn't justify why Managed Direct X, XNA, Silverlight (on WP 7), .NET Native got the axe.

Even the Longhorn failure, which resulted on the "everything COM", that then evolved into WinRT (basically COM + IInspectable + .NET metadata + sandboxing), could have worked out if everyone actually worked together.

I don't believe that if there was actually a willingness from Windows/C++ crowd, they couldn't have helped to push the .NET runtime into improvements similar to .NET Native.

Or to put into another way, the efforts done by Google and Apple improving the Objective-C, Swift and ART, respectively.

In fact, probably the reasoning behind bringing Midori learnings into .NET Core (thus making C# into D like), has more to do with C++/CLI being Windows only, and the managed languages competition outside Windows than anything else.

> could have worked out if everyone actually worked together

Apparently, Sinofsky suffers dreadfully from "not invented here syndrome." He simply does not trust anything that his team has not built, and Midori is the tip of the iceberg. There are a some instances where his attitude worked, but they were far and few between.

You'll notice that there is a very distinct "firewall" between core architecture and "other teams" on the projects he managed, even today (e.g. .Net Office extensions are just COM).

Indeed that is quite clear in between the lines on MSJ, Channel 9, blogs, PDC, BUILD, among others, since Visual Studio.NET came out.

nah, they had Drawbridge running on Midori, which allowed nearly perfect app compat. it really was a case of internal politics as far as I know.

though another way of looking at it is that rewriting the entirety of Windows in Midori would be been a monumental feat, and by the time Satya became CEO it was clear Windows wasn't the future of the company, so that kind of investment didn't make sense.

Maybe, but my recollection from the time (as related to me by Bryan Willman) was that a group of base team architects did an analysis of the .Net runtime and created a list of technical concerns that they felt precluded it's use in any critical component of the OS.

Of course, all of these concerns could presumably have been addressed or mitigated, but by the time analysis was released it was too late

That is exactly my view, instead of addressing the issues, like Apple and Google have been doing the last decade, the decision was to double down on C++ and COM instead.

Yes. And to a certain extent a **-swinging contest between DevDiv and the base team

My previous company had a C++ portion/team and wow were they defensive about changing anything :-)

We know how well that worked for Symbian.

Also politics.

Back in the day Nokia did road shows to gather employees feedback before going public.

One point regarding Maemo that I and others did, was the missing radio link.

Naturally that was a no go as they would eat into Symbian's turf.

I happened to be in Espoo shortly after the burning platforms memo, and it did not land well, specially since the Qt and PIPS effort was finally gathering some support.

As far as i know .NET binaries cannot run from a network share which is a big limitation.

Not actually correct. You needed to fiddle about with code access security using the caspol tool and then they'd run just fine.

.NET 4 disables CAS by default though there can still be a bit of faff to get an exe to launch from a file share, but it is doable.

.NET core abandoned CAS (https://docs.microsoft.com/en-us/dotnet/core/compatibility/c...)

When there are issues and one owns the runtime, there is a way to fix them, when there's a willingness.

Not really a disagreement with pjmlp, but MS has had several internal projects like this, where they create an “ideal state” for some part of their software portfolio, then incorporate learned lessons into their existing software packages. The blog posts linked elsewhere in the discussion threads and the one I’ve included below give examples of how both Singularity and Midori contributed to other projects, including C++, C#, .NET, and Windows.

https://www.zdnet.com/article/whatever-happened-to-microsoft...

Well that is just my point of view, following Microsoft ecosystems since MS-DOS 3.3.

Everything I state comes from reading between the lines from ways things have been written, presented and so forth.

I might be wrong, obviously.

Sounds like your read is pretty dead-on. My comment was more of an “and” to your’s.

I have been noticing recently people experimenting with things like WASM kernel modules, and even having the kernel itself (or maybe it was a supporting root-owned process?) compile Rust code in a way that validates it doesn't do any dodgy and then loading the result into the kernel. It makes me wonder whether there might be a way to achieve many of the benefits of microkernels without the inefficiencies and complexity ("everything is now a distributed system") that has held them back in the real world. It sounds like Singularity was pushing in this direction, so maybe I should pay more attention to its spiritual successor Midori.

I also wonder whether there's anything stopping _Linux_ slowly becoming something more like this over time by supporting kernel modules that have direct but _limited_ access to talk to each other in more ways that can be verified at load time. In theory even some kinds of "arbitrary shared memory" patterns could work just fine, and get you pretty close to the best of both worlds even with supporting "binary blob" drivers etc. Instead of requiring modules to be compiled to a special kind of bytecode (which would require compiler support), maybe you could even create some special conventions for how memory is accessed by these sandboxed kernel modules (fake syscalls or something?) that let them be rewritten at load time.

I guess it boils down to: how much could you statically verify the behavior of a kernel module without preventing from having the flexibility to do what it needs to do?

> I also wonder whether there's anything stopping _Linux_ slowly becoming something more like this over time by supporting kernel modules that have direct but _limited_ access to talk to each other in more ways that can be verified at load time.

You are more or less describing eBPF and the evolution you are wondering about has indeed started slowly happening for some years now.

It does however use special bytecode but getting compiler support is not such a hard problem compared to building the safe VM.

Sounds a bit like Google’s Native Client, which was kind of superseded by wasm. https://en.m.wikipedia.org/wiki/Google_Native_Client

It's rumored that Midori was built on Singularity, so it's much more than a "spiritual" successor if that's the case. (Also sadly discontinued as well.)

To my understanding, Midori evolved out of Singularity

Sure, my remark was more intended to convey that I usually expect the phrase "spiritual successor" to be used for something where there's no direct shared ancestry/code between two projects other than "hey, you had some good ideas", which I would be astonished if were the case here.

I couldn't tell you how much of Singularity remained in Midori, but to give some context, this was a team that was not afraid to rewrite, often significantly, there was essentially a closed environment, so you could make what would be a breaking change in any other environment, and be sure that everything still built and ran.

Example: I completely rewrote the process loader to load binaries from "the cloud" and other than a heisenbug caused by a misconfigured F5 router that had us scratching our heads for a couple of months, everything just kept working

I mean, that's one way to handle package management. Wow.

It's a shame that it's not going to see the light of day, it sounds like it'd be invaluable to see the decisions and mistakes made.

Search for OS/400 language environments and TIMI.

I've long believed that OS/400 is a path not taken in systems programming, one that would have been much more influential had it happened outside of IBM.

The core concept described here significantly overlaps with an OS idea from the 90s that sadly didn't go anywhere. The system was Opal, from the OS group at UWashington CS&E and in particular Jeff Chase.

The key idea in Opal was to put all processes in the same address space (like Singularity does), but to use hardware systems to provide memory protection (whereas Singularity relies on "software mechanisms"). Communication between processes now becomes as simple as one process giving the other a pointer (obviously it has to refer to a page with appropriate access). As with Singularity, the overhead of TLB flushes and page table management goes away, making context switches much faster (especially for large working set processes). To quote:

> Protection in Opal is independent of the single address space; each Opal thread executes within a protection domain that defines which virtual pages it has the right to access. The rights to access a page can be easily transmitted from one process to another. The result is a much more flexible protection structure, permitting different (and dynamically changing) protection options depending on the trust relationship between cooperating parties. We believe that this organization can improve both the structure and performance of complex, cooperating applications.

You can read lots more about Opal here (it's all quite old now): https://homes.cs.washington.edu/~levy/opal/opal.html

I still think it's one of the best OS ideas ever, and I'm sad that it never really came to fruition.

Thanks for sharing the link.

Fun fact, Wroclaw's University of Science and Technology, one of the leading STEM-focused colleges in Poland, teaches about Singularity as something really new and innovative. They also teach service-oriented architecture and peer-to-peer networks that might, at some point, enable decentralized transfer of money, as if Bitcoin never happened. When I was looking at that specific course, it definitely gave me early 2000s "make everything p2p" era vibes.

This is doubling down on the mistake of .NET, it won't end well.

We need a microkernel based OS that uses hardware protection to keep all the user code well contained. We need a default assumption of NO when it comes to access to resources, instead using capabilities and powerboxes.

What happens if actual native code gets run somehow by a user processes in this system? The system is owned, instantly. There's no secondary layers of protection at all. It's like counting on a single cable to support a bridge.

> it won't end well

Per the article, it ended in 2008. Beyond that, there are probably dozens of embedded systems I interact with every day where I would choose performance over the level of security you're suggesting. Beyond even that, I lived through an era of multi-process machines before MMUs were ubiquitous, and the main problem wasn't that malware had root access, it was that poorly written code would corrupt the memory of other processes and the OS, which this system solves.

How does this solve it? If native malicious code gets executed, there is NO backstop what so ever.

Unless there's a bug in the JIT compiler, managed code can't accidentally write into another process's memory or jump to an arbitrary address, meaning that when an application goes off the rails it only crashes itself.

Can we agree that IF there is a bug in the compiler, THEN the system will be compromised?

>We need a microkernel based OS that uses hardware protection to keep all the user code well contained. We need a default assumption of NO when it comes to access to resources, instead using capabilities and powerboxes.

Does Zircon/Fuschia fit the bill at all?

https://fuchsia.dev/fuchsia-src/get-started/learn/intro/zirc...

> Each SIP is actually sealed — They can’t be modified from outside. There’s no shared memory between different SIPs, no signals, only explicit IPC. There are also no code modifications from within — no JIT, class loaders, dynamic libraries

So obviously this would never fly in the real world. Did they ever resolve how to make JITed code work? Maybe in separate container space that didn't have full privileges?

As an interesting related data point. Edge has a mode with no JIT and it might be usable for a lot of practical scenarios: https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...

Our current software is designed around a particular set of operations being the "expensive" ones. Maybe other configurations are workable too, with enough rearchitecting. For example, Singularity IPC looks like it should have about the same cost as a typical userspace dynamic library function call.

(IMO the main problem with Singularity's approach is instead that it leaves everything wide open to Spectre...)

At least in Midori, there was an escape hatch that, IIRC, was only used for the JavaScript engine, but that allowed some of the constraints to be broken.

Ever heard of iOS?

In any case, AOT and OS IPC cover most cases, welcome to UNIX pre-shared-objects.

In any case, Midori had another approach.

Are we talking about this iOS? https://developer.apple.com/documentation/javascriptcore

Exactly and that JIT case is special purpose, only available to Apple themselves.

Even WinRT added back VirtualProtect with execute permissions after trying to ban it. And on the Xbox One and Xbox 360, they wanted to make the hypervisor enforce not making arbitrary pages executable (requiring the equivalent of VirtualProtect to provide crypto signatures), but needed an escape hatch for their back compat emulator.

iOS is just willing to cut themselves off of entire classes of applications in a way that a lot of systems aren't.

Because they can allow themselves to push their way through.

Adding back VirtualProtect to WinRT has hardly helped to improve its uptake.

Had Microsoft played an Apple move, probably WinRT would look much better nowadays.

> Software-isolated processes

Is it true that this idea is dead nowadays, because of Spectre-style attacks?

It has nothing to do with Spectre. Spectre exploits Intel's (and tbf others') mistake of changing the processor's global state when speculatively executing code. Intel could fix it either by always checking permissions before spec-ex, or by transactionally rolling back all global state changes (e.g. cache lines) when permission failures are detected.

Edit: I misunderstood your question. Yes, Spectre cannot be fixed with software. But if Spectre were fixed in hardware (as it must be in new designs), software process isolation could still work barring new undiscovered hardware vulnerabilities.

Isn't eBPF basically the same idea?

Yes, but it is more restrictive, e.g., it is not Turing complete. I’m not sure whether this directly addresses Spectre risks though.

An analysis of Spectre and software isolation is here:

https://arxiv.org/abs/1902.05178

>> can we do it better?

>> can we improve security and robustness?

>> can we prevent unexpected interactions between applications?

Of course you can. Are there incentives, though, for MS to do so?

>> Goals [...] Lack of robustness

Did Windows 11 _have to_ become dependent on users' internet connection? I don't think so.

Are there incentives that would guide MS towards not introducing a complete and utter dependence on the net, thereby making it possible to opt-out from their telemetry?

ive been using windows 11 in a vm with no internet with zero problems, i think you are mistaken

Are you by any chance using Windows 11 Professional, a version my mom, her sister, their brother and 99% of my cousins will not get their hands on, because they are not "pro" users, they are "home" users?

It should be made illegal for some softwares, such as an OS, to be able to force you to have an internet connection or create an account.

Almost all devices containing a CPU run an OS. Can none of them, like IOT devices have service based accounts? This would make illegal almost all current consoles as well. I understand your ire at Microsoft but I don’t think massacring huge swathes of the current device ecosystem is proportionate or necessary.

> This would make illegal almost all current consoles as well.

Good! The inability to play a local game by putting in a disc and playing is enormously stupid, possibly even more than with a general purpose computer.

I'm pretty sure you can play games on consoles without creating an account on some service, at least in last gen consoles. Did that change with the current gen?

The Switch does work offline, as does the PS5; Xbox X is unclear (different sources give different answers), Xbox S can't (https://answers.microsoft.com/en-us/xbox/forum/all/set-up-xb...).

Perhaps I should amend to "would be enormously stupid".

You can have service based accounts. They should just be always optional.

You have the option not to buy the product.

I'm not taking an absolutist stance on this, I think there's scope for regulation of how accounts can or cannot be used and privacy protection of user data. I just don't think eliminating online accounts is practical.

You also have the option to live in a cave, or to kill yourself.

But I don't think we should use them in a reasonable argument.

There is no alternative product.

Stop making things illegal. Find a smarter way.

Yeah, let's stop making murder illegal. I'm sure there is a smart startup that can disrupt it.

This is a category error.

"Its last release was in November 2008 and since then the project was stopped."

may add 2008 to title, cause thats when the project was stopped

Microsoft has such impressive research and such great developers. Makes it all the more frustrating what their products end up like (I’m guessing due to leadership).

> Makes it all the more frustrating what their products end up like (I’m guessing due to leadership).

"Need to make money" is the main reason, actually. Leadership are merely running after that.

If there's one "conspiracy theory" I'm inclined to believe is that Microsoft deliberately makes every other Windows version subpar to the previous in order to make the market (that has the memory of a goldfish) applaud the follow-up for... going back to what to how things used to be with a few tweaks in between.

It's like they thought that keep improving on the things they work would make them hit a ceiling so instead of steadily climb they take one step back to delay the climb.

And the reason why I think it's deliberate is because none of their other products follows that pattern: Azure faces fierce competition so you cannot afford to stumble, C# is amazing compared to Java at least, Office has alternatives breathing on their back, VS Code... used to have competition but now that it's super popular I'm scared it'll be the next product to follow the "Windows progression pattern".

I think it’s more likely a company that size and the technology as a whole keeps them stuck around a local maxima, only able to iterate around it.

fwiw, VSCode is very impressive. I often forget I'm using an electron app.

Which is a big reason why I'm consistently surprised at how terrible Microsoft Teams is, despite also being made with Electron.

One of my favorite "just why" moments in Teams: let's say I have an image, `foo.jpg`.

I share it once and it gets uploaded to Sharepoint (as `foo.jpg`). This happens even if you're just sharing a funny image in a private message. It gets uploaded to Sharepoint. Ugh.

Anyway, let's say I share the same image again. Teams says "hey do you want to overwrite `foo.jpg`, or keep the existing one?" I select keep. Teams now creates `foo-1.jpg`.

We're already off to a bad start, but bear with me. Here's where it gets amazing:

1. I share `foo.jpg` a third time.

2. Teams says "Do you want to overwrite or keep?" I select keep.

3. Teams then again asks "Do you want to overwrite or keep?", because `foo-1.jpg` is taken. I select keep.

4. Teams tries to create `foo-2.jpg`. Return to step #2 until an unused integer is found.

That chain of dialogs can continue for a while for common file names on large teams.

One of the biggest reason I find teams not usable for teams. And so easy to fix, just assume when the user does not want to overwrite the first file that they don't want to overwrite consecutive files.

Aside from the annoyance factor, this is a huge gaping hole allowing information leaks. Let's replace `foo.jpg` with `Annual Review 2021.pdf`. You send employee #1 their review, and then send employee #2 theirs, but forget about this quirk, and instead of keeping, you overwrite. Now employee #1 can open employee #2's confidential info in their link.

Thankfully (I guess?) that isn't a problem: the files are uploaded to Sharepoint folders specific to conversations or channels.

So the issue I detailed would only rear it's head in your scenario if you sent employee #1 their review twice.

Humorously, this issue does not occur when uploading files directly in the Sharepoint interface – despite the interface looking like it stepped out of Windows 95.

I'll have to verify this tomorrow, but I am 99% certain I have seen this message when sharing the same file name between different 1:1 conversations. I guess it's possible that it is a configuration issue since our Teams/SharePoint is self-hosted at my company.

Yeah, I am not a licensed Microsoft config guy whatsoever, but do know that Sharepoint can be configured to the moon and back. That was, after all, the reason my old org went with Teams over Slack.

So it's not hard for me to imagine that it could be set up in a way that causes this issue across discussions. Yuck.

Man I hate this. I sort of get wanting to support robust file sharing for teams, but let's be honest: 99% of file uploads on teams are going to be silly gifs.

It is also SO SLOW. It's so slow. Uploading images takes full seconds before they can be sent because Teams has to put them onto Sharepoint first (which itself is slow).

For those still on Teams, my condolences, here's a workaround: copy the image onto your clipboard and paste it into the textbox. It skips the uploading to Sharepoint, prevents the issue I described, and is sendable in milliseconds. Downsides: a. they're randomly ephemeral and sometimes just permanently disappear, b. no animated images - it'll just send the first frame of a GIF/APNG/etc.

And for those on macOS, that means you can get screenshots sent quickly. Ctrl-Cmd-Shift-3, Cmd-V into the text field. Send.

I have stumbled over the same problem and wondered why at minimum it isn't able to recognize that this is the identical file and not ask. Also, it should be able to reshare one file already uploaded.

Only until I have to open Task Manager to see what's hogging my memory.

Ha, usually it's a game of "is this vscode, postman, chrome, or all of the above?"

Chrome. It's Chrome.

Many things, including OS, will take as much memory as you allow — this is by design/helpful in some cases.

Only the OS and applications intending to be the only application ever running on a box should do that. When normal applications do that, they don't have the information to share when their peers need those resources too.

Worth noting they didn’t use dotnet to build VSCode (and to a lesser extent Teams) when they could have.

Has or had? Singularity's last release was more than 10 years ago predating Windows 7 perhaps the most acclaimed OS release Microsoft had.

> and it was then when they came up with a pretty cool name for their new OS — Singularity.

Or, it was then when they (intentionally?) ripped off the name of an existing, open source, OS-related project. https://sylabs.io/singularity/

Sylabs launched their Singularity product in 2015,[1] whereas Microsoft Singularity is from the mid 2000s,[2] so the ripping off is in the other direction.

1. https://techcrunch.com/2018/02/08/sylabs-launches-singularit...

2. https://www.microsoft.com/en-us/research/project/singularity...

That, and every good name for a software project has already been used.

"Its last release was in November 2008 and since then the project was stopped."

AFAICT Sylabs Singularity started after Microsoft's research project ended, probably by some years. So no-one is ripping anyone off.

"Singularity began as an open source project in 2015 [...]" - https://www.top500.org/news/sylabs-brings-singularity-contai...

Whereas the last commit on MS' Singularity project is from 2010.

> Singularity is an experimental operating system (OS) which was built by Microsoft Research between 2003 and 2010.

Yeah.. They didn't AFAIK.

Lol you don't get to just claim a word for yourself forever.

Reading more carefully, this is an old project that predates Singularity containers.

I've run across so many software projects named singularity that at this point it's a trope.

Damnit. That was going to be the name of my project.

Trope? That's a good name.

So basically Erlang/Elixir style OS. They wanted to build Erlang, lol.

It is really hilarious!

> Utilize a safe programming language — no more of C’s shenanigans, we don’t want to “cook” pointers out of integers, no more manually freeing memory and no more buffer overflows.

C language is little mora than (portable) assembler. To the CPU the difference between pointers and integers is in the code, not in the type.

These people thinks C is unsafe. C is as safe as your design and skills. Yes, you need to be a very careful C programmer and still getting bugs. But also be able to squeeze all the juice out of your hardware.

The problem is C shouldn't be as safe as your design as skills, modern languages provide assurances that prevent programmers from shooting themselves in the foot and as we know, all programmers do that sometimes.

Reply on news.ycombinator.com