Linked by Thom Holwerda on Mon 18th Jan 2010 16:06 UTC, submitted by fireball
ReactOS The ReactOS project aims to be an open source Windows NT-compatible operating system which can run Windows applications and utilise Windows drivers. Obviously, this is quite a daunting task, and as such, progress has been relatively slow. As a result, project coordinator and kernel developer Aleksey Bragin has proposed a rather drastic solution.
Thread beginning with comment 404959
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:

Thanks for the clarification, there, I was confused too.

If I can ask a second, stupid question: what parts of the Win32 API run are kernel-mode? I thought the NT kernel/Win32 architecture design featured a small kernel, with layers built on top of it (in user mode) to generate the system interface that user applications see; basically, I thought that, by design, the Win32 interface was implemented in libraries and didn't penetrate down into the NT kernel itself?

Reply Parent Score: 2

jjezabek Member since:

The microkernel architecture was used in NT 3.1-3.51, but in NT 4 some performance critical components were moved to kernel-mode (although not into the NT kernel itself, which is a separate module). AFAIK this is when Win32k was born. This move resulted in a big performance improvement, but also in less clean design and some security risks (win32k has been exploited to elevate privileges).

I'm not sure what exactly goes to win32k, but at least some of the usermode GDI functions are thin wrappers that just call their kernel mode counterparts.

Reply Parent Score: 2

boldingd Member since:

I find that to be... interesting. I remember reading some time ago that someone had added a similar facility to the Linux kernel -- the ability to take a user-mode process and promote it to kernel mode. The main use, I think, was to speed up system services like X, by reducing the number of times that it had to call into the kernel (as calling into the kernel from outside is apparently quite expensive). I think that a consensus was formed, tho, that promoting random userspace daemons - even if they where known, trusted and system-critical - into kernel space was a really, really terrible idea, for exactly that reason: an X bug become then becomes a kernel bug, and an X exploit becomes a kernel exploit. It's interesting that Microsoft apparently ran into the same problem, thought of the same solution... but opted for raw performance over potential security and stability costs.

Reply Parent Score: 2