Installers based on InnoSetup use invisible window owning the main
installer window. When focus is given to the installer window popup,
window managers sometimes do not raise it as their owner is invisible
and it stays below other windows unless they are minimized.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=49933
This is not a regression and it is arguably perhaps a window manager
bug, but it is also extremely annoying for users as installer windows
tend to disappear from the pager, as well as missing from the window
selector and below all other windows.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1859
This makes it possible to detect modules that weren't unmapped from
dlclose, and that we should not fixup again.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=49640
This usually happens with C++ winelibs, where some C++ symbols may
be inlined into the winelib, then later resolved in preference over
other symbol definitions when libstdc++ loads.
This results in circular dependency between the winelib and libstdc++,
making dlclose no-op.
In this case, reloading the lib later and calling `map_so_dll` on it
again will fixup the RVAs again, ending up with invalid addresses.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1498
On Tue Oct 18 12:09:32 2022 +0000, **** wrote:
> Marvin replied on the mailing list:
> ```
> Hi,
> It looks like your patch introduced the new failures shown below.
> Please investigate and fix them before resubmitting your patch.
> If they are not new, fixing them anyway would help a lot. Otherwise
> please ask for the known failures list to be updated.
> The tests also ran into some preexisting test failures. If you know how
> to fix them that would be helpful. See the TestBot job for the details:
> The full results can be found at:
> https://testbot.winehq.org/JobDetails.pl?Key=125085
> Your paranoid android.
> === debian11 (32 bit report) ===
> ddraw:
> ddraw7.c:15663: Test failed: Expected unsynchronised map for flags 0x1000.
> ddraw7.c:15663: Test failed: Expected unsynchronised map for flags 0x3000.
> Report validation errors:
> advapi32:security has no test summary line (early exit of the main process?)
> advapi32:security has unaccounted for todo messages
> kernel32:sync has no test summary line (early exit of the main process?)
> === debian11 (build log) ===
> 01d0:err:winediag:d3d_device_create The application wants to create a
> Direct3D device, but the current DirectDrawRenderer does not support this.
> 01d0:err:winediag:d3d_device_create The application wants to create a
> Direct3D device, but the current DirectDrawRenderer does not support this.
> 01d0:err:winediag:d3d_device_create The application wants to create a
> Direct3D device, but the current DirectDrawRenderer does not support this.
> === debian11 (build log) ===
> Use of uninitialized value $Flaky in addition (+) at
> /home/testbot/lib/WineTestBot/LogUtils.pm line 720, <$LogFile> line 24489.
> Use of uninitialized value $Flaky in addition (+) at
> /home/testbot/lib/WineTestBot/LogUtils.pm line 720, <$LogFile> line 24489.
> Use of uninitialized value $Flaky in addition (+) at
> /home/testbot/lib/WineTestBot/LogUtils.pm line 720, <$LogFile> line 24489.
> ```
I believe these failures should be fixed now, the `kernel32:sync` failure was coming from a thread terminated before it started. This should work fine now.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1088#note_23056
On Windows it seems sending to port 0 does nothing and does not error.
Presently sendmsg errors with EINVAL.
This works around it, by checking if it's port 0 then skipping the data.
--
v5: ntdll: Do not send data to port 0.
tests: Added to check if sending port 0 succeeds
https://gitlab.winehq.org/wine/wine/-/merge_requests/2100
On Windows it seems sending to port 0 does nothing and does not error.
Presently sendmsg errors with EINVAL.
This works around it, by checking if it's port 0 then skipping the data.
--
v6: ntdll: Do not send data to port 0.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2100
On Windows it seems sending to port 0 does nothing and does not error.
Presently sendmsg errors with EINVAL.
This works around it, by checking if it's port 0 then skipping the data.
--
v4: ntdll: Do not send data to port 0.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2100
On Windows it seems sending to port 0 does nothing and does not error.
Presently sendmsg errors with EINVAL.
This works around it, by checking if it's port 0 then skipping the data.
--
v3: ntdll: Do not send data to port 0.
tests: Added to check if sending port 0 succeeds
https://gitlab.winehq.org/wine/wine/-/merge_requests/2100
Commit 448e68ab5b937d168f5d091d8f65a7de534a9891 made searching for beatmaps in the in-game map list very slow, going from a few 100 ms to more than 10 seconds with my set of downloaded maps.
The first commit in this MR fixes this problem, and the second commit potentially helps too.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2114
On Windows it seems sending to port 0 does nothing and does not error.
Presently sendmsg errors with EINVAL.
This works around it, by checking if it's port 0 then skipping the data.
--
v2: ntdll: Do not send data to port 0.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2100
WinRT apps check if the Windows theme is set to dark mode through IUISettings3::GetColorValue().
An option needs to be added to Winecfg to enable dark mode support, which just sets the registry key AppsUseLightTheme to 0 for dark mode and 1 for light mode. It will have to be in a separate merge request. Also, not sure if a dark mode checkbox should be added or if dark mode should be automatically set based on the loaded theme in Wine. Though, for the latter there needs to be a property that returns the mode of the theme. Name alone might not be sufficient.
Marking this as draft because I'm not sure what I'm doing wrong with the test. It's returning E_NOINTERFACE for IUISettings3.
--
v2: windows.ui/tests: Add IUISettings3::GetColorValue() tests.
windows.ui: Implement IUISettings3::GetColorValue().
windows.ui: Add IUISettings3 stub interface.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2103
WinRT apps check if the Windows theme is set to dark mode through IUISettings3::GetColorValue().
An option needs to be added to Winecfg to enable dark mode support, which just sets the registry key AppsUseLightTheme to 0 for dark mode and 1 for light mode. It will have to be in a separate merge request. Also, not sure if a dark mode checkbox should be added or if dark mode should be automatically set based on the loaded theme in Wine. Though, for the latter there needs to be a property that returns the mode of the theme. Name alone might not be sufficient.
Marking this as draft because I'm not sure what I'm doing wrong with the test. It's returning E_NOINTERFACE for IUISettings3.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2103
For example, loading by full path, myodbc8a.dll causes a load
failure since it dependencies libcrypto-1_1.dll, libssl-1_1.dll
are in the DLL directory and not in the search path.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2113
Because of the change introduced in f21693b2, SM1 scalars and vectors were not longer getting the correct writemask when they are allocated, so this is fixed.
Also, the mapping of sm1 src register swizzles is moved outside `write_sm1_instruction()` since there are some instructions that don't do this, remarkably dp2add. This is fixed.
Before the last patch we are writing the operation as:
```
dp2add r0.x, r1.x, r0.x, r2.x
```
and now it is:
```
dp2add r0.x, r1.xyxx, r0.xyxx, r2.x
```
dp2add now has its own function, write_sm1_dp2add(), since it seems to
be the only instruction with this structure.
Ideally we would be using the default swizzles for the first two src arguments:
```
dp2add r0.x, r1, r0, r2.x
```
since, according to native's documentation, these are supported for all sm < 4.
But using default swizzles whenever is possible -- along with following the conversion of repeating the
last component of the swizzle when fewer than 4 components are to be
specified -- has a higher scope. Probably would involve modifying
`hlsl_swizzle_from_writemask()` and `hlsl_map_swizzle()`.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/81
Convert all consecutive calls to d7_DrawPrimitive(TRIANGLE_FAN) into
a single call to d7_DrawPrimitive(TRIANGLE_LIST) with all the vertices.
Note, it *increase* the number of vertices, but bandwith is much less costly
than multiple calls.
Note, only a very precise subset of the calls get buffered in order to
ensure that the disruption is minimal.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=33814
--
v4: ddraw: Add local buffer in d3d_device7_DrawPrimitive()
https://gitlab.winehq.org/wine/wine/-/merge_requests/2105
Convert all consecutive calls to d7_DrawPrimitive(TRIANGLE_FAN) into
a single call to d7_DrawPrimitive(TRIANGLE_LIST) with all the vertices.
Note, it *increase* the number of vertices, but bandwith is much less costly
than multiple calls.
Note, only a very precise subset of the calls get buffered in order to
ensure that the disruption is minimal.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=33814
--
v3: ddraw: Add local buffer in d3d_device7_DrawPrimitive()
https://gitlab.winehq.org/wine/wine/-/merge_requests/2105
Convert all consecutive calls to d7_DrawPrimitive(TRIANGLE_FAN) into
a single call to d7_DrawPrimitive(TRIANGLE_LIST) with all the vertices.
Note, it *increase* the number of vertices, but bandwith is much less costly
than multiple calls.
Note, only a very precise subset of the calls get buffered in order to
ensure that the disruption is minimal.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=33814
--
v2: ddraw: Add local buffer in d3d_device7_DrawPrimitive()
https://gitlab.winehq.org/wine/wine/-/merge_requests/2105
Convert all consecutive calls to d7_DrawPrimitive(TRIANGLE_FAN) into
a single call to d7_DrawPrimitive(TRIANGLE_LIST) with all the vertices.
Note, it *increase* the number of vertices, but bandwith is much less costly
than multiple calls.
Note, only a very precise subset of the calls get buffered in order to
ensure that the disruption is minimal.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=33814
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2105
Starting from Win10, when an apiset target dll (most notably in practice, ucrtbase and msvcrt) is loaded through import resolution or LoadLibrary, the dll from system32 directory is loaded regardless of presence of the same dll in a higher priority search path (e. g., at .exe directory). The other version of apiset target dll is still loaded if LoadLibrary() has a path (even if relative).
The practical issue I am trying to solve is the following scenario (encountered with a game using certain Uplay plugin) which has regressed since apisets implementation in Wine. The game imports ucrtbase.dll. Then, a plugin calls GetModuleHandle("api-ms-win-crt-runtime-l1-1-0.dll") and expects GetProcAddress("_crt_atexit") to succeed on the returned handle. The problem is that the game has ucrtbase.dll in its .exe directory. That one currently gets loaded. Then, find_dll_file() resolves api-ms-win-crt-runtime-l1-1-0.dll to the ucrtbase with a full path in system32 and tries to find that one (this part matches Windows behaviour as far as tests show). Since we have the other ucrtbase loaded this results in NULL module handle.
That issue is reproduced in my test in line 1661 (```ok( hapiset == hsystem || broken( old_behaviour && !hapiset )...```), current Wine behaviour corresponds to old Windows before Win10.
The third patch (which removes the last todo in the added test) is not something I hit with any real application so far, just stomped on that in tests and the fix looks trivial.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2101
The Ubisoft overlay version 135 hot patches and hooks wbem_locator_Release(),
but crashes if Release() is called inside CoCreateInstance(), a condition
that doesn't appear to happen on Windows. So we try to exhibit the
same behavior.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2104
--
v4: rpcrt4/tests: Use common code to set the firewall.
wsdapi/tests: Use common code to set the firewall.
dpnet/tests: Use common code to set the firewall.
dplayx/tests: Use common code to set the firewall.
webservices/tests: Move firewall code to a common header.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1987
On Windows it seems sending to port 0 does nothing and does not error.
Presently sendmsg errors with EINVAL.
This works around it, by checking if it's port 0 then skipping the data.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2100
In practice they never fail. If they fail, it means that there
is some underlying platform problem and there is little we can do
anyway. Under pthreads function prototypes allow returning failure,
but that's only used for "error checking" mutexes, which we
don't use.
On the other hand, error handling in vkd3d is rather inconsistent:
sometimes the errors are ignored, sometimes logged, sometimes
passed to the caller. It's hard to handle failures appropriately
if you can't even keep your state consistent, so I think it's
better to avoid trying, assume that synchronization primitives do
not fail and at least have consistent logging if something goes
wrong.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/75
Not completely sure if it's worth having for 8.0, but opening this to share the target I'm trying to reach.
--
v5: ntdll: Add a thread-specific category group cache.
ntdll: Use atomics and lock-free list for category groups.
ntdll: Implement Low Fragmentation Heap frontend.
ntdll: Count allocations and automatically enable LFH.
ntdll: Implement HeapCompatibilityInformation.
ntdll: Fix HeapWalk with empty uncommitted consecutive subheaps.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1628
Currently, apartment OXIDs are generated using the process ID
(and the thread ID for a single threaded-apartment). This means
that if an apartment is destroyed and re-created (using
`CoUninitialize` followed by `CoInitializeEx`), the newly created
apartment will end up with the same OXID as the old apartment.
However, testing shows that Windows will generate a *new* OXID
when an apartment is created in the above manner. This patch
uses `rpcss` to generate a new OXID. The current process id is combined
with an incrementing counter stored in rpcss. This ensures that
re-creating an apartment will not re-use an OXID.
Additionally, this fixes an issue that caused the .NET 4.8
installer to become stuck during the downloading stage under Wine.
The installer appears to perform the following actions:
1. Call `IBackgroundCopyJob_SetNotify` interface on a BITS
job. This causes us to create a proxy (in the other process
hosting 'qmgr') for the `IBackgroundCopyCallback` pointer
passed as a parameter.
2. Trigger MTA apartment re-creation (in the process running the setup,
*not* the process with the `IBackgroundCopyCallback` proxy)
through `CoUninitialize` followed by `CoInitializeEx`.
3. Call `IBackgroundCopyJob_SetNotify` on a newly created job,
but with the same `IBackgroundCopyCallback` pointer parameter.
When we deserialize the pointer passed to
`IBackgroundCopyJob_SetNotify`, we will end up re-using the same
`proxy_manager` that we created for the previous `IBackgroundCopyCallback`.
This is due to the fact that the OIDs happen to match (due to the fact that
the .NET 4.8 setup appears to perform actions in the same order between
the old and new apartments), and the apartment OXIDs match as explained above.
above. As a result, we will use the old IPID when we send RPC packets
using this `proxy_manager`. However, the new and old IPIDs will *never* match,
since their generation process includes `RtlGenRandom`. This will cause a fault
packet to be generated on the listening side of the RPC connection.
By avoiding re-using OXIDs across re-created apartments,
we ensure that the proxy side will never incorrectly re-use a stale `proxy_manager`.
--
v4: combase: Generate apartment OXID in rpcss
ole32/tests: Test that re-creating an apartment results in a new OXID
https://gitlab.winehq.org/wine/wine/-/merge_requests/2059
--
v2: ddraw/tests: Test that presenting does not set the pixel format on a window without one.
d3d8/tests: Test that presenting does not set the pixel format on a window without one.
d3d9/tests: Test that presenting does not set the pixel format on a window without one.
ddraw/tests: Remove unnecessary skips and conditionals from test_pixel_format().
https://gitlab.winehq.org/wine/wine/-/merge_requests/2072
Second commit is to be removed.
Signed-off-by: Bernhard Kölbl <besentv(a)gmail.com>
--
v2: windows.media.speech: Implement Vosk create and release functions in the unixlib.
windows.media.speech: Add a unixlib stub.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2091
Chromium uses this, and debug builds assert if it fails.
--
v2: kernelbase: Implement and add tests for QueryProcessCycleTime.
ntdll: Add stub for NtQueryInformationProcess(ProcessCycleTime).
https://gitlab.winehq.org/wine/wine/-/merge_requests/2089
First part of v2 of !27, which aims to:
* Allow allocation of variables of complex types that contain both numerics and objects across multiple register sets (regsets).
* Support the tex2D and tex3D intrinsics, inferring generic samplers dimension from usage, writing sampler declarations, and writing sample instructions.
* Support for arrays of resources for both SM1 and SM4 (not to be confused with the resource-arrays of SM 5.1, which can have non-constant indexes).
* Support for resources declared within structs.
* Support for synthetic combined samplers for SM1 and synthetic separated samplers for SM4, considering that they can be arrays or members of structs.
* Imitate the way the native compiler assigns the register indexes of the resources on allocation, which proved to be the most difficult thing.
* Support for object components within complex input parameters.
* Small fixes to corner cases.
This part consists on parsing the `tex2D()` and `tex3D()` intrinsics and beginning to support the allocation of variables across multiple regsets.
The whole series, is on my [master6](https://gitlab.winehq.org/fcasas/vkd3d/-/commits/master6) branch.
--
v4: vkd3d-shader/hlsl: Allocate register reservations in a separate pass.
vkd3d-shader/hlsl: Respect object reservations even if the object is unused.
vkd3d-shader/hlsl: Allocate objects according to register set.
vkd3d-shader/hlsl: Keep an hlsl_reg for each register set in hlsl_ir_var.
vkd3d-shader/hlsl: Store the type's register size for each register set.
vkd3d-shader/hlsl: Parse the tex3D() intrinsic.
vkd3d-shader/hlsl: Parse the tex2D() intrinsic.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/66
Needed for Gungrave G.O.R.E. (besides some bits in raw AAC handling).
The game is fine with GetInputStatus always returning MFT_INPUT_STATUS_ACCEPT_DATA for both h264 and aac but I think it is better to be correct here.
--
v3: winegstreamer: Set MF_SA_D3D11_AWARE attribute for h264 transform.
winegstreamer: Implement _GetInputStatus() for aac decoder transform.
winegstreamer: Implement _GetInputStatus() for h264 decoder transform.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2080
Bunch of misc fixes and preparations for further improvements. The location changes are especially important later when we'll use outer windows everywhere we pass them to external callers (such as script engines, since inner windows are an implementation detail and all operations otherwise should go through the outer window "proxy").
--
v3: mshtml: Embed the HTMLLocation into the outer window.
mshtml: Tie window.location to the outer window.
mshtml: Simplify dynamic props unlinking.
mshtml: Traverse and unlink builtin func disps.
mshtml: Return undefined from window.XMLHttpRequest for uninitialized
jscript: Pass the correct ServiceProvider when invoking external prop.
mshtml: Use Scrollbar_Auto as default for vertical scrollbars.
include/mshtml: Add the other IHTMLEventObj* interfaces.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2069
Continueing PDB support in winedump:
- stricter size checks (to protect against bogus files)
- more bits of PDB files dumped (ranges, sections, OMF details...)
- keeping cleaning up some internal fields names
--
v2: winedump: Be stricter about sizes while walking module's list.
winedump: Properly dump segment map information from PDB/DBI stream.
winedump: Dump correctly ranges' part of DBI stream.
winedump: Explain a bit more errors on hash header.
winedump: Correctly dump PDB_STREAM_INDEX.segment.
winedump: Introduce a helper to print PE section's characteristics.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2087
Continueing PDB support in winedump:
- stricter size checks (to protect against bogus files)
- more bits of PDB files dumped (ranges, sections, OMF details...)
- keeping cleaning up some internal fields names
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2087
Broadly this feels fine to me. Other that the few little leftover issues, this should probably be split in at least three commits (one for writing DOT, one for lowering DOT and another one for writing DP2ADD).
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/74#note_22630
Giovanni Mascellani (@giomasce) commented about libs/vkd3d-shader/hlsl_sm1.c:
> write_sm1_unary_op(ctx, buffer, D3DSIO_FRC, &instr->reg, &arg1->reg, D3DSPSM_NONE);
> break;
>
> + case HLSL_OP2_DOT:
> + switch (dst_type->base_type)
> + {
> + case HLSL_TYPE_FLOAT:
I think that SM1 basically only supports float, which is why all the other operations do not have this switch on the data type. I am not really confident on the details of this, but I guess that only float operations should arrive here anyway.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/74#note_22624
This series brings some improvements for debugging support
in the new wow64 environment:
- detects and adapt to the new environement
- fixes a couple of bugs appearing now
- adds a couple of tests
- extends winedbg to hide or display the modules when
multiple machines are used in the same process
--
v2: dbghelp: Identify a 32bit multi-arch wow64 debuggee as a live target.
winedbg: Don't expose to gdb module which machine isn't the process' one.
winedbg: Handle multi-machine process in command 'info share'.
dbghelp: Filter on machine when searching for Wine system PE modules.
dbghelp: Allow loading modules for different machines.
dbghelp: Add tests about modules loading.
dbghelp: Stop unwinding on potential 64bit frame for i386 cpu.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2078
Bunch of misc fixes and preparations for further improvements. The location changes are especially important later when we'll use outer windows everywhere we pass them to external callers (such as script engines, since inner windows are an implementation detail and all operations otherwise should go through the outer window "proxy").
--
v2: mshtml: Embed the HTMLLocation into the outer window.
mshtml: Tie window.location to the outer window.
mshtml: Return undefined from window.XMLHttpRequest for uninitialized
jscript: Pass the correct ServiceProvider when invoking external prop.
mshtml: Use Scrollbar_Auto as default for vertical scrollbars.
include/mshtml: Add the other IHTMLEventObj* interfaces.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2069
Needed for Gungrave G.O.R.E. (besides some bits in raw AAC handling).
The game is fine with GetInputStatus always returning MFT_INPUT_STATUS_ACCEPT_DATA for both h264 and aac but I think it is better to be correct here.
--
v2: winegstreamer: Set MF_SA_D3D11_AWARE attribute for h264 transform.
winegstreamer: Implement _GetInputStatus() for aac decoder transform.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2080
Huw Davies (@huw) commented about programs/rpcss/rpcss_main.c:
> return S_OK;
> }
>
> +/* Generates a new OXID suitable for use by an apartment.
> + * Each call to this function returns a distinct OXID.
> + * This function should not be invoked directly - use rpcss_get_new_apartment_oxid
> + * instead. */
> +HRESULT __cdecl irpcss_get_new_apartment_oxid(handle_t h, OXID *oxid)
> +{
> + HRESULT status;
> + ULONG oxid_upper_bits;
> +
> + static LONG oxid_lower_bits;
> +
> + status = I_RpcBindingInqLocalClientPID(h, &oxid_upper_bits);
> + ERR("Got client PID: %ld", oxid_upper_bits);
This looks like it's left-over from debugging.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2059#note_22593
Huw Davies (@huw) commented about programs/rpcss/rpcss_main.c:
> }
>
> +/* Generates a new OXID suitable for use by an apartment.
> + * Each call to this function returns a distinct OXID.
> + * This function should not be invoked directly - use rpcss_get_new_apartment_oxid
> + * instead. */
> +HRESULT __cdecl irpcss_get_new_apartment_oxid(handle_t h, OXID *oxid)
> +{
> + HRESULT status;
> + ULONG oxid_upper_bits;
> +
> + static LONG oxid_lower_bits;
> +
> + status = I_RpcBindingInqLocalClientPID(h, &oxid_upper_bits);
> + ERR("Got client PID: %ld", oxid_upper_bits);
> + if (status != S_OK) {
Please put the opening brace on a new line.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2059#note_22594
Huw Davies (@huw) commented about dlls/combase/apartment.c:
>
> - if (apt->multi_threaded)
> - {
> - /* FIXME: should be randomly generated by in an RPC call to rpcss */
> - apt->oxid = ((OXID)GetCurrentProcessId() << 32) | 0xcafe;
> - }
> - else
> - {
> - /* FIXME: should be randomly generated by in an RPC call to rpcss */
> - apt->oxid = ((OXID)GetCurrentProcessId() << 32) | GetCurrentThreadId();
> - }
> + /* Get a new OXID to use for this apartment. Note that re-creating
> + * an apartment (by calling CoUninitialize and then CoInitializeEx)
> + * will result in a new OXID. This ensures that we don't re-use a
> + * proxy_manager` that refers to a dead apartment. */
> + rpcss_get_new_apartment_oxid(&apt->oxid);
We would want to test for this failing (and probably clean up and return NULL).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2059#note_22591
Huw Davies (@huw) commented about programs/rpcss/rpcss_main.c:
> return S_OK;
> }
>
> +/* Generates a new OXID suitable for use by an apartment.
> + * Each call to this function returns a distinct OXID.
> + * This function should not be invoked directly - use rpcss_get_new_apartment_oxid
> + * instead. */
> +HRESULT __cdecl irpcss_get_new_apartment_oxid(handle_t h, OXID *oxid)
> +{
> + HRESULT status;
> + ULONG oxid_upper_bits;
> +
I think we can get rid of this blank line.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2059#note_22592