5 ms·

Hello, actually WINE works in a different way, it does not attempt to intercept system calls (it is not possible because Windows system calls work in an incompa

Hello, actually WINE works in a different way, it does not attempt to intercept system calls (it is not possible because Windows system calls work in an incompatible way), instead it reimplements Windows DLLs, and normal application code never calls syscalls directly, but always via the DLLs implementing the libc or other libraries. So the DLLs of the core Windows functions are simply replaced with the WINE implementation on top of the POSIX API.

deleted 8y ago
[deleted]
penagwin 8y ago
So they essentially had to re-write the windows system files (the DLLs) to implement libc and other linux friendly stuff?
- monocasa 8y ago
  Yeah. FWIW, Micorsoft's implementations of Win32 have swapped out the kernel a few times anyway, so it's not the biggest leap for a third party (DOS/Win32s, Win9x, WinNT). Because of this, Microsoft considers the system call layer to be unstable, and appears to go out of their way to change the system call table every service pack. So the dll entry points are the stable ABI, and that's what 99.99% of developers rely on.
  - saagarjha 8y ago
    That's an oddly un-Microsoft move given their general attitude towards maintaining compatibility even for undocumented API…
    - monocasa 8y ago
      They've backed away from their classic Herculean efforts at back compat over the past decade or so.
yjftsjthsd-h 8y ago
That does seem more elegant. Then why does wine need ptrace? (per linked StackOverflow)
- jcranmer 8y ago
  Windows has a much more powerful process-poking layer than Linux does. This layer is pretty much consolidated into the ptrace syscall on Linux systems (I honestly prefer Windows' APIs here). Doing any of these calls in a Windows application is going to require WINE to use ptrace. Now why are those calls needed? I think some of it relates to DRM provisions. I also want to say that some of it is necessary to implement various features of COM (i.e., remote procedure call stuff), but that might not be the case, given that the reports suggest that ptrace support is often unnecessary.

deleted 8y ago

[deleted]

penagwin 8y ago

So they essentially had to re-write the windows system files (the DLLs) to implement libc and other linux friendly stuff?

monocasa 8y ago
Yeah. FWIW, Micorsoft's implementations of Win32 have swapped out the kernel a few times anyway, so it's not the biggest leap for a third party (DOS/Win32s, Win9x, WinNT). Because of this, Microsoft considers the system call layer to be unstable, and appears to go out of their way to change the system call table every service pack. So the dll entry points are the stable ABI, and that's what 99.99% of developers rely on.
- saagarjha 8y ago
  That's an oddly un-Microsoft move given their general attitude towards maintaining compatibility even for undocumented API…
  - monocasa 8y ago
    They've backed away from their classic Herculean efforts at back compat over the past decade or so.

yjftsjthsd-h 8y ago

That does seem more elegant. Then why does wine need ptrace? (per linked StackOverflow)

jcranmer 8y ago
Windows has a much more powerful process-poking layer than Linux does. This layer is pretty much consolidated into the ptrace syscall on Linux systems (I honestly prefer Windows' APIs here). Doing any of these calls in a Windows application is going to require WINE to use ptrace. Now why are those calls needed? I think some of it relates to DRM provisions. I also want to say that some of it is necessary to implement various features of COM (i.e., remote procedure call stuff), but that might not be the case, given that the reports suggest that ptrace support is often unnecessary.