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

Re: [PATCH 2/4] comdlg32: Add stub implementation of the Common Item dialogs.

by Nikolay Sivov

On 3/22/2011 23:24, David Hedberg wrote: > On Mon, Mar 21, 2011 at 14:55, Nikolay Sivov<bunglehead(a)gmail.com> wrote: > >>> +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. > At the moment I'm checking the vtbl pointers to determine which type > of dialog it is in QueryInterface, although this looked better using > the old COM coding style (no explicit check necessary). > > Is using a union and an explicit type field preferred? I think it is, it makes it clear that dialogue instance is about save or open, not both. By the way, IFileSaveDialog is based on IFileDialog, and you add IFileDialog2 too. It's a bit messy, does target class object that will use FileDialogImpl really respond to IFileDialog2? >>> + >>> + fdimpl = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, >>> sizeof(FileDialogImpl)); >>> + if(!fdimpl) >>> + return E_OUTOFMEMORY; >> Zero initialization is useless here. > As mentioned above it's not completely useless currently, but I can > initialize them explicitly. Sure, that's what I meant. No need to initialize whole struct if you need only 'ref' to be 0 before QueryInterface. > Thanks for the review.

March 22, 2011

Re: [PATCH 2/4] comdlg32: Add stub implementation of the Common Item dialogs.

by David Hedberg

On Mon, Mar 21, 2011 at 14:55, Nikolay Sivov <bunglehead(a)gmail.com> wrote: >> +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. At the moment I'm checking the vtbl pointers to determine which type of dialog it is in QueryInterface, although this looked better using the old COM coding style (no explicit check necessary). Is using a union and an explicit type field preferred? >> + >> + fdimpl = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, >> sizeof(FileDialogImpl)); >> + if(!fdimpl) >> + return E_OUTOFMEMORY; > > Zero initialization is useless here. As mentioned above it's not completely useless currently, but I can initialize them explicitly. Thanks for the review.

March 22, 2011

Re: [1/4] wined3d/context: Track the number of render targets in FBO entries.

by Henri Verbeet

On 22 March 2011 18:12, Adam Martinson <amartinson(a)codeweavers.com> wrote: > On 03/22/2011 05:02 AM, Henri Verbeet wrote: >> This is meaningless. Which applications, and how much time of the >> total is spent in context_apply_fbo_state()? > > In the 3DMark06 batch size 8 test, as of Friday's tip, it was 5.5% of > wined3d; 1.2% of total wine CPU time. Searching the FBO list is almost all > of that. It's called every time drawPrimitive() is (assuming ORM_FBO), so > that shouldn't be much of a shock. I would hope that significant changes to fundamental parts of wined3d would be backed up by a somewhat wider range of benchmark results. >> How does this translate into concrete thing like frame time? > > It's an improvement, but I can't give you very meaningful FPS numbers there > for individual patches. In my testing raw FPS is less reliable than profile > results; it's dependent on GPU time as well, which I can't profile. The > range of normal FPS variability is larger than the effect of most individual > patches, including this one. GPU time matters. Freeing up CPU time just so you can spend more time waiting for the GPU to finish isn't all that useful. >> More importantly, why does this change come before the one for >> tracking FBO dirty state? > > Really? I sent both at the same time, and the order bothers you? Really?? Really. And I did even explain why. Note that while displays of disbelief rarely help with getting patches committed, solid arguments tend to do just fine. >> Avoiding redundant FBO entry comparisons completely is likely to >> have a much more significant effect than making the comparisons >> themselves slightly cheaper in very specific applications. > > Actually, it would take a much more specific FBO configuration for this to > make no difference. The whole list would have to have the same number of > render targets, and almost all of them full. memcmp() is expensive. > Avoiding unnecessary comparisons is cheap. This makes both successful and > unsuccessful FBO entry comparisons cheaper. The other patch helps too, > that's why I submitted both. > I'm quite aware of the costs of memory accesses, thanks. So, to be more explicit this time: - I understand just fine what the patch actually does. - I'm not opposed to this change in principle, but you will have to justify changes like these. - How much of a real difference does this patch make, after you avoid the redundant lookups? (I.e., after the second patch in this series.)

March 22, 2011

Re: [1/4] wined3d/context: Track the number of render targets in FBO entries.

by Adam Martinson

