wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

How can I debug an issue where a specific commit breaks transparency?
by zhengxianwei 16 Aug '25

16 Aug '25

>> | * cb787d0c566 - (2 months ago) win32u: Use a pbuffer to implement GL on memory DCs. - Rémi Bernon This commit caused one of my images to go from transparent to non-transparent. How should I debug this? I tried using RenderDoc to capture, but it errors out saying that on Linux it supports the core profile and not the compatibility profile. When I capture a trace with apitrace, it seems the program isn’t using a standard OpenGL frame rendering flow. May I ask what the default method is in Wine for debugging OpenGL or investigating incorrect/garbled rendering?

1 0

Wine staging 10.13 release
by Alistair Leslie-Hughes 16 Aug '25

16 Aug '25

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.13 (300 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * ws2_32: Add afunix.h header. Removed (No longer required). * None Added: * [31675] oleaut32: Use correct flag to detect IDispatch interfaces. Updated: * vkd3d-latest * oleaut32-default-pic-size 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

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

Does the timing of composition need to be moved from dcomp.dll to win32u?
by zhengxianwei 19 Jun '25

19 Jun '25

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

14 Jun '25

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

11 Jun '25

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

Mismatch Between win32syscalls.h and Windows System Call Numbers
by zhengxianwei 05 Jun '25

05 Jun '25

The APIs and call numbers in win32syscalls.h don't seem to match those in the Windows system. NtGdiAlphaBlend is listed as 4 in win32syscalls.h, but in reality, it's 0x1075 in win32u.dll on Windows 11. So are these values user-defined?

6 7

How to implement
by zhengxianwei 03 Jun '25

03 Jun '25

Hello, I would like to implement part of the logic within dcomp.dll in order to properly support applications that depend on it. I found that Zhiyi Zhang has implemented some data structures and interface stubs: https://gitlab.winehq.org/zhiyi/wine/-/commits/directcomposition?ref_type=h… Among these, the only method with actual logic appears to be IDCompositionDevice::Commit. However, after reviewing the implementation, I suspect there may be an issue with the current approach. It seems that Zhiyi Zhang starts a separate thread for each IDCompositionDevice, and this thread runs at a fixed refresh rate. But this approach appears to introduce a problem: from the window's (HWND) perspective, there are now *two threads* concurrently updating its device context. This results in a frame sequence similar to the following (note: the frame intervals are illustrative only): gdi_frame | dcomp_frame | gdi_frame | gdi_frame | dcomp_frame In this model, GDI-generated frames and DComp-generated frames are interleaved. Is my understanding correct? If so, I believe this method may lead to *inaccurate rendering results*, although I am not entirely certain about the exact consequences (as I am not an expert in this area). Therefore, I have decided to pursue an approach that produces a *standardized frame stream* like the following: gdi_mix_dcomp_frame | gdi_mix_dcomp_frame | gdi_mix_dcomp_frame In other words, I plan to merge GDI and DComp content before presenting each frame, ensuring consistency in the final output. I’ve reviewed the normal GDI frame refresh process, and it seems to follow this path: --> flush_window_surfaces --> window_surface_flush --> x11drv_surface_flush I’m planning to insert the following logic inside x11drv_surface_flush: if (is_hwnd_bind_to_dcomp(hwnd)) { struct Surface *final = get_comp_surface(hwnd); blend_dcomp_surface_over_gdi(dest_surface, final); } However, there’s still a question regarding *how to access the DComp data* inside x11drv_surface_flush. One option is to do the composition inside IDCompositionDevice::Commit() like this: void IDCompositionDevice_Commit() { composite_proc(); ... ... push_frame_to_x11drv(); } Another option is to *directly call into DComp APIs from within x11drv* to retrieve the surface data on demand. However, *both approaches feel somewhat unnatural*, and from what I can tell, Windows seems to establish some kind of *internal channel* to pass the composed content to the compositor. Is there a better or more canonical way to do this? Any suggestions or guidance would be greatly appreciated.

3 5

Wine staging 10.9 release
by Alistair Leslie-Hughes 01 Jun '25

01 Jun '25

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.9 (342 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None. Removed (No longer required). * None Added: * [44931] kernel32: Limit old exe to 3MB available space 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

IRandomAccessStream doesn't belong in windows.storage
by light gray 21 May '25

21 May '25

Hi devs! I've recently noticed that there's a new `windows.storage` WinRT library within Wine, and the library houses a stubbed implementation for `IRandomAccessStream`. There's an issue however. Looking at Windows registry keys to see which libraries register which runtime classes, it appears `shcore` houses the implementation for `IRandomAccessStream`. Not `windows.storage`. While inherently this isn't a problem since applications acquire runtime classes via `RoGetActivationFactory`, this could pose an issue later down the line when more WinRT interfaces get implemented within Wine. Mainly with how different classes are registered at compile time. Not only that, it would also make implementing functions such as `CreateRandomAccessStreamOnFile` a bit more complicated. As a reference, the following is my own experimental implementation of `IRandomAccessStream`: https://github.com/Weather-OS/WineCoreUAP/commit/318d3b8ecb036f04dcf6365235… Best wishes, Weather.

3 3

irc.libera.chat ?
by zhengxianwei 19 May '25

19 May '25

May I ask, what's the difference between asking questions on irc.libera.chat and asking here? Will this place gradually be phased out, with activity gradually shifting over there?

2 2

How to add multiple versions of the same DLL (with the same base name) in apisetschema.spec?
by zhengxianwei 18 May '25

18 May '25

Hello, I'm planning to add the following line to apisetschema.spec: *api-ms-win-power-setting-l1-1-1 = powrprof.dll* However, this causes a hash conflict with the existing line: *apiset api-ms-win-power-setting-l1-1-0 = powrprof.dll* May I ask how you usually resolve such conflicts? I'm concerned that removing version 1-0 might cause some older applications to stop working. Would it be possible to delete the router for 1-0 and instead add a new line like this? *ln -s powrprof.dll api-ms-win-power-setting-l1-1-0*

3 3

Wine staging 10.8 release
by Alistair Leslie-Hughes 17 May '25

17 May '25

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.8 (344 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * odbc32: SQLColAttributesW accept field id SQL_COLUMN_NAME. Removed (No longer required). * None Added: * None Updated: * vkd3d-latest * odbc32-fixes 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

Pre-commit
by robert lippmann 16 May '25

16 May '25

Hi all, I was looking in the docs, and came across this (https://gitlab.winehq.org/wine/wine/-/wikis/Git-Wine-Tutorial#removing-trai…): "It fixes whitespace on all the commits that you've made. I think it's pretty good about merge conflicts due to whitespace as well. I don't know of a way of doing this at commit time though.” Well, actually there is. Pre-commit (https://pre-commit.com/). Actually fixing whitespace is a built in rule, I believe. And there are various others tailored to different languages. It’s used pretty extensively in Python development, but doesn’t need Python. Since it runs in node, there’s a VSCode extension for it. So, I was wondering if there was any interest in perhaps adding the yaml configurations to the wine source tree, and figuring out what rules might be useful to implement. Thanks, Rob

1 0

Gitlab workflow question
by robert lippmann 16 May '25

16 May '25

Hi all, I submitted a patch, and needed to make changes. I made the changes, but am not sure how to submit it for re-review. I’m used to GitHub, and less formal development practices where it just automatically pops up as open again. Is there something I need to do to get it so it’s mergeable again? I’ve been rebasing for weeks. Should I just close the MR, and submit a new one? Thanks, Rob

2 2

[RFC] Running Wine under AddressSanitizer
by Yuxuan Shui 13 May '25

13 May '25

Hi all, I've been working on this for a while and the list of changes are getting long. So I think this is a good time as ever to announce it, and get some feedback to make sure I haven't gone too far off the rails. This email is a bit long. What is this about? =================== AddressSanitizer (ASan for short) is one of a class of tools that help with discovering common coding mistakes. ASan specifically detects memory problems, like buffer overflows, use after frees, memory leaks, etc. It has been extremely successful in the past decade, and the list of bugs it helped discover is very very long. It has even already seen successes in the wine project as well. @bernhardu was able to get the PE side of wine to work with ASan (with some exceptions) using llvm-mingw, after he fixed [1] a handful of incompatibility problems in llvm compiler-rt. And with that many bugs [2] were then discovered and fixed. And my plan is to take this a step further. [1]: https://github.com/llvm/llvm-project/pulls?q=is%3Apr+is%3Aclosed+author%3Ab… [2]: https://gitlab.winehq.org/bernhardu/wine/-/blob/asan-pe_2025-04-26_wine-10.… Goals ===== I want this to be a quick and easy to use tool, the first thing one would reach for when seeing something that might be a memory related problem. e.g. I spend 5 minutes reproducing the bug with an ASan-enabled wine build, if it catches it, then I am done; otherwise I move on with my usual debugging routine, without having wasted too much time. I also want it to be a first line of defence, which runs in CI to catch occasional bugs that slip through reviews. In my mind, this means 1) it must be easy to set up, ideally just a flag passed to `configure`, no fuss. 2) it should cover as much of wine as possible, both PE and unix, and ideally all PE DLLs. Current status ============== Wine builds and runs. A majority of test cases pass, but some failures seem to be ASan related, which I still need to investigate. Both stack and heap problems are detected and reported. Stack traces are captured, but only on the PE side, and are not symbolized yet - I need to pipe the numbers into llvm-symbolizer. Stack traces aren't being saved for heap allocations and frees, so for use-after-frees the reports aren't very useful yet. Fiber support is TODO. Leak detection is TODO as well. Works done so far ================ You can find my branch here: [3]. To build it, you need either clang, or a slightly patched [4] gcc, and you just run configure with `--enable-sanitize`. I tried to put into the commit messages as comprehensive a list of what I did as possible, but I'll also provide an overview here. It's very abbreviated to not make this email even longer. If you need to know of how ASan works, there is a quick explanation here [5]. Since no existing ASan runtimes can support the unix and the PE side at the same time, I chose to write my own ASan runtime. The runtime is made part of ntdll, since that's the first DLL that loads. A non-standard shadow offset was chosen, so in the new WoW64 mode the 32-bit and the 64-bit side can share a common shadow. Shadow memory is mapped very early inside `virtual_init` to make sure we can enable ASan for as much code as possible (though doing it inside the loader is also an option). Some care needed to be taken to make sure no false positives show up after stack manipulations (e.g. unwinding). Redzoning and quarantining is added to ntdll's heap allocator, though I don't like that. [3]: https://gitlab.winehq.org/yshui/wine/-/commits/address-sanitizer-presentable [4]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119926 [5]: https://github.com/google/sanitizers/wiki/AddressSanitizerAlgorithm Request for help ================ I intend to continue working on this, and I don't really see any technical challenges that would make this fundamentally undoable. But I do worry that certain things I had/will have to do might make this not upstreamable. So, I think I need some guidance. (I will open a draft MR on winehq gitlab shortly, if you prefer commenting there). Bad things I did to get it working ---------------------------------- There are certain things I did that didn't feel good when I did them, so I am listing them here to see if anyone has a better way to do them. - ASan runtime as part of ntdll. I can't think of a better place to put it, since the runtime needs to be available before PE code runs. This also means all these functions are exported from ntdll, and I have yet to find a way to not export them when ASan is disabled. - dinput/tests and ntoskrnl.exe/tests need to be linked with ntdll, since they need to get their ASan runtime from ntdll. - Things I added to winecrt0. ASan uses some global variables for information such as where the shadow was mapped, and dynamically linked libraries need this information too. On the unix side the dynamic linker will nicely find them for you, but the same doesn't work with PE. So ASan duplicates these variables for each DLLs. In the vanilla ASan runtime, this comes from linking with a "dynamic runtime thunk"; in wine, I felt winecrt0 is the best place for them? These variables also need to be initialized, which means calling an ASan interface function which is exported from ntdll, from `DllMainCRTStartup`. This meant I had to add `-Wl,--{start,end}-group` for starters, because now libntdll.a and libwinecrt0.a have circular dependencies. Additionally though this works for other DLLs, it becomes a problem when winecrt0 is linked into ntdll, which creates a importing-from-self situation. I added a `DllMainCRTStartup` to ntdll, so the one from libwinecrt0.a is not pulled in, thus breaking the cycle. But it definitely feels wrong. (Vanilla ASan does this initialization by putting functions into the `.CRT$XIB` section, which the CRT will call on DLL load. I was told wine CRT doesn't implement this). - `__WINE_FRAME`. I don't fully understand this, but IIUC this is a hacky exception/unwinding mechanism, for when the compiler doesn't support native __try/__except? These are put on the stack which later the unwinder will look for to find the correct exception handler. This doesn't work since ASan uses fake stack frames, so the unwinder can't find these `__WINE_FRAME`s and thus fails. I get this somewhat working by translating between fake and real stack addresses, ew. I don't know much about SEH, is it really not possible to use it for these __try/__excepts as well? Things I need advices on ----------------------- - Heap. I added ASan redzoning directly to the ntdll heap allocator, which I don't like since it added a lot of complexity to it, and it's not available on the unix side. I want to write an ASan specific allocator, since performance and memory efficiency aren't major concerns here, this allocator can be made simple. But I am not 100% sure if this is a good idea. - Stack trace. What's the best way of capturing stack traces from PE _and_ unix, if we are in a syscall/unix call for example? - Shadow offset. This is a bit complicated. clang supports dynamic shadow offset but mingw-gcc doesn't (it doesn't officially have ASan support), so for max compatibility we want a fixed shadow offset. If we want a single shadow to be shared between 32 and 64 bit in the case of new WoW64, the shadow offset needs to be below 4G, which basically precludes non-relocatable 64-bit PE from being loaded (the shadow takes 16 TiB); or we choose a high shadow offset for 64-bit to avoid conflicts, but that means we need to mirror this shadow into the lower 4G of the address space for 32-bit, which complicates the initialization phase. (If you made it to the end, thank you!) -- Regards Yuxuan Shui

1 0

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