Stefan Dösinger <stefan(a)codeweavers.com> writes:
> @@ -6576,6 +6592,8 @@ int WINAPI WS_getaddrinfo(LPCSTR nodename, LPCSTR servname, const struct WS_addr
>
> hostname = get_hostname();
> if (!hostname) return WSA_NOT_ENOUGH_MEMORY;
> + fqdn = get_fqdn();
> + if (!fqdn) return WSA_NOT_ENOUGH_MEMORY;
It seems to me that you shouldn't need to retrieve both separately, the
FQDN contains the hostname already.
--
Alexandre Julliard
julliard(a)winehq.org
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 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.
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=32837
Your paranoid android.
=== w8 (32 bit visual) ===
visual.c:7952: Test failed: Input test: Quad 3(2crd-wrongidx) returned color 0x00ff00ff, expected 0x00ff0080
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 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.
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 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.
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 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.
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 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
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: Got unexpected color 0x00007580 for quad 2 (different colors).