March 2023 - Wine-Devel - list.winehq.org

Re: Wine configurations naming

by Zebediah Figura

On 3/31/23 12:47, Gabriel Ivăncescu wrote: > On 31/03/2023 19:59, Zeb Figura wrote: >> On 3/31/23 11:46, Eric Pouech wrote: >>> So this mail to share the question, and a proposal >>> >>> - *wow64*: the new multi-arch wow64 configuration, which mimics >>> windows wow64 architecture ; dropping the 'new' to match with windows >>> (and also, not sure that in 10years from now it will still be "new") >> >> I don't see what is gained by being *less* specific, especially when >> we've been referring to this as unqualified "wow64" for years. I fully >> intend to keep calling this "new", and I'd exhort anyone else to as well. >> >> > > Isn't the "old wow64" still going to be used if the host supplies the > necessary 32-bit libraries? To avoid rather expensive syscalls and mode > switches (only "unix calls"). I recall something along those lines. I would have thought so, but apparently we've started making some features exclusive to new-style wow64. (Note that syscalls happen either way, but mode switches are definitely going to be expensive.)

March 31, 2023

Re: Wine configurations naming

by Gabriel Ivăncescu

On 31/03/2023 19:59, Zeb Figura wrote: > On 3/31/23 11:46, Eric Pouech wrote: >> So this mail to share the question, and a proposal >> >> - *wow64*: the new multi-arch wow64 configuration, which mimics >> windows wow64 architecture ; dropping the 'new' to match with windows >> (and also, not sure that in 10years from now it will still be "new") > > I don't see what is gained by being *less* specific, especially when > we've been referring to this as unqualified "wow64" for years. I fully > intend to keep calling this "new", and I'd exhort anyone else to as well. > > Isn't the "old wow64" still going to be used if the host supplies the necessary 32-bit libraries? To avoid rather expensive syscalls and mode switches (only "unix calls"). I recall something along those lines. In that case I would suggest something like "host wow64" or "multi-arch wow64" for the old wow64. "host32" suggested by Esme is probably fine but I feel like it still needs wow64 in the name?

March 31, 2023

Re: Wine configurations naming

by Esme Povirk

Sillier idea for the new configuration: wou64 (windows on unix 64)

March 31, 2023

Re: Wine configurations naming

by Zeb Figura

On 3/31/23 11:46, Eric Pouech wrote: > So this mail to share the question, and a proposal > > - *wow64*: the new multi-arch wow64 configuration, which mimics windows > wow64 architecture ; dropping the 'new' to match with windows (and also, > not sure that in 10years from now it will still be "new") I don't see what is gained by being *less* specific, especially when we've been referring to this as unqualified "wow64" for years. I fully intend to keep calling this "new", and I'd exhort anyone else to as well.

March 31, 2023

Re: Wine configurations naming

by Esme Povirk

I suggest "host32" for the old configuration, since it uses the 32-bit support of the host OS.

March 31, 2023

Wine configurations naming

by Eric Pouech

Hi, it seems we should gain some clarification for the naming of the various ways Wine can be configured. This question arises between "old wow64" and "new wow64" esp. some use wow64 without it being very clear to what it applies (some using wine's old wow64 configuration as it was the only one, others refer to window's wow64 architecture, hence "new wow64" in wine lingo) some have used multi-arch wow(64) or multi arch wine for reference to the new wine wow64... it seems to me we'd better use a common denomination for all of this... - only applying to cross compilation (open point if we still need to refer to ELF/dylib exec:s) - different from images naming (for which the <CPU>-<HOST> applies) So this mail to share the question, and a proposal - *wow64*: the new multi-arch wow64 configuration, which mimics windows wow64 architecture ; dropping the 'new' to match with windows (and also, not sure that in 10years from now it will still be "new") - (wine)*old wow64*: the wine-only old wow64 configuration if needed (at least to remind that they exist) - *pure32*: the 32bit only configuration - *pure64*: the 64bit only configuration Note: the proposal doesn't include whether the configuration can run a module for a given CPU. That's questionable. For comments, rant, other proposals... better ideas TIA

March 31, 2023

Re: Should we stop linking to FAudio for our XAudio implementation?

by Zebediah Figura

