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.
Post a Comment
Member since:
2005-07-06
Member since:2005-07-06
Member since:2006-08-18
Member since:
2006-03-20
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.
Member since:
2010-08-06
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.
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.
Member since:2005-07-06
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 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
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
Member since:2005-07-08
Member since:
2006-04-10
Member since:
2011-05-05
Member since:2007-05-02
Member since:
2005-07-08
If you can read French there is some technical information available here
http://www.blog.ma-config.com/
Member since:2008-04-10
Member since:2005-07-08
Member since:2009-05-30
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.
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.
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.
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
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
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 ...
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?
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.
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.
Member since:2005-07-11
Member since:2005-07-06
