February 2009 - Wine-devel - list.winehq.org

deb packages archive down?
by Tom Wickline 02 Feb '09

02 Feb '09

Hello, I have been trying to access the Wine deb archives for about six hours now and Ive been receiving a "connection to the server was reset" error. I'm not sure how long this has been the case but can the maintainer of the archive please look into this failure? http://wine.budgetdedicated.com/archive/index.html Cheers, Tom -- http://www.wine-reviews.net/ http://bordeauxgroup.com/

4 3

DIB Engine - Separated in small patches
by Massimo Del Fedele 02 Feb '09

02 Feb '09

As requested I separated the engine in small patches, trying to keep original authors when possible. As the post didn't appear here (problem with zipped files, maybe ?), I've put it on bug 421 page. I whish to know if it can be ok for including on wine tree. Ciao Max

3 2

wine.budgetdedicated.com down?
by Dan Kegel 02 Feb '09

02 Feb '09

I can't download debian wine packages from wine.budgetdedicated.com today...

4 4

Re: [2/2] mshtml: Add support for IHTMLStyle4 interface
by Jacek Caban 02 Feb '09

02 Feb '09

Alistair Leslie-Hughes wrote: > Hi, > > Changelog: > mshtml: Add support for IHTMLStyle4 interface > --- dlls/mshtml/Makefile.in | 1 + dlls/mshtml/htmlstyle.c | 4 ++ dlls/mshtml/htmlstyle.h | 3 + dlls/mshtml/htmlstyle4.c | 135 ++++++++++++++++++++++++++++++++++++++++++++++ dlls/mshtml/tests/dom.c | 7 +++ 5 files changed, 150 insertions(+), 0 deletions(-) create mode 100644 dlls/mshtml/htmlstyle4.c This interface has very few methods so it doesn't make sense to add new file for it. Jacek

1 0

Re: [1/2] mshtml: Add support for IHTMLStyle3 interface
by Jacek Caban 02 Feb '09

02 Feb '09

Alistair Leslie-Hughes wrote: > Hi, > > Changelog: > mshtml: Add support for IHTMLStyle3 interface > + + hres = IHTMLStyle_QueryInterface(style, &IID_IHTMLStyle3, (void**)&style3); + ok(hres == S_OK, "Could not get IHTMLStyle3 iface: %08x\n", hres); + if(SUCCEEDED(hres)) { + IHTMLStyle3_Release(style3); + } Please use style_iids to test QueryInterface calls. Jacek

1 0

Re: Anything wrong with this patch?
by Ben Klein 02 Feb '09

02 Feb '09

2009/1/24 Jérôme Gardou <jerome.gardou(a)gmail.com>: > Ben Klein a écrit : >> >> 2009/1/24 Jerome Leclanche <adys.wh(a)gmail.com>: >> >>> (Damnit, gmail interface) >>> Pipermail shows as empty, here. >>> >>> On Fri, Jan 23, 2009 at 10:05 PM, Jérôme Gardou <jerome.gardou(a)gmail.com> >>> wrote: >>> >>>> http://www.winehq.org/pipermail/wine-patches/2009-January/067564.html >>>> Any comment on this one? Related to bug 15616. >> >> Looks like >> http://www.winehq.org/pipermail/wine-patches/2009-January/067564.html >> has a brief description that says "See bug 15616", but the previous >> mail http://www.winehq.org/pipermail/wine-patches/2009-January/067565.html >> has the actual patch. >> >> Jérôme, be more careful when submitting patches! :) > > strange... the first one is the original message, the second one looks like > the attachment... Maybe something wrong with thunderbird. I'll resend if > needed. > I just looked at bug 15616. Maybe you should look at it too. Also, please hit "Reply to all" so your message gets sent to the mailing list too :)

3 7

Re: [2/2] mlang: Export a couple of functions by ordinal.
by Dmitry Timoshkov 02 Feb '09

02 Feb '09

"Hans Leidekker" <hans(a)codeweavers.com> wrote: > IE7 imports these and possibly others by ordinal. > > -Hans > > diff --git a/dlls/mlang/mlang.spec b/dlls/mlang/mlang.spec > index 1e8f022..689ad27 100644 > --- a/dlls/mlang/mlang.spec > +++ b/dlls/mlang/mlang.spec > @@ -1,14 +1,15 @@ > +112 stdcall ConvertINetUnicodeToMultiByte(ptr long ptr ptr ptr ptr) > +120 stdcall LcidToRfc1766A(long ptr long) > +121 stdcall LcidToRfc1766W(long ptr long) > + > @ stdcall ConvertINetMultiByteToUnicode(ptr long ptr ptr ptr ptr) > @ stub ConvertINetReset > @ stdcall ConvertINetString(ptr long long ptr ptr ptr ptr) > -@ stdcall ConvertINetUnicodeToMultiByte(ptr long ptr ptr ptr ptr) > @ stdcall -private DllCanUnloadNow() > @ stdcall -private DllGetClassObject(ptr ptr ptr) > @ stdcall -private DllRegisterServer() > @ stdcall -private DllUnregisterServer() > @ stdcall GetGlobalFontLinkObject() > @ stdcall IsConvertINetStringAvailable(long long) > -@ stdcall LcidToRfc1766A(long ptr long) > -@ stdcall LcidToRfc1766W(long ptr long) > @ stdcall Rfc1766ToLcidA(ptr str) > @ stdcall Rfc1766ToLcidW(ptr wstr) I've compared the exports of win98 and winxp versions of mlang.dll and they have exactly the same ordinals assigned. So it should be safe to assign ordinals to all mlang exports (it's worth to mention that PSDK doesn't ship an mlang.lib). -- Dmitry.

