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

Re: Stub DDE interface for Progman.exe
by Dmitry Timoshkov Feb. 6, 2009

Feb. 6, 2009

"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. -- Dmitry.

5 12

re: New Wine Gecko package
by Dan Kegel Feb. 6, 2009

Feb. 6, 2009

James Mckenzie wrote: > It depends on the timeline for the 1.2 release. > If this is a long way off, it may be worth the effort. I don't know. The 1.1 branch has are lots of improvements people want; what's so special about Gecko? IMHO we should leave the 1.0 branch alone, and just get on with 1.2. Speaking of which, I wonder which of Alexandre's 1.2 wish list features will be done first? http://wiki.winehq.org/WineReleasePlan Win64 is looking like the front runner at the moment, but there were some USB patches recently, maybe that will come from behind.

3 2

[Fwd: WINE: suspected bug in change to winealsa.drv/waveout.c]
by Deomid Ryabkov Feb. 6, 2009

Feb. 6, 2009

Maarten didn't reply, widening to wine-devel@ summary: looks like a bug was introduced into WaveOut queue management back in october that causes sound to skip and stutter. -------- Original Message -------- Subject: WINE: suspected bug in change to winealsa.drv/waveout.c Date: Sun, 25 Jan 2009 03:46:09 +0000 From: Deomid Ryabkov <myself(a)rojer.pp.ru> To: m.b.lankhorst(a)gmail.com hi, Maarten. i'm a complete noob in WINE, this is the first time i delved in the source, so please bear with me if i'm wrong, but i believe i traced a specific problem i've been having with sound in Heroes of Might and Magic III to a change you made couple months ago to the ALSA waveout driver. the regression manifests itself as rather annoying audio skipping and stuttering. having spent some time tracing and looking at the code, i believe that the problem was introduced by this change to dlls/winealsa.drv/waveout.c made on Oct 4: http://source.winehq.org/git/wine.git/?a=commitdiff;h=717df5b2972b3cb998ca5… specifically, this line + wwo->dwPlayedTotal += lpWaveHdr->reserved - wwo->dwPlayedTotal; advances the dwPlayedTotal watermark when i believe it shouldn't. fundamentally, only DSP can report how much has been played, updating this pointer after reporting that a sample has been played makes no sense. DSP has reported that it has played up to a certain point that covers the sample in question, we are reporting this back and removing the sample. we should *not* be changing the value DSP sent us. i don't know what was the specific issue you were addressing with the patch in question, but i'd like you to take one more look at it, because removing this one line fixes skipping and stuttering for me. if you need any more information, please feel free to ask. -- Deomid Ryabkov aka Rojer myself(a)rojer.pp.ru rojer(a)sysadmins.ru ICQ: 8025844 -- Deomid Ryabkov aka Rojer myself(a)rojer.pp.ru rojer(a)sysadmins.ru ICQ: 8025844

1 0

http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/smbsrv/ndl/
by Luke Kenneth Casson Leighton Feb. 6, 2009

Feb. 6, 2009

holy cow. opensolaris appears to have its own smb server / idl compiler: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/tools/ndrgen/ CDDL licensed, unfortunately (listed as incompatible with GPL. darn). but... dang :)

1 0

http://wiki.winehq.org/NamedPipes
by Luke Kenneth Casson Leighton Feb. 6, 2009

Feb. 6, 2009

