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

Re: mshtml: Implement IHTMLStyle_put_backgroundColor

by Alistair Leslie-Hughes

Hi Ricardo, > hi alistair, > you say it implements the put method but the patch has only the get > method... typo? > Thanks for picking this up. It's a typo, Ill resend shortly. Best Regards Alistair Leslie-Hughes

Feb. 4, 2009

Re: Stub DDE interface for Progman.exe

by Jeremiah Flerchinger

On Tue, 2009-02-03 at 22:55 +0800, Dmitry Timoshkov wrote: > "Jeremiah Flerchinger" <jeremiah.flerchinger(a)gmail.com> wrote: > > > Stubs basic DDE interface of Progman.exe. Similar to Progman stub in > > shell32.dll. Both will need to be extended and a 3rd progman interface > > will need to be added in user32. > > Progman DDE interface should be implemented by shell32.dll, nowhere else. > The shell32.dll DDE callback isn't always initialized & handling Progman calls for all apps. I've seen Progman calls pass through the DDE_client and DDE_server of user32.dll instead and never go through shell32.dll. We can have the actual Progman functions in shell32.dll, but at least user32.dll will have to be able to call & be called by these. I think a separate progman.c/progman.h in /dlls/user32 to handle calls from all locations may be preferred. Any suggestions?

Feb. 4, 2009

Re: [PATCH] mshtml: call install_cab_file() with name directly on non-Wine

by Steven Edwards

On Wed, Feb 4, 2009 at 1:11 PM, Marcus Meissner <marcus(a)jet.franken.de> wrote: > Hi, > > A ReactOS developer told me that if the wine_get_dos_file_name() does > not return a function, we should just pass in the current filename > to install_cab_file. > > So I coded it, but the non-UNIX path is untested. > <snip> > Wonder why he does not send a patch himself. Heh maybe his Julliard ranking is not high enough. ;) > + } else { /* ReactOS mode. */ Maybe this should say Windows mode or Mingw mode. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Feb. 4, 2009

Re: bugzilla stuck?

by Austin English

On Wed, Feb 4, 2009 at 11:36 AM, Dan Kegel <dank(a)kegel.com> wrote: > It seems hung to me at the moment... > > > Back up now. -- -Austin

Feb. 4, 2009

Re: bugzilla stuck?

by Jeremy Newman

Bugzilla is freaking out quite a bit lately. I think this is due to how much busier Bugzilla and the AppDB has become. It will usually clear up on it's own, but it takes 5 to 10 minutes. It is pretty clear that the current box can no longer handle the load. Dan Kegel wrote: > It seems hung to me at the moment... > >

Feb. 4, 2009

Re: messagemode named pipes investigation: blocking-reads block writers indefinitely

by Luke Kenneth Casson Leighton

> main process: blocking-read on namedpipe. > 5 threads: write to same named pipe > > the writes NEVER return (this is with xp). > > so that WOULD indicate that there IS a per-pipe mutex (and that there > are bugs in nt!) unbelievable. turns out it's an msvcrt bug (in windows nt). if you use _beginthread() to create the 5 threads (or even just the one), the reader can block the writer(s). however if you use CreateThread(), everything's hunky-dory. anyone want to record _that_ one as a future interoperability bug-test, be my guest! ha ha :) no, but seriously: if someone tells me it's a worthwhile thing to have as an interoperability test, i'll write one. l.

Feb. 4, 2009

bugzilla stuck?

by Dan Kegel

It seems hung to me at the moment...

Feb. 4, 2009

messagemode named pipes investigation: blocking-reads block writers indefinitely

by Luke Kenneth Casson Leighton

fascinatingly strange observation came out of writing the latest test (threadwrites) to do namedpipe interoperability testing. main process: blocking-read on namedpipe. 5 threads: write to same named pipe the writes NEVER return (this is with xp). so that WOULD indicate that there IS a per-pipe mutex (and that there are bugs in nt!) l.

Feb. 4, 2009

IPinImpl_QueryInternalConnections() is unused

by Francois Gouget

dlls/qcap/pin.c defines an IPinImpl_QueryInternalConnections() function but it is not actually used anywhere. Is there any reason to keep it? It sort of looks like IPin is a virtual class and that IPin::QueryInternalConnections() is going to be implemented in its descendents like VfwPin as is currently the case. But then VfwPin_QueryInternalConnections() is just as much of a stub so maybe it is it that should go away? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ A polar bear is a cartesian bear after a coordinate transform.

Feb. 4, 2009

Re: X11DRV_XRandR_Cleanup() is not used

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > So my question is: should this function be removed? Or should I simply > send a patch calling it from x11drv_main.c:process_detach(), enclosed > with the appropriate SONAME_LIBXRANDR? You can remove it, it doesn't do anything useful. -- Alexandre Julliard julliard(a)winehq.org

Feb. 4, 2009