Very few programs actually make system calls directly. Most call the C standard library instead, which then issues the calls. If the program can be persuaded to use a native version of the library, this can provide a more cohesive experience. An example is WINE, which allows Windows programs to be run in *NIX.
Simple system call translation isn’t really an option in this case; the Windows kernel is very different from a UNIX-like system, so a large translation layer would be needed. Windows programs also interact differently with the system. Most graphical *NIX programs use X11, which has a well-defined protocol for communicating with the screen. Since it was designed to be network-transparent, it’s fairly loosely coupled, so it doesn’t matter to the X server whether the drawing commands come from a native or an emulated client (or even from a client running on a different machine on the network).
Windows applications don’t use X11, however; they use the Windows GDI or DirectX. While it might be technically possible—although a lot of effort—to create a system-call translation layer on a system like Linux that would allow running the Windows GUI, it wouldn’t be very helpful, because it wouldn’t integrate at all with the rest of the system.
Instead, the WINE project moves the emulation up the stack, providing replacements for most of the libraries that ship with Windows. When a Windows program wants to draw something onscreen, it calls a function defined in gdi32.dll. On a Windows system, this will then issue calls to the display driver and produce the desired effect. On *NIX, these calls go to the WINE version of gdi32.dll, which translates them into X11 drawing calls. Similar translations happens in other parts of the API.
As with system call translation, this arrangement can result in the code running faster than on the native platform if the new implementation is more efficient than the old one.