Microkernel shim for ReactOS or Windows NT?

[yasha_yakov]

Is it possible to develop a patch for the ROS kernel that hooks into the APIs of a microkernel such as seL4? One wouldn't necessarily have to change stuff like drivers, instead, ROS/NT could run on top of the microkernel, kernel-mode drivers and all. L4Linux is a similar case, where Linux and all of it's modules run as a process on L4. It would act as a form of paravirtualization.

I'm an open source person, and I don't really know much about Windows, so maybe this is stupid - but if a patch like that is developed, would one be able to then unlink the proprietary NTOSKRNL binary and replace needed routines with the L4-patched-ROS ones? If so, that would greatly help out the growing demographic of people who are interested in virtualizing Windows to play games on a Linux host. Windows could hook on to UIO devices instead of having to deal with VT-d!

This all hinges on hypotheticals, since ReactOS is currently working for NT 5.2 support (?) and I doubt the latter paragraph would be feasible with any modern version of Windows.

[Quim]

Is it possible to develop a patch for the ROS kernel that hooks into the APIs of a microkernel such as seL4? One wouldn't necessarily have to change stuff like drivers, instead, ROS/NT could run on top of the microkernel, kernel-mode drivers and all. L4Linux is a similar case, where Linux and all of it's modules run as a process on L4. It would act as a form of paravirtualization.

I'm an open source person, and I don't really know much about Windows, so maybe this is stupid - but if a patch like that is developed, would one be able to then unlink the proprietary NTOSKRNL binary and replace needed routines with the L4-patched-ROS ones? If so, that would greatly help out the growing demographic of people who are interested in virtualizing Windows to play games on a Linux host. Windows could hook on to UIO devices instead of having to deal with VT-d!

This all hinges on hypotheticals, since ReactOS is currently working for NT 5.2 support (?) and I doubt the latter paragraph would be feasible with any modern version of Windows.

Interesting concept but, I don´t see ReactOS devs implement it.
Could you explain more?

[karlexceed]

Kinda reminds me of: https://en.wikipedia.org/wiki/Longene

a patch for the ROS kernel that hooks into the APIs of a microkernel such as seL4? One wouldn't necessarily have to change stuff like drivers, instead, ROS/NT could run on top of the microkernel, kernel-mode drivers and all.

Running the whole NT system (drivers and all), on top of a Linux kernel and drivers? This just sounds like virtualization to me.

would one be able to then unlink the proprietary NTOSKRNL binary and replace needed routines with the L4-patched-ROS ones? If so, that would greatly help out the growing demographic of people who are interested in virtualizing Windows to play games on a Linux host.

And now we're talking about running just Windows userspace on top of a Linux kernel? It sounds like you want to re-create WINE...

[yasha_yakov]

Kinda reminds me of: https://en.wikipedia.org/wiki/Longene

...

Running the whole NT system (drivers and all), on top of a Linux kernel and drivers? This just sounds like virtualization to me.

...

And now we're talking about running just Windows userspace on top of a Linux kernel? It sounds like you want to re-create WINE...

It is topologically quite different from hardware virtualization, or WINE.

Firstly, L4 is a microkernel completely unaffiliated with Linux. (Linux is a monolithic kernel, not a microkernel) There are projects such as L4Linux (https://l4linux.org) which seek to run Linux as a user mode process on top of the L4 microkernel. L4Linux’s goals are to be able to coexist with another, real-time scheduler to run mission-critical RTOS apps.

Windows NT, and hence ReactOS, are monolithic kernels too. My question is what the relative possibility of running NT as a process on top of a microkernel would be, and whether such work could be translated to work on Microsoft Windows.

Longene is similar, because IIRC it provides an egalitarian approach to resource usage. Windows software is not running on top of Linux, they are given equal priority to run without overhead.

The key difference is that Longene maintains a monolithic architecture, instead of compartmentalizing the Windows and Linux components respectively as userspace processes. This solves problems like reconciling Linux’s process system (big pile of task_structs ) with whatever Windows uses.

I could see a few use cases for software like this:


* Corporations who want to share mission-critical RTOS applications on the same device as legacy Windows software

* People who want seamless interoperability between Windows and Linux programs (I.e. a single abstracted filesystem) without sacrificing stuff like low-level compatibility (admittedly more useful when applied to proprietary Windows)

* Gamers who don’t have to use VT-d for virtualization, as they can expose their graphics cards as UIO devices and have Windows respond to them like native devices.

* Researchers (nerds).

[cb88]

The windows kernel already supports having multiple kernel API personalities... it was designed to implement the windows API of course, but these days it also implements Linux kernel calls, and could have implemented odd things like VMS etc... in the past an OS/2 subsystem existed also.