Linked by Dan Massameno on Wed 4th May 2011 21:28 UTC
Microsoft Microsoft has released new details on an experimental operating system concept named Drawbridge. In early March Microsoft researchers presented a paper entitled Rethinking the Library OS from the Top Down. The paper describes a new interaction between a user-level application and its OS. The paper can be found at the ACM Digital Library [frustratingly, we can't redistribute the article since it's behind a paywall, like too much of the scientific world]. It describes an ambitious plan to separate the traditional API parts of an OS from the underlying kernel of the OS. But a full analysis requires some background.
Order by: Score:
email authors
by jonsmirl on Wed 4th May 2011 22:20 UTC
jonsmirl
Member since:
2005-07-06

Every time I have emailed the authors at MS about paywalls they have put the article up on an MS server and sent me a link in a day or two.

Reply Score: 4

RE: email authors
by l3v1 on Thu 5th May 2011 05:42 UTC in reply to "email authors"
l3v1 Member since:
2005-07-06

That holds true for almost any publication you can find out there. I've done this, both ways - ask for and send out publications - multiple times, just go directly to the authors.

Reply Score: 2

RE: email authors
by Tractor on Fri 6th May 2011 13:20 UTC in reply to "email authors"
Tractor Member since:
2006-08-18

Every time I have emailed the authors at MS about paywalls they have put the article up on an MS server and sent me a link in a day or two.


Could someone ask for it ? browsing the source article sounds very interesting.

Reply Score: 1

terrible
by project_2501 on Wed 4th May 2011 22:30 UTC
project_2501
Member since:
2006-03-20

This is terrible. Look at the benefits - cleaner exits of applications, security. Instead of creating a simpler more elegant design they go the opposite direction and create a crazy monster solution... only Microsoft could make a virtue out of this.

Reply Score: 1

RE: terrible
by kaiwai on Thu 5th May 2011 02:51 UTC in reply to "terrible"
kaiwai Member since:
2005-07-06

How is it terrible? If you create an application and compile it into the said package then a future release Microsoft can make some radical changes and not have to worry about backwards compatibility. For example in Windows 8 they could make some major changes to the operating system such as removing old crufty APIs etc. and old applications using the packaging system would continue working without any problems.

It appears that Microsoft is moving towards a three tier model of backwards compatibility; virtualisation (hosting a complete operating system), the packaging model in said article and then native applications. As part of this packaging will it also include ARM/x86/x64 binaries all in one package? that would be a great feature if they not only provided the above packaging for compatibility but multiple binaries as well.

Reply Score: 3

Comment by fran
by fran on Wed 4th May 2011 23:57 UTC
fran
Member since:
2010-08-06

meaty article

Reply Score: 2

v They must be embarrassed.
by Shannara on Thu 5th May 2011 00:06 UTC
Very interesting....
by rdean400 on Thu 5th May 2011 00:07 UTC
rdean400
Member since:
2006-10-18

Microsoft's pushing the envelope. There have been some other entries in this field, including IBM i, which does a very effective job of decoupling applications from the kernel (but also goes farther than Microsoft -- the binaries automatically recompile to take advantage of hardware changes), and Oracle VM, which is a "no OS" appliance designed to run WebLogic.

This approach seems very appropriate for the virtualization/cloud wave we're on now.

Reply Score: 3

MinWin
by malxau on Thu 5th May 2011 00:19 UTC
malxau
Member since:
2005-12-04

Just to be clear, MinWin is not nor has ever been a new kernel. MinWin is a collection of the pieces at the lowest layers of Windows built in a standalone way. It is an attempt to enforce layering in the system - lower layers should not depend on upper layers to operate. WinWin should be thought of as a GUI-less subset of WinPE, which is (roughly) a subset of Server Core, which is a subset of fully fledged Windows. The kernel is the same in each.

