Blog

[Update: You can now find the source code for this on bitbucket]

Call me crazy, but I've wanted to run a linux binary natively under windows for a while now; kinda like wine, but in reverse.

Well, the other day I was browsing through the MSDN docs (as you do) and discovered that it is possible to install a "vectored" exception handler. A quick bit of test code later, and I discovered that I can trap "int 0x80" instructions using this technique--those are used by linux binaries to initiate syscalls.

A couple of days hacking later, and I have a very small linux kernel emulation environment; it's split into two parts--low.dll (the kernel code) and low.exe (the bootstrap). The usage is quite simple; from your command prompt, run the linux binary of choice by prefixing the command line with "low.exe":

low.exe linuxsmallapp one two three four

The code from the named linux binary is loaded (low.dll includes an ELF loader) and bootstraps the process by faking an execve() syscall. When the syscall returns, the code resumes execution inside the loaded module. The code is running natively on your processor; and syscalls happen in userspace (just like the binary) although they run under a separate stack inside the win32 exception handler code. So, this is almost like kernel space.

What I have now is good enough to run my simple hello world application. It doesn't yet handle dynamic elf executables--they need to be statically linked. Thanks to Tal Peer, I have a collection of statically compiled coreutils from gentoo; they start up fine, but die somewhere in the stdio part of libc. I'm trying to track down the problem.

If anyone has any insight into why this might be (maybe windows is doing stuff for software interrupt number 128? before it calls my exception handler?), I'd like to hear it :-)

[Update] If you're interested in playing with it, please don't expect to acheive much at this stage. You can download it here.


View Comments