On 03/22/2011 05:02 AM, Henri Verbeet wrote: > On 21 March 2011 21:56, Adam Martinson<amartinson(a)codeweavers.com> wrote: >> Cuts CPU time in context_apply_fbo_state() in half. > This is meaningless. Which applications, and how much time of the > total is spent in context_apply_fbo_state()? In the 3DMark06 batch size 8 test, as of Friday's tip, it was 5.5% of wined3d; 1.2% of total wine CPU time. Searching the FBO list is almost all of that. It's called every time drawPrimitive() is (assuming ORM_FBO), so that shouldn't be much of a shock. > How does this translate into concrete thing like frame time? It's an improvement, but I can't give you very meaningful FPS numbers there for individual patches. In my testing raw FPS is less reliable than profile results; it's dependent on GPU time as well, which I can't profile. The range of normal FPS variability is larger than the effect of most individual patches, including this one. > More importantly, why does this change come before the one for > tracking FBO dirty state? Really? I sent both at the same time, and the order bothers you? Really?? > Avoiding redundant FBO entry comparisons completely is likely to > have a much more significant effect than making the comparisons > themselves slightly cheaper in very specific applications. Actually, it would take a much more specific FBO configuration for this to make no difference. The whole list would have to have the same number of render targets, and almost all of them full. memcmp() is expensive. Avoiding unnecessary comparisons is cheap. This makes both successful and unsuccessful FBO entry comparisons cheaper. The other patch helps too, that's why I submitted both.

March 22, 2011

Re: Must multimedia players check the message queue and invoke DispatchMessage?

by Juan Lang

> None of Wine's MCI drivers do. (snip) > Who could shed some light? Have you looked at any open source MCI drivers? They may or may not be of the best quality, but at least one exists in my brief perusal: the MediaXW package, http://sourceforge.net/projects/mediaxw/ > What do you mean exactly by "message pumping"? There are a few places in Wine > that call PeekMessage e.g. MCI_DefYieldProc, MMSYSTEM_MidiStream_MessageHandler, > but to me it looks like an error when that is not accompanied by DispatchMessageA/W > of all the messages that the local handler does not understand. > I'd expect DispatchMessage, not PeekMessage to invoke all the callbacks. > Isn't it an error for all loops executing on the app's thread? It's a broad topic, but yes, basically you want to call DispatchMessage on some messages periodically. See e.g. MsgWaitForMultipleHandles. --Juan

March 22, 2011

Re: winex11.drv/opengl.c: Unhandled null pointer

by Joshua Beck

On 03/22/2011 05:55 AM, Henri Verbeet wrote: > On 22 March 2011 08:59, Joshua Beck<jxb091000(a)utdallas.edu> wrote: > >> What do you think? >> >> > Does the pglXMakeCurrent() call a few lines above succeed? We should > probably check the result of that call. It doesn't succeed. I added some FIXMEs to the code to get output for debugging and this is what it printed before it crashed: >fixme:wgl:X11DRV_WineGL_InitOpenglInfo pglXMakeCurrent returned 0 >fixme:wgl:X11DRV_WineGL_InitOpenglInfo pglGetString pointer is equal to 0 > Nevertheless, this means > something is broken with your GL setup, so while the error handling > could be improved, it's not going to make the application work. With > the NVIDIA drivers this kind of thing typically happens when you have > a version mismatch between libGL and the kernel module. > I know it's not going to make it work, but it's still a good idea to have descriptive error messages. It helps less technically skilled people figure out what's wrong. Also wine-devel isn't really the place to ask for help setting up 32-bit drivers, so I didn't ask for that help here. If you want to help me we should email each other outside of the mailing list.

March 22, 2011

GSoC questions (Re: Question)

by Hin-Tak Leung