The comments at the end of the article about security seem misguided about what the impact of the approach presented really is. If each application contains its own isolated usermode environment and talks to the kernel directly, the consequence will be more patching. If a bug is found in those layers, it needs to be patched in every application, as opposed to patched once in the OS. If an application is not being actively serviced, the user can be left more exposed to exploits rather than less. Not to mention the less efficient use of disk space, memory, etc.

The main benefit here, IMO, is allowing each application developer to test and deploy software in a tightly defined environment, to minimize the chances of an application misbehaving when deployed to the millions of random Windows installations out there.

Reply Score: 2

RE: MinWin
by kaiwai on Thu 5th May 2011 03:18 UTC in reply to "MinWin"
kaiwai Member since:
2005-07-06

Just to be clear, MinWin is not nor has ever been a new kernel. MinWin is a collection of the pieces at the lowest layers of Windows built in a standalone way. It is an attempt to enforce layering in the system - lower layers should not depend on upper layers to operate. WinWin should be thought of as a GUI-less subset of WinPE, which is (roughly) a subset of Server Core, which is a subset of fully fledged Windows. The kernel is the same in each.


From what I understand though this 'WinMin' was only the start of a much larger project. The scope of the project is beyond just focusing on the lower levels to also include modularising the whole operating system to avoid the spaghetti of dependencies. The basic idea then is that a small group can work on particular module in isolation, make changes then merge back into the larger tree without all hell breaking loose. The result of that are changes can be made and the amount of regressions should substantially reduced thus the compatibility within the OS and third parties should be maintained relatively easily.

The comments at the end of the article about security seem misguided about what the impact of the approach presented really is. If each application contains its own isolated usermode environment and talks to the kernel directly, the consequence will be more patching. If a bug is found in those layers, it needs to be patched in every application, as opposed to patched once in the OS. If an application is not being actively serviced, the user can be left more exposed to exploits rather than less. Not to mention the less efficient use of disk space, memory, etc.

The main benefit here, IMO, is allowing each application developer to test and deploy software in a tightly defined environment, to minimize the chances of an application misbehaving when deployed to the millions of random Windows installations out there.


The security therefore is up to the application developer to provide updates for their applications by recompiling against operating system updates that Microsoft releases; thus there is more burden on the third party developer in terms of providing regular updates but at the same time there is a lot more power at his disposal in terms fine grain testing against a very specific version of Windows of a particular build/service pack. The result is that enterprise customers can release updates promptly and not have to worry about any disruption caused to issues between said updates and third party applications installed. The result is that the operating system is secure and you as a third party can control the environment that your applications are going to run in.

The other side of the equation regarding alternative operating systems, could we see Microsoft maybe scrap Office for Mac in the future in favour of a single release of Microsoft Office that includes the said abstraction layer which is bundled with Office for Mac thus not having to maintain two versions etc. Could we see maybe see Windows 8 and Windows CE offered on the tablet to OEM's and Microsoft using said packaging system to offer their applications on both platforms? Interesting times ahead if these academic ideas are transformed into real products.

Edited 2011-05-05 03:22 UTC

Reply Score: 2

Patching will hopefully not be that bad.
by danmassa7 on Fri 6th May 2011 11:35 UTC in reply to "MinWin"
danmassa7 Member since:
2008-07-22

You’re totally right. Having a subset of the OS packaged into the application means with 50 Drawbridge applications installed on one system you would have to potentially patch 50 OS sub-systems. Nightmare.
Thankfully, it probably will not be that bad.

1. Vulnerabilities exposed in an app should not be reachable if the app is not running. The attack surface is limited to those apps that are actually executing.

2. Patching all those Win32 subsystems will hopefully be automated with tools.

3. If a particular app doesn’t need 98% of the OS subsystem, those unused parts could be pruned off prior to distributing it to the end-users. Would this be something the developer could do or would it take a team of engineers familiar with the underlying guts of the OS to pull off? I don’t know. Hopefully the former (with automated tools).

