Yes, the ability to use native drivers on ReactOS stems from writing a kernel that mimics the Windows kernel API/ABI as closely as possible. The ReactOS userlan

Yes, the ability to use native drivers on ReactOS stems from writing a kernel that mimics the Windows kernel API/ABI as closely as possible. The ReactOS userland, however, is provided primarily by WINE. You can think of ReactOS primarily as an open kernel compatible with Windows's kernel API, and WINE as an open userland compatible with Windows's userland APIs. ReactOS isn't rewriting WINE, they use WINE extensively. The main unique work of ReactOS is the Windows-compatible kernel. Mono is helpful for pure .NET directly from a Unix environment. However, Mono is more of an open .NET development environment than a .NET compatibility environment; while Mono can run a lot of .NET apps that are made for Windows, that's almost incidental of compatibility with the CLR bytecode. There are important implementation differences that Mono is aware of and has no intention to correct because, unlike WINE, Mono is not really a compatibility layer. Additionally, many Windows programs launch .NET programs directly, and afaik it's not very easy to get them to use Mono by default. For instance, I recently purchased C&C 4 on Steam, but it's a pain to make it work because circumventing the .NET-based launcher wants me to include an EA ID (I could use a fake auth server but just don't feel like putting that much effort in), and launching directly doesn't work because of the .NET-based launcher (.NET doesn't work). Further, more and more products are relying on .NET components, including Visual Studio, Office, and other big things. I think getting the .NET runtimes working well should be one of the main goals for WINE devs.