Sanket Patel wrote: > How Teams Are Formed in Google Summer Of Code For Any Project. > Is It Formed By Organization Or Google ? First, it would be good etiquette to post to mailing lists with sensible and specific subject fields, rather than generic like your past few posts. Many people only read posts from mailing lists of subjects which interest them; so a generic subject fields like yours is almost a guarantee to be ignored. You might have the naive idea that people read *all* e-mails with ambiguous subjects so to get attention it is best to make the subject as ambiguous as possible - that's quite misguided. Again, your questions are ambiguous. There is no "teams" at the student's level, and there is no "teams" at the mentor level, nor there is "teams" in the organization (either wine or google) level. *A* student needs to file *a* proposal, against an organization (e.g. wine) under the GSoC web site. *A* mentor needs to take official responsibility of *a* student, and *a* organization admin (often self-appointed, but usually a well-known person in a community) needs to approve of the mentor taking on the student, against all the other student+mentor combinations. Then the sets of student+mentor combination per organization is ranked and approved by Google on a quota system against all the other organizations'. Any suggestion of a "team" only generally happens AFAIK in the mentor level: i.e. while *a* mentor is officially responsible to check up on the progress of *a* student, the community as a whole, or some individuals in particular, can take on informal responsibility for guiding the student's progress. It is relatively rare for two students to work on the same project (but different aspect of it) although not unheard of; Google asks towards the end of the selection process for *a* student which has been accepted by more than one organizations, for one of the organizations to drop one of the applications so the other application can proceed.

March 22, 2011

