September 2025 - Wine-Devel

Re: ALSA MIDI is not working under NixOS

by Alexandre Julliard

Elizabeth Figura <zfigura(a)codeweavers.com> writes: > On Monday, 22 September 2025 13:31:49 CDT Paul Gofman wrote: >> On 9/22/25 12:14, Elizabeth Figura wrote: >> > On the other hand, I am reminded of an unrelated bug, involving a >> > program (I don't have the name unfortunately) which copies >> > ws2_32.dll to a temp file with a randomly generated name and >> > attempts to load the copy. This fails on Wine because ws2_32 has a >> > unixlib, and we derive the name of the unixlib from the path of >> > the DLL. In order to fix this bug we would probably need to embed >> > the name of the unixlib in the DLL itself rather than relying on >> > its path. If we did that the DLLs for winepulse and winealsa would >> > no longer be identical. >> > >> That doesn't look quite related to the discussed issue? This part is >> about how we find Unix library. > > The point is that if we were to do this, winepulse and winealsa would > no longer have the exact same contents, which would sidestep this > problem. For this specific case, the plan is to get rid of these empty PE files and make it possible for mmdevapi to load the appropriate Unix backend directly. Presumably the same mechanism could then be used to handle the ws2_32 case. Of course that doesn't change the fact that hardlinking files behind our back is not a good idea on NixOS's part. -- Alexandre Julliard julliard(a)winehq.org

Sept. 24, 2025

Re: ALSA MIDI is not working under NixOS

by Paul Gofman

On 9/22/25 19:20, Yuxuan Shui wrote: > Hi, > > On Mon, Sep 22, 2025 at 7:49 PM Marc-Aurel Zent<mzent(a)codeweavers.com> wrote: >> >> >>> On 22. Sep 2025, at 20:39, Paul Gofman<pgofman(a)codeweavers.com> wrote: >>> >>> On 9/22/25 12:37, Marc-Aurel Zent wrote: >>>>> On 22. Sep 2025, at 20:31, Paul Gofman<pgofman(a)codeweavers.com> wrote: >>>>> >>>>> On 9/22/25 12:14, Elizabeth Figura wrote: >>>>>> On the other hand, I am reminded of an unrelated bug, involving a program (I don't have the name unfortunately) which copies ws2_32.dll to a temp file with a randomly generated name and attempts to load the copy. This fails on Wine because ws2_32 has a unixlib, and we derive the name of the unixlib from the path of the DLL. In order to fix this bug we would probably need to embed the name of the unixlib in the DLL itself rather than relying on its path. If we did that the DLLs for winepulse and winealsa would no longer be identical. >>>>>> >>>>> That doesn't look quite related to the discussed issue? This part is about how we find Unix library. I didn't check exactly this case lately but doesn't Wine search for Unix libraries in the configured or determined on start Wine paths now? I'd guess it might just work? >>>>> >>>>> >>>>> For the original issue, having the same inodes for different files looks clearly like a bug in NixOS to me. First, yes, if there are two differently named files they are different files even if the contents happens to be the same. For one, the contents is identical right now but may change, and if those are differently named files the contents is not synchronous between those. Then, inode is supposed to be unique within the same file system:https://man7.org/linux/man-pages/man7/inode.7.html, "Inode number": "Each file in a filesystem has a unique inode number.". >>>>> >>>>> >>>> I think they can mostly get away with this because the nix store is by design read-only (and there are in practice many duplicates there). Though I agree that such a form of deduplication should happen on the filesystem layer ideally. >>> But also I don't quite understand from the description why that happens to winepulse.drv and winealsa.drv, these files are not indentical and have different contents?? >>> >>> >> For me at least winepulse.drv and winealsa.drv are in content exactly identical. If nix were to deduplicate only cross-derivation this would not happen I think. >> > Yes, this will be a solution indeed. I think I saw people mentioning > this on the nix issue tracker. This is not a solution, this is a workaround for a particular case of the problem. The similar issue may happen with app's dll loaded from different directories, or other (more special) cases not related to loading dlls. FWIW Wine behaviour checking underlying file identity is not random. For instance, LdrGetModuleHandle called with full DLL path will distinguish dll which was renamed (while loaded) and replaced by different file, we have a test for that (and that's one example where correct file identification is needed). The problem is not Wine specific, identifying files by inode within FS is what other Unix apps can rightfully do, making deduplication look like a hard link (made on behalf of the app) which then gets "unlinked" when either file is modified is severe change of Unix inode semantics and IMO should be fixed.

Sept. 23, 2025

Re: ALSA MIDI is not working under NixOS

by Yuxuan Shui

Hi, On Mon, Sep 22, 2025 at 7:49 PM Marc-Aurel Zent <mzent(a)codeweavers.com> wrote: > > > > > On 22. Sep 2025, at 20:39, Paul Gofman <pgofman(a)codeweavers.com> wrote: > > > > On 9/22/25 12:37, Marc-Aurel Zent wrote: > >>> On 22. Sep 2025, at 20:31, Paul Gofman <pgofman(a)codeweavers.com> wrote: > >>> > >>> On 9/22/25 12:14, Elizabeth Figura wrote: > >>>> On the other hand, I am reminded of an unrelated bug, involving a program (I don't have the name unfortunately) which copies ws2_32.dll to a temp file with a randomly generated name and attempts to load the copy. This fails on Wine because ws2_32 has a unixlib, and we derive the name of the unixlib from the path of the DLL. In order to fix this bug we would probably need to embed the name of the unixlib in the DLL itself rather than relying on its path. If we did that the DLLs for winepulse and winealsa would no longer be identical. > >>>> > >>> That doesn't look quite related to the discussed issue? This part is about how we find Unix library. I didn't check exactly this case lately but doesn't Wine search for Unix libraries in the configured or determined on start Wine paths now? I'd guess it might just work? > >>> > >>> > >>> For the original issue, having the same inodes for different files looks clearly like a bug in NixOS to me. First, yes, if there are two differently named files they are different files even if the contents happens to be the same. For one, the contents is identical right now but may change, and if those are differently named files the contents is not synchronous between those. Then, inode is supposed to be unique within the same file system: https://man7.org/linux/man-pages/man7/inode.7.html, "Inode number": "Each file in a filesystem has a unique inode number.". > >>> > >>> > >> I think they can mostly get away with this because the nix store is by design read-only (and there are in practice many duplicates there). Though I agree that such a form of deduplication should happen on the filesystem layer ideally. > > > > But also I don't quite understand from the description why that happens to winepulse.drv and winealsa.drv, these files are not indentical and have different contents?? > > > > > > For me at least winepulse.drv and winealsa.drv are in content exactly identical. If nix were to deduplicate only cross-derivation this would not happen I think. > Yes, this will be a solution indeed. I think I saw people mentioning this on the nix issue tracker. BTW the nixpkgs issue discussion is here: https://github.com/NixOS/nixpkgs/issues/444543 > -- Regards Yuxuan Shui

Sept. 23, 2025

Re: ALSA MIDI is not working under NixOS

by DodoGTA GT

> For me at least winepulse.drv and winealsa.drv are in content exactly identical. Maybe this could be a side-effect of reproducible builds? Here the hashes aren't identical for those two libraries

Sept. 22, 2025

Re: ALSA MIDI is not working under NixOS

by Marc-Aurel Zent

> On 22. Sep 2025, at 20:39, Paul Gofman <pgofman(a)codeweavers.com> wrote: > > On 9/22/25 12:37, Marc-Aurel Zent wrote: >>> On 22. Sep 2025, at 20:31, Paul Gofman <pgofman(a)codeweavers.com> wrote: >>> >>> On 9/22/25 12:14, Elizabeth Figura wrote: >>>> On the other hand, I am reminded of an unrelated bug, involving a program (I don't have the name unfortunately) which copies ws2_32.dll to a temp file with a randomly generated name and attempts to load the copy. This fails on Wine because ws2_32 has a unixlib, and we derive the name of the unixlib from the path of the DLL. In order to fix this bug we would probably need to embed the name of the unixlib in the DLL itself rather than relying on its path. If we did that the DLLs for winepulse and winealsa would no longer be identical. >>>> >>> That doesn't look quite related to the discussed issue? This part is about how we find Unix library. I didn't check exactly this case lately but doesn't Wine search for Unix libraries in the configured or determined on start Wine paths now? I'd guess it might just work? >>> >>> >>> For the original issue, having the same inodes for different files looks clearly like a bug in NixOS to me. First, yes, if there are two differently named files they are different files even if the contents happens to be the same. For one, the contents is identical right now but may change, and if those are differently named files the contents is not synchronous between those. Then, inode is supposed to be unique within the same file system: https://man7.org/linux/man-pages/man7/inode.7.html, "Inode number": "Each file in a filesystem has a unique inode number.". >>> >>> >> I think they can mostly get away with this because the nix store is by design read-only (and there are in practice many duplicates there). Though I agree that such a form of deduplication should happen on the filesystem layer ideally. > > But also I don't quite understand from the description why that happens to winepulse.drv and winealsa.drv, these files are not indentical and have different contents?? > > For me at least winepulse.drv and winealsa.drv are in content exactly identical. If nix were to deduplicate only cross-derivation this would not happen I think.

Sept. 22, 2025

Re: ALSA MIDI is not working under NixOS

by Paul Gofman

On 9/22/25 12:43, Elizabeth Figura wrote: > On Monday, 22 September 2025 13:31:49 CDT Paul Gofman wrote: >> On 9/22/25 12:14, Elizabeth Figura wrote: >>> On the other hand, I am reminded of an unrelated bug, involving a program (I don't have the name unfortunately) which copies ws2_32.dll to a temp file with a randomly generated name and attempts to load the copy. This fails on Wine because ws2_32 has a unixlib, and we derive the name of the unixlib from the path of the DLL. In order to fix this bug we would probably need to embed the name of the unixlib in the DLL itself rather than relying on its path. If we did that the DLLs for winepulse and winealsa would no longer be identical. >>> >> That doesn't look quite related to the discussed issue? This part is >> about how we find Unix library. > The point is that if we were to do this, winepulse and winealsa would no longer have the exact same contents, which would sidestep this problem. I see now why are those are the same, the PE part may be identical indeed. But it is only a particular case, the bug will stay in general, there will be other cases when things are broken due to that (while probably not reproducible across majority of apps under Wine). > >> I didn't check exactly this case lately >> but doesn't Wine search for Unix libraries in the configured or >> determined on start Wine paths now? I'd guess it might just work? > The problem isn't the path, it's the base name. ws2_32.dll gets renamed to "tmp1234.dll" or something, and we look for (and fail to find) "tmp1234.so". Ah, it is renamed...

Sept. 22, 2025

Re: ALSA MIDI is not working under NixOS

by Elizabeth Figura

On Monday, 22 September 2025 13:31:49 CDT Paul Gofman wrote: > On 9/22/25 12:14, Elizabeth Figura wrote: > > On the other hand, I am reminded of an unrelated bug, involving a program (I don't have the name unfortunately) which copies ws2_32.dll to a temp file with a randomly generated name and attempts to load the copy. This fails on Wine because ws2_32 has a unixlib, and we derive the name of the unixlib from the path of the DLL. In order to fix this bug we would probably need to embed the name of the unixlib in the DLL itself rather than relying on its path. If we did that the DLLs for winepulse and winealsa would no longer be identical. > > > That doesn't look quite related to the discussed issue? This part is > about how we find Unix library. The point is that if we were to do this, winepulse and winealsa would no longer have the exact same contents, which would sidestep this problem. > I didn't check exactly this case lately > but doesn't Wine search for Unix libraries in the configured or > determined on start Wine paths now? I'd guess it might just work? The problem isn't the path, it's the base name. ws2_32.dll gets renamed to "tmp1234.dll" or something, and we look for (and fail to find) "tmp1234.so".

Sept. 22, 2025

Re: ALSA MIDI is not working under NixOS

by Paul Gofman

On 9/22/25 12:39, Paul Gofman wrote: > On 9/22/25 12:37, Marc-Aurel Zent wrote: >>> On 22. Sep 2025, at 20:31, Paul Gofman <pgofman(a)codeweavers.com> wrote: >>> >>> On 9/22/25 12:14, Elizabeth Figura wrote: >>>> On the other hand, I am reminded of an unrelated bug, involving a >>>> program (I don't have the name unfortunately) which copies >>>> ws2_32.dll to a temp file with a randomly generated name and >>>> attempts to load the copy. This fails on Wine because ws2_32 has a >>>> unixlib, and we derive the name of the unixlib from the path of the >>>> DLL. In order to fix this bug we would probably need to embed the >>>> name of the unixlib in the DLL itself rather than relying on its >>>> path. If we did that the DLLs for winepulse and winealsa would no >>>> longer be identical. >>>> >>> That doesn't look quite related to the discussed issue? This part is >>> about how we find Unix library. I didn't check exactly this case >>> lately but doesn't Wine search for Unix libraries in the configured >>> or determined on start Wine paths now? I'd guess it might just work? >>> >>> >>> For the original issue, having the same inodes for different files >>> looks clearly like a bug in NixOS to me. First, yes, if there are >>> two differently named files they are different files even if the >>> contents happens to be the same. For one, the contents is identical >>> right now but may change, and if those are differently named files >>> the contents is not synchronous between those. Then, inode is >>> supposed to be unique within the same file system: >>> https://man7.org/linux/man-pages/man7/inode.7.html, "Inode number": >>> "Each file in a filesystem has a unique inode number.". >>> >>> >> I think they can mostly get away with this because the nix store is >> by design read-only (and there are in practice many duplicates >> there). Though I agree that such a form of deduplication should >> happen on the filesystem layer ideally. > > But also I don't quite understand from the description why that > happens to winepulse.drv and winealsa.drv, these files are not > indentical and have different contents?? > In any case, different files can't have same inode number in the same FS outside of a bug. The same file may have different names hardlinked to the same file. Inode is exactly what identifies the file per se on Unix filesystems.

Sept. 22, 2025

Re: ALSA MIDI is not working under NixOS

by Paul Gofman

On 9/22/25 12:37, Marc-Aurel Zent wrote: >> On 22. Sep 2025, at 20:31, Paul Gofman <pgofman(a)codeweavers.com> wrote: >> >> On 9/22/25 12:14, Elizabeth Figura wrote: >>> On the other hand, I am reminded of an unrelated bug, involving a program (I don't have the name unfortunately) which copies ws2_32.dll to a temp file with a randomly generated name and attempts to load the copy. This fails on Wine because ws2_32 has a unixlib, and we derive the name of the unixlib from the path of the DLL. In order to fix this bug we would probably need to embed the name of the unixlib in the DLL itself rather than relying on its path. If we did that the DLLs for winepulse and winealsa would no longer be identical. >>> >> That doesn't look quite related to the discussed issue? This part is about how we find Unix library. I didn't check exactly this case lately but doesn't Wine search for Unix libraries in the configured or determined on start Wine paths now? I'd guess it might just work? >> >> >> For the original issue, having the same inodes for different files looks clearly like a bug in NixOS to me. First, yes, if there are two differently named files they are different files even if the contents happens to be the same. For one, the contents is identical right now but may change, and if those are differently named files the contents is not synchronous between those. Then, inode is supposed to be unique within the same file system: https://man7.org/linux/man-pages/man7/inode.7.html, "Inode number": "Each file in a filesystem has a unique inode number.". >> >> > I think they can mostly get away with this because the nix store is by design read-only (and there are in practice many duplicates there). Though I agree that such a form of deduplication should happen on the filesystem layer ideally. But also I don't quite understand from the description why that happens to winepulse.drv and winealsa.drv, these files are not indentical and have different contents??

Sept. 22, 2025

Re: ALSA MIDI is not working under NixOS

by Marc-Aurel Zent

> On 22. Sep 2025, at 20:31, Paul Gofman <pgofman(a)codeweavers.com> wrote: > > On 9/22/25 12:14, Elizabeth Figura wrote: >> On the other hand, I am reminded of an unrelated bug, involving a program (I don't have the name unfortunately) which copies ws2_32.dll to a temp file with a randomly generated name and attempts to load the copy. This fails on Wine because ws2_32 has a unixlib, and we derive the name of the unixlib from the path of the DLL. In order to fix this bug we would probably need to embed the name of the unixlib in the DLL itself rather than relying on its path. If we did that the DLLs for winepulse and winealsa would no longer be identical. >> > That doesn't look quite related to the discussed issue? This part is about how we find Unix library. I didn't check exactly this case lately but doesn't Wine search for Unix libraries in the configured or determined on start Wine paths now? I'd guess it might just work? > > > For the original issue, having the same inodes for different files looks clearly like a bug in NixOS to me. First, yes, if there are two differently named files they are different files even if the contents happens to be the same. For one, the contents is identical right now but may change, and if those are differently named files the contents is not synchronous between those. Then, inode is supposed to be unique within the same file system: https://man7.org/linux/man-pages/man7/inode.7.html, "Inode number": "Each file in a filesystem has a unique inode number.". > > I think they can mostly get away with this because the nix store is by design read-only (and there are in practice many duplicates there). Though I agree that such a form of deduplication should happen on the filesystem layer ideally.

Sept. 22, 2025