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

Fwd: steam web browsing on OS X

by Theodore Dubois

Darn! Forgot to cc the list. Can someone explain exactly why absolute addresses are needed here? I'm new to wine, but eager to learn. ~Theodore On Nov 01, 2015, at 04:29 PM, Jacek Caban <jacek(a)codeweavers.com> wrote: Hi Sebastian, On 10/30/15 5:57 PM, Sebastian Lackner wrote: On 30.10.2015 17:42, Theodore Dubois wrote: Wine Staging includes some patches to fix Steam web browsing, but they are deactivated on Mac because they apparently require special build flags. Does anyone know what this refers to? ~Theodore The staged patchset adds thunk wrappers for ntdll functions, but to be compatible with Windows, they have to contain absolute addresses. This requires text relocations, which are not allowed by default on OSX. Since this issue was discovered shortly before the last release, disabling the patchset on OSX was easier than the necessary configure.ac changes, but I'm working on a solution. Unless we hit some impossible to solve problems Wine Staging 1.7.54 will make the Steam fix also available on OSX. ;) I took a look at this problem and the patchset and I think we should be able to avoid text relocation in this case. I should have a proof of concept patch soon. Thanks, Jacek

Nov. 2, 2015

Re: loader manpages get installed in wrong build step

by Sebastian Lackner

On 02.11.2015 02:33, Alexandre Julliard wrote: > Sebastian Lackner <sebastian(a)fds-team.de> writes: > >> Hiho, >> >> I've noticed another side effect introduced by >> http://source.winehq.org/git/wine.git/commit/da340169d6518cf42f1cbe169fbf12…, >> and I'm not sure if its intentional, or if its a bug. > > It's intentional, in the sense that the manpages should go along with > the corresponding binary. So the wine manpage is installed when the wine > binary is installed, which in a wow64 setup means on the 32-bit side > (arguably we should also have a wine64 manpage installed on the 64-bit > side). I agree, it probably makes more sense than the previous solution. Thanks for the clarification. > >> When both builds end in the same package (like on Archlinux) this doesn't matter, >> however there are plenty of distributions which ship the 32-bit and 64-bit >> parts in different packages. Having a few manpages in one and the rest in the >> other is at least a bit unusual, but could also lead to package conflicts. > > I'm not sure I understand why it would be a problem to have the 32-bit > package install manpages. What issues do you see? > Its not really a problem, but it requires changes in most distro packaging scripts. Best regards, Sebastian

Nov. 2, 2015

Re: loader manpages get installed in wrong build step

by Alexandre Julliard

Sebastian Lackner <sebastian(a)fds-team.de> writes: > Hiho, > > I've noticed another side effect introduced by > http://source.winehq.org/git/wine.git/commit/da340169d6518cf42f1cbe169fbf12…, > and I'm not sure if its intentional, or if its a bug. It's intentional, in the sense that the manpages should go along with the corresponding binary. So the wine manpage is installed when the wine binary is installed, which in a wow64 setup means on the 32-bit side (arguably we should also have a wine64 manpage installed on the 64-bit side). > When both builds end in the same package (like on Archlinux) this doesn't matter, > however there are plenty of distributions which ship the 32-bit and 64-bit > parts in different packages. Having a few manpages in one and the rest in the > other is at least a bit unusual, but could also lead to package conflicts. I'm not sure I understand why it would be a problem to have the 32-bit package install manpages. What issues do you see? -- Alexandre Julliard julliard(a)winehq.org

Nov. 2, 2015

Re: steam web browsing on OS X

by Jacek Caban

