June 2025 - Wine-Devel - list.winehq.org

wine and safearray marshalling

by Ilya Sokolov

Hello I have a question about how WINE processes marshalling between .Net Core code and COM object. There is an application, which runs in x64 prefix. Application contains COM object and .Net Core user interface. Data between the com object and the UI are transmitted in structures, which contains safearrays of other structures, some of structures include BSTRs. Some example of code is listed below: typedef [uuid(59d7e939-2a40-4d4c-a750-e8bd85f08a77)] > struct stLimitsSettings > { > float AbortMinus; > float AbortPlus; > float MaxDriveVoltage; > float MaxShakerAcc; > float MaxShakerDisp; > float MaxShakerVel; > float MaxVDivGForRunning; > float MaxVDivGForStartup; > int PhusicalUnitIndex; > float ProductMass; > BSTR ShakerProducerName; > enLimitAndLevelUnitType TolAndAbortUnits; > float TolMinus; > float TolPlus; > int UnexceedLimitsNum; > float UnExceedAverAlpha; > float UnExceedStableLinePrec; > BSTR ShakerModelName; > BOOL CheckShakerLimits; > float SpectOutOfLimitsPers; > BOOL UseSigmaClippingInCheck; > enShkLimitType ShkLimitType; > > BOOL useMultyShkUnExFullLimits; > > stDetailedMassDesc DetailedMass; > BOOL LimitRandomLinesOutsideTheProfile; > > > float > LinesOutsideTheBorder; > > > BOOL > UseTableLimits; > > enWhatToLiminInRndSpectrum WhatToLimitInSpectrum; > float AbDDBSpectrumPlus; > float AbDDBSpectrumMinus; > float TolDDBSpectrumPlus; > float TolDDBSpectrumMinus; > enLimitAndLevelUnitType SpectrumLimitUnitType; > BOOL DisableLowLimitWhileOnNotching; > SAFEARRAY(stShkLimitPair) LimitsTable > SAFEARRAY(stChUnexceedLimit) UnexceedChParameters; > > BOOL CheckChannelsOnOverload; > }stLimitsSettings; > > > typedef [uuid(311D09EA-7943-4A18-ADAB-CFE991E4A3D1), > struct stSyntheseSRSPoint > { > float Freq; > float Responce; > float NegativeMax; > float PositiveMax; > } stSyntheseSRSPoint; > cpp_quote("struct > __declspec(uuid(\"{311D09EA-7943-4A18-ADAB-CFE991E4A3D1}\")) > stSyntheseSRSPoint;") > > typedef [uuid(6A8B679F-E7C6-45F6-A0DB-378D2E4CD0ED), > struct stSRSPointsFromSynthese > { > int PointsCount; > SAFEARRAY(stSyntheseSRSPoint) SRSPoints; > }stSRSPointsFromSynthese; > > typedef [uuid(747684a8-7b15-4215-8484-7e674fce3e16), > struct stSRSProfilesDescription > { > int ID; > BSTR Name; > float EndAcc; > float EndVel; > float EndDisp; > float MaxAcc; > float MaxVel; > float MaxDisp; > float PWA; > DWORD CompencateSeed; > stSRSSyntheseSettings SyntheseSettings; > stSRSTable SRSTable; > stWaveletsTable Wavelets; > stSRSPointsFromSynthese SynthesePoints; > DWORD RealShkLenInSamples; > float RealSampleRate; > }stSRSProfilesDescription; > cpp_quote("struct > __declspec(uuid(\"{747684a8-7b15-4215-8484-7e674fce3e16}\")) > stSRSProfilesDescription;") > > > typedef [uuid(d4b7ee82-d6ca-4131-9ab2-1c0ca9093935), > struct stMosaSRSProfiles > { > int ProfilesCount; > float MaxAcc; > float MaxVel; > float MaxDisp; > float EndAcc; > float EndVel; > float EndDisp; > float ShkTimeInSec; > double Te; > double TeConc; > SAFEARRAY(stSRSProfilesDescription) Profiles; > }stMosaSRSProfiles; > > typedef [uuid(ee6226d6-3ac9-47b4-aab3-3e1d612b8c69), > struct stMosaSRSTestSettingsStruct > { > BOOL IsReportSettingsInited; > BOOL TestStartQuestState; > DWORD TestTimeInSec; > DWORD TotalShkCount; > int ActiveOutputsCount; > int AxisesCount; > SAFEARRAY(stMultishakerOutputLimitsDescription) OutputLimits; > stMosaSRSProfiles TestProfiles; > stMultishTaskToAxisMap Axises; > stMultishakerReportSettings ReportSettings; > stAnalyseSettings AnalysesSettings; > stChannelsConfigSettings ChannelsConfig; > stControlSettings ControlSettings; > stLimitsSettings Limits; > stSchedule Schedule; > stDataSaveSettings DataSaveSettings; > }stMosaSRSTestSettingsStruct; > > Sometimes getting data woks well, however sometimes an error appears with log which looks like: 06e8:fixme:ole:IRecordInfoImpl_RecordClear Not supported vt = 29 > 06e8:fixme:ole:IRecordInfoImpl_RecordClear Not supported vt = 29 > 06e8:fixme:ole:IRecordInfoImpl_RecordClear Not supported vt = 29 > 06e8:fixme:ole:IRecordInfoImpl_RecordClear Not supported vt = 29 > 06e8:fixme:ole:IRecordInfoImpl_RecordClear Not supported vt = 29 > 06e8:fixme:ole:IRecordInfoImpl_RecordClear Not supported vt = 29 > 06e8:fixme:ole:IRecordInfoImpl_RecordClear Not supported vt = 29 > 06e8:fixme:ole:IRecordInfoImpl_RecordClear Not supported vt = 29 > 06e8:fixme:ole:IRecordInfoImpl_RecordClear Not supported vt = 29 > 06e8:fixme:ole:IRecordInfoImpl_RecordClear Not supported vt = 29 > 06e8:fixme:ole:IRecordInfoImpl_RecordClear Not supported vt = 29 > 06e8:fixme:ole:IRecordInfoImpl_RecordClear Not supported vt = 29 > 06e8:fixme:advapi:RegisterEventSourceW ((null),L".NET Runtime"): stub > 06e8:fixme:advapi:ReportEventW > (00000000CAFE4242,0x0001,0x0000,0x00000402,0000000000000000,0x0001,0x00000000,00007FFFFE27A7F0,0000000000000000): > stub > 06e8:err:eventlog:ReportEventW L"Application: VisProbe_SL.exe\n" > 06e8:err:eventlog:ReportEventW L"CoreCLR Version: 8.0.1425.11118\n" > 06e8:err:eventlog:ReportEventW L".NET Version: 8.0.14\n" > 06e8:err:eventlog:ReportEventW L"Description: The process was terminated > due to an unhandled exception.\n" > 06e8:err:eventlog:ReportEventW L"Exception Info: > System.AccessViolationException: Attempted to read or write protected > memory. This is often an indication that other memory is corrupt.\n" > 06e8:err:eventlog:ReportEventW L"Stack:\n" > 06e8:err:eventlog:ReportEventW L" at > System.StubHelpers.MngdSafeArrayMarshaler.ClearNative(IntPtr, System.Object > ByRef, IntPtr)\n" All the arrays are initialized with SafeArrayCreateEx and deleted with SafeArrayDestroy functions, BSTRs are allocated with SysAllocString and deleted with SysFreeString. Could you give me an advice of how to locate the reason of error and eliminate it?

June 30, 2025

Re: DXVK + DComp causes graphics rendering to fail

by zhengxianwei

After the adjustments in DXVK, it's working now. https://github.com/doitsujin/dxvk/issues/5053 On Fri, Jun 27, 2025 at 2:06 PM zhengxianwei <baikaishiuc(a)gmail.com> wrote: > I'm not sure whether this issue should be posted on the DXVK forum or > here. If I've posted it in the wrong place, I apologize. > > I wrote a test program called dcomp_test.exe, which is already working > under Wine. Its main function is to render circles, and the effect looks > like this: > > > [image: image.png] > > The actual operation is...： surface content = gdi * backgroup_alpha + > swapchain[0] * foreground_alpha > > > However, after replacing Wine's built-in DLLs with the ones I built from > DXVK > > specifically dxgi, d3d8, d3d9, d3d10core, d3d11, and d3d12 > > I found that the circle was no longer rendered. > > The image extracted from the swapchain contained all zeros. > [image: image.png] > > I did a quick trace and confirmed that it reached: > > 1. ID3D11DeviceContext1_DrawIndexed > 2. ID3D11DeviceContext1_Draw > > > https://github.com/wine-mirror/wine/blob/80bc1338bea7d9dac78ab449b4505e5bb9… > > So I feel that the circle is indeed being rendered onto the DXVK D3D11 > swapchain, > > but I'm not sure at which step the content fails to be retrieved correctly. > > Any suggestions are welcome > >

June 29, 2025

How long after XFlush is called does the screen typically refresh correctly?

by zhengxianwei

I wrote a small test program that modifies a region using BitBlt, then checks the color of that region. I found that even immediately after BitBlt, it takes over 80 milliseconds before the correct color can be reliably detected. Then, I added an XSync(gdi_display, False) after the XFlush in x11drv_surface_flush, and the delay dropped to around 50–60 milliseconds. Is this expected? I was hoping that after BitBlt, the updated color could be detected immediately, without needing to add a delay or jitter. But it seems that XFlush only pushes the commands to the X server, and is not like vkQueuePresentKHR with semaphores or fences, which signal that the data has been pushed to the display (even though that still doesn’t guarantee vertical scanout completion).

June 29, 2025

Re: Wine staging 10.11 release

by DodoGTA GT

> Various NTSync patches. You forgot to mention the silent disabling of the esync patches (also perhaps the transition period from esync to ntsync should be more clear)

June 28, 2025

Wine staging 10.11 release

by Alistair Leslie-Hughes

Summary since last release * Rebased to current wine 10.11 (289 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * Various NTSync patches. Removed (No longer required). * None Added: * None Updated: * vkd3d-latest Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

June 28, 2025

DXVK + DComp causes graphics rendering to fail

by zhengxianwei

I'm not sure whether this issue should be posted on the DXVK forum or here. If I've posted it in the wrong place, I apologize. I wrote a test program called dcomp_test.exe, which is already working under Wine. Its main function is to render circles, and the effect looks like this: [image: image.png] The actual operation is...： surface content = gdi * backgroup_alpha + swapchain[0] * foreground_alpha However, after replacing Wine's built-in DLLs with the ones I built from DXVK specifically dxgi, d3d8, d3d9, d3d10core, d3d11, and d3d12 I found that the circle was no longer rendered. The image extracted from the swapchain contained all zeros. [image: image.png] I did a quick trace and confirmed that it reached: 1. ID3D11DeviceContext1_DrawIndexed 2. ID3D11DeviceContext1_Draw https://github.com/wine-mirror/wine/blob/80bc1338bea7d9dac78ab449b4505e5bb9… So I feel that the circle is indeed being rendered onto the DXVK D3D11 swapchain, but I'm not sure at which step the content fails to be retrieved correctly. Any suggestions are welcome

June 27, 2025

Re: Issues in OpenGL 16bpp formats support

by Rémi Bernon

On 6/20/25 18:45, vyacheslav.chigrin(a)izba.dev wrote: > Hello, > > Two years ago I locally fixed some bug with Civilization III game, > caused by problems with 16bpp format support in OpenGL on joint of Wine > and Mesa libraries. I described my findings here > > https://bugs.winehq.org/show_bug.cgi?id=41930#c60 > > Now realized that may be bugtracker alone is not enough, and may be > writing to this e-mail list is better. > > I'm wondering if anybody interesting in fixing this issue? I will be > glad to work with somebody to fix this problem in the main Wine brunch > (just don't know correct workflow for upstreaming and discussing fixes > like that). > > With best regards, > Vyacheslav Chigrin > > Well that's perfect timing because we've recently dropped OSMesa in favor of PBuffer rendering through the GLX/EGL stack. Turns out that this also broke the game, see https://bugs.winehq.org/show_bug.cgi?id=58384, which I was looking into earlier, but that should be fixed with https://gitlab.winehq.org/wine/wine/-/merge_requests/8384 I think https://gitlab.winehq.org/wine/wine/-/merge_requests/8383 might also be useful here. As far as I can see, with both MR I don't see any terrain turning black anymore, because... it turns stripped orange instead (is this progress?). In short, memory DC are now using the accelerated GL stack to do their drawing, with some synchronization points where the bitmap is read into the GL front buffer, when a GL context is set current, or the other way around from the front buffer to the selected bitmap, when the GL context is flushed. This seems to be how Windows does it too, although we might be missing some sync points. It's not entirely clear when the data is being flushed in one way or the other on Windows. We have a couple of tests about it and I would suggest to have a look at `test_bitmap_rendering` in `dlls/opengl32/tests/opengl.c`, and maybe see if you can reproduce something similar to what the game is doing and find behavior differences with Windows. The pixel formats are enumerated from the Linux GL configs, and it's possible that there's some things to tweak there to match what memory DCs are supposed to enumerate, but other than that the pbuffer is created directly from the pixel format that was selected by the game. Here too, it should be possible to write tests to compare Windows vs Wine, and change our implementation to better match it. Cheers, -- Rémi Bernon <rbernon(a)codeweavers.com>

June 20, 2025

Issues in OpenGL 16bpp formats support

by vyacheslav.chigrin＠izba.dev

Hello, Two years ago I locally fixed some bug with Civilization III game, caused by problems with 16bpp format support in OpenGL on joint of Wine and Mesa libraries. I described my findings here https://bugs.winehq.org/show_bug.cgi?id=41930#c60 Now realized that may be bugtracker alone is not enough, and may be writing to this e-mail list is better. I'm wondering if anybody interesting in fixing this issue? I will be glad to work with somebody to fix this problem in the main Wine brunch (just don't know correct workflow for upstreaming and discussing fixes like that). With best regards, Vyacheslav Chigrin

June 20, 2025

Re: Does the timing of composition need to be moved from dcomp.dll to win32u?

by zhengxianwei

Or pass a user-level callback into win32u, and have it invoked inside win32u:composite? This might require adding a new syscall — not sure if that would make things simpler? On Thu, Jun 19, 2025 at 3:48 PM Zhiyi Zhang <zzhang(a)codeweavers.com> wrote: > > > On 6/19/25 14:13, zhengxianwei wrote: > > Zhiyi Zhang provided an implementation of DComp composition： > > > https://gitlab.winehq.org/zhiyi/wine/-/commit/ef4f90c2ae909f4a732f0ebeae3b7… > < > https://gitlab.winehq.org/zhiyi/wine/-/commit/ef4f90c2ae909f4a732f0ebeae3b7… > > > > > > I created a simple sample that renders three equally sized red circles > with varying alpha values on a plain white background window. > > > > On Windows, it displays as follows. > > > > dcomp_test_window.png > > > > But on Linux, it display as follows. > > dcomp_test_wine.png > > > > One of the main issues here is that the background turns black. This is > because the foreground (swapchain) is not alpha-blended with the background > (GDI); instead, it is simply overlaid using BitBlt. > > > > ``` > > * BitBlt(dst_dc, 0, 0, rect.right - rect.left, rect.bottom - > rect.top, src_dc, 0, 0, SRCCOPY); > > * > > ``` > > > > So I added an alpha_blend step here instead of simply using the original > BitBlt. > > > > ``` > > s1 = src_data; > > d1 = dst_data; > > for (int i = 0; i < height; i++) > > { > > for (int j = 0; j < width; j++) > > { > > // src is alpha pre multiple > > float bg_alpha = ((255.f - s1[3])) / 255; > > d1[0] = (d1[0] * bg_alpha) + s1[0]; > > d1[1] = (d1[1] * bg_alpha) + s1[1]; > > d1[2] = (d1[2] * bg_alpha) + s1[2]; > > > > s1 += 4; > > d1 += 4; > > } > > } > > > > //iret = SetDIBits(dst_hdc, dst_bitmap, 0, height, dst_data, &bmi, > DIB_RGB_COLORS); > > iret = SetDIBitsToDevice(dst_hdc, 0, 0, width, height, > > 0, 0, 0, height, dst_data, &bmi, DIB_RGB_COLORS); > > ``` > > The new display effect is as follows. > > dcomp_test_wine_alpha_blend.png > > It looks like basic blending is working, but the alpha values of the > circles are lost. After analyzing the issue, I found the following cause. > > > > > > I'll draw a diagram to briefly illustrate the cause of this issue. > > > > My original expectation of the image generation process > > > > flush1.png > > > > But the actual process is as follows > > > > image.png > > > > After the bitmap is alpha-blended and displayed on the screen, it is > retrieved again in the next frame and repeatedly involved in alpha blending > — resulting in redundant computations. > > > > > > > > I personally think that a more reasonable solution would be to insert > |window_surface_composition| within |window_surface_flush| to more > thoroughly resolve these kinds of issues > > > > image.png > > > > > > During |window_surface_flush|, composite the current surface with the > swapchain's surface into an offscreen surface, then flush that to the > screen. This way, the original window surface won't be affected. > > > Sounds reasonable. > > > > > > I'm trying to fix this issue now — do you have any suggestions? > > > > > > > > > >

June 19, 2025

Re: Does the timing of composition need to be moved from dcomp.dll to win32u?

by zhengxianwei

The part that confuses me here is that, in *win32u*, it doesn't seem convenient to manipulate data structures like *swapchain*. In *dcomp.dll*, I can use a large number of COM interface functions, such as IDXGISwapChain1_GetDesc and IDXGISwapChain1_GetBuffer. But is this allowed in *win32u*? If I were to heavily use COM interfaces within *win32u*, would that cause any issues? On Thu, Jun 19, 2025 at 3:48 PM Zhiyi Zhang <zzhang(a)codeweavers.com> wrote: > > > On 6/19/25 14:13, zhengxianwei wrote: > > Zhiyi Zhang provided an implementation of DComp composition： > > > https://gitlab.winehq.org/zhiyi/wine/-/commit/ef4f90c2ae909f4a732f0ebeae3b7… > < > https://gitlab.winehq.org/zhiyi/wine/-/commit/ef4f90c2ae909f4a732f0ebeae3b7… > > > > > > I created a simple sample that renders three equally sized red circles > with varying alpha values on a plain white background window. > > > > On Windows, it displays as follows. > > > > dcomp_test_window.png > > > > But on Linux, it display as follows. > > dcomp_test_wine.png > > > > One of the main issues here is that the background turns black. This is > because the foreground (swapchain) is not alpha-blended with the background > (GDI); instead, it is simply overlaid using BitBlt. > > > > ``` > > * BitBlt(dst_dc, 0, 0, rect.right - rect.left, rect.bottom - > rect.top, src_dc, 0, 0, SRCCOPY); > > * > > ``` > > > > So I added an alpha_blend step here instead of simply using the original > BitBlt. > > > > ``` > > s1 = src_data; > > d1 = dst_data; > > for (int i = 0; i < height; i++) > > { > > for (int j = 0; j < width; j++) > > { > > // src is alpha pre multiple > > float bg_alpha = ((255.f - s1[3])) / 255; > > d1[0] = (d1[0] * bg_alpha) + s1[0]; > > d1[1] = (d1[1] * bg_alpha) + s1[1]; > > d1[2] = (d1[2] * bg_alpha) + s1[2]; > > > > s1 += 4; > > d1 += 4; > > } > > } > > > > //iret = SetDIBits(dst_hdc, dst_bitmap, 0, height, dst_data, &bmi, > DIB_RGB_COLORS); > > iret = SetDIBitsToDevice(dst_hdc, 0, 0, width, height, > > 0, 0, 0, height, dst_data, &bmi, DIB_RGB_COLORS); > > ``` > > The new display effect is as follows. > > dcomp_test_wine_alpha_blend.png > > It looks like basic blending is working, but the alpha values of the > circles are lost. After analyzing the issue, I found the following cause. > > > > > > I'll draw a diagram to briefly illustrate the cause of this issue. > > > > My original expectation of the image generation process > > > > flush1.png > > > > But the actual process is as follows > > > > image.png > > > > After the bitmap is alpha-blended and displayed on the screen, it is > retrieved again in the next frame and repeatedly involved in alpha blending > — resulting in redundant computations. > > > > > > > > I personally think that a more reasonable solution would be to insert > |window_surface_composition| within |window_surface_flush| to more > thoroughly resolve these kinds of issues > > > > image.png > > > > > > During |window_surface_flush|, composite the current surface with the > swapchain's surface into an offscreen surface, then flush that to the > screen. This way, the original window surface won't be affected. > > > Sounds reasonable. > > > > > > I'm trying to fix this issue now — do you have any suggestions? > > > > > > > > > >

June 19, 2025