rob, hi, regarding the above wiki page - there is no "obstacle". you can use any of the code that i wrote for samba (about 100,000 lines of code), i released all of it into the public domain, on dec 16th, 2005. there's enough there so that you can do an entirely "hands off" approach, getting packets in and out using (see last post!) surprise,surprise, emulated named pipes. what i did for tng was to create a "packaging" system which sent security contexts (complete security descriptors and other identifiying information) over a unix socket. it was completely transparent as far as smbd was concerned, which just "handed it around" to the appropriate daemons. i asked jeremy to add in simple support for this into main samba several times. the last time (dec 2005) once _again_ he fucked about, but did actually agree that it was a good idea. samba having "break-out" for named pipes traffic is one of those absolutely _essential_ things that should have fucking well gone into the samba source code a _long_ time ago. around 1998 would have been good. _several_ projects would enormously benefitted - including samba - if that had happened. sun microsystems, who bought the [well known to be a complete piece-of-crap] port of nt to unix, AFPS, for $USD 4m and were utterly appalled by the poor quality of the implementation of the smb server gave serious consideration to dumping it, keeping the MSRPC services, and riding off the back of samba.... .. via _guess what_! a named pipe "break-out" interface. which, of course, doesn't exist. so they couldn't do it. but gordon did discuss it with me, saying things like, "y'know, if samba had a way in to its named pipes interface..." and guess what? in order for you to do named pipes via samba, you need a named pipe "break-out" interface. guess how luke howard implemented XAD (which he sold to novell a couple of years ago)? he implemented a patch to samba which provided a named pipe "break-out" interface. that patch was released back in about 2002 and has never been incorporated into samba. the protocol for a break-out interface is very simple: you need four functions ( and they can be done in as little as about 300 lines of c-code, as a patch to samba) 1) open named pipe connection 2) read pipe 3) write pipe 4) close pipe if you implement that in a dynamically-loadable .so, style, as a vector table (see e.g. apache2 module interface for example) then you can dump a .so into a directory which samba can pick up. any data that comes in from SMB will then "activate" the .so, call the open_named_pipe function in the vector table, and you're away. you release the code of the .so under the LGPL, that gets "GPL'd" by samba, license problem is solved. so, with a small patch to samba, the means to take control of the direction of wine is within _your_ hands. because the dynamically loadable .so conforms to the "break-out" interface and is loaded _by_ samba, on demand, and the code in it is part of Wine and communicates using Wine protocols - entirely under your control. ... you know... it would actually be a lot easier to integrate wine with samba tng, because the infrastructure to communicate by emulated NamedPipes already exists. take a look at the following functions: ncalrpc_l_connect ncalrpc_l_close_socket receive_msrpc msrpc_send all of which are in lib/msrpc-client.c - you'll see in there that there are corresponding functions for the samba tng win32 port - CreateNamedPipe, ReadFile, WriteFile, WaitNamedPipeHandleState, CloseHandle etc. which will help give you some _really_ big clue-handles to understand the corresponding "emulating" functions using unix sockets. you _should_ also recognise the ncalrpc_srv_get_user_creds function and its equivalent client-side "sender" ncalrpc_l_authenticate. these two are a matched pair of functions which marshal and unmarshal an NT security context [based on a NET_USER_INFO_3 structure - recognise that one? :) it's a stub in wine - now you have some code that gives it purpose! ] basically after a connect (ncalrpc_l_connect) the client sends the user creds _immediately_, and the server picks them up, and saves them in its internal context (for later passing around etc). also they end up getting used to do seteuid() but as the entire protocol was used by root _only_ it was perfect safe to do this. the unix sockets were protected 600 with the directory they were in being protected 755 because some unixen _still_ bloody well let you access a unix domain socket even if its permissions were 600, all owned by root, all services running _as_ root, so one daemon being a client passing over a security context that told _another_ daemon running as root to seteuid to a user's uid was no big hairy deal. except that andrew thought that i was some sort of fucking 17-year-old incompetent student, and he didn't like the thought of me actually being a capable unix systems programmer. thus, this code could be justified as never going into samba (even though a similar implementation was designed _by_ him for use in winbind). _really_ interesting bit of hypocrisy going on there. the sad thing is that it's stopped _so_ much progress in free software, it's unreal. anyway - you can pick up that code with: cvs -d anoncvs(a)anoncvs.samba-tng.org:/home/cvsroot co tng it's anoncvs - just press return look in tng/source/lib/msrpc-client.c btw don't be fooled into thinking that just because you're on loopback - running samba and wine on the same machine and only processing requests that come in or go out over 127.0.0.1 - don't be fooled into thinking that you can throw away the security context (the NET_USER_INFO_3 stuff) - you can't. you _really_ need to keep it around, and pass it back-and-forth. so - to recap what the protocol / procedure is: * a small .so has already been dropped into samba's lib/ directory which has been dynamically-loaded; any SMB-based "NamedPipe" traffic that is NOT destined for internal samba services (such as \\PIPE\lsarpc etc) is handed to this .so. the .so, when an incoming "ConnectNamedPipe" request is made, will direct the contents, pretty much verbatim BUT pre-pending the security context "blob" (see above) to any initial connects. * any win32 programs that call CreateNamedPipe will result in a call .. ... you know what? this is getting complex - and i'm spending quite a bit of time writing it. i designed this stuff, once, and it worked. wine needs it. samba needs it. so, i'm really _really_ sorry to have to bring this up - but it's a quite important point: if you can find someone to pay for the necessary development, i'm more than happy to do the work. i'm also happy to help advise people on how this can be implemented (if the above clues and directional guides aren't enough) it's been ten years since this kind of cross-project integration stalled: i've watched the development of wine go its way, and samba go its way, and ntfs filesystem drivers for linux go _their_ way, and all of these projects don't _actually_ cooperate or link together properly. nobody's actually _paid_ any fucking money to coordinate and liase with these projects. there's people paid to work on linux; there's people paid to work on wine; there's people paid to work on samba. and the only people who really suffer for lack of this really important strategic interoperability is: users. so can we _please_ pull our collective fingers out of our arses, get some sponsorship and funding from _somewhere_ and get moving? that last said with the utmost of respect :) l.

2 5

Re: [patch] rpcrt4_conn_np_read needs to expect and accept ERROR_MORE_DATA
by Juan Lang Feb. 6, 2009

Feb. 6, 2009