4. Remember, this is only a stopgap solution. The real goal is to roll out an entirely new OS that is MUCH more secure (among other tangible benefits, I’m sure). Drawbridge could then be used to supply backward compatibility during a transition period (i.e. 20 years). During that time, our core OS would be much more secure but our Drawbridge apps would be no better off, but no worse off.

Edited 2011-05-06 11:37 UTC

Reply Score: 2

v If you think this is a new idea your wrong.
by oiaohm on Thu 5th May 2011 05:12 UTC
moondevil Member since:
2005-07-08

Zones Containers and Jails. Are all from the Unix world.


I guess you might be young. Many mainframes already had such features, and Unix was still a to be born OS.

Edited 2011-05-05 08:42 UTC

Reply Score: 4

Great read
by Fergy on Thu 5th May 2011 07:42 UTC
Fergy
Member since:
2006-04-10

I really liked this article and it felt short which is always good. It also gives me hope for ms ;)

Reply Score: 2

Wine ?
by zorrodurezo on Thu 5th May 2011 08:19 UTC
zorrodurezo
Member since:
2011-05-05

This looks like packaging the Wine libraries with the application program.

If the run-time system calls are so much reduced, then running Win applications on Linux is going to be far more simple !

Reply Score: 1

RE: Wine ?
by jboss1995 on Thu 5th May 2011 17:26 UTC in reply to "Wine ?"
jboss1995 Member since:
2007-05-02

Actually it reminds me of wine with prefixes. Maybe WineHQ should sue MicroSoft.

Reply Score: 0

Technical Information
by moondevil on Thu 5th May 2011 08:47 UTC
moondevil
Member since:
2005-07-08

If you can read French there is some technical information available here

http://www.blog.ma-config.com/

Reply Score: 3

RE: Technical Information
by Moredhas on Thu 5th May 2011 20:40 UTC in reply to "Technical Information"
Moredhas Member since:
2008-04-10

I'm pretty sure we can all read it... It's the understanding of it that we'd have trouble with </smartass>

Reply Score: 2

v Been there, done that...
by bert64 on Thu 5th May 2011 09:26 UTC
RE: Been there, done that...
by moondevil on Thu 5th May 2011 10:38 UTC in reply to "Been there, done that..."
moondevil Member since:
2005-07-08

And Unix plays catch up with Mainframe systems.

Reply Score: 2

RE: Been there, done that...
by oiaohm on Thu 5th May 2011 14:57 UTC in reply to "Been there, done that..."
oiaohm Member since:
2009-05-30

All of this looks to be a copy of chroot() and winebottler from unix systems...
MS playing catch-up and trying to market it as something new, as always.

chroot is flawed.

Zones Containers and Jails. Are the latter techs. Some people think these are mainframe pre Unix. Infact they are after Unix.

Pre Unix was the precursor to virtualization.

But yes. Been done for years in the Unix world. Only thing anywhere near exciting is that it up into graphical.

DRI2 Wayland alterations allow same kind of features with Unix based containment. Virtual interfaces for sound from cgroups from linux, Jails from bsd and Zones from solaris already exist.

Reply Score: 1

Portablility
by fretinator on Thu 5th May 2011 12:23 UTC
fretinator
Member since:
2005-07-06

I would also think this would help create an iOS-like version of Windows. Windows would scale better to the small world. If they follow this same modularity concept with Office apps, they could create mobile versions of Office apps that are fully-compatible compatible with a more mobile interface.

As an example, the base OS could be Phone 7, but a specially-packaged version of Word with Drawbridge would bring a fully-functional version to tablets, instead of the current "mini" apps.

Reply Score: 2

Sounds like....
by TemporalBeing on Thu 5th May 2011 14:21 UTC
TemporalBeing
Member since:
2007-08-22

