wine-devel

wine-devel@winehq.org

9 participants
84397 discussions

Wine staging 7.18 release
by Alistair Leslie-Hughes 23 Sep '22

23 Sep '22

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 7.18 (514 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * ws2_32: Return a valid value for WSAIoctl SIO_IDEAL_SEND_BACKLOG_QUERY. * dwrite: Test IDWriteTextFormat with nonexistent font. * dwrite: Use MapCharacters for non-visual characters. * dwrite: Use MapCharacters for dummy line metrics. Added: * None Updated: * server-unix_name * ntdll-Junction_Points 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

What macOS SDK is being tested against on gitlab?
by Dean Greer 23 Sep '22

23 Sep '22

Hi everyone, I’d just tried to build the current git and winemac.drv is failing building on macOS Monterey with the latest 12.3 SDK so I’m assuming the gitlab test is using an older macOS SDK?

3 10

How to test out wines WoW64?
by Dean Greer 23 Sep '22

23 Sep '22

Hi everyone, Since there now seems to be support within winex11.drv and winemac.drv what patches are now required to make use of the WoW64 work? I'd like to have this enabled within the macOS packages as soon as possible even if that means possibly carrying some patches locally for a while, ideally having a way to build the contents of i386-windows without needing to build i386-unix.

2 3

[vkd3d] Handling object components within the HLSL compiler.
by Francisco Casas 20 Sep '22

20 Sep '22

Hello, I write this update on what I am working on, because I think it introduces some architectural changes that may be good to discuss, or at least mention. Sorry if this text is a bit dense, I hope to send all this as a merge request in a couple of days from now. Albeit we may want to avoid merging before the code freeze ends. More than a week ago, I started trying to implement SM1 resource loads. For this, in particular, it is necessary to infer each sampler's dimensions from usage (a use in a tex2D implies that the sampler is 2D, if not previously declared as such). This gets complicated when there are arrays of samplers, because each sampler component can have a different dimension, and yet being part of the same variable. For solving this I tried introducing a field to allow us to store data for each component within hlsl_ir_var. But this turned to be a complicated solution. As now, we lost the component information in the derefs once we start working with register offsets. I also wanted to have per-component data because I realized that, in general, we are not handling object components properly when they are part of a larger array/struct. But then I thought on an alternative solution: adding a compiler pass to promote each object component within a large variable to a new standalone variable, and prepend a store from this standalone variable to the the original path of the component within the large variable; relying on copy-prop and dce so that all references that refer to these components end up pointing to the new standalone variable. This allows us to use the fields of the hlsl_ir_var (in particular, the register allocation) for each object component, which solves the problem. While that strategy works, I then realized that we cannot use it when targeting SM1 profiles, because we wouldn't be replicating the CTAB (which doesn't introduce a new variable for each component in multi-dimensional object arrays, just increases its register size). SM4 on the other hand seems to do this, separating each sampler and texture as its own variable in the RDEF block. My conclusion then, is that it is a good idea to separate each object component into its own variable in SM4 (as long they are named with the correct subscripts, like "foo.tex[3]"). And while we can't do that in SM1, the good news is that SM1 doesn't allow objects as components of larger types except within (possible multi-dimensional) arrays. Samplers and Textures cannot be components of structs within SM1 profiles, so we only have to support those cases in hlsl_sm1.c. This approach also has the benefit that now, all the component register allocation information should be representable using the fields in the hlsl_ir_var struct and the register size data within hlsl_type [1], since each variable should only care about a single register type now. Storing register allocation data component-wise should not be necessary. So I am implementing a series of patches to ensure that: * When targeting SM4 profiles, all object components are separated into a sole variable. * When targeting SM1 profiles, it is not allowed to declare objects as components of structs; so they will either be a sole variable, or belong to either a (possibly multi-dimensional) array of elements of the same type, as declared within the shader. * SM1 resource loads work. My plan for this series, in terms of patches is: * Parse the tex3D() intrinsic. (already made by zf) * Parse the tex2D() intrinsic. (already made by zf) * Validate that object are not components of structs in SM1. * Properly allocate registers for object arrays for SM1. * Infer sampler register dimensions and write declarations in SM1. * Write resource loads in SM1. * Separate objects as standalone variables in SM4. * Lower combined samplers to separate sampler and texture objects for SM4. (already made by zf) * Lower separate sampler and texture objects to combined samplers for SM1. (already made by zf) It remains to check if object arrays are handled properly in the last two [2], or modify these patches accordingly. Best regards, Francisco. --- [1] I know we intend to remove this field later, when we move register allocation to each sm*_write.c, but I think we probably want to replace those precomputed register offset fields with equivalent SM-specific functions that retrieve the register offset for each component. [2] In SM1 profiles, when there are texture arrays and they are used together with samplers, only one variable is created (not one for each pair of components). This is allowed: ``` Texture2D tex[3][2]; sampler sam; float4 main() : SV_TARGET { return tex[0][1].Sample(sam, float2(1, 2)) + tex[1][0].Sample(sam, float2(1, 2)); } ``` This is allowed (but "not yet implemented" in fxc 9 and 10) ``` Texture2D tex; sampler sam[2][3]; float4 main() : SV_TARGET { return tex.Sample(sam[0][2], float2(1, 2)) + tex.Sample(sam[1][0], float2(1, 2)); } ``` This is not allowed: ``` Texture2D tex[3]; sampler sam[4]; float4 PSMain() : SV_TARGET { return tex[1].Sample(sam[1], float2(1, 2)) + tex[2].Sample(sam[0], float2(1, 2)); } ``` gives: ``` error X4581: Cannot use texture arrays on DX9 targets with multiple samplers. ```

2 5

Request for new 7.0 stable release
by Nick Sarnie 18 Sep '22

18 Sep '22

Hi, I'm part of the Wine packaging team for Gentoo. We noticed that the 7.0.x stable branch is currently at 7.0, and the 6.0.x stable branch has had some maintenance releases after the release of 7.0, so there have been some bug fixes backported to 6.0.x (e.g. 6.0.4) that are not available in the 7.0 stable release. Would the Wine team be willing to do a maintenance release for the 7.0.x branch to include these bug fixes (and possibly others)? If not, would you please explain the rationale behind that decision and the intended stable branch release cadence? Thanks for your time, Sarnex

2 2

WineHQ.org Downtime
by Jeremy Newman 12 Sep '22

12 Sep '22

The WineHQ.org server will be down for maintenance and upgrades starting today 2022-09-12 at 13:00 CDT (GMT-5) This downtime will be a minimum of 30 minutes, but could take longer depending on any issues that arise. This will take offline all mailing lists and websites during the maintenance timeframe. After the maintenance is complete, various services may take longer to come back online or may exhibit unexpected behavior. We will be fixing these issues are quickly as we can. Thanks for your patience and I will reply back to this thread if anything changes. I will also be online on the #winehackers IRC room. -N

1 1

Re: fixing some fixme code
by Jin-oh Kang 12 Sep '22

12 Sep '22

Forwarding to wine-devel. Please remember to use the "reply all" button next time. Thank you! On Mon, Sep 12, 2022, 11:11 AM Owen Hogarth <gurenchan(a)gmail.com> wrote: > Hello guys, I am trying to get this program; R Trader Pro to work on Linux. > I installed winetricks and then I received some different errors. > > I would like to fix the problem but I would also like to avoid doing > unnecessary work, that's why I am asking on the development mailing list. > > Here's the new error log, is it possible to get the program working? > 017c:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling > back to RandR 1.0. Please consider using the Nouveau driver instead. > 0174:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling > back to RandR 1.0. Please consider using the Nouveau driver instead. > 0174:fixme:file:NtLockFile I/O completion on lock not implemented yet > 0174:fixme:ntdll:NtQuerySystemInformation info_class > SYSTEM_PERFORMANCE_INFORMATION > 0194:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling > back to RandR 1.0. Please consider using the Nouveau driver instead. > 0174:fixme:wincodecs:jpeg_decoder_get_metadata_blocks stub > 0174:fixme:imm:ImeSetActiveContext (0x2ca590, 1): stub > 0174:fixme:imm:ImmReleaseContext (0004006E, 002CA590): stub > 017c:fixme:imm:ImeSetActiveContext (0x3c780, 0): stub > 017c:fixme:imm:ImmReleaseContext (0000000000020082, 000000000003C780): stub > 0174:fixme:wincodecs:jpeg_decoder_get_metadata_blocks stub > 0174:err:richedit:ReadStyleSheet skipping optional destination > 0174:err:richedit:ReadStyleSheet skipping optional destination > 0174:err:richedit:ReadStyleSheet skipping optional destination > 0174:fixme:wincodecs:jpeg_decoder_get_metadata_blocks stub > 0174:fixme:wincodecs:jpeg_decoder_get_metadata_blocks stub > 0174:fixme:wincodecs:jpeg_decoder_get_metadata_blocks stub > 0174:fixme:msi:ITERATE_CreateShortcuts poorly handled shortcut format, > advertised shortcut > 0174:fixme:msi:ITERATE_CreateShortcuts poorly handled shortcut format, > advertised shortcut > 0174:fixme:msi:ITERATE_CreateShortcuts poorly handled shortcut format, > advertised shortcut > 01e8:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling > back to RandR 1.0. Please consider using the Nouveau driver instead. > 01f0:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling > back to RandR 1.0. Please consider using the Nouveau driver instead. > 01e0:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling > back to RandR 1.0. Please consider using the Nouveau driver instead. > 01f8:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling > back to RandR 1.0. Please consider using the Nouveau driver instead. > regsvr32: Successfully registered DLL 'C:\Program Files > (x86)\Rithmic\Rithmic Trader Pro\StockChartX.ocx' > 0174:fixme:msi:internal_ui_handler internal UI not implemented for message > 0x0b000000 (UI level = 5) > 0174:fixme:msi:internal_ui_handler internal UI not implemented for message > 0x0b000000 (UI level = 5) > 0174:fixme:wincodecs:jpeg_decoder_get_metadata_blocks stub > 0200:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling > back to RandR 1.0. Please consider using the Nouveau driver instead. > 0200:fixme:mscoree:parse_supported_runtime > sku=L".NETFramework,Version=v4.5.2" not implemented > 0200:fixme:mscoree:parse_supported_runtime > sku=L".NETFramework,Version=v4.5.2" not implemented > 0200:fixme:ntdll:NtQuerySystemInformation info_class > SYSTEM_PERFORMANCE_INFORMATION > 0200:fixme:nls:GetFileMUIPath stub: 0x10, > L"C:\\windows\\system32\\tzres.dll", (null), 0032EE98, 00DAA728, 0032EE9C, > 0032EE90 > 0200:fixme:nls:GetFileMUIPath stub: 0x10, > L"C:\\windows\\system32\\tzres.dll", (null), 0032EE98, 00DAA728, 0032EE9C, > 0032EE90 > 0200:fixme:nls:GetFileMUIPath stub: 0x10, > L"C:\\windows\\system32\\tzres.dll", (null), 0032EE98, 00DAA728, 0032EE9C, > 0032EE90 > 0200:fixme:imm:ImeSetActiveContext (0xdc41c0, 1): stub > 0200:fixme:imm:ImmReleaseContext (00030080, 00DC41C0): stub > 0200:fixme:winsock:errno_from_unix unknown error: Device or resource busy > 0200:err:winediag:getaddrinfo Failed to resolve your host name IP > 0218:fixme:wbemprox:wbem_locator_ConnectServer authentication not supported > 0218:fixme:wbemprox:wbem_locator_ConnectServer specific locale not > supported > 0218:fixme:wbemprox:wbem_locator_ConnectServer unsupported flags > 021c:fixme:wbemprox:wbem_locator_ConnectServer authentication not supported > 021c:fixme:wbemprox:wbem_locator_ConnectServer specific locale not > supported > 021c:fixme:wbemprox:wbem_locator_ConnectServer unsupported flags > wine: Read access denied for device L"\\??\\Z:\\", FS volume label and > serial are not available. > 0200:fixme:winsock:errno_from_unix unknown error: Device or resource busy > 0200:err:winediag:getaddrinfo Failed to resolve your host name IP > 0200:fixme:winsock:errno_from_unix unknown error: Device or resource busy > 0200:err:winediag:getaddrinfo Failed to resolve your host name IP > An error occured while contacting the license server. > > Raised in : com.omnesys.omne.om.OMField > Method : OMsetData > Error : no data > Raised in : 31004 1 unknown host 20014 1 unknown addr > > Method : OMaddData > Error : create error > Please contact Omnesys Technologies Inc., at www.omnesys.com. > > On Mon, Sep 12, 2022 at 8:51 AM Jin-oh Kang <jinoh.kang.kr(a)gmail.com> > wrote: > >> On Mon, Sep 12, 2022, 9:46 AM Zebediah Figura <zfigura(a)codeweavers.com> >> wrote: >> >>> On 9/11/22 19:38, Jin-oh Kang wrote: >>> >> and secondly because it's actually quite hard if not >>> >> impossible to implement (POSIX has no way to wait for a mandatory >>> lock, >>> >> for instance). >>> >> >>> > >>> > We don't use POSIX locks to implement file locks; they are emulated >>> > entirely in the server, which I guess is specifically designed to avoid >>> > that problem with POSIX file lock semantics. Thus, this won't be *that* >>> > hard to implement; nonetheless, asynchronous I/O is not really easy to >>> > implement in general, especially for those new to wine codebase. >>> >>> I don't see where you're getting that; we do indeed use POSIX locks. See >>> set_unix_lock() in server/fd.c. >> >> >> I stand corrected. >> >> There's no poll() for file locks, so it would have to busy-wait anyway. >> >> I did incorrectly use the term >>> "mandatory", though; we don't set mandatory locks on a file. >>> >>

1 0

fixing some fixme code
by Owen Hogarth 12 Sep '22

12 Sep '22

Hello, I tried to run an application and saw that there are a few unimplemented features, such as: 00d0:fixme:file:NtLockFile I/O completion on lock not implemented yet I was reading the developers guide and wanted to say hello to the mailing list.

3 4

Wine staging 7.17 release
by Alistair Leslie-Hughes 10 Sep '22

10 Sep '22

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 7.17 (529 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * ntdll: Add support for FileFsFullSizeInformation class in NtQueryVolumeInformationFile(try 2) Added: * None Updated: * None 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

Ubuntu 20.04 vs 32bit wine [-staging] - more detailed documentation?
by Sebastian M. Ernst 09 Sep '22

09 Sep '22

Hi all, just burned *a lot* of time making Wine (Staging) for 64 and **32 bit** work on Ubuntu 20.04 (Ubuntu 22.04 was a little less painful) as part of a Github action of mine. The official documentation that is very commonly referred / pointed to ("if it does not work, you did not follow the instructions there to the letter") ... https://wiki.winehq.org/Ubuntu ... misses a few, apparently constantly shifting details on the 32 bit side of things. The "authoritative resource" on this topic appears to be this lovely long Github issue ... https://github.com/actions/runner-images/issues/4589 ... which thankfully also provides up-to-date workarounds (with rather significant side-effects), like the following as of July 26: ```bash sudo rm -f /etc/apt/sources.list.d/microsoft-prod.list sudo apt-get update -qq sudo apt-get install -yqq --allow-downgrades libgd3/focal libpcre2-8-0/focal libpcre2-16-0/focal libpcre2-32-0/focal libpcre2-posix2/focal sudo apt-get purge -yqq libmono* moby* mono* php* libgdiplus libpcre2-posix3 libzip4 ``` See, in the following order: - https://github.com/actions/runner-images/issues/4589#issuecomment-980506595 - https://github.com/actions/runner-images/issues/4589#issuecomment-1100899313 - https://github.com/actions/runner-images/issues/4589#issuecomment-1123074635 - https://github.com/actions/runner-images/issues/4589#issuecomment-1194891446 I am not sure if (or how) this belongs into your wiki (of if it can even be fixed / worked around partially within the dependencies of the packages from WineHQ's PPA). But since the above mentioned Github issue is not easy to find between a lot of other related but less helpful "noise" in online search results (and takes a while to comprehend), it might warrant creating a central, well known place that documents this behaviour in an up-to-date manner. Either way, in all honesty, thx to everybody who keeps 32 bit support running. For better or for worse, it is still badly needed. Best regards, Sebastian

3 2

Jump to page:

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