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

Gitlab News
by Alexandre Julliard Sept. 15, 2025

Sept. 15, 2025

Folks, As you may have noticed, now that the ARM64 support is done (just kidding), I've picked up the work on the Gitlab migration: 1. The Wiki has been moved to Gitlab, it's now at [1]. Existing URLs to the previous Wiki are redirected to the appropriate page. There are also separate Wikis for appdb, vkd3d and wine-staging, under their respective project pages. As part of the migration I've done some minor edits, but most of the Wiki is badly out-of-date, and could use some love. Help is welcome! Check the Writers page [2] for details on how to contribute. 2. We are now hosting the Mono project on the WineHQ Gitlab [3]. Please join me in welcoming the Mono developers to our community! 3. We have new hardware for the Gitlab server, which is now noticeably faster. Thanks to Jeremy Newman for setting this up! This also made it possible to enable robots.txt again so that our content is indexed. The next step will be to install new hardware for the Gitlab runners to offer more CI bandwidth. 4. The Gitlab issue tracker is currently disabled because it was attracting too much spam. I'm going to re-enable it, first for use by Mono, and then ultimately also for Wine itself. To fight the spam I'm planning to add an explicit user verification step, modelled along the procedure used by Freedesktop.org [4]. 5. As part of the new sign-up process, I think it would be a good idea to have an explicit Code of Conduct to spell out our expectations. Instead of reinventing the wheel, I propose that we adopt the Contributor Covenant [5] that many other projects (including Mono) are already using. Thoughts? Questions? Comments? [1]: https://gitlab.winehq.org/wine/wine/-/wikis [2]: https://gitlab.winehq.org/wine/wine/-/wikis/Writers [3]: https://gitlab.winehq.org/mono [4]: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/wikis/home [5]: https://www.contributor-covenant.org/ -- Alexandre Julliard julliard(a)winehq.org

4 4

How to use AddressSanitizer with Wine?
by Alex Henrie July 13, 2025

July 13, 2025

Dear oenologists, I would like to use GCC's AddressSanitizer [1] to investigate a memory corruption bug in Wine. There must be a way to do it because I see multiple references to "ASan" in the Wine commit log in commits from this year.[2] I found some instructions on the WineHQ wiki,[3] but I get a myriad of linker errors when I try to follow them. What Linux distributions can successfully compile Wine with libasan? Are there special steps not mentioned in the wiki? Does AddressSanitizer work with MinGW, or only with non-PE builds? I'd love to get AddressSanitizer working myself, but even if I can't, thanks to Bernhard and Nikolay for using it to fix a lot of bugs already. -Alex [1] https://github.com/google/sanitizers/wiki/AddressSanitizer [2] https://gitlab.winehq.org/wine/wine/-/commits/master?search=ASan [3] https://gitlab.winehq.org/wine/wine/-/wikis/Building-Wine#memory--address-c…

2 5

wine and safearray marshalling
by Ilya Sokolov June 30, 2025

June 30, 2025

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?

1 0

DXVK + DComp causes graphics rendering to fail
by zhengxianwei June 29, 2025

June 29, 2025

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

1 1

How long after XFlush is called does the screen typically refresh correctly?
by zhengxianwei June 29, 2025

June 29, 2025

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).

1 0

Wine staging 10.11 release
by Alistair Leslie-Hughes June 28, 2025

June 28, 2025

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.

2 1

Issues in OpenGL 16bpp formats support
by vyacheslav.chigrin＠izba.dev June 20, 2025

June 20, 2025

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

2 1

Does the timing of composition need to be moved from dcomp.dll to win32u?
by zhengxianwei June 19, 2025

June 19, 2025

Zhiyi Zhang provided an implementation of DComp composition： 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. [image: dcomp_test_window.png] But on Linux, it display as follows. [image: 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. [image: 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 [image: flush1.png] But the actual process is as follows [image: 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: 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. I'm trying to fix this issue now — do you have any suggestions?

2 3

Wine staging 10.10 release
by Alistair Leslie-Hughes June 14, 2025

June 14, 2025

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.10 (348 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None. 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.

1 0

Is it normal that the COM vtbl structure cannot be aligned between Windows and Wine
by zhengxianwei June 11, 2025

June 11, 2025

In wine, Visual2Vtbl ``` typedef struct IDCompositionVisual2Vtbl { BEGIN_INTERFACE /*** IUnknown methods ***/ HRESULT (STDMETHODCALLTYPE *QueryInterface)( IDCompositionVisual2 *This, REFIID riid, void **ppvObject); ULONG (STDMETHODCALLTYPE *AddRef)( IDCompositionVisual2 *This); ULONG (STDMETHODCALLTYPE *Release)( IDCompositionVisual2 *This); /*** IDCompositionVisual methods ***/ HRESULT (STDMETHODCALLTYPE *SetOffsetX)( IDCompositionVisual2 *This, float offset_x); HRESULT (STDMETHODCALLTYPE *SetOffsetXAnimation)( IDCompositionVisual2 *This, IDCompositionAnimation *animation); HRESULT (STDMETHODCALLTYPE *SetOffsetY)( IDCompositionVisual2 *This, float offset_y); ``` setOffsetX (float *) at offset 0x18 [image: visual2vtbl.png] But in windows 0x18 is setOffsetX (Animation *) Is this correct?

2 4