On 3/29/23 15:33, Esme Povirk wrote: > OK, maybe it's more complicated than I thought. Here's my best guess from > what I know: > > In the case of Tivoization, the GPL code isn't linked with any proprietary > code. The user can still build the program as a whole, but is unable to > sign it so that the device will execute it. > > In this case, LGPL code is linked with proprietary code: both the game > itself and the vendor's libraries. In this situation, section 6 requires a > way for the user to relink the rest of the code to their modified version > of the library: either source code, object code, or a dynamically linked > binary. A game developer could theoretically distribute their game's source > code or object code without the assets, but they cannot redistribute the > tools and libraries from the platform vendor to the general public. Oh, interesting, so I guess LGPL 2 effectively also prevents tivoization. Actually, now that you've explained it, I vaguely remember that being discussed last Wineconf (either as part of Bradley Kuhn's talk or a more informal conversation).

March 29, 2023

Re: Should we stop linking to FAudio for our XAudio implementation?

by Esme Povirk

OK, maybe it's more complicated than I thought. Here's my best guess from what I know: In the case of Tivoization, the GPL code isn't linked with any proprietary code. The user can still build the program as a whole, but is unable to sign it so that the device will execute it. In this case, LGPL code is linked with proprietary code: both the game itself and the vendor's libraries. In this situation, section 6 requires a way for the user to relink the rest of the code to their modified version of the library: either source code, object code, or a dynamically linked binary. A game developer could theoretically distribute their game's source code or object code without the assets, but they cannot redistribute the tools and libraries from the platform vendor to the general public. On Wed, Mar 29, 2023 at 1:28 PM Zebediah Figura <zfigura(a)codeweavers.com> wrote: > On 3/29/23 12:00, Esme Povirk wrote: > >> Unfortunately FAudio cannot, counterintuitively, link to LGPL code, > >> because it needs to be able to run on embedded platforms, which (for > >> reasons I do not understand) cannot ship any LGPL code. > > > > It's quite simple. If a platform (such as Nintendo Switch) does not allow > > users to sideload their own code on it, it's not possible to comply with > > the terms of the LGPL while shipping LGPL code on that platform, because > > the user cannot install their own modified version of the LGPL library. > > > > Isn't that what tivoization is, or do I misunderstand? And if so, I > would assume that only restricts (L)GPL v3, whereas LGPL v2 would still > be fine. >

March 29, 2023

Re: Should we stop linking to FAudio for our XAudio implementation?

by Zebediah Figura

On 3/29/23 01:51, Rémi Bernon wrote: > On 3/29/23 02:31, Zebediah Figura wrote: >> Hi all, >> >> This may seem something of a controversial question, but I am >> concerned that FAudio is not a good fit for Wine, mainly because of >> its licensing considerations. >> >> Recently I found a bug in FAudio wherein it does not properly handle >> unaligned buffers. While in the process of drafting a fix, I was >> stymied multiple times by its rather broken resampler, and when I >> sought to try to fix that, I found that it was a rather difficult >> endeavour, which led me to propose replacing it with an external >> library such as GStreamer. Unfortunately FAudio cannot, >> counterintuitively, link to LGPL code, because it needs to be able to >> run on embedded platforms, which (for reasons I do not understand) >> cannot ship any LGPL code. >> >> While I can to some degree respect the decision of FAudio to target >> platforms that forbid copyleft licensing, I do not think this aligns >> well with the interests of the Wine project—a project which >> specifically chose copyleft licensing. More personally, I do not want >> to have to fix the FAudio resampler or implement another resampler >> with a non-copyleft license (and I am not even particularly sure that >> I can, given my familiarity with resamplers in LGPL projects such as >> GStreamer and Wine). >> >> Besides this, it is probably worth noting that we do not seem to gain >> much from continuing to rely on FAudio. There would be the usual >> benefit of relying on upstream development, but development on FAudio >> seems very scarce, especially when restricted to parts relevant to >> Wine, and much of that is from Wine contributors anyway. (And, of >> course, due to our bundling practices, there is hardly the usual >> benefit of size or modularity in linking to external libraries.) >> >> Of course we would be well served by simply importing the current >> version of FAudio; I do not mean to propose that we reimplement XAudio >> entirely, but rather begin to modify it in ways that would not be >> acceptable upstream. >> >> This would mean replacing the resampler, as well as perhaps also the >> mixer, and probably with the ones from GStreamer, which is already a >> dependency of ours, and which has a very featureful resampler and >> mixer, and a much higher rate of development overall. >> >> Do others in the Wine community have thoughts or opinions on this matter? >> >> ἔρρωσθε, >> Zeb >> > > Fwiw FAudio has linked with GStreamer in the past, conditionally at least. > That came up in the discussion, I think (sorry, I should have thought to mention it.) The problem I see is that while FAudio can *optionally* link to GStreamer, that still means the old backend will need to be kept around. In the case of the bug I'm trying to fix, I don't think it's particularly possible to do that without fixing the old resampler as well.

March 29, 2023

Re: Should we stop linking to FAudio for our XAudio implementation?

by Zebediah Figura

On 3/29/23 12:00, Esme Povirk wrote: >> Unfortunately FAudio cannot, counterintuitively, link to LGPL code, >> because it needs to be able to run on embedded platforms, which (for >> reasons I do not understand) cannot ship any LGPL code. > > It's quite simple. If a platform (such as Nintendo Switch) does not allow > users to sideload their own code on it, it's not possible to comply with > the terms of the LGPL while shipping LGPL code on that platform, because > the user cannot install their own modified version of the LGPL library. > Isn't that what tivoization is, or do I misunderstand? And if so, I would assume that only restricts (L)GPL v3, whereas LGPL v2 would still be fine.

March 29, 2023