[Bug 45081] New: Expanded FakeDLL support changed behaviour of stubs for A /W symbols

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=45081

            Bug ID: 45081
           Summary: Expanded FakeDLL support changed behaviour of stubs
                    for A/W symbols
           Product: Wine-staging
           Version: 3.6
          Hardware: x86
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: -unknown
          Assignee: wine-bugs at winehq.org
          Reporter: Paul.Hampson at Pobox.com
                CC: erich.e.hoover at wine-staging.com, michael at fds-team.de,
                    sebastian at fds-team.de
      Distribution: ---

Created attachment 61234
  --> https://bugs.winehq.org/attachment.cgi?id=61234
Report the results of GetProcAddress for three variations of the intersting
symbol

While looking into issues with running current Cygwin on current Wine, an error
was raised under Wine Staging 3.6:

fatal error - couldn't dynamically determine load address for
'DsEnumerateDomainTrustsW' (handle 0x7F1E632A0000), Win32 error 127

This doesn't happen either natively or with Wine 2.4 (Staging)

Looking into it, it appears the current netapi32.spec has:

@ stub DsEnumerateDomainTrusts

Given the near-trivial code attached, the behaviour difference is clear.

Windows (Windows 10 1709):
DsEnumerateDomainTrusts  not found
DsEnumerateDomainTrustsA found
DsEnumerateDomainTrustsW found

Wine 2.4 (Staging) and 3.6 (Staging):
DsEnumerateDomainTrusts  found
DsEnumerateDomainTrustsA not found
DsEnumerateDomainTrustsW not found

The weird thing is that Wine 2.4 worked in Cygwin, when clearly nothing has
apparently changed for this particular DLL export code-wise since 2005.

I believe this is to do with the patches in Wine Staging
(https://github.com/wine-staging/wine-staging/tree/master/patches/winebuild-Fake_Dlls)
which have surfaced a class of previously-hidden issues in Wine.

I haven't worked out where yet, but I suspect that the Fake_DLLs are breaking
some kind of Wine magic which lets the unadorned symbols for stubs also respond
to a lookup for the adorned symbols.

Otherwise, I expect we'd see a lot more pairs like this:
@ stub DsEnumerateDomainTrustsA
@ stub DsEnumerateDomainTrustsW

I'm surprised such a change hasn't seen more issues but I was unable to find
any references to it on this Bugzilla or by searching Google.

ReactOS have a trivial patch which turns them from spec-stubs to code-stubs,
and hence corrects the exports etc: https://jira.reactos.org/browse/CORE-11056
and that would make sense for Wine.

All Wine installations here are on Ubuntu 14.04 from winehq packages, in Docker
images built from https://github.com/TBBle/wine_msys64

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.