Hi Luke, @@ -382,7 +382,14 @@ static int rpcrt4_conn_np_read(RpcConnection *Connection, { DWORD bytes_read; ret = ReadFile(npc->pipe, buf, bytes_left, &bytes_read, NULL); - if (!ret || !bytes_read) + if (!ret) + { + TRACE("ReadFile error, status %x\n", GetLastError()); + if (GetLastError() != ERROR_MORE_DATA) + break; + ret = TRUE; /* ERROR_MORE_DATA is an expected acceptable error code */ + } + if (!bytes_read) break; Style nit: it would be simpler to do: DWORD bytes_read; ret = ReadFile(npc->pipe, buf, bytes_left, &bytes_read, NULL); + if (!ret && GetLastError() == ERROR_MORE_DATA) + ret = TRUE; if (!ret || !bytes_read) break; Don't you think? --Juan

2 1

Re: Use environment variable WINE_NO_MENU_ENTRIES to prevent menu icon and menu entry creation.
by Detlef Riekenberg Feb. 6, 2009

Feb. 6, 2009

On Do, 2009-02-05 at 18:02 +0100, Christoph Korn wrote: > int PASCAL WinMain (HINSTANCE hInstance, HINSTANCE prev, LPSTR > cmdline, int show) > { > + if(getenv("WINE_NO_MENU_ENTRIES")) > + { > + return 0; > + } > + > LPSTR token = NULL, p; Declaring a variable after code is C99 and not allowed in Wine. -- By by ... Detlef

2 1

Re: widl: initialize _RetVal to avoid compiler warnings
by Rob Shearman Feb. 6, 2009

Feb. 6, 2009

2009/2/5 Christoph von Wittich <Christoph(a)apiviewer.de>: > --- a/tools/widl/proxy.c > +++ b/tools/widl/proxy.c > @@ -327,7 +327,12 @@ static void gen_proxy(type_t *iface, const var_t > *func, int idx, > if (has_ret) { > print_proxy( "" ); > write_type_decl_left(proxy, type_function_get_rettype(func->type)); > - print_proxy( " _RetVal;\n"); > + > + /* Initialize _RetVal properly in order to avoid compiler warnings */ > + if (is_ptr(type_function_get_rettype(func->type)) || > is_array(type_function_get_rettype(func->type))) > + print_proxy(" _RetVal = NULL;\n"); > + else > + print_proxy(" _RetVal = 0;\n"); > } > print_proxy( "RPC_MESSAGE _RpcMessage;\n" ); > if (has_ret) { I think this is just hiding the problem. Can you give an example of IDL which causes widl to generate code that causes compiler warnings? -- Rob Shearman

1 0

Re: rpcrt4: Check for null endpoint in RpcServerUseProtseqEpExW
by Rob Shearman Feb. 6, 2009

Feb. 6, 2009

2009/2/5 Nikolay Sivov <bunglehead(a)gmail.com>: > Changelog: > - Check for null endpoint in RpcServerUseProtseqEpExW. > Installed IE8 RC1 crashes on this call, parameter set is specified in > test case. > > >From 89f889b2c7a754302b599884577b4eba22b3d235 Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <bunglehead(a)gmail.com> > Date: Thu, 5 Feb 2009 22:03:48 +0300 > Subject: Check for null endpoint in RpcServerUseProtseqEpExW > > --- > dlls/rpcrt4/rpc_server.c | 6 ++++-- > dlls/rpcrt4/tests/rpc.c | 15 +++++++++++++++ > 2 files changed, 19 insertions(+), 2 deletions(-) > > diff --git a/dlls/rpcrt4/rpc_server.c b/dlls/rpcrt4/rpc_server.c > index b6e058a..e9bed42 100644 > --- a/dlls/rpcrt4/rpc_server.c > +++ b/dlls/rpcrt4/rpc_server.c > @@ -775,8 +775,10 @@ RPC_STATUS WINAPI RpcServerUseProtseqEpExW( RPC_WSTR Protseq, UINT MaxCalls, RPC > return status; > > EndpointA = RPCRT4_strdupWtoA(Endpoint); > - status = RPCRT4_use_protseq(ps, EndpointA); > - RPCRT4_strfree(EndpointA); > + if (EndpointA) { > + status = RPCRT4_use_protseq(ps, EndpointA); > + RPCRT4_strfree(EndpointA); > + } This isn't correct, I'm afraid. The protseq open function should generate an endpoint name to use. For example, the ncacn_ip_tcp code should select a random available TCP port. > return status; > } > > diff --git a/dlls/rpcrt4/tests/rpc.c b/dlls/rpcrt4/tests/rpc.c > index bf538e4..b815acc 100644 > --- a/dlls/rpcrt4/tests/rpc.c > +++ b/dlls/rpcrt4/tests/rpc.c > @@ -830,6 +830,20 @@ static void test_UuidCreate(void) > } > } > > +static void test_RpcServerUseProtseqEpEx(void) > +{ > + RPC_STATUS status; > + RPC_POLICY policy; > + static WCHAR protW[] = {'n','c','a','l','r','p','c',0}; > + > + policy.Length = sizeof( policy ); > + policy.EndpointFlags = 0; > + policy.NICFlags = 0; > + > + status = RpcServerUseProtseqEpExW(protW, 10, NULL, NULL, &policy); > + ok(status == RPC_S_OK, "Expected RPC_S_OK, got %d\n", status); > +} This is a good start, but you should also test the bindings created as a result of doing this and then you will probably discover that the fix to RpcServerUseProtseqEpExW isn't quite correct. > START_TEST( rpc ) > { > static unsigned char ncacn_np[] = "ncacn_np"; > @@ -849,4 +863,5 @@ START_TEST( rpc ) > test_endpoint_mapper(ncalrpc, NULL, lrpc_endpoint); > test_RpcStringBindingFromBinding(); > test_UuidCreate(); > + test_RpcServerUseProtseqEpEx(); > } -- Rob Shearman

2 2

DIB Engine - Patchset separated by original author
by Massimo Del Fedele Feb. 6, 2009

Feb. 6, 2009

As asked to me, I have separated the dib engine into a patchset, trying to keep (when possible) the original author's submissions, so Huw Davies, Jesse Allen and me. I had to change some of other author's commits in order to fit my engine and to rebase it on 1.1.14, so I ask both previous authors to check if they agree on the patches. I hope this will help the review, as keeping it rebased on wine tree will become quite hard having it as a separated patchset. Attached here is a zipped patchset, which apply on wine 1.1.14. Ciao Max

4 4

re: gdiplus: Some tests for GdipGetLineRect
by Dan Kegel Feb. 6, 2009

Feb. 6, 2009

Nikolay Sivov <bunglehead at gmail.com> wrote: > ... > + ok(rectf.X == 10.0, "Expected 10.0 got %.2f\n", rectf.X); Exact equality comparison on float is never a good idea in unit tests. You need a range test instead. See http://code.google.com/p/googletest/wiki/GoogleTestAdvancedGuide#Floating-P…

1 0

Re: widl: filter_func isn't used when USE_COMPILER_EXCEPTIONS is defined
by Rob Shearman Feb. 6, 2009

Feb. 6, 2009

2009/2/6 Christoph von Wittich <Christoph(a)apiviewer.de>: > diff --git a/tools/widl/proxy.c b/tools/widl/proxy.c > index 0dcb737..88c0e53 100644 > --- a/tools/widl/proxy.c > +++ b/tools/widl/proxy.c > @@ -122,10 +122,12 @@ static void init_proxy(const statement_list_t *stmts) > print_proxy( " void *This;\n"); > print_proxy( "};\n"); > print_proxy( "\n"); > + print_proxy("#ifndef USE_COMPILER_EXCEPTIONS\n"); > print_proxy("static int __proxy_filter( struct __proxy_frame *__frame > )\n"); > print_proxy( "{\n"); > print_proxy( " return (__frame->_StubMsg.dwStubPhase != > PROXY_SENDRECEIVE);\n"); > print_proxy( "}\n"); > + print_proxy("#endif /* USE_COMPILER_EXCEPTIONS */\n"); > print_proxy( "\n"); > } I think a better solution to this would be to use proxy_filter as the expression in the RpcExcept statements. Alexandre, what do you think? -- Rob Shearman

2 1

[patch] rpcrt4_conn_np_read needs to expect and accept ERROR_MORE_DATA
by Luke Kenneth Casson Leighton Feb. 6, 2009

Feb. 6, 2009

http://bugs.winehq.org/show_bug.cgi?id=17263 hooray! very simple fix, here - allow ERROR_MORE_DATA status code as an acceptable error. ... and _check it_, afterwards. ideally, the loop to read a complete PDU should be vaguely like this: do { RpcConnection conn->ops->read(data, &len) total_read += len; if GetLastError() == ERROR_MORE_DATA if total_read == total_packet_size return FALSE; /* not ok to return ERROR_MORE_DATA at end of PDU! } while (total_read != total_packet_size); i.e. you should _expect_ there to be an ERROR_MORE_DATA status code on all but the _very_ last bit of the PDU. but, you can't do that in rpcrt4_conn_np_read() because that function is just a "data getter", it doesn't know when it's being used to grab the last bit of the PDU. this will prove to be important for catching problems, both internally and also when SMBs are used. _yes_ the SMB system also returns ERROR_MORE_DATA. actually, if NT STATUS codes are enabled, it's STATUS_MORE_PROCESSING_REQUIRED which _do_ go over-the-wire if the smb server negotiates their use, but that's another story. l.

2 2

wine iexplore speed test (JavaScript)
by Detlef Riekenberg Feb. 6, 2009

Feb. 6, 2009

I did a speed test for JS with Wine: ######################## http://v8.googlecode.com/svn/data/benchmarks/v3/run.html wine 17666004c839a40f1dbc5c98468557091bf3e13c Score: 48.5 Richards: 47.7 DeltaBlue: 56.3 Crypto: 32.1 RayTrace: 54.9 EarleyBoyer: 65.9 RegExp: 41.9 Same System, with Firefox 3.0.5: Score: 60.4 Richards: 65.8 DeltaBlue: 76.7 Crypto: 45.1 RayTrace: 53.7 EarleyBoyer: 96.5 RegExp: 41.2 Is there a way to use our jscript.dll instead of js3250.dll? Or a way to use js3250.dll in our jscript.dll? ################################### SunSpider does not show the results. http://www2.webkit.org/perf/sunspider-0.9/sunspider-driver.html I filled http://bugs.winehq.org/show_bug.cgi?id=17264 for that. -- By by ... Detlef

2 2

IPinImpl_QueryInternalConnections() is unused
by Francois Gouget Feb. 6, 2009

Feb. 6, 2009

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.

2 1

Re: New Wine Gecko package
by James Mckenzie Feb. 5, 2009

Feb. 5, 2009

Jacek Caban <jacek(a)codeweavers.com> wrote: >Sent: Feb 5, 2009 12:28 PM >To: James Mckenzie <jjmckenzie51(a)earthlink.net> >Cc: Scott Ritchie <scott(a)open-vote.org>, wine-devel <wine-devel(a)winehq.org> >Subject: Re: New Wine Gecko package > >James Mckenzie wrote: >> Jacek Caban <jacek(a)codeweavers.com> wrote: >> >>> Scott Ritchie wrote: >>> >>>> Is this version compatible with Wine 1.0.1 by chance? >>>> >>>> >>> No, it's technically impossible. >>> >>> >> Is it possible to build a patch upgrade to 1.0.1 to incorporate the new Gecko or will we have to wait until 1.2 (that is the next stable release)? >> > >No, it would require too much risky changes. The fact that we need a >bugfix release proves that it's a bad idea. This is your opinion and I respect it as you have more experience with Gecko than I. > >Also I don't see any point in upgrading Gecko in 1.0 branch. > It depends on the timeline for the 1.2 release. If this is a long way off, it may be worth the effort. If it is a matter of months, then the effort would not be worth it, since this would be a major project. James McKenzie

1 0

Re: [PATCH] mshtml: Fixed last argument to MBtoWC
by Rob Shearman Feb. 5, 2009

Feb. 5, 2009

2009/2/4 Marcus Meissner <marcus(a)jet.franken.de>: > @@ -442,7 +442,7 @@ static LPWSTR get_url(void) > > if(size > sizeof(httpW) && !memcmp(url, httpW, sizeof(httpW))) { > strcatW(url, v_formatW); > - MultiByteToWideChar(CP_ACP, 0, GECKO_VERSION, -1, url+strlenW(url), -1); > + MultiByteToWideChar(CP_ACP, 0, GECKO_VERSION, -1, url+strlenW(url), (size-strlenW(url))/sizeof(WCHAR)); Dividing a string length (which returns character count) by sizeof(WCHAR) doesn't look right. -- Rob Shearman

2 1

ideas and questions for implementation of MessageMode in Named Pipes
by Luke Kenneth Casson Leighton Feb. 5, 2009

Feb. 5, 2009

ok, alexandre: i tried moving named_pipe_read into wineserver - it's not possible to do completely, as you cannot do blocking-reads in wineserver but you still need blocking-read characteristics in the client (kernel32, ntdll). if you start messing with the fd, setting or clearing ioctl O_NONBLOCK in one, it interferes with the other. there's a race-condition risk. so, i have some ideas and questions. 1) is it possible for wineserver to tell a thread to wait indefinitely? is there a communication channel where wineserver can tell "anyone who's interested" to go away, go to sleep, i'll tell you when to wake up"? what i want is to replace the fd blocking-read with something that still blocks, but doesn't interfere with the file descriptor. 2) would a _second_ filedescriptor fit the required criteria, as described in 1), above? in other words, if the message-lengths (4 bytes) were sent on a secondary control fd - and nothing _but_ message-lengths were sent on that fd - my intuition tells me that that could work, even without having any infrastructure in wineserver. in fact, i get the feeling that it would be _better_ - and a lot simpler - than having any infrastructure in wineserver. the reasoning goes roughly something like this: * 5 threads are waiting - blocking - on a message-mode read named pipe. all of them are blocking to read from the "control" channel, in userspace (kernel32/ntdll). * client 1 does a message-mode write, and in userspace (kernel32/ntdll) 4 bytes indicating the length of the message are sent, followed by N bytes on the unix_fd (exactly as is done at the moment). * one and ONLY one of the 5 threads, thanks to STANDARD linux kernel scheduling, happens to be awake and gets to read the 4-byte length. all the other 4 stay asleep. damnit, that's not right, is it. you want the other 4 to wake up once ONE of them has read the 4-byte length, and for ALL of them to move on to blocking on the "message" pipe - the actual content. so, i suppose what you could do is have a per-read-thread filedescriptor (!!!) which _would_ have to involve arbitration by wineserver, so that when a write is performed, ALL of the clients get notified "wake up now, start trying to read". is there _anything_ in wine which already exists that does what is required, as illustrated, above? answers and information greatly appreciated so as to be able to improve this free software project's effectiveness. l.