Hi Sebastian, On 10/30/15 5:57 PM, Sebastian Lackner wrote: > On 30.10.2015 17:42, Theodore Dubois wrote: >> Wine Staging includes some patches to fix Steam web browsing, but they are deactivated on Mac because they apparently require special build flags. Does anyone know what this refers to? >> >> ~Theodore >> > The staged patchset adds thunk wrappers for ntdll functions, but to be compatible with Windows, they have to contain absolute addresses. This requires text relocations, which are not allowed by default on OSX. Since this issue was discovered shortly before the last release, disabling the patchset on OSX was easier than the necessary configure.ac changes, but I'm working on a solution. Unless we hit some impossible to solve problems Wine Staging 1.7.54 will make the Steam fix also available on OSX. ;) I took a look at this problem and the patchset and I think we should be able to avoid text relocation in this case. I should have a proof of concept patch soon. Thanks, Jacek

Nov. 2, 2015

loader manpages get installed in wrong build step

by Sebastian Lackner

Hiho, I've noticed another side effect introduced by http://source.winehq.org/git/wine.git/commit/da340169d6518cf42f1cbe169fbf12…, and I'm not sure if its intentional, or if its a bug. For WOW64 builds all manpages were installed in the 64-bit build step before. After the commit, some manpages (those in loader/) also get installed in the 32-bit build step. Here are some logs for comparison: - before: http://repos.wine-staging.com/all/20151021-0141-arch-x64/build.log - after: http://repos.wine-staging.com/all/20151101-0726-arch-x64/build.log (search for "wine.1" for example) When both builds end in the same package (like on Archlinux) this doesn't matter, however there are plenty of distributions which ship the 32-bit and 64-bit parts in different packages. Having a few manpages in one and the rest in the other is at least a bit unusual, but could also lead to package conflicts. Should this be considered a bug, or is it up to package maintainers to workaround this issue? And what would be the preferred solution to fix this? I don't really want to reintroduce install-man-pages just after it was removed... Best regards, Sebastian

Nov. 1, 2015

Re: [4/4] dlls/ole32: Add more traces to the storage methods.

by Vincent Povirk

Whoops, accidentally dropped wine-devel from my reply. On Sun, Nov 1, 2015 at 6:49 AM, Vincent Povirk <madewokherd(a)gmail.com> wrote: > There's no test that calls these directly because they are internal methods. > I could have used any code to signal that the operation does not make sense > for this object. > > We should have tests that open and commit to a non-toplevel storage object, > which would call them. Sorry, that wasn't quite right. It's not enough to commit to a non-toplevel storage object. What you'd have to do is nest transacted storages and commit to the inner one.

Nov. 1, 2015

Re: [4/4] dlls/ole32: Add more traces to the storage methods.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > > Still printing a FIXME wouldn't hurt, right? Or maybe you have an > > application that calls it thousands of times flooding the console > > output? > > It would hurt. It would be misleading because there's nothing to fix. Is there a test for this? -- Dmitry.

Nov. 1, 2015

Re: [4/4] dlls/ole32: Add more traces to the storage methods.

by Vincent Povirk

> Still printing a FIXME wouldn't hurt, right? Or maybe you have an > application that calls it thousands of times flooding the console > output? It would hurt. It would be misleading because there's nothing to fix.

Nov. 1, 2015

Re: [4/4] dlls/ole32: Add more traces to the storage methods.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > > static HRESULT TransactedSnapshotImpl_GetTransactionSig(StorageBaseImpl *base, > > ULONG* result, BOOL refresh) > > { > > + FIXME("stub\n"); > > return E_NOTIMPL; > > } > > This is intentional. We don't need transaction signatures because > nothing else can have our snapshot open to commit to it. Anything > calling these methods should expect and handle E_NOTIMPL. Still printing a FIXME wouldn't hurt, right? Or maybe you have an application that calls it thousands of times flooding the console output? -- Dmitry.

Nov. 1, 2015

Re: [2/4] dlls/ole32: Zero out returned stats when IEnumSTATSTG::Next reaches end of enumeration.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > Are you sure we shouldn't be zeroing the entire remaining buffer? And > maybe we should put it after the loop, given there are multiple exits. I have the tests only for case of fetching one element at end of enum, that's why the patch fixes only this. If there is a theory that zeroing should be done for the remaining cells as well, that should be a separate change with new tests. -- Dmitry.

Nov. 1, 2015