Sebastian Lackner <sebastian(a)fds-team.de> 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 ntdll.dll.so 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(a)winehq.org