steam web browsing on OS X

Alexandre Julliard julliard at
Mon Nov 2 06:22:20 CST 2015

Sebastian Lackner <sebastian at> writes:

> On 02.11.2015 12:45, Alexandre Julliard wrote:
>> It seems that in your patch this is the default behavior, and you have
>> to explicitly bypass the syscall. Are there really that many cases where
>> it's necessary to go through the syscall?  I would have expected that
>> internal calls would bypass unless explicitly required.
> Well, the main difficulty is to find out what exactly is required. For loader
> functions some applications depend on it, but does that mean we should only use
> the thunks there? It seems a bit risky to me, and I would expect this to cause
> regressions. If such a solution is preferred, we should definitely test it some
> time before shipping it as stable to our users. ;)

I don't think it's more risky, our ntdll internals are pretty different
from the Windows ones, so it's unlikely that we'd trigger the correct
sequence of syscalls either way.

>> The problem is that this allows a single version of the thunks, but we
>> are most likely going to need multiple variants selected at run-time
>> based on the Windows version. That doesn't mean it has to be done in
>> winebuild, I agree it could also be done with macros, but it's not as
>> simple as the thiscall case.
> Imho it doesn't make much sense to think about other architectures right now. Unless
> the linux kernel offers a way to define custom system calls, or we want to trace
> every process, we technically can not implement x86_64 support. Also x86 (wow64) support
> is only possible when we either build twice, or patch the functions at
> runtime. And for other architectures like ARM/ARM64/... I'm not aware of any application
> which would need special thunks at all.

I'm not talking about other platforms, but at a minimum wow64 needs to
be supported. We can't require people to use 32-bit prefixes forever.
As far as I can tell from the sandbox source, Windows 8 and Windows 10
versions would also have to be handled differently.

Alexandre Julliard
julliard at

More information about the wine-devel mailing list