Hi all,
I have an application that is creating a process suspended and then
using detours modifies the imports of the new process prior to
resuming it (the application is called Tracker.exe and is part
of MS toolchain, it can be retrieved in MS EWDK package)
The application does not work as it should on Wine, as the DLL its
trying to inject to the new process is not getting loaded, I tracked
down the problem here are the technical details:
When a new process is created, after all the other …
[View More]set-ups its running
the function:
dlls/ntdll/server.c!server_init_process_done
This function sets up the handlers for the different signals
(signal_init_process) and makes a wine_server_call init_process_done.
In the wine server function server/process.c!init_process_done a check
is made to see if the
thread of the process needs to be suspended (stop_thread_if_suspended)
and indeed when
a process is created with the CREATE_SUSPENDED flag, thread->suspend
== 1, process->suspend == 0, and the process state is done at this
point).
This makes the wine_server call to stop_thread which will send a
SIGUSR1 signal to the new process.
The new process however still have the signals in a block state, thus
not processing the signal and putting it into a pending state.
The next thing that happens is LdrInitializeThunk continues and fixing
up the EXE module imports, this is not the same behavior as Windows in
which the Ldr only starts running after the thread has
resumed.
Only later signals are being unblocked and then the thread enters a
suspended state, the function
which unblocks the signals today is attach_process_dlls
The interesting thing is that in the past Wine behavior was correct
and the change that basically broke it is commit:
commit 0f5fc117a2320bb7e21b9ae4d07d717bed413171
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Mon Nov 19 14:27:07 2007 +0100
ntdll: Unblock signals in process init only after the dlls have
been imported.
Unfortunately though there I could not find any reason why the change
was made or if there is any bug that it fixed back then (2007) .
I was thinking that perhaps in order to resolve the problem and be
closer in the behavior to Windows would be to unblock the signals just
before server_init_process_done returns.
Please let me know if you have any other questions, will be happy to
resolve this now that we have all the information laid out.
Thanks,
-- Jon.
[View Less]
On 23 August 2017 at 16:17, Paul Gofman <gofmanp(a)gmail.com> wrote:
> -static IDirect3DDevice9 *create_device(IDirect3D9 *d3d, HWND device_window, HWND focus_window, BOOL windowed)
> +static IDirect3DDevice9 *create_device_behavior(IDirect3D9 *d3d, HWND device_window, HWND focus_window,
> + BOOL windowed, DWORD behavior_flags)
It's perhaps a bit of an uncomfortable change to make due to the
number of tests in visual.c, but ideally this would match the version
of …
[View More]create_device() in device.c. Lacking that, there are a few tests in
visual.c that just call IDirect3D9_CreateDevice() directly. In either
case, we'd like device.c and visual.c to converge instead of diverge.
> + hr = IDirect3DDevice9_SetVertexShader(device, NULL);
> + ok(SUCCEEDED(hr), "Got unexpected hr %#x.\n", hr);
> + hr = IDirect3DDevice9_SetVertexShader(device, pure_sw_shader);
> + ok(SUCCEEDED(hr), "Got unexpected hr %#x.\n", hr);
Is resetting the shader to NULL really needed here?
> + hr = IDirect3DDevice9_DrawPrimitiveUP(device, D3DPT_TRIANGLESTRIP, 2, quad, sizeof(*quad));
> + todo_wine
> + ok(hr == D3DERR_INVALIDCALL, "Got unexpected hr %#x.\n", hr);
> + hr = IDirect3DDevice9_DrawPrimitiveUP(device, D3DPT_TRIANGLESTRIP, 2, quad, sizeof(*quad));
> + ok(SUCCEEDED(hr), "Got unexpected hr %#x.\n", hr);
Odd.
> + /* wined3d does not guarantee 0 for out of bounds constant access by default. */
IIRC neither does Windows, in general. Matteo may have a better
recollection of the details, but IIRC while it mostly works out in
practice on current NVIDIA hardware, it doesn't necessarily everywhere
else, and is essentially hardware/driver specific behaviour.
[View Less]
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://testbot.winehq.org/JobDetails.pl?Key=32807
Your paranoid android.
=== w7u (32 bit htmldoc) ===
htmldoc.c:2682: Test failed: unexpected call GetOverrideKeyPath
Hi all,
I have an application that is creating a process suspended and then
using detours modifies the imports of the new process prior to
resuming it (the application is called Tracker.exe and is part
of MS toolchain, it can be retrieved in MS EWDK package)
The application does not work as it should on Wine, as the DLL its
trying to inject to the new process is not getting loaded, I tracked
down the problem here are the technical details:
When a new process is created, after all the other …
[View More]set-ups its running
the function:
dlls/ntdll/server.c!server_init_process_done
This function sets up the handlers for the different signals
(signal_init_process) and makes a wine_server_call init_process_done.
In the wine server function server/process.c!init_process_done a check
is made to see if the
thread of the process needs to be suspended (stop_thread_if_suspended)
and indeed when
a process is created with the CREATE_SUSPENDED flag, thread->suspend
== 1, process->suspend == 0, and the process state is done at this
point).
This makes the wine_server call to stop_thread which will send a
SIGUSR1 signal to the new process.
The new process however still have the signals in a block state, thus
not processing the signal and putting it into a pending state.
The next thing that happens is LdrInitializeThunk continues and fixing
up the EXE module imports, this is not the same behavior as Windows in
which the Ldr only starts running after the thread has
resumed.
Only later signals are being unblocked and then the thread enters a
suspended state, the function
which unblocks the signals today is attach_process_dlls
The interesting thing is that in the past Wine behavior was correct
and the change that basically broke it is commit:
commit 0f5fc117a2320bb7e21b9ae4d07d717bed413171
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Mon Nov 19 14:27:07 2007 +0100
ntdll: Unblock signals in process init only after the dlls have
been imported.
Unfortunately though there I could not find any reason why the change
was made or if there is any bug that it fixed back then (2007) .
I was thinking that perhaps in order to resolve the problem and be
closer in the behavior to Windows would be to unblock the signals just
before server_init_process_done returns.
Please let me know if you have any other questions, will be happy to
resolve this now that we have all the information laid out.
Thanks,
-- Jon.
[View Less]
Hi,
I've noticed that some of the ABI specific structs for ARM64 are
incomplete or missing - namely _JUMP_BUFFER in include/msvcrt/setjmp.h
(not yet available) and _CONTEXT (not missing but only has got made-up
content so far) and associated CONTEXT_* defines, and structs like
RUNTIME_FUNCTION and UNWIND_HISTORY_TABLE in include/winnt.h.
As far as I know, these structs should be available in the win10 sdk.
(MSDN doesn't have them but just says to refer to winnt.h for the CONTEXT
struct …
[View More]at least). In order not to accidentally make myself uneligible for
contributing code on these matters, I've tried to not look at the sdk.
Can someone help out with completeing these data structures according to
whatever clean-room guidelines are required? When looking at existing code
with git blame, they mostly appear as such without any further explanation
on how they were derived, so I'm taking the more cautious route here.
// Martin
[View Less]
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://testbot.winehq.org/JobDetails.pl?Key=32778
Your paranoid android.
=== w8 (32 bit visual) ===
visual.c:7975: Test failed: Input test: Quad 3(2crd-wrongidx) returned color 0x00ff00ff, expected 0x00ff0080
=== w1064 (64 bit visual) ===
visual.c:8023: Test failed: …
[View More]Got unexpected color 0x00007580 for quad 2 (different colors).
[View Less]
Hello all,
I am wanting to output the audio from various applications run in WINE
to the JACK server on my computer. I would prefer that WINE do this
natively instead of routing across various wrapper setups with ALSA or
PulseAudio. I have looked on the WINE wiki page for sound[1] and see
that there was a JACK driver at one point, but it was removed when the
driver architecture was changed.
I am interested in trying to implement a driver to get WINE talking to
JACK natively. The wiki …
[View More]says to ask on the mailing list before starting
such a project, and so here I am. I have downloaded a local copy of the
source repo and have started browsing through its contents. Being
unfamiliar with the WINE codebase, which portions of the source should I
start studying first? I am interested in studying the drivers for ALSA,
OSS, and Pulse for comparison; do those live in a particular place in
the source tree? I'm presently looking on the Wiki for other helpful
information, but is there some particular documentation I should be
studying for this endeavor?
Regards,
Jeremy Banks
1. https://wiki.winehq.org/Sound#Backend_information
[View Less]
Hi Rosanne,
I saw on https://bugs.winehq.org/show_bug.cgi?id=43525 that wineusr-guide
is deprecated (which I realized), but I didn't realize it was still up.
Would you (or anyone else) be opposed to completely removing it? IMO it's
doing more harm than good, especially without a deprecated notice on it.
--
-Austin
GPG: 14FB D7EA A041 937B
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://testbot.winehq.org/JobDetails.pl?Key=32755
Your paranoid android.
=== w7u (32 bit htmldoc) ===
htmldoc.c:2682: Test failed: unexpected call GetOverrideKeyPath
On 18.08.2017 13:41, Dmitry Timoshkov wrote:
> Signed-off-by: Dmitry Timoshkov <dmitry(a)baikal.ru>
> Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de>
> ---
> dlls/user32/tests/dialog.c | 6 ++++++
> dlls/user32/tests/resource.rc | 6 ++++++
> 2 files changed, 12 insertions(+)
>
There is no need to resubmit, the patches are exactly identical to
what Andrew submitted. Also, why the hell is there my sign-off? It is
apparently not fine for you when …
[View More]Andrew wants to take responsiblity
for your patches, but you expect me to take responsibility for it,
without confirming that I'm fine with it first? For other people I
would now start to explain that Wine Staging also accepts workarounds
and imperfect patches, and that the addition to Wine Staging does not
imply my sign-off, but I'm pretty sure you are well aware of it...
[View Less]
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://testbot.winehq.org/JobDetails.pl?Key=32738
Your paranoid android.
=== w7u (32 bit msg) ===
msg.c:5084: Test failed: ShowWindow(SW_RESTORE):overlapped: 18: the msg sequence is not complete: expected 0000 - actual 0088
msg.c:5207: Test failed: SetWindowPos:…
[View More]show_popup_first_show_window: 11: the msg 0x001c was expected, but got msg 0x0047 instead
msg.c:5207: Test failed: SetWindowPos:show_popup_first_show_window: 12: the msg 0x0086 was expected, but got msg 0x001c instead
msg.c:5207: Test failed: SetWindowPos:show_popup_first_show_window: 13: the msg 0x0006 was expected, but got msg 0x0086 instead
msg.c:5207: Test failed: SetWindowPos:show_popup_first_show_window: 18: the msg 0x0009 was expected, but got msg 0x0006 instead
msg.c:5207: Test failed: SetWindowPos:show_popup_first_show_window: 19: the msg 0x0007 was expected, but got msg 0x0009 instead
msg.c:5207: Test failed: SetWindowPos:show_popup_first_show_window: 20: the msg 0x0047 was expected, but got msg 0x0007 instead
msg.c:5207: Test failed: SetWindowPos:show_popup_first_show_window: 21: the msg 0x0003 was expected, but got msg 0x0047 instead
msg.c:5207: Test failed: SetWindowPos:show_popup_first_show_window: 22: the msg sequence is not complete: expected 0000 - actual 0003
=== wvistau64 (32 bit listbox) ===
listbox.c:706: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY, *) filled with 7 entries, expected > 7
listbox.c:941: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY|DDL_EXCLUSIVE, *) failed err 18
=== wvistau64 (64 bit listbox) ===
listbox.c:706: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY, *) filled with 7 entries, expected > 7
listbox.c:941: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY|DDL_EXCLUSIVE, *) failed err 18
=== w864 (32 bit broadcast) ===
The task timed out
=== w8 (32 bit sysparams) ===
sysparams.c:2519: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out
sysparams.c:2530: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1
=== w1064 (32 bit sysparams) ===
sysparams.c:206: Test failed: Unexpected WM_DISPLAYCHANGE message
=== w864 (64 bit sysparams) ===
The task timed out
[View Less]
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://testbot.winehq.org/JobDetails.pl?Key=32717
Your paranoid android.
=== wvistau64 (32 bit listbox) ===
listbox.c:706: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY, *) filled with 7 entries, expected > 7
listbox.c:941: Test failed: SendMessage(LB_DIR, …
[View More]DDL_DIRECTORY|DDL_EXCLUSIVE, *) failed err 18
=== wvistau64 (64 bit listbox) ===
listbox.c:706: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY, *) filled with 7 entries, expected > 7
listbox.c:941: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY|DDL_EXCLUSIVE, *) failed err 18
=== w864 (64 bit broadcast) ===
The task timed out
=== w8 (32 bit sysparams) ===
sysparams.c:2519: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out
sysparams.c:2530: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1
=== w864 (32 bit sysparams) ===
sysparams.c:2519: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out
sysparams.c:2530: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1
[View Less]
Andrew Eikum <aeikum(a)codeweavers.com> wrote:
> From: Dmitry Timoshkov <dmitry(a)baikal.ru>
>
> Signed-off-by: Andrew Eikum <aeikum(a)codeweavers.com>
> ---
> dlls/user32/tests/dialog.c | 6 ++++++
> dlls/user32/tests/resource.rc | 6 ++++++
> 2 files changed, 12 insertions(+)
I think that I've expressed my opinion clear enough in my response
to your private e-mail that I don't allow you to send my patches
included in the wine-staging tree to …
[View More]winehq, and explained well enough
my reasoning. The only person who has my permission is Sebastian Lackner -
wine-staging maintainer. I'm too sometimes sending the patches, but I have
to admit that's pretty rare cases these days, and usually that's not my
personal decision.
Please try to find your own areas to work on, and stop stealing patches
created by somebody else, especially when directly asked not to.
--
Dmitry.
[View Less]
On 15.08.2017 13:40, Nikolay Sivov wrote:
> if (cached_key_size == key_size && !memcmp(cached_key, key, key_size)) {
> + if (FAILED(hr = IDWriteFontFace4_QueryInterface(cached->fontface, riid, obj)))
> + WARN("Failed to get %s from fontface, hr %#x.\n", debugstr_guid(riid), hr);
> +
> TRACE("returning cached fontface %p\n", cached->fontface);
> - *font_face = (IDWriteFontFace*)cached->fontface;
> - …
[View More] return S_OK;
> + break;
> }
> }
There is still a minor problem (no race condition though). Lets assume a fontface is
just about to be destroyed, then the code above will abort enumeration after reaching
the fontface with refcount == 0. Lets assume the newly created fontface is added
after the old one, then all following attempts to get the fontface from the cache
will fail, until the old one has finally be removed. This issue can be avoided by
doing "continue;" instead of "break;" for E_FAIL.
[View Less]
On 17 August 2017 at 00:28, Nikolay Sivov <nsivov(a)codeweavers.com> wrote:
> diff --git a/dlls/kernel32/nls/far.nls b/dlls/kernel32/nls/far.nls
> index 0f5b17068b..2baf289223 100644
> --- a/dlls/kernel32/nls/far.nls
> +++ b/dlls/kernel32/nls/far.nls
> @@ -124,6 +124,7 @@ STRINGTABLE LANGUAGE LANG_PERSIAN, SUBLANG_DEFAULT
> LOCALE_SMONTHNAME13 ""
> LOCALE_SMONTHOUSANDSEP "٬"
> LOCALE_SNAME "fa-IR"
> + LOCALE_SNAN "ﻥﺎﻋﺩﺩ"
That doesn't look right. …
[View More]According to
http://www.unicode.org/cldr/charts/latest/by_type/numbers.symbols.html#2a6d…
"ناعدد" is correct, but the above is using the Presentation Forms-B
characters.
[View Less]
Hello,
i am trying to fix #9337 [1] for VietCong game (game is crashing during
loading 3D objects) for which exists community util which fixes it. This
util was made to fix issues for VC on newer Windows - fixing this bug in
Wine was just side effect. Anyway, i have talked to creator of this util
(Brchi from The Archi Family) about it. The game originally use software
vertexes only, but he edited the game and switched to hardware vertexes
(which increased FPS rapidly on Windows), but he …
[View More]was facing the same
problem - the game was crashing. Fortunately, he found that the game
uses different code branches when hardware vertex are used - developers
probably never finished support for hardware vertexes and that is reason
why it is crashing when HW vertexes are used. He fixed game code so it
works with HW vertexes (even in Wine).
The problem is that game uses only SW vertexes and these unfinished
branches are called only when HW vertexes are used, which is not a
problem for Windows (which support SW vertexes). But for some reason
Wine uses HW vertexes even if game wants to use SW vertexes. Thats why
the game works in Wine only with this util applied.
I can see from report [2] that game tries to use SW vertexes, which are
unsupported by Wine. Can I simply edit some code in Wine (some D3D flag)
so the game will think that it use SW vertexes, so after checking some
flags by game it will not jump into some unfinished branches for HW
vertexes? I just want to test if it is really caused by this. From
application view, what is difference between using SW and HW vertexes,
do you think that using HW vertexes with code done for SW vertexes will
work?
[1] https://bugs.winehq.org/show_bug.cgi?id=9337
[2] https://bugs.winehq.org/show_bug.cgi?id=9337#c35
Thanks,
Jan
[View Less]
I wrote a test program (attached), and it doesn't work when the start
point isn't 0,0.
> + if (line->startpoint.X == line->endpoint.X)
> + t = line->startpoint.Y > line->endpoint.Y ? 3.f * M_PI / 2.f : M_PI / 2.f;
> + else
> + t = atanf((line->endpoint.Y - line->startpoint.Y) / (line->endpoint.X - line->startpoint.X));
> +
> + t_cos = cosf(t);
> + t_sin = sinf(t);
This seems like an oddly complicated and fragile way to normalize a vector.
Zebediah Figura <z.figura12(a)gmail.com> writes:
> Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com>
> ---
> server/device.c | 46 ++++++++++++++++++++--------------------------
> 1 file changed, 20 insertions(+), 26 deletions(-)
It's probably a matter of taste, but this doesn't look to me like an
improvement.
--
Alexandre Julliard
julliard(a)winehq.org
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://testbot.winehq.org/JobDetails.pl?Key=32694
Your paranoid android.
=== wvistau64 (32 bit module) ===
module.c:479: Test failed: Expected ERROR_MOD_NOT_FOUND or ERROR_DLL_NOT_FOUND (win9x) or ERROR_INVALID_PARAMETER (win2003), got 8
=== w2008s64 (32 bit module) =…
[View More]==
module.c:479: Test failed: Expected ERROR_MOD_NOT_FOUND or ERROR_DLL_NOT_FOUND (win9x) or ERROR_INVALID_PARAMETER (win2003), got 8
=== wvistau64 (64 bit module) ===
module.c:479: Test failed: Expected ERROR_MOD_NOT_FOUND or ERROR_DLL_NOT_FOUND (win9x) or ERROR_INVALID_PARAMETER (win2003), got 8
=== w2008s64 (64 bit module) ===
module.c:479: Test failed: Expected ERROR_MOD_NOT_FOUND or ERROR_DLL_NOT_FOUND (win9x) or ERROR_INVALID_PARAMETER (win2003), got 8
[View Less]
On 14 August 2017 at 20:04, Aric Stewart <aric(a)codeweavers.com> wrote:
> + script = get_opentype_script(hdc,psa,psc,FALSE);
Does that do anything? If I'm reading the code correctly that will set
it to the same value it already was. (In which case most of this would
simplify to "if (!script) script = MS_MAKE_TAG('l','a','t','n');")
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://testbot.winehq.org/JobDetails.pl?Key=32672
Your paranoid android.
=== wxppro (32 bit combo) ===
combo.c:315: Test failed: Focus not on Main Window, instead on 00000000
=== w2003std (32 bit combo) ===
combo.c:315: Test failed: Focus not on Main Window, instead …
[View More]on 00000000
=== wvistau64 (32 bit combo) ===
combo.c:315: Test failed: Focus not on Main Window, instead on 00000000
=== w2008s64 (32 bit combo) ===
combo.c:315: Test failed: Focus not on Main Window, instead on 00000000
=== w7u (32 bit combo) ===
combo.c:786: Test failed: Test 2, expected list height to be 16, got 0
combo.c:786: Test failed: Test 3, expected list height to be 16, got 18
combo.c:786: Test failed: Test 4, expected list height to be 32, got 18
combo.c:786: Test failed: Test 5, expected list height to be 32, got 36
combo.c:786: Test failed: Test 6, expected list height to be 32, got 36
combo.c:786: Test failed: Test 7, expected list height to be 32, got 36
combo.c:786: Test failed: Test 8, expected list height to be 32, got 36
combo.c:786: Test failed: Test 11, expected list height to be 16, got 0
combo.c:786: Test failed: Test 12, expected list height to be 16, got 18
combo.c:786: Test failed: Test 13, expected list height to be 32, got 18
combo.c:786: Test failed: Test 14, expected list height to be 48, got 36
combo.c:781: Test failed: Test 15, expected list height to be 48, got 54
combo.c:786: Test failed: Test 16, expected list height to be 64, got 54
combo.c:786: Test failed: Test 17, expected list height to be 64, got 72
combo.c:315: Test failed: Focus not on Main Window, instead on 00000000
=== w7pro64 (32 bit combo) ===
combo.c:315: Test failed: Focus not on Main Window, instead on 00000000
=== w8 (32 bit combo) ===
combo.c:315: Test failed: Focus not on Main Window, instead on 00000000
=== w864 (32 bit combo) ===
combo.c:315: Test failed: Focus not on Main Window, instead on 00000000
=== w1064 (32 bit combo) ===
combo.c:315: Test failed: Focus not on Main Window, instead on 00000000
=== wvistau64 (64 bit combo) ===
combo.c:315: Test failed: Focus not on Main Window, instead on 0000000000000000
=== w2008s64 (64 bit combo) ===
combo.c:315: Test failed: Focus not on Main Window, instead on 0000000000000000
=== w7pro64 (64 bit combo) ===
combo.c:315: Test failed: Focus not on Main Window, instead on 0000000000000000
=== w864 (64 bit combo) ===
combo.c:315: Test failed: Focus not on Main Window, instead on 0000000000000000
=== w1064 (64 bit combo) ===
combo.c:315: Test failed: Focus not on Main Window, instead on 0000000000000000
[View Less]
On 12 August 2017 at 11:06, <nneonneo(a)gmail.com> wrote:
> - /* Apple seems to be into arbitrary limits, and timeouts larger than
> - * 0xfffffffffffffbff immediately return GL_TIMEOUT_EXPIRED. We don't
> - * really care and can live with waiting a few μs less. (OS X 10.7.4). */
> + /* Timeouts near 0xffffffffffffffff may immediately return GL_TIMEOUT_EXPIRED,
> + * possibly because macOS internally adds some slop to the timer. To …
[View More]avoid this,
> + * we use a large number that isn't near the point of overflow (macOS 10.12.5).
> + */
> GLenum gl_ret = GL_EXTCALL(glClientWaitSync(fence->object.sync,
> - GL_SYNC_FLUSH_COMMANDS_BIT, ~(GLuint64)0xffff));
> + GL_SYNC_FLUSH_COMMANDS_BIT, (GLuint64)((1ULL << 62ULL) - 0xffff)));
Adjusting the workaround is probably fine, but ULL literals are not
portable. Does something along the lines of "~(GLuint64)0 >> 1" work
as well? I don't think we care about the low bits, but note that the
patch as it is doesn't actually preserve them.
[View Less]
Zebediah Figura <z.figura12(a)gmail.com> writes:
> Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com>
> ---
> dlls/krnl386.exe16/ne_module.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
I don't think that's a good idea. Why do you need that?
--
Alexandre Julliard
julliard(a)winehq.org
On 11.08.2017 16:10, Zebediah Figura wrote:
> +cpp_quote("#define INTERNETEXPLORERCONFIGURATION_HOST 0x00000001")
This should be a value of INTERNETEXPLORERCONFIGURATION enum.
Jacek
On 10.08.2017 20:52, Zebediah Figura wrote:
> +
> +cpp_quote("DEFINE_GUID(CLSID_InternetExplorerManager, 0xdf4fcc34, 0x067a, 0x4e0a, 0x83,0x52, 0x4a,0x1a,0x50,0x95,0x34,0x6e);")
Please use coclass, like in PSDK, instead.
Jacek
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://testbot.winehq.org/JobDetails.pl?Key=32633
Your paranoid android.
=== wvistau64 (32 bit module) ===
module.c:479: Test failed: Expected ERROR_MOD_NOT_FOUND or ERROR_DLL_NOT_FOUND (win9x) or ERROR_INVALID_PARAMETER (win2003), got 8
=== w2008s64 (32 bit module) =…
[View More]==
module.c:479: Test failed: Expected ERROR_MOD_NOT_FOUND or ERROR_DLL_NOT_FOUND (win9x) or ERROR_INVALID_PARAMETER (win2003), got 8
=== wvistau64 (64 bit module) ===
module.c:479: Test failed: Expected ERROR_MOD_NOT_FOUND or ERROR_DLL_NOT_FOUND (win9x) or ERROR_INVALID_PARAMETER (win2003), got 8
=== w2008s64 (64 bit module) ===
module.c:479: Test failed: Expected ERROR_MOD_NOT_FOUND or ERROR_DLL_NOT_FOUND (win9x) or ERROR_INVALID_PARAMETER (win2003), got 8
[View Less]
Hi Zebediah,
On 08.08.2017 20:04, Zebediah Figura wrote:
> HRESULT register_class_object(BOOL do_reg)
> {
> HRESULT hres;
>
> - static DWORD cookie;
> + static DWORD ie_cookie, iem_cookie;
>
> if(do_reg) {
> hres = CoRegisterClassObject(&CLSID_InternetExplorer,
> (IUnknown*)&InternetExplorerFactory, CLSCTX_SERVER,
> - REGCLS_MULTIPLEUSE|REGCLS_SUSPENDED, &cookie);
> - if (…
[View More]FAILED(hres)) {
> + REGCLS_MULTIPLEUSE, &ie_cookie);
> + if (FAILED(hres))
> + ERR("failed to register object %08x\n", hres);
> + hres = CoRegisterClassObject(&CLSID_InternetExplorerManager,
> + (IUnknown*)&InternetExplorerManagerFactory, CLSCTX_SERVER,
> + REGCLS_MULTIPLEUSE, &iem_cookie);
> + if (FAILED(hres))
> ERR("failed to register object %08x\n", hres);
> - return hres;
> - }
> -
> - hres = CoResumeClassObjects();
> - if(SUCCEEDED(hres))
> - return hres;
> -
> - ERR("failed to resume object %08x\n", hres);
> }
> -
> - return CoRevokeClassObject(cookie);
> + else
> + {
> + hres = CoRevokeClassObject(ie_cookie);
> + if (FAILED(hres))
> + ERR("failed to register object %08x\n", hres);
> + hres = CoRevokeClassObject(iem_cookie);
> + if (FAILED(hres))
> + ERR("failed to register object %08x\n", hres);
> + }
> + return hres;
> }
Are you sure that's how it's supposed to work? I didn't test it myself,
but given how it's registered and documented, I'd expect that
CLSID_InternetExplorerManager should live in a different process from
CLSID_InternetExplorer. It should be easy to distinguish those processes
with -startmanager command line argument.
> +static HRESULT WINAPI InternetExplorerManager_CreateObject(IInternetExplorerManager *iface, DWORD config, LPCWSTR url, REFIID riid, void **ppv)
> +{
> + FIXME("(%p)->(0x%x, %s, %s, %p) semi-stub\n", iface, config, debugstr_w(url), debugstr_guid(riid), ppv);
> +
> + return CoCreateInstance(&CLSID_InternetExplorer, NULL, CLSCTX_LOCAL_SERVER, riid, ppv);
> +}
Using CoCreateInstance is very questionable here (eg. due to the comment
above). Also, a patch adding a stub should just return E_NOTIMPL.
Implementation deserves a separated patch. I'd expect that it should
just use internal ieframe functions to create a new IE instance.
Also, I'd suggest to reorder patches to something like: 2, 4, 5, 1
(likely replaced by support for -startmanager command line argument), 3
and then a new patch implementing CreateObject.
Thanks,
Jacek
[View Less]
On 10.08.2017 08:45, Nikolay Sivov wrote:
> Based on patch by Anton Romanov <theli.ua(a)gmail.com>
>
> Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
> ---
> dlls/dwrite/dwrite_private.h | 6 ++++--
> dlls/dwrite/font.c | 24 ++++++++++++---------
> dlls/dwrite/main.c | 50 +++++++++++++++++++++++++++++++++-----------
> 3 files changed, 56 insertions(+), 24 deletions(-)
>
Isn't it also necessary to protect …
[View More]factory_cache_fontface()?
By the way: An alternative method to implement proper synchronization (which does
not require locking critical sections before InterlockedDecrement) would be to do
something like:
In the destructor:
--- snip ---
if (!ref)
{
EnterCriticalSection(...);
list_remove(...);
LeaveCriticalSection(...);
...
}
--- snip ---
And when querying cached font faces:
--- snip ---
EnterCriticalSection(...);
LIST_FOR_EACH_ENTRY(...)
{
...
/* the following code could also be hidden in QueryInterface */
if (InterlockedIncrement( &obj->refcount ) == 1)
{
InterlockedDecrement( &obj->refcount );
continue;
}
/* return it */
}
LeaveCriticalSection(...);
--- snip ---
This is also what is done in Wines threadpool implementation [1], and has the
advantage that the CS is not needed for every Release, only when the object is
really destroyed. But in the end it is a matter of taste, for rpcrt4 Jacek
also picked the "hold CS during InterlockedDecrement" method.
[1] https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/threadpool.c#l…
Best regards,
Sebastian
[View Less]
+ stat = GdipGetRegionData(region, (BYTE*)object_record +
FIELD_OFFSET(EmfPlusObject, Header.Size), size, NULL);
+ object_record->Header.DataSize = object_record->Header.Size;
+ object_record->Header.Size = record_size;
This is a little too clever. I'd rather have a solution similar to
write_path_data.
On 10.08.2017 15:41, Nikolay Sivov wrote:
> @@ -861,6 +877,10 @@ HRESULT factory_get_cached_fontface(IDWriteFactory5 *iface, IDWriteFontFile * co
> const void *cached_key;
> IDWriteFontFile *file;
>
> + if (IDWriteFontFace4_AddRef(cached->fontface) == 1)
> + continue;
> + IDWriteFontFace4_Release(cached->fontface);
This will not work as expected. The refcount also matters when the object is
about to be destroyed. There …
[View More]could be multiple threads running
factory_get_cached_fontface() before _Release() can finally remove the fontface
from the list. Please note that always calling _Release() also wouldn't be
correct because it would run the destructor twice.
It is not really necessary to access the private structs from other parts of
dwrite, but you should either:
* change AddRef to use something like interlocked_dec_if_nonzero (see ntdll/sync.c)
* implement the check in QueryInterface (manually run InterlockedDecrement to
decrement the refcount without going through the destructor)
There are probably also other ways, for example using a flag to make sure the
destructor is not called twice.
Best regards,
Sebastian
[View Less]
Nikolay Sivov <nsivov(a)codeweavers.com> wrote:
> - TRACE("(%p)->(0x%08x)\n", This, ch);
> + TRACE("(%p)->(0x%#x)\n", This, ch);
This will cause printing of the 0x prefix twice.
Same applies to other places.
--
Dmitry.
André Hentschel <nerv(a)dawncrow.de> writes:
> This fixes at least arm64-v8a builds, where you have lib64/libwine.so and bin/wine64
>
> Signed-off-by: André Hentschel <nerv(a)dawncrow.de>
> ---
>
> This and "winebuild: Improved position independent code generation" enable Wine on ARM64 Android phones (e.g. most Android devices).
> The check for 64 in the CPU_ABI can be discussed, but I think it's reliable and fast.
>
> dlls/wineandroid.drv/WineActivity.…
[View More]java | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
We already prefix with the ABI, so I think plain "lib" is better.
--
Alexandre Julliard
julliard(a)winehq.org
[View Less]