Sounds a lot like The OS Project's API Converters (http://theosproject.sourceforge.net/Requirements/api_converters.htm...) applied slightly differently. The main difference is that MS is pushing the converter into the application where TOSP wanted to run one converter for all applications using that API.

Reply Score: 2

old news?
by kopke on Thu 5th May 2011 20:09 UTC
kopke
Member since:
2011-05-05

Refactoring an existing OS to a library OS and using it as a virtual machine substitute sounds a lot like RUMP on NetBSD which according to the man page was present already in NetBSD 5.0:
http://netbsd.gw.com/cgi-bin/man-cgi?rump++NetBSD-current

Reply Score: 0

Is there a point?
by Brendan on Fri 6th May 2011 03:07 UTC
Brendan
Member since:
2005-11-16

Hi,

I'm having trouble seeing any point to this. To avoid excess bloat, the first thing application developers would do is use the "Drawbridge API" instead of the (legacy) Windows APIs.

Then, in 10 years time (after Microsoft has created 5 different versions of the "Drawbridge API", each more bloated than the last), some smart-ass will come up with a way of switching to a newer/leaner API and implementing the "Drawbridge API" in a library.

Then, 10 year after that...

- Brendan

Reply Score: 2

Can anyone explain?
by -pekr- on Fri 6th May 2011 12:59 UTC
-pekr-
Member since:
2006-03-28

I am not fluent C or low level coder, but can anyone help me to understand, by answering following two questions?

1) Isn't packaging OS API into each application kind of waste of resources? And what if that layer has a bug? All such apps will have to be patched?

2) Hmm, app local registry - does not it contradict the initial purpose of registry = having everything in one place? How does it differ then from the plain text, local app config files?

I have to be missing something. I know that such isolation might help them to migrate between various kernels, they solve it in kind of "app virtualisation" manner, but imo it is still significant waste of resources.

Just my two uneducated cents ...

Reply Score: 2

RE: Can anyone explain?
by Tuishimi on Fri 6th May 2011 16:05 UTC in reply to "Can anyone explain?"
Tuishimi Member since:
2005-07-06


2) Hmm, app local registry - does not it contradict the initial purpose of registry = having everything in one place? How does it differ then from the plain text, local app config files?


I wasn't sure how to read that as well. I am not sure it means having a separate registry database... It might just mean that the registry would be organized differently?

Reply Score: 2

RE[2]: Can anyone explain?
by bogomipz on Fri 6th May 2011 21:50 UTC in reply to "RE: Can anyone explain?"
bogomipz Member since:
2005-07-11

It means, just like the article says, that when you uninstall an app, there won't be any leftover cruft hanging around in the registry.

The registry is just as much about having a standard API for storing settings as for having all in one place. Most settings are application specific anyway. I guess there are a few settings that affect all apps, though. I'll admit that having multiple instances of those does sound like a problem.

Reply Score: 2

RE[3]: Can anyone explain?
by Tuishimi on Fri 6th May 2011 23:17 UTC in reply to "RE[2]: Can anyone explain?"
Tuishimi Member since:
2005-07-06

Re: API, yes, a good thing. I was just wondering if they meant separate files per application or reorganizing the way entries are written to the [one] registry so that application separation is not buried as deeply as it is now and there are no cross-referenced values, stuff like that.

Reply Score: 2

RE[4]: Can anyone explain?
by bogomipz on Fri 6th May 2011 23:26 UTC in reply to "RE[3]: Can anyone explain?"
bogomipz Member since:
2005-07-11

Because much of the state of the OS is contained within the package, the app could more easily be migrated from one running machine to another.

I read this as meaning the registry is stored inside the application package.

Reply Score: 2

RE[5]: Can anyone explain?
by Tuishimi on Fri 6th May 2011 23:28 UTC in reply to "RE[4]: Can anyone explain?"
Tuishimi Member since:
2005-07-06

Yes, now that you mention it, that does seem obvious. ;)

Reply Score: 2