[PATCH 1/3] winebuild: Added support for entry points generated in runtime.

[Jacek Caban]

On 01/19/16 17:06, Alexandre Julliard wrote:
> Jacek Caban <jacek at codeweavers.com> writes:
>
>> All such solutions require changes in both Chrome and Wine, which makes
>> it tricky to decide on a solution. What's your opinion?
> My concern is not just about hooking the system calls, it's what happens
> once they are hooked. Sebastian said that hooks inside the Ldr*
> functions don't work right. I'm worried that supporting this properly
> would require that our internal code paths follow the Windows ones
> closely, which is neither feasible nor desirable.
>
> This could of course also be changed in Chrome so that it could deal
> with the way Wine's ntdll is implemented, but that would probably be
> more intrusive.

It's hard to discuss what Sebastian reports without understanding the
problem. For what I know, his variant of patches exposes way more
hookable calls than it should. It's not a secret that on Windows Nt*
functions will not call any other exported functions. This is an
implementation detail that I don't consider too internal to follow. The
fact that those hooks may be called recursively with Sebastian's patches
makes me think that it's the most likely reason of the problems.

For other internal behaviour, we already have cases where they do
matter. My recent example is Office 2013 online installer (which has
sandbox-like code that among others merges some special dirs, sometimes
containing DLLs, into file system). It's obvious that we need
NtOpenFile-alike in loader to open a file in loader and all changes that
it required was to pass SYNCHRONIZE flag. For all I know native may use
different APIs there, but all is fine using this call as long as we pass
an argument that is sane and makes sense anyway.

That said, I fully agree that we don't want to follow Windows too
closely, but I don't think we're at this point yet. Also, my variant of
the patch (others could be reworked to follow that as well) exposes even
less internal behaviour than existing code, because we need to
explicitly mark parts that would go through exported thunks.

Here is my proposal for fixing the situation:

Short term we use one of variants of patches for syscall thunks. This
will give an immediate fix for at lest some (most common?) Wine configs.

Long term (as in we do it now, but we will benefit way later due to
latency of Chrome release and the time needed for embedders to pick it),
we do changes in Chrome. My thinking is that we could make runtime
matching of all known thunks in Chrome instead of allowing only one
variant in given config (this would fix Wine with all Windows versions
set as well as wow64). For 64-bit we could make the check less strict
(allowing jump in place of mov eax,52h) or invent other, Wine-specific,
solution.

Thanks,
Jacek