June 2012 - Wine-Devel - list.winehq.org

Wine's support for reporting calling conventions

by Roger Cruz

In dlls/dbghelp/dwarf.c, there is this snippet of code which appears to hard-code the calling convention to CALL_FAR_C. Does Wine not support reporting a function's calling convention correctly then? Is it a limitation of DWARF or just that it is not implemented? I can see that DWARF has a DW_AT_calling_convention field but when I examine a Wine DLL with objdump, it does not show this field in use. /* FIXME: assuming C source code */ sig_type = symt_new_function_signature(ctx->module, ret_type, CV_CALL_FAR_C); Thanks Roger

June 6, 2012

Re: [1/5] msi: Add support for 64-bit registry components.

by Jacek Caban

On 6/5/12 8:48 PM, Hans Leidekker wrote: > On Tue, 2012-06-05 at 20:35 +0200, Alexandre Julliard wrote: >> Hans Leidekker<hans(a)codeweavers.com> writes: >> >>> --- >>> dlls/msi/action.c | 30 +++++++--- >>> dlls/msi/msi_main.c | 1 + >>> dlls/msi/msipriv.h | 1 + >>> dlls/msi/package.c | 2 - >>> dlls/msi/tests/install.c | 140 ++++++++++++++++++++++++++++++++++++++++++++++ >>> 5 files changed, 162 insertions(+), 12 deletions(-) >> This breaks the Gecko installer on 64-bit for me. > That's a bug in the installer, its registry component should be marked > as a 64-bit component. Sounds like perfect timing to me :) Firefox 13 was released today and I plan to do the next Gecko update based on it in the next few days. We may fix Gecko installer, which will allow the patch to be committed. Cheers, Jacek

June 5, 2012

Re: [1/5] msi: Add support for 64-bit registry components.

by Hans Leidekker

On Tue, 2012-06-05 at 20:35 +0200, Alexandre Julliard wrote: > Hans Leidekker <hans(a)codeweavers.com> writes: > > > --- > > dlls/msi/action.c | 30 +++++++--- > > dlls/msi/msi_main.c | 1 + > > dlls/msi/msipriv.h | 1 + > > dlls/msi/package.c | 2 - > > dlls/msi/tests/install.c | 140 ++++++++++++++++++++++++++++++++++++++++++++++ > > 5 files changed, 162 insertions(+), 12 deletions(-) > > This breaks the Gecko installer on 64-bit for me. That's a bug in the installer, its registry component should be marked as a 64-bit component.

June 5, 2012

Re: [1/5] msi: Add support for 64-bit registry components.

by Alexandre Julliard

Hans Leidekker <hans(a)codeweavers.com> writes: > --- > dlls/msi/action.c | 30 +++++++--- > dlls/msi/msi_main.c | 1 + > dlls/msi/msipriv.h | 1 + > dlls/msi/package.c | 2 - > dlls/msi/tests/install.c | 140 ++++++++++++++++++++++++++++++++++++++++++++++ > 5 files changed, 162 insertions(+), 12 deletions(-) This breaks the Gecko installer on 64-bit for me. -- Alexandre Julliard julliard(a)winehq.org

June 5, 2012

Re: [1/2] user32: Add a test to demonstrate the z-order problem for a top level window with a region.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > --- > dlls/user32/tests/win.c | 56 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 56 insertions(+) It doesn't work here: ../../../../wine/tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so ../../../../wine/dlls/user32/tests/win.c && touch win.ok win.c:7111: Test succeeded inside todo block: expected next window 0x400ea, got 0x400ea win.c:7114: Test succeeded inside todo block: expected previous window 0x400f0, got 0x400f0 make[1]: *** [win.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

June 5, 2012

Re: http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh also installs mono

by James Eder

>> >> You obviously have absolutely no idea what the wine-mono package is for. >> You should read up and apologize. >> >> > NO APOLOGY! You are missing the point. > You are missing the point. You're argument lacks weight because you clearly have no idea what you're talking about. One cannot base a reasonable argument on top of displays of ignorance and irrationality. You can try but in the end you only look like an ass. I understand that you're very passionate about the subject but understand that such displays harm your cause more than help it. You were wrong on several technical details which you based several key points of your argument on. A reasonable thing to do would be to offer an apology while moving on to other points you feel more sure about. Instead you respond with more rudeness. At this point I don't think you can recover well enough to have a meaningful discussion. You should make a strategic withdrawal, do some research, and reform your argument. -- Jim

