steam web browsing on OS X

[Sebastian Lackner]

On 02.11.2015 12:45, Alexandre Julliard wrote:
> Sebastian Lackner <sebastian at fds-team.de> writes:
> 
>> Yes, I also looked at this approach. The difficult part to get this correct
>> is to initialize user shared data as early as possible, without any call to
>> a wrapper function before that. Please note that its not sufficient to wrap
>> calls from other dlls, even some ntdll-internal calls have to go through the
>> wrappers (for example when loading a library). Those are implemented in
>> ntdll usermode on Windows.
> 
> 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 already tried it out in practice and partially disagree. As mentioned above,
>> its not sufficient to put autogenerated wrappers between the implementation
>> and the ntdll exports. Exactly the same wrappers have to be used from inside
>> of the ntdll loader code for example. This means, even if the thunks are
>> generated somewhere else, we still have to add them to one of the wine header
>> files. If we do not want to generate thunks for all architectures, we might
>> even have to add them twice, one time as typedef, and the second time a #define
>> as fallback for unsupported architectures.
> 
>> I'm not saying that its impossible to do it this way, but compared to thiscalls,
>> which could easily be generated by winebuild, a macro is similar good here imho.
>> If you want to look into the idea to autogenerate thunks, here is one of my
>> work-in-progress patches (based on Erichs work): http://ix.io/lLz
> 
> 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.

Best regards,
Sebastian