Linked by Dan Massameno on Wed 4th May 2011 21:28 UTC
Permalink for comment 471836
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/23/13 23:22 UTC
Linked by Thom Holwerda on 05/23/13 22:04 UTC
Linked by Thom Holwerda on 05/23/13 22:01 UTC
Linked by Thom Holwerda on 05/23/13 17:52 UTC
Linked by Thom Holwerda on 05/22/13 22:23 UTC
Linked by Thom Holwerda on 05/22/13 13:38 UTC
Linked by Thom Holwerda on 05/22/13 13:30 UTC, submitted by JRepin
Linked by Thom Holwerda on 05/21/13 22:06 UTC
Linked by Thom Holwerda on 05/21/13 21:45 UTC
Linked by Thom Holwerda on 05/21/13 15:53 UTC
More News »
Sponsored Links



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.