"Midori" Concepts Materialize In .NET

dp619 writes "Concepts outlined in Microsoft's internal 'Midori' OS documents are materializing in .NET, according to an SD Times report. Midori is a new operating system project that is designed for distributed concurrency. Microsoft has assigned some of its all-star programmers to the project, while recruiting others. It is also working on other projects to replace Windows that make the OS act more like a hypervisor."

Comments

midori???

[Anonymous Coward]

i will return???

Linus

[binarylarry]

Presumably this is the project they hired Linus to head up? /ducks

.. i must have seen that before

[Anonymous Coward]

Oh, you mean something like a micro-kernel (hypervisor like mini-OS to run a full fledged one on top)?

Re:.. i must have seen that before

[Anonymous Coward]

sounds like this is minix++ (or even minix#). A hypervisor is much more powerful than a regular mickrokernel, because it can spawn off vm's with protected 0-ring privileges.

Re:.. i must have seen that before

[shutdown -p now]

If it's anything like Singularity, then the point is to exploit static memory safety analysis (which is possible for sandboxed managed code) to avoid the overhead of virtual memory protection. Basically, if you have two processes for which you can statically prove that they never try to access each other's memory (e.g. because all pointer accesses are via pointers which are derived from heap allocations for that particular process, and no arithmetic is done on them that can put the result out of bounds of the original allocated block), then you can safely run them in a single memory space.

Re:.. i must have seen that before

[ShadowRangerRIT]

Midori is just a first stab at a commercial version of Singularity. When I was working at MS a few years ago Midori was already being worked on; some of Windows built-in apps were being converted to run on it so they had something to test with it. It's not exactly new, and it's only a step or two from the Research group; I don't expect to see an actual released OS from the project for a long time.

From my impression of the project, it was mostly about finding a way to make the OS scale to massively multi-core machines; Windows can run on a many-core OS, but eventually all the locking and contention at the kernel level starts costing you a lot. Both the OS and the associated .NET-like language are designed to put constraints on the programming such that the processes can be parallelized efficiently without excessive locking.

Re:.. i must have seen that before

[Anonymous Coward]

Yebbut is it good or is it whack?

Re:.. i must have seen that before

[shutdown -p now]

Depends on how you define either one.

Anyway, Wikipedia has a more detailed high-level description of Singularity, and the source code for it is available (use, modification and redistribution allowed non-commercial academic use only - not FLOSS). Assuming that Midori is a further development from that (and we don't really know), you can take a look at those two and judge for yourself.

Re:.. i must have seen that before

[pydev]

If it's anything like Singularity, then the point is to exploit static memory safety analysis (which is possible for sandboxed managed code) to avoid the overhead of virtual memory protection.

That's been tried many times before, including with runtimes like Java, with signed code, and even with program analysis.

It's going to fail. Most of the commercial processors have virtual memory hardware. Even if eliminating it would result in speedups, no processor without virtual memory hardware is going to be optimized as much as the mainstream processors that have it. As a result, in practice, this is going to be slower. And even if they succeed in that, we would have to throw away most of the software and compilers we already have; it's not going to happen.

A much more sensible way is to add some kind of pointer verification to our processors. That way, existing programs could run more safely without a rewrite. In fact, that's already feasible for many programs even just using existing hardware, and hardware changes would be minimal.

These Microsoft projects are just academic; they are not going to lead anywhere. But even as academic interests, they don't really deliver much innovation.

Re:.. i must have seen that before

[shutdown -p now]

That's been tried many times before, including with runtimes like Java, with signed code, and even with program analysis.

It's all of the above, with DbC thrown into the mix.

It's going to fail. Most of the commercial processors have virtual memory hardware. Even if eliminating it would result in speedups, no processor without virtual memory hardware is going to be optimized as much as the mainstream processors that have it. As a result, in practice, this is going to be slower. And even if they succeed in that, we would have to throw away most of the software and compilers we already have; it's not going to happen.

Probably not in near future. However, consider this: Windows Phone 7 restricts software to managed & sandboxed only. Is it just to limit features and contain potential malware, or is there a long-term plan there?..

These Microsoft projects are just academic

True.

they are not going to lead anywhere.

That doesn't follow. Typical software development methodologies and tools of today were considered academic a few decades ago (e.g. OOP was an obscure academic experiment for quite some time; more recently, FP has been transitioning from academia to mainstream).

Re:.. i must have seen that before

[master_p]

but eventually all the locking and contention at the kernel level starts costing you a lot.

Locking and contention is a matter of design. It the Windows kernel does not scale well for multicore machines, it seems it is not designed correctly; just like Linux had a big kernel lock a few years back.

Both the OS and the associated .NET-like language are designed to put constraints on the programming such that the processes can be parallelized efficiently without excessive locking.

And if I want to write assembly because I have a part of my app that requires performance not offered by .NET? Then I would have to use another operating system.

The real issue in scaling is the hardware. I don't understand why CPUs don't offer hardware-based in-process component isolation. As CPUs are currently designed, it's all (no isolation) or nothing (user-supervisor mode). There needs to be a better component isolation between components within a process.

Oh?

[Zixaphir]

Midori?

Re:Oh?

[Minwee]

And here I thought it was Midori. Perhaps she and SteveB could discuss alternative uses for chairs or something.

Re:Oh?

[Anonymous Coward]

And here I thought it was Midori.

Re:Oh?

[Zantac69]

And here I thought it was Midori

Re:Oh?

[Snarf You]

And here I thought it was Midori.

Re:Oh?

[Anonymous Coward]

It's original research name was Singularity

Re:Oh?

[Anonymous Coward]

And here I thought it was the Japanese word for "green" ...

Re:Oh?

[Anonymous Coward]

That explains Microsoft's design process pretty well.

Re:Hypervisor

[sopssa]

What are you smoking? Windows kernel itself hasn't really been vulnerable to anything, it's the third party software like Flash, Adobe PDF Reader, internet browsers, and previously some services.

Re:Wasn't Windows 95 and 98 built from the ground

[x2A]

Win9x were built upon DOS (although replaced and virtualised it underneath itself) and provided win16/32 calls etc as subsystems. They're talking here about a fresh codebase that runs as a hypervisor and executes managed code. The idea basically being kinda like a microkernel but with increased isolation using newer virtualisation technology rather than the old erm... virtual memory technology... which has never really been used to its full potential I don't think.

Re:Hypervisor

[Zixaphir]

Internet explorer is third party? O.o

A hypervisor

[nurb432]

That is tied to the Microsoft 'cloud' for its core functionality.. A return to the mainframe days where if you don't continue to pay, you don't have squat.

Re:A hypervisor

[ShadowRangerRIT]

What are you smoking? Just because the OS supports distributed concurrency doesn't mean a cloud OS. The design is intended to support massively multi-core machines; the same techniques happen to be useful for distributed concurrency as well, but Midori isn't a cloud OS any more than an OpenMPI "OS" would be.

Re:A hypervisor

[nurb432]

Smoking? No. However i do read papers that Microsoft publish that outlines their long term roadmap.

Midori is a step in the direction of a cloud based desktop, which is a stated goal. ( as is the current slow migration of their back office products )

Re:Hypervisor viruses

[nurb432]

Sure there is a small potential, but it works well for 100's of thousands of ESX installs..

Re:Hypervisor

[davester666]

They're just trying to make it so their problems affect everybody. That way, it's more likely that things like this http://www.computerworld.com/s/article/9164438/Microsoft_s_security_chief_suggests_Net_tax_to_clean_computers would be seriously considered by governments for example. And it becomes a way for them to try to reclaim Linux servers [so you still pay a Microsoft tax even if you run Linux servers...

Re:Hypervisor

[Anonymous Coward]

It may as well be.

Re:Hypervisor

[The MAZZTer]

Then what is Microsoft patching every month?

TFA

[Steauengeglase]

An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.

Yep, bright future ahead.

Re:TFA

[Anonymous Coward]

I'm picturing a kind of big, "war room" like board with "Incoming slashdot effect!" signs lighting up, blaring sirens, and all sorts of people running around crazily with fire extinguishers or hiding under their desks in fear.

Don't worry, guys. I'm sure some people at sdtimes.com will survive in the basement shelters.

Re:TFA

[Anonymous Coward]

Quick! install X11 on there servers, so we can run a browser from the local machine and see the actual error message!

Re:TFA

[commodore73]

I doubt you tried this, but I seem to remember that if you did a view source on some error pages returned from some versions of IIS, they show the stack trace, even though the configuration implied that it hid error details. I don't know if this is the case anymore. Security by attempted obscurity is no security at all.

Re:Hypervisor

[Anonymous Coward]

I believe he was stating that Microsofts ring 0 processes usually arent the security risk.

where are you getting at?

[FuckingNickName]

As always, MS, you're right that there are abstraction improvements which can be made at systems and app level, but as always, MS, you're never clear about what the problem is and what you're offering with your solution.

What do I get with Midori that I didn't get before? What's going to improve, for programmer or user?

Re:where are you getting at?

[Anonymous Coward]

It would help if you'd bother reading the docs on Midori and the Singularity core it's built on.
For starters it's a microkernel, which, at least according to Liedke's principal of minimality offers flexibility and reliability through minimality. Because everything that isn't part of the microkernel is isolated from the kernel, and from other processes (via SIPs (Software Isolated Processes)) a service that crashes or goes goes does not take the kernel or anything else with it, instead the "service" is stopped, and detatched from everything depending on it, restarted and reattached - crashes behave like a web browser would, should the internet connection be severed - it just sits there and wait for the connection to be re-established, leaving you with a much more robust and reliable system.

Second, it also "acts like a hypervisor" (mind you, a hypervisor is little more than a glorified microkernel which doesn't completely adhere to Liedke's principal of minimality), to run an OS written entirely in managed code (Sing# and Spec# in this case, IIRC) which conveys they security benefits of managed code to the entire OS, leeaving you, once again, with as more secure and more reliable system, with a fun bonus that what is essentially the .NET framework becomes to Midori, what Win32 is to previous and current edditions of Windows.

There's also the ease of debugging and management argument; which is easier to manage, debug and ultimately least likely to contain critical bugs, a 4,000 line kernel, or a 15,000,000 line kernel? And the performance argument of old regarding microkernels don't apply here (and haven't really applied anyway, since L4 and much more so when hypervisors started popping up all over the place), I don't recall the number OTOH (but they're available at MSL's site under the section devoted to Singularity), though they manage to put out impressive perf numbers,. apparently mostly due to its use of SIPs, rather than more traditional means of process isolation..

All the information is readily available on MSL and has been for quite some time, in fact, the Singularity RDK has been freely available for at least two years now, and the whitepapers and such for longer. You'll find that MS has been fairlt forthcoming regarding the answers you're looking for.

Re:where are you getting at?

[Anonymous Coward]

These articles were not written by Microsoft to promote itself. These articles were written by outsiders to discuss the implications of the extremely little that people know about Midori.

Re:where are you getting at?

[FuckingNickName]

No, you're inventing a problem ("insecure, hard to manage kernels/services") and proposing a solution ("the microkernel!") in the style of Tanenbaum vs Torvalds back in '91. There tends not to be a problem with stable, insecure kernels on modern server platforms.

MS appear to be offering an Ocaml implementation, right? And then want to implement everything system-flavoured under it, in the style of a LISP machine, right?

Re:where are you getting at?

[BitZtream]

Its going to be exactly like we have now, except basically you'll have two layers of kernels and abstraction to go through instead of one!

Re:Hypervisor

[AndrewNeo]

The userspace?

Re:Hypervisor

[Lunix Nutcase]

The userland api and applications, mostly.

NUMA + MPI?

[Anonymous Coward]

Well, I personally tested a 4 processor 32 cores 64 threads beast.

I have found that with integrated RAM controllers connected to separate RAM banks and without going to NUMA + MPI, one would simply waste CPU cycles waiting for RAM transaction to complete.
Local MPI helps a lot but requires a lot of code re-shuffling.

In few years multi-core single CPUs will choke on memory bandwidth too and we will have separate RAM controllers on die.
This will bring NUMA and MPI horros to a desktop PC.

So yes, I think I see where it goes: to something more manageable then MPI, with .Net wrappers and such.

Re:Hypervisor

[Jahava]

What are you smoking? Windows kernel itself hasn't really been vulnerable to anything, it's the third party software like Flash, Adobe PDF Reader, internet browsers, and previously some services.

So here's what Google has to say on the subject:

• Vulnerabilities in Windows Kernel
• Vulnerabilities in Windows Kernel Could Allow Elevation of Privilege (977165)
• Vulnerability in Windows Kernel Privilege Escalation
• GDT and LDT in Windows kernel vulnerability exploitation
• Vulnerability in Windows Kernel Could Allow Elevation of Privilege
• And many more...

For the lazy reader, almost every article here has the phrase "An attacker who successfully exploited this vulnerability could run arbitrary code in kernel mode." For the even lazier, allow me to summarize: "That's a Bad Thing"

Indeed, like any long-lasting public multi-version kernel, the Windows kernel has had a hefty share of vulnerabilities. What you said is just plain false. However, to the OP:

So this means your hypervisor can get infected? Is it really such a great idea to use the largest individual security risk in computers as a hypervisor?

You may want to think a little harder about what you mean by kernel. Every hypervisor is a type of kernel. Some things that perform hypervisor-like roles are full-fledged kernels. However, if you actually click the link in the article that you're quoting, you'd see that they're not talking even remotely about what you think they are. The article details how Microsoft is investigating changing some fundamental (read: legacy, UNIXy, etc.) kernel models and roles to take a shot at getting more successful multicore performance and a better user experience. It's less about "zomg Windows is a hypervisor" and more about "what traditional Kernel roles can we modify?"

If you understood even fundamental systems architecture concepts, you'd realize that Windows as a hypervisor is a lot less scary than Windows as a standalone OS, as the latter is not only handed full system control, but is also responsible for arbitrating userspace execution.

Re:Wasn't Windows 95 and 98 built from the ground

[ka9dgx]

Managed code doesn't fix things, because it doesn't allow the user to decide how his computer should be used by an application he's decided to execute. Nothing to date seems to do this basic task, outside of some stuff in research or military land.

Re:Where is the Borg King?

[K. S. Kyosuke]

Given that the topic is "distributed concurrency", I find the Borg Gates pic especially fitting for the occasion. :)

Re:Hypervisor

[virgilp]

Name one successful Flash exploit out there. I could name several in the core windows services... Conficker, for one.

Corrections regarding F#

[shutdown -p now]

There are a few things in SDTimes article, in the bit where they talk about F#, which are incorrect:

For instance, F# is highly immutable—meaning that object states cannot be modified once created

This isn't really true. F# defaults to immutable locals and record/object fields, but you can always declare them as mutable explicitly if you want. In that, it's quite similar to OCaml, and quite different from Haskell. Example:

type Foo =
  let x = 0 // immutable field
  member this.Bar() =
    let y = x // immutable local
    y <- y + 1 // error
    x <- y // error
 
// Mutable class
type Foo =
  let mutable x = 0 // mutable field
  member this.Bar() =
    let mutable y = x // mutable local
    y <- y + 1 // okay
    x <- y // okay

And then also:

... and has an implicit type system

There's nothing "implicit" about F#'s type system - it's quite in-your-face, in fact even more so than in a typical OO language such as C# or Java. For example, it won't do automatic upcasts.

I guess what they meant there is that F# has Hindley-Milner type inference.

Re:Corrections regarding F#

[GigaHurtsMyRobot]

Great post... no mod points. I looked into F# for a work project and was very interested in learning it, just haven't found the time.

Re:Corrections regarding F#

[EvanED]

There's nothing "implicit" about F#'s type system - it's quite in-your-face, in fact even more so than in a typical OO language such as C# or Java. For example, it won't do automatic upcasts.

Actually "implicit" is a pretty decent description of type systems that do type inference.

What's the definition of "implicit"? Random House says (for the first definition), "implied, rather than expressly stated." But this is exactly what happens in a language like ML or Haskell. If I say "fun f x = x + 1", I have not expressly stated that f's type is "int -> int", but that's exactly what that code implies.

Re:Corrections regarding F#

[EvanED]

In fact, take a look at that Wikipedia article that you linked to. Here's how it starts: "Type inference, or implicit typing, refers to the ability to deduce automatically the type of a value..." (my emphasis).

Re:Corrections regarding F#

[shutdown -p now]

Fair enough. I must admit that it's the first time I've heard the word used in this context, though. But then I can't even complain about how WP may be incorrect, since I was the one to link to it... pwned all the way. ~

Re:Corrections regarding F#

[RAMMS EIN]

Of course, typing in F# (assuming it works the same way as in OCaml, which, as far as I know, it does) is not really implicit, it's just that the types are specified by the operations when they aren't specified explicitly.

If you write

let f x y = x + y

the + says that x and y are ints just as surely as if you had written

let f (x : int) (y : int) = x + y

Still, it is true that, in the first example, the name of the type doesn't occur anywhere. So I think that is what people mean when they say "implicit".

Re:Corrections regarding F#

[shutdown -p now]

Of course, typing in F# (assuming it works the same way as in OCaml, which, as far as I know, it does)

It does with a few exceptions. Specifically for + (and other arithmetic operators), they're overloaded on int and float, rather than having separate operator +. etc for float as in OCaml.

However, they're not properly polymorphic, in a sense that there's no way to constrain a type on "having operator +" (which would require proper type classes) - so, when it sees + in a context of some unknown type 'a, it has to constrain 'a to be a specific type with +, and it always picks int, so your example still works as described.

Re:Wasn't Windows 95 and 98 built from the ground

[K. S. Kyosuke]

"and executes managed code."

...rendering hopelessly inefficient all the programming languages that won't fit the execution model of the one particular managed code spec that MS chooses to implement. Goodbye, Scheme, continuations etc.

No good

[oldhack]

It left sour taste in my mouth.

Re:Wasn't Windows 95 and 98 built from the ground

[cjl224]

Windows 2008 is pretty much a hypervisor anyway with one 'guest' OS (itself). Installing the HyperV role only really virtualises the hardware and exposes the functionality to multiple guests. Not entirely accurate but close enough.

Midori?!?

[Izhido]

What does my lovely Guitar Hero waifu have to do with anything MS does??

Midori?

[IGnatius T Foobar]

Forget about Midori ... I want to know when parts of Mojave will find their way into Windows and .net !!

Re:Hypervisor

[cjl224]

Well, there was that rootkit that intercepted a kernel call a month or two ago. That said, it was not an issue on x64 platforms and as MS have already dropped dev on 32bit server OSs, looks like they're going the right way to get away from that sort of thing.

Re:Hypervisor

[Anonymous Coward]

Where does it say the user will be acting more like a hypervisor?

It's green!

[Anonymous Coward]

> What do I get with Midori that I didn't get before? What's going to improve, for programmer or user?

Well, they're calling it Midori, so I'm assuming it's some kind of green tech?

Or at least the boxes the software comes in are green. I dunno.

Re:Hypervisor

[sopssa]

But it wasn't even Microsoft's fault, it was a bug in the rootkit code. They overwrote OS code they though never gets updated, and when MS update patched it.. well, crash.

Re:Hypervisor

[gbjbaanb]

What are you smoking? Windows kernel itself hasn't really been vulnerable to anything, it's the third party software

but there have been several security updates for the kernel, so its more a case of what are you drinking?

(the MS koolaid, obviously).

As for 3rd party apps, yes, that true there are way more vulnerabilities in them, but that mostly applies to the Windows userland apps. I can tell how many vulnerabilities there are in Windows simply by looking at my update history - all those critical updates aren't distributed for fun.

Re:Wasn't Windows 95 and 98 built from the ground

[jared9900]

Not to be an MS apologist, but IronScheme runs on the .NET (or more specifically CLR) platform. Also F#--which will be included in VS 2010-- supports continuations (found during a quick Google search of f# and continuations). Not that this effects me too much since I'm primarily using Linux/FreeBSD these days, but should I ever end up on an MS system based on these ideas there may still be hope.

Managed code?

[Suiggy]

Will this spell the death of of unmanaged programming languages like C and C++ and the respective software developers who uses those languages? How will people such as game developers, who are heavily entrenched in C++ development, migrate themselves and their game engines and code bases to this new operating system?

Re:Managed code?

[gbjbaanb]

I doubt it.

eg. from TFA:

The Midori programming model includes Bartok, an MSR project that endeavored to create a lightweight compiled and managed runtime system that was more efficient than the .NET Framework

So maybe its not quite .NET after all. Anyhow, I think this research project is something that they;'re using to take the good ideas out of - especially where they apply to cloud computing as MS doesn't really have much there yet and they see it as a great way of making you pay for a subscription to their software instead of a one-off purchase.

As for C/C++, there's a reason game programmers write in those languages and not .NET, though you do see some more strategy-based games coming out made in XNA, they're not at the cutting edge. Games sell either as mass-market, run-everywhere flash-type things (eg little games on your iPhone), or big super-graphically based ones. There's not that much market for .NET games that fall somewhere in the middle.

Re:Managed code?

[Suiggy]

Right, but if Midori replaces Windows, what's going to happen to PC gaming? All current popular gaming devices support native C/C++ development, including the iPhone OS and Android with the NDK.

Re:Managed code?

[gbjbaanb]

Right, but if Midori replaces Windows, what's going to happen to PC gaming

Bubble Bobble?

Re:Wasn't Windows 95 and 98 built from the ground

[BitZtream]

The problem is they can't fix Windows so their coming up with a unique and non-obvious way to start from scratch without telling everyone they are starting from scratch.

They aren't actually doing anything new. Its just a different way to implement EXACTLY what we have in OSes now.

The REAL problem is ... when you have all these systems interacting with each other, they ALL have to be secure or it falls apart. Rewriting it isn't going to change that. I mean, sure it will in theory, and it will in practice right up until the point where the OS actually becomes useful for something. Why? Because to actually be useful you have to interact with something else. Notepad is useless if it can't take keyboard input/display output. Its worth is questionable at best if it can't print. Saving and loading are rather important. Even in a simple app like notepad there are many interactions between components of differing levels of access. By the time 'Midori' becomes useful, all these things will be back.

Applications within the OS are already supposed to be 'virtualized' and 'isolated' ... you know ... thats what the OS is supposed to do already.

All we're doing is making the shared portion of our computers smaller and smaller, which means bloat bloat bloat and issues with updating all the various bits multiple times.

It really bothers me that people thing vmware/hyper-v/virtualbox are acceptable. If the OS actually did its job right, these wouldn't be needed. When you use these tools you're just running multiple OSes. You've solved nothing and added more bloat and bugs.

Re:Wasn't Windows 95 and 98 built from the ground

[Cyberax]

Not exactly. Traditional microkernels turned out to be too slow and complex because of high overhead of context switching and complexity of distributed algorithms.

Microsoft is planning to replace context switches with statically-checked managed code. Managed code by its nature can work WITHOUT memory protection at all. And unmanaged code (aside from some thin driver-support code) can be nicely segregated into virtual machines.

It's actually quite a clever approach, not without its problems, of course.

Re:Wasn't Windows 95 and 98 built from the ground

[K. S. Kyosuke]

Yes, and Gambit Scheme is still miles ahead. You will never beat native code compilers on this. If anything, microkernels are the way to go. Language-based security enforcement OSes work for...well, supported languages. All the others will be either slow (either interpreted code or compiled code with workarounds) or simply unsupported. Say "no" to serious programming language research on such a platform, unless unmanaged code will be supported as well.

Re:Hypervisor

[Anonymous Coward]

Did you just point your finger and say "Its not my problem, its their problem"? I thought so. Its not the car that's bad, its the roads, the gasoline, the weather, the tires, the air, the driver..... But... other cars go over those same roads, use the same gas, have the same weather, tires.....and they don't go boink all the time. So is it the theoretical showroom car (the one in the glossy magazine ads) that's the perfect version of the car, and only when you put the key in the ignition when the bad things happen (or dropping the analogy, when you press the power button).

Re:Wasn't Windows 95 and 98 built from the ground

[BitZtream]

Contrary to what their marketing would have you believe it isn't anything like that. Infact, its more like firing up Windows 7 and replacing explorer with the hyperv manager.

Re:Wasn't Windows 95 and 98 built from the ground

[psetzer]

That's the problem with any software that's not running on bare iron. A C program running on Linux is still limited in the exact same way that managed code is. It's just that the OS imposes those limitations with SIGSEGV rather than simply not deallocating referenced memory. If it really did let you do whatever you want that the hardware allows, that'd be a tremendous security hole.

Re:Wasn't Windows 95 and 98 built from the ground

[Anonymous Coward]

You miss the point. The problem with mainstream OSes is that once you run an app it's free to do anything you can do, which includes shitting all over your data. He's talking about limiting what applications can do, not letting them do more. Google Capability Security Model for details.

"all star programmers" huh...

[Anonymous Coward]

only 11 guys working on the next gen OS.
Good to know M$ is keeping the development team compact and agile.
Shouldn't take much more than 20 years for these 11 guys to get the RC1 out the door.

Offtopic, but I hope with an os redesign that they

[Anonymous Coward]

I just want an os with application level etiquette that doesn't steal focus from where I'm typing. It's very frustrating to type something, hit space as soon as some dialogue comes up, and not know wtf just happened... Or get an IM while typing an e-mail and find a few words in the IM window, possibly followed by making it permanent. This is made worse when the applications are slow and effectively prevents you from doing anything until it finishes because you know it'll steal focus.

It's my biggest pet peeve with computing today, and I hope they take advantage of this opportunity (of redesigning the os) to redefine how applications should work on it.

Re:Hypervisor

[Ozlanthos]

So in other words, a GUI interface with no real root access? If so, why is everyone trying to steal root from their users?

-Oz

Re:Offtopic, but I hope with an os redesign that t

[Kazoo the Clown]

I second that motion, kill ugly popups. Or at least, delay them until there's sufficient pause in my typing...

Re:Hypervisor

[Anonymous Coward]

Mostly.

Re:Wasn't Windows 95 and 98 built from the ground

[x2A]

"without telling everyone they are starting from scratch"

What?! That's exactly what they're telling everyone. A new system as a replacement to Windows, written from the ground up around extended concurrency models (to take more advantage of multicore/proc) and protection.

"They aren't actually doing anything new. Its just a different way to implement EXACTLY what we have in OSes now"

You think it inconceivable that the differences might mean things that you haven't thought of??

What if you forget about "malicious" for a moment (there's TPM chips for that) and think 'bugs'? With so many stability issues with Windows related to bugs in third party drivers and software, virtualising hardware interaction can be very beneficial, such as to the DMA chips. Without virtualising this, buggy drivers can end up reading/writing all over memory, beyond what permissions in the page table would allow CPU memory access. Windows wouldn't be the only OS to ever have problems with that occuring.

"Applications within the OS are already supposed to be 'virtualized' and 'isolated' ... you know ... thats what the OS is supposed to do already"

Well OSs often only really use a couple of the CPUs protection rings, with either all-in ring0 or all-out ring3. With "all or nothing", anything needing more than nothing needs to take everything. Evidentally whatever they're doing isn't always 100% successful, and one thing can crash another, even when there's no reason why those two things should be able to influence each other at all. Ignoring this fact and not putting some research into other ways of tacking the problem... well, would be pretty stupid, so I don't know why you would suggest that trying something that's not working in a different way would be a bad thing.

"All we're doing is making the shared portion of our computers smaller and smaller"

Yeah, why should your network card driver be able to read/write to memory allocated to your filesystem driver? These bits of memory shouldn't be shared. It doesn't mean "bloat bloat bloat"; you're not duplicating the filesystem drivers memory to allow the network card driver to write over its own copy of it "safely"; the network driver just doesn't get to see it at all.

"It really bothers me that people thing vmware/hyper-v/virtualbox are acceptable"

Well go on then Mr Perfect, write the perfect operating system that doesn't need them... making no mistakes ever, and not accepting any help of anybody who you couldn't absolutely guarentee wouldn't make any mistakes either.

It really bothers me that people think you should ignore a problem, and any solutions for the problem, simply because you don't think the problem should exist.

There's a reason why layers of abstraction occur in computing. Don't convince yourself that there can be no reason for something just because you can't think of it yourself. There's a lot of people out there. They will think of things you don't.

Re:Wasn't Windows 95 and 98 built from the ground

[x2A]

Ahh... of course, you do away with MMU overhead, TLB flushes, stack overflows, and you can still translate much (if not all) to native code... if you can do that with lower overheads than context switching etc gives you, you've got a win. I've never really understood though why OSs (at least on x86, which is all I can comment on) rely so soley on the page table and TLB flushing as they do, while ignoring selector based protection and having them just map the whole of their address space. Eg, your code selector should not allow higher memory access than the bottom of your stack, and as your stack maps from the top of the stack selectors limit, different processes stacks could be placed at different places in memory, rather than at the same "the top of the address space" which requires flushing those TLBs between context switches. I suppose it would make calling conventions harder where the stack's used for storage... I dunno, I'm rambling, just surprised they seem so under utilised.

Cheers for that info anyway.

Re:Wasn't Windows 95 and 98 built from the ground

[x2A]

"A C program running on Linux is still limited in the exact same way that managed code is"

Not really. Managed code will tend to grow buffers, moving them if need be, rather than allow one out-of-bounds write to a buffer overwrite something next to it as unmanaged code will do.

Those who don't understand UNIX ...

[BalkanBoy]

are condemned to reinvent it, poorly.

old hat; try solving the hard problems instead

[pydev]

These "operating system concepts" have been explored at length in systems like Plan 9, Inferno, Mach, various Java distributed toolkits, agent-based programming, and God knows how many more obscure operating systems and platforms.

As usual, Microsoft is late and non-innovative. If Microsoft had actually managed to deliver a commercial kernel based on those concepts, that might have been interesting. But just folding the stuff into .NET is the same kind of retreat everybody else who has tried this has made: they all started off dreaming of building the next gen OS, and they all ended up with a bunch of bloated libraries and frameworks that are barely used.

The tough part is not figuring out what the right thing to do is in this area, the tough part is figuring out how to build a real operating system around it that real developers and users will actually want to use.

Re:old hat; try solving the hard problems instead

[FuckingNickName]

I've already been awarded Troll for expressing my doubts that MS is clear about what problem it's solving (instead just experimenting with a tech and then shoehorning some of it into a low-risk existing product, as is typical for them), but I think it's clear that, aware that they can't just replace one OS kernel with another, their ostensible intention is to begin by offering their new magic as a VM on top of Windows. If Silverlight is their delivery platform, I'll be surprised if they don't get the same receiption as Java applets on the desktop, of course.

To analyse for a moment what they're trying to do:
1. Provide an Ocaml implementation;
2. In the style of a LISP machine, get as much as possible at system and app level running above (1).

(1) is ostensibly justified because performance increases today are supposedly about increasing #cores rather than increasing #MHz, while (2) supposedly helps OS performance in the same way as well as improving security.

Now, (1) is being trackled for now by improving the .NET VM, using underlying scheduling primitives of the existing OS. It could be done using any other number of concurrent language implementations.

But is OS performance a bottleneck? Is OS security a problem? Is there some other sort of integration advantage to (2)? As for performance, one would suppose that you're going to get the best out of optimising your system code for the hardware, and when you've done that, you provide the illusion of performance. Is system code really full of unsolved non-embarrassingly parallel problems? Are there locks inherent to(?!) bare metal operating systems which makes them unable to scale beyond a certain point? Or do we have to wait for trivial things because modern desktop operating systems provide no hard real-time style performance guarantees, instead sending off an instruction from layer to layer, pleased that it all works but blind to how long it sometimes takes to open a fucking Explorer window?

As for security, are there so many flaky mass market or enterprise level drivers that fail in ways which would not make the hardware unstable anyway? How often does Windows 2008/7 blue screen? Do I really care if we reach a level where my system hard disk driver can explode but, hey, at least I can continue doing anything which doesn't require the system hard disk? Is there really such a fear about rogue drivers making use of unrestricted DMA on desktop class machines to snoop into privileged memory? We have driver signing, which people click through blindly anyway - why wouldn't they also check the "grant UnrestrictedDMAReadAndWrite privilege", giving them access to functions which indirectly do the same thing?

Which brings me to integration. So we're abstracting CPUs with in a box, clearly... are we caring which box we're on? In the same datacentre, or in a different continent? With no single point of management? Taking account of where the UI is moved around to? Considering where data can be stored, how far it can be moved and how it's best to sync it? Which architecture/class? These are the less tackled engineering problems. Does MS want its solution to be a basis for tackling these further questions? Because you only get so far in the commercial world by saying "here's a tool, maybe you can do something cool with it?" For Midori, if you probe an adherent enough, they'll end up saying something like "Well, it solves Bob's Classical Concurrency Problem!!!!" and all I want to say is, "So do many other things - and who cares anyway?"

Stepping back a bit, as far as using the computer as a day-to-day desktop consumer tool, I want to see 1991 on the desktop again, where I could double click on a folder (on my cooperative multitasking OS) and it would open instantly. I want scheduling algorithms which care about the user who is staring at the machine, and policies which strive to guarantee particular performances. IOW, what Apple does with its iPhone/iPad, but without the kludge of limiting multitasking to a few app

Re:Hypervisor

[pydev]

Of course it's mostly the application programs and libraries that get hacked. But the Windows kernel is ultimately responsible for those vulnerabilities because it defines the security and protection model that application programmers have to use. A well-designed kernel should make it hard to write software that is vulnerable.

Re:Wasn't Windows 95 and 98 built from the ground

[setagllib]

Managed code by its nature can work WITHOUT memory protection at all.

How did you think the "management" worked? Either you trap each pointer access manually (and maintain all of that state and overhead), or you use a memory management unit to do it for you (and accept the cost of traps and context switches).

The very best that a VM runtime can do is infer that a class of access is impossible and thus exclude traps for it. This only works in extremely limited circumstances, and still requires code to be correct. It in fact makes profiling really difficult - and performance is the whole problem in the first place.

Will Linux get to enjoy "Distributed Concurrency"?

[Taco Cowboy]

So MS is gonna get this "Distributed Concurrency" thing into Windows.

How about Linux?

When will Linux get enhanced by "Lidori" (Linux version of Midori)?

Re:Wasn't Windows 95 and 98 built from the ground

[Mr2001]

The very best that a VM runtime can do is infer that a class of access is impossible and thus exclude traps for it. This only works in extremely limited circumstances, and still requires code to be correct.

That's exactly what "managed code" means in this context: the VM spec and the JIT-time verifier prohibit the types of accesses that would need to be trapped.

For example, you can't dereference a pointer that might point to any arbitrary memory location, because the verifier won't let you cast an integer to a managed pointer; you can only get a managed pointer by taking the address of a variable. You can't dereference a pointer to a local variable in a stack frame that no longer exists, because the verifier won't let you return the pointer out of that frame, and won't let any other function store the pointer anywhere except in an even deeper stack frame. This is checked statically, before the code runs, and then doesn't need to be checked again. (Certain operations do need runtime checking, like object casts and array access.)

The circumstances in which it works aren't really all that limited: just look at all the programs that have been written for .NET and Java. As for requiring code to be correct, well, that's what the verifier is for.

Midori is a web browser

[Anonymous Coward]

WebKit, GTK2, LGPL

http://www.twotoasts.de/index.php?/pages/midori_summary.html

Re:Wasn't Windows 95 and 98 built from the ground

[jpmorgan]

Not really. Managed code will use static analysis to prove that out-of-bounds writes will never happen.

Magically growing datastructures can be implemented in any language, managed or not.

Those who are too stupid to understand OS design..

[Anonymous Coward]

to comment on this article seem to be the ones leaving boring un-funny comments.

Re:Wasn't Windows 95 and 98 built from the ground

[vegiVamp]

SELinux / AppArmor, but more so, then ?

Re:Hypervisor

[Zixaphir]

Even so (joking aside this time), third party is not the correct verbiage to express that. Third party suggests made by a party external to Microsoft.

Re:Offtopic, but I hope with an os redesign that t

[RAMMS EIN]

I know what you mean, and I share your pain. This has long been a pet peeve of mine, too.

Interestingly, instances where focus has been stolen from me have markedly decreased in recent years, from where they were a constant annoyance to the point where I almost completely forget about the phenomenon and spend several minutes recovering after it happens.

The reason, it seems to me, is that I have switched to (1) terminal-based apps for most of my activities and (2) tabbed browsing. The result is that I really only have a few windows open at any given time, and I very rarely open new windows. This has made the focus stealing problem almost disappear.

Then I discovered that my next annoyance was window placement. It was never quite right, windows always ended up in the wrong place or overlapping the part of another window I needed most. Then I discovered tiling window managers, and that problem went away, too. I now basically have a bunch of full-screen windows which I can access by keyboard shortcut (e.g. Alt+1 is my terminal, Alt+2 is my browser). I've been using this setup for a few years now, and I have been happy with it.

Perhaps something similar will work for you. Good luck!