AW: Must multimedia players check the message queue and invoke DispatchMessage?

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Juan Lang wrote: >Are you concerned about the applications introducing deadlocks by not >servicing messages quickly enough, or about MCI introducing deadlocks >by not processing messages in the current thread? I was concerned both about the MCI and the rest of winmm (midi*, wave*) API. We've a few bug reports about apps that hang but work with a native msvfw32.dll. I'm wondering if that could be related (erk, another dll that I'm not familiar with). >If the latter, this probably requires that MCI pump the message loop >while it's processing. The MCI API explcitly acknowledges some need for message pumping in the MCI_WAIT case via the mciSetYieldProc function. MSDN says that the MCI drivers must periodically call it. None of Wine's MCI drivers do. It's unclear to me why it should be called. Once I read that it's used to be able to react to the Break key to abort an animation (few people care). Maybe it's also needed to continuously dispatch messages (refresh, resize, buttons etc.)? I found no similar information about the wave* and midi* functions. Yet testing indicates that they also hijack the application's thread since w2k, possibly for as long as there's audio to play. Perhaps there's no documentation precisely because that changed since w2k, all winmm documentation predates that and in w9x another thread was used so there was no analogue to MCI_WAIT design issues. Who could shed some light? >It's common to require that applications continue to "pump" the message >loop when calling some blocking function. Modal dialog boxes continue >to do so, for example. Indeed, one of my colleagues has written a mono-threading multi-windowing application. It rarely seems to hang, except when reading from CTAPI. It must be full of nested callbacks and calls to DispatchMessage. What do you mean exactly by "message pumping"? There are a few places in Wine that call PeekMessage e.g. MCI_DefYieldProc, MMSYSTEM_MidiStream_MessageHandler, but to me it looks like an error when that is not accompanied by DispatchMessageA/W of all the messages that the local handler does not understand. I'd expect DispatchMessage, not PeekMessage to invoke all the callbacks. Isn't it an error for all loops executing on the app's thread? >I wouldn't be surprised if some app expects that it can post messages >from its callbacks. MSDN on waveOutProc explicitly allows Post[Thread]Message. wave* are forbidden (no waveOutWrite from within a WOM_DONE callback, no midiOutClose, but there are logs in Bugzilla that show otherwise). MSDN documents MMSYSERR_HANDLEBUSY "The handle is being used simultaneously by another thread (for example, a callback thread)." I've never seen that error. Yet it means that they are considering detecting possible dead-locks and contentions. Thank you, Jörg Höhle

March 22, 2011

Question

by Sanket Patel

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 "

March 22, 2011

Re: kernel32: avoid shadowing a parameter (try 2)

by Henri Verbeet

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.

March 22, 2011

Re: winex11.drv/opengl.c: Unhandled null pointer

by Henri Verbeet

On 22 March 2011 08:59, Joshua Beck <jxb091000(a)utdallas.edu> wrote: > What do you think? > Does the pglXMakeCurrent() call a few lines above succeed? We should probably check the result of that call. Nevertheless, this means something is broken with your GL setup, so while the error handling could be improved, it's not going to make the application work. With the NVIDIA drivers this kind of thing typically happens when you have a version mismatch between libGL and the kernel module.

March 22, 2011

Re: [1/4] wined3d/context: Track the number of render targets in FBO entries.

by Henri Verbeet

On 21 March 2011 21:56, Adam Martinson <amartinson(a)codeweavers.com> wrote: > > Cuts CPU time in context_apply_fbo_state() in half. This is meaningless. Which applications, and how much time of the total is spent in context_apply_fbo_state()? How does this translate into concrete thing like frame time? More importantly, why does this change come before the one for tracking FBO dirty state? Avoiding redundant FBO entry comparisons completely is likely to have a much more significant effect than making the comparisons themselves slightly cheaper in very specific applications.

March 22, 2011

Re: [1/4] wined3d/context: Track the number of render targets in FBO entries.

by Stefan Dösinger

-----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-----

March 22, 2011

Re: Idea

by Hin-Tak Leung

(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.

March 22, 2011

Re: winex11.drv/opengl.c: Unhandled null pointer

by Dmitry Timoshkov

[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.

March 22, 2011

Re: winex11.drv/opengl.c: Unhandled null pointer

by Dmitry Timoshkov

Joshua Beck <jxb091000(a)utdallas.edu> wrote: > 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. What OpenGL driver are you using? glGetString(GL_EXTENSIONS) returning NULL might be a driver bug. > 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. -- Dmitry.

March 22, 2011

Re: [1/4] wined3d/context: Track the number of render targets in FBO entries.

by Dmitry Timoshkov

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.

March 22, 2011

winex11.drv/opengl.c: Unhandled null pointer

by Joshua Beck

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?

March 22, 2011

Re: [1/2] uxtheme: Add OpenThemeDataEx

by Dmitry Timoshkov

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.

March 22, 2011

Re: Idea

by Damjan Jovanovic

On Tue, Mar 22, 2011 at 4:40 AM, Sanket Patel <sanketpatel.com(a)gmail.com> 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 > -- If you want to make a "Portable App" of Wine (ie. a directory containing the Wine installation which can be moved anywhere in the filesystem or run from a USB flash disk) I think Wine supports that already; the "wine" executable finds the path to other files it needs using its own location, not the --prefix option to configure. The only thing I found that doesn't work is winegcc, which hardcodes search paths at compile time, but end users almost never need it anyway. Damjan

March 22, 2011

Idea

by Sanket Patel

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 "

March 22, 2011

Re: Xbox 360 controller compatibility

by Vitaliy Margolen

On 03/21/2011 01:36 AM, Alesh Slovak wrote: > I've also found a set of patches by Michael Gruber from 2009 that appear to > actually implement xinput: > http://marc.info/?l=wine-patches&m=124710119700598&w=4 > <http://marc.info/?l=wine-patches&m=124710119700598&w=4> > http://marc.info/?l=wine-patches&m=124710124200662&w=4 > <http://marc.info/?l=wine-patches&m=124710124200662&w=4> > http://marc.info/?l=wine-patches&m=124710129100718&w=4 > <http://marc.info/?l=wine-patches&m=124710129100718&w=4> > http://marc.info/?l=wine-patches&m=124710132300760&w=4 > <http://marc.info/?l=wine-patches&m=124710132300760&w=4> > > What do people think of these? Looks more-less complete. Needs some cleanup. The main hurdle would be convincing AJ that this the best and only way to talk to x360 controller. Of course will need some extra infrastructure to add drivers for other O/Ses. Vitaliy.

March 22, 2011

Re: Xbox 360 controller compatibility

by Vitaliy Margolen

On 03/20/2011 02:46 PM, Austin English wrote: > http://www.winehq.org/pipermail/wine-patches/2008-November/064302.html > http://www.winehq.org/pipermail/wine-patches/2008-November/064304.html > http://www.winehq.org/pipermail/wine-patches/2008-November/064305.html > These are stubs more-less. No actual implementation of the interface. This part already in Wine. Vitaliy

March 22, 2011

Re: mshtml: avoid shadowing a parameter (2/2)

by Austin English

On Wed, Mar 9, 2011 at 06:30, Jacek Caban <jacek(a)codeweavers.com> wrote: > 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. Sure, resent. Thanks for reviewing! -- -Austin

March 22, 2011

Re: wined3d: Prevent crash when blit_priv is NULL.

by Henri Verbeet

2011/3/21 Roderick Colenbrander <thunderbird2k(a)gmail.com>: > Good :) I guess I should submit the patch as it is now, I hope Henri > would be fine with doing it this way for the time being (the FBO code > is doing something equivalent). Should be ok for the time being.

March 21, 2011