9

As long as the architectures are the same, it is no wonder that Windows .exe file can run on the Linux system (if it is properly loaded on the RAM). But systemcalls of Linux and Windows are entirely different. So when an .exe file calls a systemcall on Linux, the result won't be what we expect.

I think that Wine converts Windows systemcall to Linux systemcall, but I can't imagine how to convert. Maybe systemcalls are realized by int, syscall, systenter, etc. Does Wine directly hook such operations by some way?

Marcus Müller
  • 21,602
  • 2
  • 39
  • 54
user356126
  • 599
  • 4
  • 11
  • 1
    does [this](https://en.wikipedia.org/wiki/Wine_(software)) help at all? There's many useful links on that wikipedia page if you want to dive deeper into researching how it works – Jaromanda X Jan 12 '23 at 03:44
  • 2
    Because smart people wrote code that does the right things. – hobbs Jan 12 '23 at 20:57
  • "Why can Wine convert Windows systemcall to Linux systemcall?" - Because it was programmed that way :) You probably meant "How", not "Why". – SethMMorton Jan 14 '23 at 23:47

1 Answers1

25

Currently Correct Answer

It does not translate system calls.

System calls are usually not made by the software under windows itself, but through normal calls to shared system libraries¹. The windows API that software uses is mostly a normal library API and not focussed on system calls (most of which are considered private and not to be used by software that's not part of windows at all), which allows Windows to implement a rather impressive long-term compatibility.

So, wine implements the API, but not the windows system calls - it couldn't even do that, it's userland software, and hence couldn't catch a software interrupt.

By the way,

As long as the architectures are the same, it is no wonder that Windows .exe file can run on the Linux system

undersells the differences in calling conventions, file abstraction, object file formats and a lot of other things. It's not that easy to let a piece of software written for the interfaces used on a different operating system run successfully, making calls and exchanging memory with your native system.

¹ this is quite like you use C functions like read, which implement the POSIX/libc and Linux API, normally, and rarely do system calls yourself. You'll rarely find someone doing syscall(SYS_READ, …) if they're not trying to write a libc.

Finer Answer, Speculation

Wine still can't, and it's not clear it will ever. Wine-staging can, experimentally as it is, if you enable the right patches.

While the above is true for most things that WINE emulates, as @mbrig points out in the comments, starting ca. 2019, wine-staging does have the ability to trap Windows syscalls. It does that by using Linux' seccomp functionality.

Seccomp was invented to let processes tell the kernel, for example:

Hey, dear kernel, I'm a server, and I've just set up all my listening sockets. There's going to be no reason for me to do syscalls beyond what is necessary to serve websites, so if I do any syscall but exit, read, write, and sigreturn, kindly kick me in my binary bottom.

It does so by doing a prctl syscall with the PR_SET_SECCOMP parameter.

As that's a bit inflexible, later on, the ability for processes to actually define a piece of program supposed to check whether a syscall and it's arguments are OK, was added. Such a filter, however, needs to be defined as a BPF program at the time you're making the prctl(PR_SET_SECCOMP,…) syscall. You also specify which function the resulting signal handler should run.

Now, WINE can do exactly that, and basically does nothing but check whether the syscall made from within a WINE process does fall above a range that's used for Linux syscalls. If it's not, the syscall is allowed to proceed as normal, if it is, SIGSYS is raised, and a dispatcher for the individual Windows syscall is executed.

Small problem: As far as I could find in the official mainline wine repository, this patch hasn't made it to "end-user" wine yet. 3 years is a bit of a long time for a patch to linger in that limbo, and I'd like to think that's because this approach has issues (performance impact, and issues when used in conjunction with security mechanisms), and might or might not be a mechanism that gets included in mainline wine, i.e. the piece of software that you'd refer to as wine.

Marcus Müller
  • 21,602
  • 2
  • 39
  • 54
  • 4
    That's probably why Wine stands for "Wine Is Not an Emulator". It's far more than just that. – Philipp Jan 12 '23 at 11:57
  • I suspect that if Windows did use system calls, the Wine folks and the Linux folks would sit down over a beer (very metaphorically speaking) and figure out a way to let Wine catch the system calls. It wouldn't be impossible to add this feature to Linux. – user253751 Jan 12 '23 at 14:29
  • 1
    This is the difference between WINE and VirtualBox. – Barmar Jan 12 '23 at 15:31
  • 3
    That is about to change, though: . – user3840170 Jan 12 '23 at 16:03
  • @user3840170 Could you expand this into a full answer? I know it doesn't answer the question _yet_, but pretty soon it's going to be the correct answer. – wizzwizz4 Jan 12 '23 at 17:13
  • @wizzwizz4 I think the correct answer is still going to be that it doesn't - 99% of the time. Most Windows programs do not access Windows directly through syscalls. Only badly behaved ones that are trying to be clever. Not only do they not run on Wine, they also won't run on several versions of Windows, possibly including ones that haven't been invented yet. – user253751 Jan 12 '23 at 17:39
  • @user253751 The question is about whether it _can_, not whether it _does_. – wizzwizz4 Jan 12 '23 at 17:43
  • 5
    @wizzwizz4 yes, but now and in the foreseeable future, WINE still *can't*! I'm all for adding info, but at this point, there's no Linux mechanism that people seem to agree on, nor any promise that it would then also end up in the WINE you know – or how WINE will then actually implement the syscall mangling. There's just speculation and (good) technical studies, but to me as outsider it really doesn't look like this answer will be obsolete anytime soon enough to warrant more than our discussion in the comments! – Marcus Müller Jan 12 '23 at 17:49
  • 1
    @user3840170 what's happened there in the last 2.5 years? – RonJohn Jan 12 '23 at 22:10
  • 3
    Sorry, but this answer isn't entirely right. As far back as 2019, wine(-staging) was [using seccomp](https://github.com/wine-staging/wine-staging/commit/595f2f9860adafed612737529745ad24c50acdb9) to catch and translate windows syscalls. The desire for a better mechanism lead to [syscall user dispatch](https://docs.kernel.org/admin-guide/syscall-user-dispatch.htm), but I can't tell if wine actually uses this in place of the seccomp method yet. – mbrig Jan 12 '23 at 22:43
  • 1
    @mbrig didn't know that! But to set up a seccomp filter, I would have needed root to run wine, right? – Marcus Müller Jan 12 '23 at 23:29
  • @MarcusMüller I *think* it can do it without needing root because it does `prctl(PR_SET_NO_NEW_PRIVS, 1...` first, see the [kernel docs](https://man7.org/linux/man-pages/man2/seccomp.2.html#:~:text=prctl(PR_SET_SECCOMP%2C%20SECCOMP_MODE_STRICT)%3B-,SECCOMP_SET_MODE_FILTER,-The%20system%20calls) – mbrig Jan 12 '23 at 23:48
  • 1
    @MarcusMüller You don't need root to set up a seccomp filter. You only need root if you want to be able to run the filter without `PR_SET_NO_NEW_PRIVS` enabled (as mbrig pointed out). Otherwise, any unprivileged process can set up a seccomp filter and it will be active until the process exits. – forest Jan 12 '23 at 23:58
  • 1
    @MarcusMüller: Why would you do this? The syscall numbers in Windows have changed in minor patches before. – Joshua Jan 13 '23 at 00:03
  • 1
    @mbrig please see my edit – Marcus Müller Jan 13 '23 at 10:05
  • 1
    @MarcusMüller looks good to me. There's maybe some room for minor pedantic quibbling about how people these days tend to install specific wine versions/patches for specific games into virtualenv-like things, so people running games that need it probably use the patch regularly, and what does that mean for what is "real wine" and what isn't, but I'm not gonna worry about that. I'll focus my energy on coming back to suggest an update edit if/when wine starts using syscall user dispatch :) – mbrig Jan 16 '23 at 17:25
  • @mbrig that'd be very cool of you :) – Marcus Müller Jan 16 '23 at 17:31