Comment by intea

In the past when porting netbsd to new architectures the approach was to first run a kernel with a binary compatibility layer to the existing operating system, be it something like OSF/1 or SunOS.

Not only was it doable, but people did it as a shortcut to getting a functional userland first.

It is easier on unix because they are similar to each other, but with enough persistence I believe Windows is possible too.

The steps are to get some kernel booting to a "native" userland, then add code to execute the simplest standalone Windows binary. Then when it makes a call to the kernel it will fail.

Generally tracing on Windows should give you a strong idea of what calls it makes to the kernel (I don't know, I have never developed on Windows, but probably it has something like ktrace/strace/etc.)

Once you can run a basic standalone programs, you try to add enough of a Windows userland to run bigger programs.

Once that's done, you can start to re-implement parts of the Windows userland. The symbols they export are public, you must implement all of them, and programs usually crash if you fail.

As for drivers, the Windows driver API is public, and other people have re-implemented it in the past. You can even pick up some of their work.

The information about many internal "undocumented" structures is actually documented on third-party sites. And if there are structures that are really not documented anywhere then you don't have to reimplement them because no developer is using them and they are not necessary for compatibility.