Hey, good timing. I'd wanted to follow up on this and point out a few links and stuff, and hot on the heels of looking at how Windows can run UNIX programs comes the news that the UNIX-based OSX has some vestigial code to handle Windows programs. It doesn't seem to do anything too interesting at the moment, but it does recognise the Windows PE executable file format, and it even appear to try and load Windows dlls. Rumours abound that it's the first steps to getting OSX to be able to natively run Windows applications.
I love this idea - it's kinda obvious and counter-intuitive at the same time. Conventional wisdom states that you simply can't run a Windows binary on UNIX - they are different OS's, after all. But it's also just x86 code, so why shouldn't you be able to run it?
Of course, it's going to be more complicated than just running x86 code - there's a whole bunch of system services that need to be available, including COM, the registry, the file system layout, the clipboard, etc.
But it's not a new idea. Wine has been running Windows apps on UNIX-like machines for ages. Wine isn't like Interix. It's a compatibility layer, and works in a number of different ways. They have reimplemented a load of Win32 dlls that retarget the calls to the underlying UNIX OS, so you don't need Windows installed (they've even implemented DirectX!). Or you can optionally use native Windows dlls. Or simply recompile against their libs to get source code compatibility. But binary compatibility is the main draw.
A similarly herculean effort exists in the other direction - Cygwin. Their home page nicely states what it is, and what it isn't. It's different to Wine, in that it's a source code compatible UNIX environment. You can't take a UNIX binary and just run it (just as in Interix). And it's different to Interix in that it's a compatibility layer built on top of Win32, rather than it's own subsystem, and so it inherits the constraints of the Win32 platform, constraints that Interix can avoid. A nice example of which is fork. Fork creates a copy of a process, including address space. Win32 has no such concept, but (and Google is failing me for backup, here) Interix has full support for fork, because the Windows NT kernel has full support for fork. Similarly, NTFS was designed to support POSIX requirements, such as group ownership, hard links and of course, case sensitivity. These concepts aren't available to Win32, so also aren't available to Cygwin apps.
Cygwin has it's drawbacks, but it has good things too. By running in the Win32 subsystem, it has access to GDI, and so a port of the X Windows Server is possible. Interix can't display graphics, and so has to rely on a full Win32 port, such as Xming. But most important is the simple fact that Cygwin Actually Works. This is huge in and of itself. It's very popular, and has a massive range of ports, and autoconf support means porting should be very easy. In fact, it's so popular that it has better support of ported apps than Interix, and should really be considered the de facto standard for running UNIX apps on Windows.
So why do I prefer Interix? Well, that's easy. It's cooler in a far more geeky way. Cygwin's clearly done incredibly impressive stuff, but (with the greatest of respect) it's a big hack. Interix is a much cleaner way of doing things. Take how the Windows file system is exposed, for example. In Cygwin, you get to your standard driver letters (C:, D:) via /cygdrive/c or /cygdrive/d, and network paths, such as \\server\share\dir are available as //server/share/dir. Interix exposes them in a slightly more UNIX friendly /dev/fs/C, /dev/fs/D and /net/server/share/dir. A minor thing perhaps, but I like it.
(But then I also like Cygwin's /proc/registry.)
Right, quick link-fest. The Interop Community site is a semi-official site that has a bunch of forums, faqs, tech notes and provides a package management system for a whole heap of extra utilities, including recent versions of the GNU utilities (and it's managed by Rodney Roddick, one time Interix dev). Alternatively, you can download packages from NetBSD or Debian. Another previous dev has a great techy white paper for download. And there's even a blog.
And now I'm back off to my command line.