2 7

Re: New Wine Gecko package
by James Mckenzie Feb. 5, 2009

Feb. 5, 2009

Jacek Caban <jacek(a)codeweavers.com> wrote: > >Scott Ritchie wrote: >> Jacek Caban wrote: >> >>> Hi all, >>> >>> The last release of Wine Gecko caused a few regressions. Thanks to >>> Alexandre, we've found the reason. The bad news is that the fix requires >>> a new package. I've uploaded RC build to: >>> >>> http://gerwazy.lo3.wroc.pl/~jcaban/wine/wine_gecko-0.9.1.cab >>> >>> I'd appreciate if people that observe the regression (mostly strange >>> crashed) could retest bugs with this build. To do so, you will need the >>> new package and the attached patch. Also quick tests with random apps >>> would be nice. This is a bugfix release based on the same codebase as >>> 0.9.0 version so I don't expect any new regressions with it. >>> >>> >> >> Is this version compatible with Wine 1.0.1 by chance? >> > >No, it's technically impossible. > Is it possible to build a patch upgrade to 1.0.1 to incorporate the new Gecko or will we have to wait until 1.2 (that is the next stable release)? James McKenzie

2 1

bugzilla stuck?
by Dan Kegel Feb. 5, 2009

Feb. 5, 2009

It seems hung to me at the moment...