1 0

Re: BOOL WINAPI versus BOOL in d3dx9 and d3dx8
by Tony Wasserka 02 Feb '09

02 Feb '09

> Hi, > > the declaration of IntersectionTri is > BOOL IntersectionTri(.....) in d3dx8mesh.h and > BOOL WINAPI? IntersectionTri(.....) in d3dx9mesh.h . > > Is the latter one compatible with the former one (so I can forward d3dx9 function to the d3dx8 one) > or must I implement them separately? > > David It's already forwarded in d3dx9_36.spec to d3dx8, so you don't need to implement it twice. I was pretty careful when creating that specfile, i.e. it's in 99% safe to trust it ;) As a rule of thumb, every d3dx9 function which has no device (or any other D3D9 specific interface) parameter and has the exact same parameter list can safely be forwarded to d3dx8. However, are you sure it's only BOOL in d3dx8? AFAIK, dll functions always have to be WINAPI, as the calling convention gets screwed up otherwise... Best regards, Tony

2 1

wined3d and winex11 hand in hand...
by Jérôme Gardou 02 Feb '09

02 Feb '09

Quite oddly enough, wined3d and winex11 don't communicate with each other at all (well, wined3d uses WGL in gdi32, and gdi32 is based on winex11), and this leads to problems which are tricky to resolve... For instance, when a d3d application wants to disable screensavers, there is no way to do this through the windows api, but xlib provides XSetScreenSaver which is axactly what we need there. Would it be a good way to do this, as in user32 and gdi32, to create a driver structure holding each function pointer we would need, and forward them to stub if unavailable?

2 2

performance issue when OffscreenRenderingMode = "pbuffer"
by Jérôme Gardou 02 Feb '09

02 Feb '09

I tried to play Supreme Commander using pbuffer option instead of fbo. I was quite happy with it, since I gained quite a bunch of performance (I mean, something I really COULD see), but after a while, the performance dropped dramatically, to ~4-5 fps. I tested quite a few thing, and I finally found that pixel bufers were not taken in account when calculating available texture memory. The game then allocated more textures, and good opengl didn't dare complain when putting them in system memory. Attached is a patch which should solve the problem. For those who are curious, try setting VideoMemorySize to 200 instead of 256. It works just like a charm. >From 8e7b7e517b15e2ddb2cdd1526dfab3dfbf856bd5 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?J=C3=A9r=C3=B4me=20Gardou?= <jerome.gardou(a)laposte.net> Date: Sun, 25 Jan 2009 02:34:03 +0100 Subject: [PATCH] wined3d: take pixel buffers in account when calculating texture ram. --- dlls/wined3d/context.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/dlls/wined3d/context.c b/dlls/wined3d/context.c index da3053a..9fad82d 100644 --- a/dlls/wined3d/context.c +++ b/dlls/wined3d/context.c @@ -898,6 +898,9 @@ WineD3DContext *CreateContext(IWineD3DDeviceImpl *This, IWineD3DSurfaceImpl *tar } This->frag_pipe->enable_extension((IWineD3DDevice *) This, TRUE); + if(create_pbuffer) + WineD3DAdapterChangeGLRam(This, ((IWineD3DSurfaceImpl*)(ret->surface))->currentDesc.Width * ((IWineD3DSurfaceImpl*)(ret->surface))->currentDesc.Height * ((IWineD3DSurfaceImpl*)(ret->surface))->bytesPerPixel) ; + return ret; out: @@ -988,6 +991,7 @@ void DestroyContext(IWineD3DDeviceImpl *This, WineD3DContext *context) { if(context->isPBuffer) { GL_EXTCALL(wglReleasePbufferDCARB(context->pbuffer, context->hdc)); GL_EXTCALL(wglDestroyPbufferARB(context->pbuffer)); + WineD3DAdapterChangeGLRam(This,(-1) * ((IWineD3DSurfaceImpl*)(context->surface))->currentDesc.Width * ((IWineD3DSurfaceImpl*)(context->surface))->currentDesc.Height * ((IWineD3DSurfaceImpl*)(context->surface))->bytesPerPixel) ; } else ReleaseDC(context->win_handle, context->hdc); pwglDeleteContext(context->glCtx); -- 1.6.0.6

5 8