June 5, 2012

Re: [2/2] server: Make sure that region and rectangle have the same origin before calling rect_in_region().

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -2457,7 +2457,9 @@ DECL_HANDLER(update_window_zorder) > if (!(ptr->style & WS_VISIBLE)) continue; > if (ptr->ex_style & WS_EX_TRANSPARENT) continue; > if (!intersect_rect( &tmp, &ptr->visible_rect, &rect )) continue; > - if (ptr->win_region && !rect_in_region( ptr->win_region, &rect )) continue; > + tmp = rect; > + offset_rect( &tmp, -ptr->client_rect.left, -ptr->client_rect.top ); > + if (ptr->win_region && !rect_in_region( ptr->win_region, &tmp )) continue; The window region is not in client coordinates. -- Alexandre Julliard julliard(a)winehq.org

June 5, 2012

Re: http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh also installs mono

by Vincent Povirk

> If it is NOT a linux native interface, it is NOT an analog of 'mono'. Mono is available on many platforms, including Windows. What we have is a fork/package of Mono that is built for Windows and only used by Wine's internals. If Mono is "contaminated" then our package is just as much so. On Windows, mscoree.dll is the interface that programs use to access the .NET runtime. However, the .NET runtimes are separate; mscoree is only the interface to them. We have an implementation of mscoree.dll in Wine, and our implementation uses Mono (which is in the wine-mono package) as its .NET runtime. The interface that mscoree uses to access Mono is the Mono embedding API. While the package also contains some other things that are specific to .NET, the core of it is Mono.

June 5, 2012

Re: http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh also installs mono

by Max TenEyck Woodbury

On 06/05/2012 03:00 AM, Francois Gouget wrote: > On Mon, 4 Jun 2012, Max TenEyck Woodbury wrote: > [...] >> A native MSWindows application that wants .net support would either >> connect to the installed dll that provides the required services or >> install such a dll. It would know nothing about 'mono'. It is only >> non-MSWindows platform programs that will try to link to the >> non-MSWinows libraries in 'mono'. >> >> So an MSWindows executable looking for .net support needs .net support, >> NOT mono. > [...] > > You obviously have absolutely no idea what the wine-mono package is for. > You should read up and apologize. > > NO APOLOGY! You are missing the point. If it is NOT a linux native interface, it is NOT an analog of 'mono'. Call it what it is: DotNetFramework or something like that. Just do NOT make the mistake of tying it to the contaminated package, even if it is only by using a similar name. This is because legal risks are fairly high here, and APPEARANCE does account for a lot in that domain. While the odds are somewhat in favor of any legal action coming out correctly if the tech is right, it IS a crap shoot and the lawyer's are the only sure winners.

June 5, 2012

Re: [PATCH 1/5] wined3d: Use NAN.

by Ruslan Kabatsayev

Oh, right, seems it wasn't there at the point when another patch broke the build, and I was bisecting it. Sorry for the noise. On Tue, Jun 5, 2012 at 1:53 PM, Francois Gouget <fgouget(a)free.fr> wrote: > On Mon, 4 Jun 2012, Ruslan Kabatsayev wrote: > >> Hello, >> >> This patch stops wine from building on my system with following errors: >> >> In file included from arb_program_shader.c:35:0: >> wined3d_private.h: In function ‘float_16_to_32’: >> wined3d_private.h:203:21: error: ‘NAN’ undeclared (first use in this function) >> wined3d_private.h:203:21: note: each undeclared identifier is reported >> only once for each function it appears in > > I sent a patch that should fix this. Did I miss some bit? > > commit 19ba80e7c2c9ef054ef5faa921616a5d43f6578d > Author: Francois Gouget <fgouget(a)free.fr> > Date: Fri Jun 1 16:56:21 2012 +0200 > > wined3d: We must include Wine's port.h before using NAN. > > > -- > Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ > Linux: Because rebooting is for adding new hardware

June 5, 2012