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

[Sebastian Lackner]

On 19.01.2016 12:20, Jacek Caban wrote:
> Signed-off-by: Jacek Caban <jacek at codeweavers.com>
> ---
>  tools/winebuild/build.h          |  1 +
>  tools/winebuild/parser.c         |  1 +
>  tools/winebuild/spec32.c         | 59
> ++++++++++++++++++++++++++++++++++++++++
>  tools/winebuild/winebuild.man.in |  3 ++
>  4 files changed, 64 insertions(+)
> 

I would also like to get this issue fixed, so I wouldn't complain if Alexandre really
prefers the JIT approach, but I personally still do not really see a big advantage
compared to static code generation. Let me quickly explain again why.
I'll also send another mail to point a couple of issues with the current patch, but
here again first the general discussion.

* We have no way to implement support for 64-bit because SYSCALL instructions are
  directly part of the thunk. Unless we want to remove the "not" in the definition
  of "Wine is not an emulator", its technically impossible to intercept those
  Syscalls and we cannot implement it.

* 32-bit Windows 8 thunks also cannot be implemented, with the same reason as 64-bit
  thunks. To see that, just take a look at the expected opcodes:

  // 00 b825000000      mov     eax,25h
  // 05 e803000000      call    eip+3
  // 0a c22c00          ret     2Ch
  // 0d 8bd4            mov     edx,esp
  // 0f 0f34            sysenter
  // 11 c3              ret
  // 12 8bff            mov     edi,edi

  And at the very strict verification:

  [...] CallEip != function_code.call_eip || function_code.call_offset != 3
  [...] kSysenter != function_code.sysenter

* Based on my knowledge, implementing WOW64 doesn't help much because we have no app
  which relies on it. Although their code technically would support it, it seems like
  Chromium and Steam never uses it in practice. At least during our testing so far,
  we haven't found a way to fix that.

* Last but not least, one of the reasons why I haven't submitted my own approach so
  far: The whole idea only works reliable as long as we do NOT forward Ldr* functions
  to syscall thunks. If we do, like it should work on Windows, and like it is most
  likely required by other apps, there are race conditions all over the place and
  Steam webstore only works with a probability of about 50% or less. I haven't figured
  out what causes it yet.

@ Alexandre: Do you have a preferrence? Suggestions we had so far:

- JIT compilation of thunks (only x86)
- Winebuild generated static thunks (see http://ix.io/nxT )
- Macro-generated thunks (see staging repo)

To my knowledge, all have the same limitations: x86, non-wow64 and race-conditions when
forwarding Ldr* functions through the syscall thunks.

Best regards,
Sebastian