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 404756
To view parent comment, click here.
To read all comments associated with this story, please click here.
jjezabek
Member since:
2005-08-07

(Disclaimer: this is how I understand the situation, I might be wrong;) )

They already use lots of current Wine code, e.g. for most of their user-mode stuff. So they don't write their own versions of common dialogs, COM components, etc., as this would be a lot of duplicated effort. Instead they import the Wine code, and they do this quite often.

What Aleksey writes about is win32k, which is the kernel mode part of Win32. This is currently written by the ReactOS guys, using some Wine code, but mainly focused on Windows compatibility. Sadly it takes an insane amount of work, and that's why Aleksey proposed a 'shortcut', which would be significantly different from the Windows architecture, but which would give a system that's usable now and that can profit from the improvements made upstream (i.e. Wine's win32k).

Reply Parent Score: 3

boldingd Member since:
2009-02-19

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:
2005-08-07

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