wine-devel

wine-devel@winehq.org

84467 discussions

Travels
by Alexandre Julliard 21 Jul '25

21 Jul '25

Folks, Just a heads up that I'm going to be traveling for the next 3 weeks. I'm still going to review and commit MRs, but on a somewhat irregular schedule. Also there won't be a new release during that time, so Wine 10.13 will be out on August 15. -- Alexandre Julliard julliard(a)winehq.org

1 0

Upcoming vkd3d 1.17 release
by Henri Verbeet 17 Jul '25

17 Jul '25

Hi all, The planned release date for vkd3d 1.17 is Thursday August 21. That means the public API will become frozen a week from now on July 24, and features will be frozen two weeks before the release, on August 7. This does not mean that development should slow down or stop, of course; after making sure that we're in good shape to release, this would be the ideal time to make sure any larger features are ready to get merged at the start of the next development cycle. As usual, if you're an upstream vkd3d developer, please do the following: - Keep an eye on Bugzilla for any reported regressions. - Review any API changes since the previous release. - Verify that all vkd3d tests pass on your hardware/setup, and please send fixes if they don't. - Review and improve the documentation. - Get any larger features ready to get merged at the start of the next development cycle. If you're a downstream user of vkd3d, please test your applications for any regressions, and file bug reports if you find any. The planned release date for vkd3d 1.18 is November 20. A tentative release schedule for future releases can be found on the vkd3d wiki[1]. Regards, Henri [1] https://gitlab.winehq.org/wine/vkd3d/-/wikis/release-schedule

1 0

How to use AddressSanitizer with Wine?
by Alex Henrie 13 Jul '25

13 Jul '25

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 staging 10.12 release
by Alistair Leslie-Hughes 12 Jul '25

12 Jul '25

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.12 (292 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Removed (No longer required). * None Added: * [52278] comctl32: Animate support AVI msvc codex. * [36686] msxml: Support ISAXXMLReader::putFeature normalize-line-breaks option Updated: * msxml3-element_props 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

Add option to winebuild to disable ASLR/dynamicbase
by Tres Finocchiaro 09 Jul '25

09 Jul '25

Hi, I'm a maintainer of LMMS and we use a wine bridge for loading 32-bit and 64-bit VST plugins into the Linux version of our software. We've recently updated our build tools and noticed that some of our older 64-bit VSTs fail to load. After a lot of back and forth, we've isolated the issue to the following wine commit: > Commit 518e394 julliard committed on Sep 25, 2023 > winebuild: Set ASLR-related dll flags by default. > https://github.com/wine-mirror/wine/commit/518e394794160818ffe6826c874ff2f5… One of our developers has proposed a patch which reverts this behavior here: https://github.com/Fastigium/winebuild/commit/7f9e27e44cfb8eba79f3850f46e12… My questions are as follows: 1. Would winehq be receptive to a winebuild flag that allows the old behavior? 2. If acceptable, would you prefer LMMS author this patch, or is this change trivial enough/small enough that the winehq team would prefer to tackle it themselves? 3. Lastly, quoting a past mailing list convo, should we be doing our wine bridge differently? Currently we build RemovePluginVst64.so.exe. "[...] I don't think we have any plans to deliberately break the old all-in-one .dll.so binaries. It is quite likely that this functionality will bitrot over time though. Also the functionality that the PE/unix split was introduced for won't be available that way [...]" Source: https://list.winehq.org/mailman3/hyperkitty/list/wine-devel@winehq.org/mess… Thanks kindly for your time, -Tres - Tres.Finocchiaro(a)gmail.com

4 9

wine and safearray marshalling
by Ilya Sokolov 30 Jun '25

30 Jun '25

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 29 Jun '25

29 Jun '25

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 29 Jun '25

29 Jun '25

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 28 Jun '25

28 Jun '25

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 20 Jun '25

20 Jun '25

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel