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

Re: winex11.drv/opengl.c: add error handling to pglXMakeCurrent() call
by Roderick Colenbrander March 24, 2011

March 24, 2011

Hi Joshua, Was about to submit a similar patch (had a few tiny fixes in my tree left), but this patch is mostly fine with me. Except I would print to 'winediag' like some of the other errors for software / indirect rendering are doing. So do something like 'Unable to active OpenGL context, like something your drivers have not been configured properly' (look what the other messages are like). Roderick On Thu, Mar 24, 2011 at 2:34 AM, Joshua Beck <jxb091000(a)utdallas.edu> wrote: > This patch should make it easier for those with driver problems to find the > problem when running Wine. > --Josh > > > >

1 0

Duplicate AppDB Entry
by Jeremy Nowka March 24, 2011

March 24, 2011

"Barnes And Noble EReader" v2.5 and "Nook for PC" are the same program. I feel that the two AppDB entries should be combined for easier access by the general public. I feel that the information should be merged to "Nook for PC" because this is the common name for version 2.5. The version number for "Nook for PC" should be changed to reflect the actual version, 2.5.

2 1

re: [GSoC] Merge winecfg and Control Panel
by Dan Kegel March 23, 2011

March 23, 2011

Also... it would be nice if there were a central commandline way of changing wine settings, kind of like 'net' is a central way of manipulating networking. I've been thinking that winecfg should have a commandline interface, too, and making it accept winetricks settings directly. Something like that would also make a good soc project.

4 3

Re: [1/2] uxtheme: Add OpenThemeDataEx (try 2)
by Dmitry Timoshkov March 23, 2011

March 23, 2011

André Hentschel <nerv(a)dawncrow.de> wrote: > Applied Dmitry's suggestions > -HTHEME WINAPI OpenThemeData(HWND hwnd, LPCWSTR pszClassList) > +HTHEME WINAPI OpenThemeDataEx(HWND hwnd, LPCWSTR classlist, DWORD flags) > { > - WCHAR szAppBuff[256]; > - WCHAR szClassBuff[256]; > - LPCWSTR pszAppName; > - LPCWSTR pszUseClassList; > + WCHAR appbuff[256]; > + WCHAR classbuff[256]; > + LPCWSTR appname; > + LPCWSTR useclasslist; > HTHEME hTheme = NULL; You are changing too much. Just use lowercase named variables for new code, not touching existing ones. > - TRACE("(%p,%s)\n", hwnd, debugstr_w(pszClassList)); > + TRACE("(%p,%s, %u)\n", hwnd, debugstr_w(classlist), flags); flags above is still printed in decimal. > + > + if(flags) > + FIXME("unhandled Flags: %x\n", flags); -- Dmitry.

1 0

Re: [PATCH 2/4] comdlg32: Add stub implementation of the Common Item dialogs.
by Nikolay Sivov March 23, 2011

March 23, 2011

On 3/21/2011 16:37, David Hedberg wrote > + */ > + > +#include<stdarg.h> > + > +#define COBJMACROS > +#define NONAMELESSUNION > +#define NONAMELESSSTRUCT > + > +#include "windef.h" > +#include "winbase.h" > +#include "winuser.h" > +#include "wingdi.h" > + > +#include "commdlg.h" > +#include "cdlg.h" > + > +#include "wine/debug.h" > + > +WINE_DEFAULT_DEBUG_CHANNEL(commdlg); > + > +typedef struct FileDialogImpl { > + IFileDialog2 IFileDialog2_iface; > + IFileOpenDialog IFileOpenDialog_iface; > + IFileSaveDialog IFileSaveDialog_iface; > + LONG ref; > +} FileDialogImpl; Maybe it's better to use a union and enum type field here, if it can't be open and save at the same time. > + > +/************************************************************************** > + * IFileDialog implementation > + */ > +static inline FileDialogImpl *impl_from_IFileDialog2(IFileDialog2 *iface) > +{ > + return (FileDialogImpl *)((char*)iface - FIELD_OFFSET(FileDialogImpl, IFileDialog2_iface)); > +} > + Use CONTAINING_RECORD macro please. > +static HRESULT WINAPI IFileDialog2_fnQueryInterface(IFileDialog2 *iface, > + REFIID riid, > + void **ppvObject) > +{ > > + } > + else > + FIXME("Unknown interface requested.\n"); It's better to dump guid here. > +} > + > +static ULONG WINAPI IFileDialog2_fnRelease(IFileDialog2 *iface) > +{ > + FileDialogImpl *This = impl_from_IFileDialog2(iface); > + LONG ref = InterlockedDecrement(&This->ref); > + TRACE("%p - ref %d\n", This, ref); > + > + if(!ref) > + { > + TRACE("Freeing object.\n"); > + HeapFree(GetProcessHeap(), 0, This); > + } > + > + return ref; > +} No need for additional trace I think, ref == 0 is enough to indicated that. > +static HRESULT FileDialog_constructor(IUnknown *pUnkOuter, REFIID riid, void **ppv, REFCLSID type) > +{ > + FileDialogImpl *fdimpl; > + HRESULT hr; > + TRACE("%p, %s, %p\n", pUnkOuter, debugstr_guid(riid), ppv); > + > + if(!ppv) > + return E_POINTER; > + if(pUnkOuter) > + return CLASS_E_NOAGGREGATION; > + > + fdimpl = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(FileDialogImpl)); > + if(!fdimpl) > + return E_OUTOFMEMORY; Zero initialization is useless here. > + > + fdimpl->IFileDialog2_iface.lpVtbl =&vt_IFileDialog2; > + > + if(IsEqualCLSID(type,&CLSID_FileOpenDialog)) > + fdimpl->IFileOpenDialog_iface.lpVtbl =&vt_IFileOpenDialog; > + else > + fdimpl->IFileSaveDialog_iface.lpVtbl =&vt_IFileSaveDialog; > + > + IUnknown_AddRef((IUnknown*)fdimpl); > + hr = IUnknown_QueryInterface((IUnknown*)fdimpl, riid, ppv); > + IUnknown_Release((IUnknown*)fdimpl); > + That looks strange, you only need one QueryInterface here.

2 4

Re: Question
by Andrew Green March 22, 2011

March 22, 2011

There are no teams in gsoc. Each person has to work individually on the project they choose. How it works is that the organisation pick projects it approves of. Then these projects are sent to google. Google takes into account various factors to decide how many projects get selected. On Mar 23, 2011 12:24 AM, "Sanket Patel" <sanketpatel.com(a)gmail.com> wrote: > > How Teams Are Formed in Google Summer Of Code For Any Project. > Is It Formed By Organization Or Google ? > > -- > " Live 2 Love and Love 2 Live " > > >

1 0

winex11.drv/opengl.c: Unhandled null pointer
by Joshua Beck March 22, 2011

March 22, 2011

I've been trying to run wine with a few games, and I've been getting a similar error and backtrace with all of them. Here's the relevant info: wine: Unhandled page fault on read access to 0x00000000 at address 0xf748c110 (thread 0043), starting debugger... Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0xf748c110). ... Backtrace: =>0 0xf748c110 in libc.so.6 (+0x74110) (0x0032e670) 1 0x7e59fae9 X11DRV_WineGL_InitOpenglInfo+0x353() [/home/jb/programs/wine-git/dlls/winex11.drv/opengl.c:351] in winex11 (0x0032e670) ... (goes on for a dozen or so more, not relevant to this bug) So my first thought was "What's wrong with libc?" Then I looked at the source of the file at level 1 of the stack and found this: 350: str = (const char *) pglGetString(GL_EXTENSIONS); 351: WineGLInfo.glExtensions = HeapAlloc(GetProcessHeap(), 0, strlen(str)+1); From this it's obvious that pglGetString is returning a null pointer. It would be better to do something like this instead: str = (const char *) pglGetString(GL_EXTENSIONS); if(str == 0) { ERR( "Couldn't find GL_EXTENSIONS string, disabling OpenGL.\n" ); goto done; } WineGLInfo.glExtensions = HeapAlloc(GetProcessHeap(), 0, strlen(str)+1); What do you think?

3 3

Question
by Sanket Patel March 22, 2011

March 22, 2011

How Teams Are Formed in Google Summer Of Code For Any Project. Is It Formed By Organization Or Google ? -- " Live 2 Love and Love 2 Live "

2 1

Re: kernel32: avoid shadowing a parameter (try 2)
by Henri Verbeet March 22, 2011

March 22, 2011

On 22 March 2011 02:27, Austin English <austinenglish(a)gmail.com> wrote: > defval_tmp = HeapAlloc(GetProcessHeap(), 0, (len + 1) * sizeof(WCHAR)); > - memcpy(defval_tmp, def_val, len * sizeof(WCHAR)); > - defval_tmp[len] = '\0'; > + memcpy(defval_tmp, def_val, defval_len * sizeof(WCHAR)); > + defval_tmp[defval_len] = '\0'; I think you're allocating the wrong amount of memory now.

1 0

Re: [1/4] wined3d/context: Track the number of render targets in FBO entries.
by Stefan Dösinger March 22, 2011

March 22, 2011

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 21.03.2011 um 21:56 schrieb Adam Martinson: > > Cuts CPU time in context_apply_fbo_state() in half. What is the performance impact on real apps? -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNiHM5AAoJEN0/YqbEcdMwi28P/1iN598GQgE9ttILayjW6f1h E8DKkF30dJyXa506XoPKWeE+319mpLOevUca2hjBaaKoL+H69TzCproGGgdw7/W3 roWyg2Q42hibFnTb5ORwgjbsQbqYlRaMj7nlCJguyDjnK81oNIpLWjdiVWpe4H+b naQf+p9NWRR6x2tOx4i71MgvWnbPRiawJO14DxwwyTxelYWu05XgWvFaRYuyKevt 67q8yGGVx+4SXmSC1D5rzRAjY2OHIvGbznlrC3VV3TmpQg5YsrWS7b8XWr/Ii3DJ DQsOLbv/KMFTOTcQ6wjI+dJPX/lM/3z7QcOVVsAGZyOvH+8fIMAwtDcgU+EAwyWY CaM7NH6JM8Jlal4r8Hfhw/9IfLr+K6WVzYKPdjxO+PUxhV1GV4GC74vQn8wMHK4U LANQ5Kw9s+dThqM6gyBTcdyD8r37ktULlOyAFfx4a63Wg8JRBiqPyEyRufoCK7Kf lfsOGcadkAy9eKh4tIlaEfOMwewOap7Mq4veyQLO6JrnWVKIPg/vCufT4SD5VgPG AMtvbG0lqX5+egdH0IM6j4e9CiescSwqHqywphvxGwzQlPpbejvnIysFLH351lBQ cqIjVmcXLDTRigO8cpg+r7yyntVSCGZ8HduZlgwCLroOHJvK1vR0LkUHPIC1M5yE CYKj0gOxXQ7k8pT0uHJb =UrlD -----END PGP SIGNATURE-----

1 0

Re: Idea
by Hin-Tak Leung March 22, 2011

March 22, 2011

(Please keep the wine-devel CC:) Sanket Patel wrote: > User File Location > > On Tue, Mar 22, 2011 at 8:25 AM, Hin-Tak Leung <hintak_leung(a)yahoo.co.uk > <mailto:hintak_leung(a)yahoo.co.uk>> wrote: > > Sanket Patel wrote: > > > hi there, > I talk about to make wine portable. > How I am Gonna Do That is , > There is a files that are related to system and integrated in to > system while install. > We gonna change that system files places . > How ? that is still question but we can do By community Support. > > If you talk about takiinng 1/2 of system files into package , i > think there is not really a case to happen > > > Hmm, I think you are confusing 'relocatable' vs 'portable' - in any > case, wine is already both portable (runs on many x86/x86_64-based > unix systems, include linux, *bsd, solaris, Mac OS X), and wine is > also relocatable to a good extent - > you can either run wine without installing, from within the > source(build) directory with the script provided, or you can choose > an install location with "./configure --prefix=..." > > Or may be you mean the user file location (${HOME}/.wine > (WINEPREFIX)) vs the wine binary locations (the ./configure > --prefix=<where>)? You need to clarify what you propose. Perhaps you did not notice, I already wrote that user file location, while defaults to ${HOME}/.wine, is controllable by setting the WINEPREFIX environment variable before launching wine. This machanism of allowing for parallel and separate user files are quite actively used and maintained. WineInBottle (or something of a similar name?) and possibly a few other "wine add-ons" does that, actually.

1 0

Re: winex11.drv/opengl.c: Unhandled null pointer
by Dmitry Timoshkov March 22, 2011

March 22, 2011

[Please do not omit wine-devel(a)winehq.org when replying] Joshua Beck <jxb091000(a)utdallas.edu> wrote: > > What OpenGL driver are you using? glGetString(GL_EXTENSIONS) returning NULL > > might be a driver bug. > > > I'm using an nvidia binary driver (260.36.19 I think). Thing is I'm > running Debian amd64 and I compiled wine with -m32. I checked and there > are nvidia libraries in /usr/lib32. However I don't know if all of them > are in there or if they work correctly. See http://wiki.winehq.org/3DDriverIssues how to diagnose GL driver problems. > >> It would be better to do something like this instead: > >> > >> str = (const char *) pglGetString(GL_EXTENSIONS); > >> if(str == 0) > >> { > >> ERR( "Couldn't find GL_EXTENSIONS string, disabling OpenGL.\n" ); > >> goto done; > >> } > >> WineGLInfo.glExtensions = HeapAlloc(GetProcessHeap(), 0, strlen(str)+1); > >> > >> > >> What do you think? > >> > > WineGLInfo.glExtensions is used in other places in the code, it must be > > initialized. > > > > > If str == 0 then the program is going to crash before anything else can > get to WineGLInfo.glExtensions. Better to say what the error is than to > crash with an "Unhandled page fault" error. If it's that important to > have WineGLInfo.glExtensions initialized to something then initialize > it to an error code. If pglGetString(GL_EXTENSIONS) returns NULL for whatever reason allocating an 1 byte WineGLInfo.glExtensions buffer and setting it to 0 should work just fine. -- Dmitry.

1 0

Re: [1/4] wined3d/context: Track the number of render targets in FBO entries.
by Dmitry Timoshkov March 22, 2011

March 22, 2011

Adam Martinson <amartinson(a)codeweavers.com> wrote: > Cuts CPU time in context_apply_fbo_state() in half. > --- > dlls/wined3d/context.c | 65 > +++++++++++++++++++++------------------ > dlls/wined3d/wined3d_private.h | 1 + > 2 files changed, 36 insertions(+), 30 deletions(-) It looks like you are not subscribed to wine-patches mailing list and your patches are delayed awaiting the moderator action. -- Dmitry.

1 0

Re: [1/2] uxtheme: Add OpenThemeDataEx
by Dmitry Timoshkov March 22, 2011

March 22, 2011

André Hentschel <nerv(a)dawncrow.de> wrote: > - TRACE("(%p,%s)\n", hwnd, debugstr_w(pszClassList)); > + TRACE("(%p,%s, %u)\n", hwnd, debugstr_w(pszClassList), Flags); > + > + if(Flags) > + FIXME("unhandled Flags: %u\n", Flags); ... > +#define OTD_FORCE_RECT_SIZING 0x0001 > +#define OTD_NONCLIENT 0x0002 > +#define OTD_VALIDBITS (OTD_FORCE_RECT_SIZING | OTD_NONCLIENT) Flags should be printed as hex in the traces. Also using names without capitalizaion and hungarian notation is always preferred for new code in Wine. -- Dmitry.

1 0

Idea
by Sanket Patel March 22, 2011

March 22, 2011

hi there, I talk about to make wine portable. How I am Gonna Do That is , There is a files that are related to system and integrated in to system while install. We gonna change that system files places . How ? that is still question but we can do By community Support. If you talk about takiinng 1/2 of system files into package , i think there is not really a case to happen -- " Live 2 Love and Love 2 Live "

2 1

Xbox 360 controller compatibility
by Alesh Slovak March 22, 2011

March 22, 2011

Hi, I apologize if this question has come up before, I could not find a search feature in the mailing list archives and google didn't give me much on the subject. I am interested in getting the Xbox 360 controller working in wine. Currently, I can use the controller, but it is recognized only as a generic controller. This is acceptable (although annoying) for games that allow me to freely configure the controller, but others seem to specifically look for an Xbox 360 controller, and when they can't find it, drop to keyboard controls. Firstly, I am not even sure this is something that should or can be handled in wine. Maybe this needs to be handled in the xpad kernel module, or maybe both. But my guess is that wine would need to detect an Xbox 360 controller and then explicitly present it as such to any games. I guess the first step would be to find out how exactly games detect the Xbox 360 controller under Windows and try to emulate that. Any other previous attempts that anyone knows of? I would appreciate it if anybody out there who has any knowledge in this area, can point me in the right direction. Thanks.

5 11

Re: mshtml: avoid shadowing a parameter (2/2)
by Jacek Caban March 22, 2011

March 22, 2011

Hi Austin, On 3/9/11 10:07 AM, Austin English wrote: > diff --git a/dlls/mshtml/htmlwindow.c b/dlls/mshtml/htmlwindow.c > index d0d378f..9948a02 100644 > --- a/dlls/mshtml/htmlwindow.c > +++ b/dlls/mshtml/htmlwindow.c > @@ -2141,22 +2141,22 @@ static HRESULT HTMLWindow_invoke(DispatchEx *dispex, DISPID id, LCID lcid, WORD > > switch(prop->type) { > case GLOBAL_SCRIPTVAR: { > - IDispatchEx *dispex; > + IDispatchEx *dpex; How about renaming argument name to 'iface'? It's not really an interface, but its purpose in this context is like iface arguments in regular COM objects. Jacek

2 1

Re: wined3d: Prevent crash when blit_priv is NULL.
by Roderick Colenbrander March 21, 2011

March 21, 2011

Hi Konrad, You should try to figure out why blit_priv is NULL. That's the real issue. What drivers are you using? Do they support arb fragment program? Right now we may still call arbfp_blit_surface when the extension isn't around (was working on this a year ago, haven't had time since then :( ), this could explain why there is no priv_data since in ffp_blit_alloc we don't do any allocation. Roderick On Sun, Mar 20, 2011 at 3:58 AM, Konrad Rzepecki <hannibal(a)astral.lodz.pl> wrote: > Might&Magic VII from gog.com crash in bink movie plaing: > > Backtrace: > =>0 0x7e70c4b9 arbfp_blit_set+0x28b(blit_priv=0x0(nil), gl_info=0x135b08, surface=0x1dc788) [/mnt/skopia/devel/winegit/wine/dlls/wined3d/arb_program_shader.c:7058] in wined3d (0x0033f98c) > 1 0x7e70d3db arbfp_blit_surface+0xa2(device=0x16cdc0, src_surface=0x1dc788, src_rect=0x33fa74, dst_surface=0x168140, dst_rect_in=0x33fa84, blit_op=BLIT_OP_BLIT, Filter=0x2) [/mnt/skopia/devel/winegit/wine/dlls/wined3d/arb_program_shader.c:7192] in wined3d (0x0033f9dc) > 2 0x7e7d28f7 IWineD3DSurfaceImpl_BltOverride+0xf1b(dst_surface=0x168140, DestRect=0x33fcf8, src_surface=0x1dc788, SrcRect=0x33fce8, flags=0x1000000, DDBltFx=(nil), Filter=WINED3DTEXF_LINEAR) [/mnt/skopia/devel/winegit/wine/dlls/wined3d/surface.c:3787] in wined3d (0x0033fbac) > 3 0x7e7d3013 IWineD3DSurfaceImpl_Blt+0x29e(iface=0x168140, DestRect=0x33fcf8, src_surface=0x1dc788, SrcRect=0x33fce8, flags=0x1000000, DDBltFx=(nil), Filter=WINED3DTEXF_LINEAR) [/mnt/skopia/devel/winegit/wine/dlls/wined3d/surface.c:3930] in wined3d (0x0033fc2c) > 4 0x7e8687f2 ddraw_surface7_Blt+0x380(iface=0x135308, DestRect=0x33fcf8, SrcSurface=0x1dc560, SrcRect=0x33fce8, Flags=0x1000000, DDBltFx=(nil)) [/mnt/skopia/devel/winegit/wine/dlls/ddraw/surface.c:908] in ddraw (0x0033fc9c) > 5 0x004a18cd in mm7-rel (+0xa18cc) (0x0033fcc8) > 6 0x004beda4 in mm7-rel (+0xbeda3) (0x0033fd08) > 7 0x004be721 in mm7-rel (+0xbe720) (0x00000000) > --- > dlls/wined3d/surface.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c > index 745bd77..baa032b 100644 > --- a/dlls/wined3d/surface.c > +++ b/dlls/wined3d/surface.c > @@ -3924,8 +3924,8 @@ static HRESULT WINAPI IWineD3DSurfaceImpl_Blt(IWineD3DSurface *iface, const RECT > } > > /* Special cases for RenderTargets */ > - if ((This->resource.usage & WINED3DUSAGE_RENDERTARGET) > - || (src && (src->resource.usage & WINED3DUSAGE_RENDERTARGET))) > + if (This->resource.device->blit_priv && ((This->resource.usage & WINED3DUSAGE_RENDERTARGET) > + || (src && (src->resource.usage & WINED3DUSAGE_RENDERTARGET)))) > { > if (SUCCEEDED(IWineD3DSurfaceImpl_BltOverride(This, DestRect, src, SrcRect, flags, DDBltFx, Filter))) > return WINED3D_OK; > -- > 1.7.4.1 > > >

3 5

Failing kernel32:change and ntdll:change tests on Mac OS
by Charles Davis March 21, 2011

March 21, 2011

Hi, I just got done looking over the latest batch of test results I sent, and one thing really sticks out and bothers me. The Change Notification tests all fail miserably on my machine (a 2009 Mac Pro with Mac OS X 10.6), because that feature hasn't been implemented on Mac yet. I could implement it for 10.5 up, but the problem is that the "public" API for Change Notifications on Mac (the "FSEvents" API, in CoreServices.framework) expects clients to either use a CFRunLoop or (on 10.6 and up) a GCD dispatch queue. I'm sure this won't sit well with AJ. I did some digging, and it turns out that FSEvents just uses a Mach port (whose name is published in root's Mach bootstrap context as "com.apple.FSEvents") to talk to a daemon, fseventsd, which in turn opens a device file, /dev/fsevents, which is the actual gateway to the kernel. Though it's largely undocumented, we could use this device file to implement Change Notification. The FDs that get returned by this file even support kqueues. But, there are two tiny problems with that: 1) You have to be root to open /dev/fsevents. If we do it this way, we will have to wait until the server is converted to run as root. 2) Because this API isn't officially documented, it's unstable and subject to change. (In fact, judging from the kernel source, it's already changed once. There are several 'old' and 'new' variants of the FSEvents ioctls that the kernel handler supports.) I guess the real question is, which way should we do this? If we do it the first way (using the public and documented but kqueue-unfriendly Carbon API), wineserver has to use a CFRunLoop (or, if we're no longer concerned about Leopard, a GCD dispatch queue) in its main loop, and if we do it the second way (using the undocumented and unstable but kqueue-friendly Unix API), wineserver needs to run as root, and may need to cope with API changes. Based on what I've heard, I'm leaning toward the second way, but I want your guys' input before I go ahead. Thanks. Chip

2 4

Re: msi: Add an offset to sequence numbers belonging to files added by a patch. (try 2)
by Hans Leidekker March 21, 2011

March 21, 2011

On Mon, 2011-03-21 at 14:14 +0100, David Hedberg wrote: > +static void msi_patch_offset_list_init(struct msi_patch_offset_list **pos) > +{ > + *pos = msi_alloc(sizeof(struct msi_patch_offset_list)); > + list_init( &(*pos)->files ); > + (*pos)->count = (*pos)->max = 0; > + (*pos)->min = 999999; > +} It would be nicer to have a _create function that returns an initialized structure.

1 0

Re: user32: Fix return value when passing a non-sibling preceding window to SetWindowPos.
by Dmitry Timoshkov March 21, 2011

March 21, 2011

David Hedberg <dhedberg(a)codeweavers.com> wrote: > +#define ERROR_ABORT_WITH_TRUE 30000 ... > /* Fix redundant flags */ > - if (!fixup_flags( winpos )) return FALSE; > + ret = fixup_flags( winpos ); > + if(ret == ERROR_FUNCTION_FAILED) > + return FALSE; > + else if(ret == ERROR_ABORT_WITH_TRUE) > + return TRUE; Please try to avoid made up names and internal conditions. I'd suggest to add a test case which shows the problem first with todo_wine around the failing test, and only then send a fix, so it's clear what actually your patch is doing. Tiny nitpick, in the code below: if (condition1) return something1; else if (contition2) return something2; 'else' statement is redundant. -- Dmitry.

1 0

Re: [1/4] wined3d: don't create VBOs in buffer::preload
by Henri Verbeet March 21, 2011

March 21, 2011

On 20 March 2011 20:07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > I'm not so sure about this patch. I think preload() should conceptually be "wined3d_resource_load_location(resource, WINED3D_RESOURCE_LOCATION_GPU, NULL);", and this patch seems to move away from that rather than towards it. I'm also not sure about how the bug you're describing would actually happen. Although device_stream_info_from_declaration() seems to assume preload() can only drop buffer objects, it does correctly call buffer_get_sysmem(), so the resulting stream info should be consistent, even though perhaps somewhat sub-optimal. Shouldn't this just be a matter of fixing device_stream_info_from_declaration() to not assume preload() can only drop buffer objects?

1 0

Re: [PATCH] winegcc - do not create .exe.so
by Vitaliy Margolen March 21, 2011

March 21, 2011

On 03/20/2011 05:14 AM, Pali Rohár wrote: > Can anybody review my patch? Not sure what you trying to do exactly. Wine already has wrapper that makes all wine binaries executable after they are being installed into system. As for the patch: - Do not use tab characters - Please no unneeded white space changes - Use git to create your patch. At the very minimum it have to have full path to the source file in the header - patch should be generated from the top of the source tree. Vitaliy.

4 8

Re: [PATCH] winegcc - do not create .exe.so
by James McKenzie March 21, 2011

March 21, 2011

On 3/20/11 4:14 AM, Pali Rohár wrote: > 2011/2/19 Pali Rohár<pali.rohar(a)gmail.com>: >> 2011/2/4 Pali Rohár<pali.rohar(a)gmail.com>: >>> Hello, >>> >>> I created patch which implement correct _start section in ELF shared >>> libraries/binaries which generate winegcc. >>> Into _start section this patch add calling execve syscall which start >>> wine with all arguments. So it is not needed to generate shell wrapper >>> and .exe.so binary. >>> >>> This replace code on: >>> http://wiki.winehq.org/Winelib_binaries_as_ELF_executables_not_.exe.so >>> >>> $ winegcc app.c --> generate only a.exe (shared object ELF binary), no >>> aditional a.exe.so >>> $ ./a.exe --> start binary correctly without shell wrapper >>> >>> -- >>> Pali Rohár >>> pali.rohar(a)gmail.com >>> >> I rewrited my patch. Now set up correctly enviromental variables too. >> Assembler code is only for x86. >> >> -- >> Pali Rohár >> pali.rohar(a)gmail.com >> > Can anybody review my patch? > Reviews are sent to wine-development list. If you want to submit a patch for comment only, please submit it to wine-development. Thank you. James McKenzie

1 0

Idea
by Sanket Patel March 20, 2011

March 20, 2011

I Have One Idea ......... Why Should not we make wine portable ? -- " Live 2 Love and Love 2 Live "

2 1