3 3

Re: [PATCH] advapi32: fixed second buffer argument to MBtoWC and WCtoMB
by Alexandre Julliard Feb. 5, 2009

Feb. 5, 2009

Marcus Meissner <marcus(a)jet.franken.de> writes: > diff --git a/dlls/advapi32/cred.c b/dlls/advapi32/cred.c > index 9ad4fb1..ab86ed6 100644 > --- a/dlls/advapi32/cred.c > +++ b/dlls/advapi32/cred.c > @@ -940,7 +940,8 @@ static void convert_PCREDENTIALW_to_PCREDENTIALA(const CREDENTIALW *CredentialW, > if (CredentialW->TargetName) > { > CredentialA->TargetName = buffer; > - string_len = WideCharToMultiByte(CP_ACP, 0, CredentialW->TargetName, -1, CredentialA->TargetName, -1, NULL, NULL); > + string_len = WideCharToMultiByte(CP_ACP, 0, CredentialW->TargetName, -1, NULL, 0, NULL, NULL); > + WideCharToMultiByte(CP_ACP, 0, CredentialW->TargetName, -1, CredentialA->TargetName, string_len, NULL, NULL); It doesn't make sense to use the output size as buffer size. You need to pass the real size of the buffer. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [RESEND] comctl32: Save and restore colours when adding masked images
by Alexandre Julliard Feb. 5, 2009

Feb. 5, 2009

Peter Urbanec <winehq.org(a)urbanec.net> writes: > This patch will save and restore the colours when adding a masked image > to ImageList. What's the point of restoring the colors in a DC that gets deleted right away? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: avifil32: ukranian translation by Artem Reznikov
by Alexandre Julliard Feb. 5, 2009

Feb. 5, 2009

Christoph von Wittich <Christoph(a)ApiViewer.de> writes: > dlls/avifil32/avifile_Uk.rc | 51 > +++++++++++++++++++++++++++++++++++++++++++ > dlls/avifil32/rsrc.rc | 1 + > 2 files changed, 52 insertions(+), 0 deletions(-) Please add a From: line with the full name and email of the original author (or better ask him to submit the patch himself). And please fix your mail setup, all your patches are wrapped. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: kernel32: DeviceIoControl: lpBytesReturned must not be NULL if lpOverlapped is NULL
by Nikolay Sivov Feb. 5, 2009

Feb. 5, 2009

Christoph von Wittich wrote: > dlls/kernel32/comm.c | 55 > +++++++++++++++++++++++++++++++------------------ > 1 files changed, 35 insertions(+), 20 deletions(-) > > diff --git a/dlls/kernel32/comm.c b/dlls/kernel32/comm.c > index d83eacb..11cfda0 100644 > --- a/dlls/kernel32/comm.c > +++ b/dlls/kernel32/comm.c > @@ -551,7 +551,8 @@ BOOL WINAPI BuildCommDCBW( > */ > BOOL WINAPI SetCommBreak(HANDLE handle) > { > - return DeviceIoControl(handle, IOCTL_SERIAL_SET_BREAK_ON, NULL, 0, > NULL, 0, NULL, NULL); > + DWORD dwBytesReturned; > + return DeviceIoControl(handle, IOCTL_SERIAL_SET_BREAK_ON, NULL, 0, > NULL, 0, &dwBytesReturned, NULL); > } > > /***************************************************************************** > @@ -573,7 +574,8 @@ BOOL WINAPI SetCommBreak(HANDLE handle) > */ > BOOL WINAPI ClearCommBreak(HANDLE handle) > { > - return DeviceIoControl(handle, IOCTL_SERIAL_SET_BREAK_OFF, NULL, 0, > NULL, 0, NULL, NULL); > + DWORD dwBytesReturned; > + return DeviceIoControl(handle, IOCTL_SERIAL_SET_BREAK_OFF, NULL, 0, > NULL, 0, &dwBytesReturned, NULL); > } > > /***************************************************************************** > @@ -595,6 +597,7 @@ BOOL WINAPI ClearCommBreak(HANDLE handle) > BOOL WINAPI EscapeCommFunction(HANDLE handle, UINT func) > { > DWORD ioc; > + DWORD dwBytesReturned; > > switch (func) > { > @@ -612,7 +615,7 @@ BOOL WINAPI EscapeCommFunction(HANDLE handle, UINT func) > SetLastError(ERROR_INVALID_PARAMETER); > return FALSE; > } > - return DeviceIoControl(handle, ioc, NULL, 0, NULL, 0, NULL, NULL); > + return DeviceIoControl(handle, ioc, NULL, 0, NULL, 0, > &dwBytesReturned, NULL); > } > > /******************************************************************** > @@ -632,8 +635,9 @@ BOOL WINAPI EscapeCommFunction(HANDLE handle, UINT func) > */ > BOOL WINAPI PurgeComm(HANDLE handle, DWORD flags) > { > + DWORD dwBytesReturned; > return DeviceIoControl(handle, IOCTL_SERIAL_PURGE, &flags, > sizeof(flags), > - NULL, 0, NULL, NULL); > + NULL, 0, &dwBytesReturned, NULL); > } > > /***************************************************************************** > @@ -654,9 +658,10 @@ BOOL WINAPI PurgeComm(HANDLE handle, DWORD flags) > BOOL WINAPI ClearCommError(HANDLE handle, LPDWORD errors, LPCOMSTAT lpStat) > { > SERIAL_STATUS ss; > + DWORD dwBytesReturned; > > if (!DeviceIoControl(handle, IOCTL_SERIAL_GET_COMMSTATUS, NULL, 0, > - &ss, sizeof(ss), NULL, NULL)) > + &ss, sizeof(ss), &dwBytesReturned, NULL)) > return FALSE; > > if (errors) > @@ -708,11 +713,12 @@ BOOL WINAPI ClearCommError(HANDLE handle, LPDWORD > errors, LPCOMSTAT lpStat) > BOOL WINAPI SetupComm(HANDLE handle, DWORD insize, DWORD outsize) > { > SERIAL_QUEUE_SIZE sqs; > + DWORD dwBytesReturned; > > sqs.InSize = insize; > sqs.OutSize = outsize; > return DeviceIoControl(handle, IOCTL_SERIAL_SET_QUEUE_SIZE, > - &sqs, sizeof(sqs), NULL, 0, NULL, NULL); > + &sqs, sizeof(sqs), NULL, 0, > &dwBytesReturned, NULL); > } > > /***************************************************************************** > @@ -732,9 +738,10 @@ BOOL WINAPI SetupComm(HANDLE handle, DWORD insize, > DWORD outsize) > */ > BOOL WINAPI GetCommMask(HANDLE handle, LPDWORD evtmask) > { > + DWORD dwBytesReturned; > TRACE("handle %p, mask %p\n", handle, evtmask); > return DeviceIoControl(handle, IOCTL_SERIAL_GET_WAIT_MASK, > - NULL, 0, evtmask, sizeof(*evtmask), NULL, NULL); > + NULL, 0, evtmask, sizeof(*evtmask), > &dwBytesReturned, NULL); > } > > /***************************************************************************** > @@ -755,9 +762,11 @@ BOOL WINAPI GetCommMask(HANDLE handle, LPDWORD evtmask) > */ > BOOL WINAPI SetCommMask(HANDLE handle, DWORD evtmask) > { > + DWORD dwBytesReturned; > + > TRACE("handle %p, mask %x\n", handle, evtmask); > return DeviceIoControl(handle, IOCTL_SERIAL_SET_WAIT_MASK, > - &evtmask, sizeof(evtmask), NULL, 0, NULL, NULL); > + &evtmask, sizeof(evtmask), NULL, 0, > &dwBytesReturned, NULL); > } > > static void dump_dcb(const DCB* lpdcb) > @@ -797,6 +806,7 @@ BOOL WINAPI SetCommState( HANDLE handle, LPDCB lpdcb) > SERIAL_LINE_CONTROL slc; > SERIAL_HANDFLOW shf; > SERIAL_CHARS sc; > + DWORD dwBytesReturned; > > if (lpdcb == NULL) > { > @@ -858,13 +868,13 @@ BOOL WINAPI SetCommState( HANDLE handle, LPDCB lpdcb) > * so flow control does not interfere. > */ > return (DeviceIoControl(handle, IOCTL_SERIAL_SET_BAUD_RATE, > - &sbr, sizeof(sbr), NULL, 0, NULL, NULL) && > + &sbr, sizeof(sbr), NULL, 0, > &dwBytesReturned, NULL) && > DeviceIoControl(handle, IOCTL_SERIAL_SET_LINE_CONTROL, > - &slc, sizeof(slc), NULL, 0, NULL, NULL) && > + &slc, sizeof(slc), NULL, 0, > &dwBytesReturned, NULL) && > DeviceIoControl(handle, IOCTL_SERIAL_SET_HANDFLOW, > - &shf, sizeof(shf), NULL, 0, NULL, NULL) && > + &shf, sizeof(shf), NULL, 0, > &dwBytesReturned, NULL) && > DeviceIoControl(handle, IOCTL_SERIAL_SET_CHARS, > - &sc, sizeof(sc), NULL, 0, NULL, NULL)); > + &sc, sizeof(sc), NULL, 0, &dwBytesReturned, > NULL)); > } > > > @@ -891,6 +901,7 @@ BOOL WINAPI GetCommState(HANDLE handle, LPDCB lpdcb) > SERIAL_LINE_CONTROL slc; > SERIAL_HANDFLOW shf; > SERIAL_CHARS sc; > + DWORD dwBytesReturned; > > TRACE("handle %p, ptr %p\n", handle, lpdcb); > > @@ -901,13 +912,13 @@ BOOL WINAPI GetCommState(HANDLE handle, LPDCB lpdcb) > } > > if (!DeviceIoControl(handle, IOCTL_SERIAL_GET_BAUD_RATE, > - NULL, 0, &sbr, sizeof(sbr), NULL, NULL) || > + NULL, 0, &sbr, sizeof(sbr), &dwBytesReturned, > NULL) || > !DeviceIoControl(handle, IOCTL_SERIAL_GET_LINE_CONTROL, > - NULL, 0, &slc, sizeof(slc), NULL, NULL) || > + NULL, 0, &slc, sizeof(slc), &dwBytesReturned, > NULL) || > !DeviceIoControl(handle, IOCTL_SERIAL_GET_HANDFLOW, > - NULL, 0, &shf, sizeof(shf), NULL, NULL) || > + NULL, 0, &shf, sizeof(shf), &dwBytesReturned, > NULL) || > !DeviceIoControl(handle, IOCTL_SERIAL_GET_CHARS, > - NULL, 0, &sc, sizeof(sc), NULL, NULL)) > + NULL, 0, &sc, sizeof(sc), &dwBytesReturned, NULL)) > return FALSE; > > memset(lpdcb, 0, sizeof(*lpdcb)); > @@ -980,8 +991,9 @@ BOOL WINAPI GetCommState(HANDLE handle, LPDCB lpdcb) > */ > BOOL WINAPI TransmitCommChar(HANDLE hComm, CHAR chTransmit) > { > + DWORD dwBytesReturned; > return DeviceIoControl(hComm, IOCTL_SERIAL_IMMEDIATE_CHAR, > - &chTransmit, sizeof(chTransmit), NULL, 0, > NULL, NULL); > + &chTransmit, sizeof(chTransmit), NULL, 0, > &dwBytesReturned, NULL); > } > > > @@ -1002,6 +1014,7 @@ BOOL WINAPI TransmitCommChar(HANDLE hComm, CHAR > chTransmit) > BOOL WINAPI GetCommTimeouts(HANDLE hComm, LPCOMMTIMEOUTS lptimeouts) > { > SERIAL_TIMEOUTS st; > + DWORD dwBytesReturned; > > TRACE("(%p, %p)\n", hComm, lptimeouts); > if (!lptimeouts) > @@ -1010,7 +1023,7 @@ BOOL WINAPI GetCommTimeouts(HANDLE hComm, > LPCOMMTIMEOUTS lptimeouts) > return FALSE; > } > if (!DeviceIoControl(hComm, IOCTL_SERIAL_GET_TIMEOUTS, > - NULL, 0, &st, sizeof(st), NULL, NULL)) > + NULL, 0, &st, sizeof(st), &dwBytesReturned, NULL)) > return FALSE; > lptimeouts->ReadIntervalTimeout = st.ReadIntervalTimeout; > lptimeouts->ReadTotalTimeoutMultiplier = > st.ReadTotalTimeoutMultiplier; > @@ -1043,6 +1056,7 @@ BOOL WINAPI GetCommTimeouts(HANDLE hComm, > LPCOMMTIMEOUTS lptimeouts) > BOOL WINAPI SetCommTimeouts(HANDLE hComm, LPCOMMTIMEOUTS lptimeouts) > { > SERIAL_TIMEOUTS st; > + DWORD dwBytesReturned; > > TRACE("(%p, %p)\n", hComm, lptimeouts); > > @@ -1058,7 +1072,7 @@ BOOL WINAPI SetCommTimeouts(HANDLE hComm, > LPCOMMTIMEOUTS lptimeouts) > st.WriteTotalTimeoutConstant = lptimeouts->WriteTotalTimeoutConstant; > > return DeviceIoControl(hComm, IOCTL_SERIAL_SET_TIMEOUTS, > - &st, sizeof(st), NULL, 0, NULL, NULL); > + &st, sizeof(st), NULL, 0, &dwBytesReturned, > NULL); > } > > /*********************************************************************** > @@ -1078,8 +1092,9 @@ BOOL WINAPI SetCommTimeouts(HANDLE hComm, > LPCOMMTIMEOUTS lptimeouts) > */ > BOOL WINAPI GetCommModemStatus(HANDLE hFile, LPDWORD lpModemStat) > { > + DWORD dwBytesReturned; > return DeviceIoControl(hFile, IOCTL_SERIAL_GET_MODEMSTATUS, > - NULL, 0, lpModemStat, sizeof(DWORD), NULL, > NULL); > + NULL, 0, lpModemStat, sizeof(DWORD), > &dwBytesReturned, NULL); > } > > /*********************************************************************** > > > Hi, your patches are corrupted by line wrapping.

1 0

Re: include: Change some DWORD to DWORD_PTR in msacm.h.
by Uwe Bonnes Feb. 5, 2009

Feb. 5, 2009

>>>>> "Michael" == Michael Stefaniuc <mstefani(a)redhat.de> writes: Michael> The change is for Win64 compatibility and it matches the DDK. -MMRESULT WINAPI acmDriverEnum(ACMDRIVERENUMCB fnCallback, DWORD dwInstance, DWORD fdwEnum) +MMRESULT WINAPI acmDriverEnum(ACMDRIVERENUMCB fnCallback, DWORD_PTR dwInstance, DWORD fdwEnum) Is the spec aentry then still right? ./dlls/msacm32/msacm32.spec:@ stdcall acmDriverDetailsW(long ptr long) -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 2