November 2022 - Wine-Devel - list.winehq.org

Re: Can we use Windows Kits idl files?

by James McDonnell

I didn't think those were taken/re-worked from those files directly. I thought they were reverse engineered from the MSDN docs and working with programs that implement those interfaces. But this clarifies that then. Thank you. On 11/29/22 11:28, Bernhard Kölbl wrote: > We are already actively using those files in Wine, just look at > /include in the tree. Though, not all of the ones from the Win Sdk may > work right now, so feel free to add the missing features to Widl. > > -- > Bernhard > > James McDonnell <topgamer7(a)gmail.com> schrieb am Di., 29. Nov. 2022, > 20:19: > > Are the Windows Kits SDK WinRT .idl files acceptable to read-rework > inside the wine source? They are akin to header files, no? > > I asked on the irc but didn't get any reply. > > There was a follow up comment asking about ReactOS headers as well: > > > on the topic of headers, are we allowed to look at ReactOS NDK > headerS > > s/headerS/headers/ > > they contain internal structure definitions only, nothing else > > Thank you, > > James > > >

Nov. 29, 2022

Re: Can we use Windows Kits idl files?

by Bernhard Kölbl

We are already actively using those files in Wine, just look at /include in the tree. Though, not all of the ones from the Win Sdk may work right now, so feel free to add the missing features to Widl. -- Bernhard James McDonnell <topgamer7(a)gmail.com> schrieb am Di., 29. Nov. 2022, 20:19: > Are the Windows Kits SDK WinRT .idl files acceptable to read-rework > inside the wine source? They are akin to header files, no? > > I asked on the irc but didn't get any reply. > > There was a follow up comment asking about ReactOS headers as well: > > > on the topic of headers, are we allowed to look at ReactOS NDK headerS > > s/headerS/headers/ > > they contain internal structure definitions only, nothing else > > Thank you, > > James > > > >

Nov. 29, 2022

Can we use Windows Kits idl files?

by James McDonnell

Are the Windows Kits SDK WinRT .idl files acceptable to read-rework inside the wine source? They are akin to header files, no? I asked on the irc but didn't get any reply. There was a follow up comment asking about ReactOS headers as well: > on the topic of headers, are we allowed to look at ReactOS NDK headerS > s/headerS/headers/ > they contain internal structure definitions only, nothing else Thank you, James

Nov. 29, 2022

Wine staging 7.22 release

by Alistair Leslie-Hughes

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 7.22 (474 patches are applied to wine vanilla) The number is quiet lower compared to the previous version due to the disabling of the nvidia dll patchesets. Upstreamed (Either directly from staging or fixed with a similar patch). * ntdll: Add support for FreeBSD style extended attributes. Added: * None Updated: * ntdll-DOS_Attributes 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.

Nov. 27, 2022

Re: Bug 52263 - Deadlock in dinput

by Fabian Maurer

Hello, I do think I have a solution, would you mind taking a look at https:// gitlab.winehq.org/wine/wine/-/merge_requests/1455 ? Regards, Fabian Maurer

Nov. 20, 2022

Re: Bug 52263 - Deadlock in dinput

by Rémi Bernon

On 11/20/22 02:28, Fabian Maurer wrote: > Hello, > > you committed a fix for Bug 52263, but I think that only masks the issue, not > really fixing it. > > Your fix is here: https://gitlab.winehq.org/wine/wine/-/commit/ > 7e5eeecdfb5c90042945d9e84a3a9f8b2ed0036a > > I described what happens in https://bugs.winehq.org/show_bug.cgi?id=52314#c4 > > I think we can only time out in this wait, so this doesn't seem right. Could > you please take a second look? > > Regards, > Fabian Maurer > > Yes this was more a workaround than a real fix, but with the wait (which times out), we're making more sure that the thread has returned from the dinput code and is itself waiting for the loader lock (and thus that we can safely unload the dinput module). It's not great, but a better fix would require much more changes, it wasn't accepted at the time, and I'm a bit anxious and touching it again as there's many places where the loader lock may be acquired implicitly. Maybe I can have another try before the freeze... Thanks for reminding me of it anyway. Cheers, -- Rémi Bernon <rbernon(a)codeweavers.com>

Nov. 20, 2022

Bug 52263 - Deadlock in dinput

by Fabian Maurer

Hello, you committed a fix for Bug 52263, but I think that only masks the issue, not really fixing it. Your fix is here: https://gitlab.winehq.org/wine/wine/-/commit/ 7e5eeecdfb5c90042945d9e84a3a9f8b2ed0036a I described what happens in https://bugs.winehq.org/show_bug.cgi?id=52314#c4 I think we can only time out in this wait, so this doesn't seem right. Could you please take a second look? Regards, Fabian Maurer

Nov. 20, 2022

Re: Cuda Applications on Wine - suggesting to merge wine-staging/patches/nvcuda-CUDA_Support patches into upstream wine.

by Erich E. Hoover

On Wed, Nov 16, 2022 at 11:55 AM Esme Povirk (any/all) <esme(a)codeweavers.com> wrote: > > On Wed, Nov 16, 2022 at 10:46 AM Erich E. Hoover <erich.e.hoover(a)gmail.com> wrote: >> >> * I do not believe that our current addons (wine-gecko/wine-mono) have >> a way to distribute files on the Unix side of the line, but I haven't >> looked at this in a while > > > This is correct, they only contain PE/Windows binaries. Distributing unix code in this way would be more complicated because it needs to be available for all platforms Wine supports, not just Linux. If you were to take this route it would require building for all these platforms and storing them with the information that allows you to download the correct one ( like Python does with "wheels" / https://stackoverflow.com/a/41645556/185828 ). > I don't think that addons are a good fit for wrapping native libraries. Yeah, I'm not really a fan either - the "autodetect the library at runtime" approach is much easier. Best, Erich

Nov. 16, 2022

Re: Cuda Applications on Wine - suggesting to merge wine-staging/patches/nvcuda-CUDA_Support patches into upstream wine.

by Esme Povirk (any/all)

On Wed, Nov 16, 2022 at 10:46 AM Erich E. Hoover <erich.e.hoover(a)gmail.com> wrote: > * I do not believe that our current addons (wine-gecko/wine-mono) have > a way to distribute files on the Unix side of the line, but I haven't > looked at this in a while > This is correct, they only contain PE/Windows binaries. Distributing unix code in this way would be more complicated because it needs to be available for all platforms Wine supports, not just Linux. I don't think that addons are a good fit for wrapping native libraries. -- https://my.pronouns.page/are/any

Nov. 16, 2022

Re: Cuda Applications on Wine - suggesting to merge wine-staging/patches/nvcuda-CUDA_Support patches into upstream wine.

by Erich E. Hoover

On Wed, Nov 16, 2022 at 7:41 AM Sveinar Søpler <cybermax(a)dexter.no> wrote: > > I tend to agree that since CUDA needs the linux version of libcuda that > only come with the nvidia driver, i am a bit unsure if it would be a > "default wine" thing. A regular windows user do not install (nv)CUDA.dll > libraries unless they use an NVIDIA adapter afaik. > ... We would either need: 1) to have it runtime detect the library (since distro builds could have the library where an end-user would not) or 2) we would need to build both the Unix and Windows library together and distribute them as an addon* > I have been working on improving CUDA support for wine here: > https://github.com/SveSop/nvcuda/tree/devel , but i am unable to crack > compatibility with CUDA SDK 11.6 and newer i am afraid. Best, Erich * I do not believe that our current addons (wine-gecko/wine-mono) have a way to distribute files on the Unix side of the line, but I haven't looked at this in a while

Nov. 16, 2022