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

Re: Stub DDE interface for Progman.exe

by Rob Shearman

2009/2/3 Dmitry Timoshkov <dmitry(a)codeweavers.com>: > "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. And it already is: ShellDDEInit. All it needs is some always running process to call it. It looks like explorer would be a good choice. -- Rob Shearman

Feb. 5, 2009

Re: ideas and questions for implementation of MessageMode in Named Pipes

by Luke Kenneth Casson Leighton

On Thu, Feb 5, 2009 at 4:08 PM, Juan Lang <juan.lang(a)gmail.com> wrote: >> i think i've finally come up with an idea that i believe will work: >> double-socketing. > (snip) >> it'll be ok (and desirable) to allow multiple "readers" of the "read" >> socket. what you _don't_ want is more than one reader trying to >> indicate "please start sending a new message" whilst there are other >> reader(s) still grabbing the previous message. >> >> so i believe that a critical section (copying the style of the code >> around server_get_unix_fd) each around "please start a new message" >> and "please send some more read-data" would be sufficient. > > Out of curiosity, why is this better than a single socket with the > length of each message prepended? a length prepended is still needed. what i had implemented so far (and demonstrated that it's flawed, thanks to the "threadread" test) is: * writes send length-prepended to data * wineserver-function get_named_pipe_info * wineserver-function read_named_pipe then: * in the client (ntdll) instead of using read() you use server_read_named_pipe() iff it's a pipe. BUT, before you do that, you do a poll() on the unix_handle (obtained using server_get_unix_fd()). this is your "blocking mode". so, although you tell the _server_ to get the data for you, you _still_ have to do "block on socket". and, because you can't use read() to do the "blocking", you have to use poll() instead. * in the wineserver-function, read_named_pipe MUST NOT EVER block on reads, but it is still being asked to perform _a_ read, and so there is some code that sets O_NONBLOCK, followed by a recv using MSG_PEEK to double-check that there's data, and _then_ a read is used to actually obtain the data. the problem here is that setting O_NONBLOCK in wineserver, in order to not end up permanently hanging wineserver, is *interfered with* by the requirement to have "blocking mode" in the client (ntdll). so there are two conflicting requirements, by using the same filedescriptor. and no, you _can't_ do "everything in wineserver", because you _still_ need a mechanism to be able to tell the client (ntdll) to "block". which is why i asked if there was a way for wineserver to tell a client wine thread/process to "go to sleep" [and didn't get an answer]. > One difficulty I'm having trouble getting my head around is, isn't the > data removed from a socket once it's ready by any process? or a thread - yes. fortunately, read() and write() to/from sockets are at least atomic (whew). > Or does it > remain for each process to read independently? no, thank god. the data is removed. except if you use recv() with MSG_PEEK, of course, but then the data is _guaranteed_ not to be removed. ever. > I guess I'm not that > familiar with how reading from a socket works. I'd always assumed > that the former was true, and that therefore the only correct approach > would be to buffer message-mode named pipe data in the server. "relax, luther - it's much worse than you think" [Mission Impossible I] :) > This > is ugly (and slow), well... it's unfortunate, but that's the way it's going to have to be. if i was told "there's these absolutely fantastic guaranteed-message-size, guaranteed-message-order characteristics you can get from message-mode named pipes, but they're a bit slower than normal pipes" when developing an application i'd go "great! i don't care if it's a bit slower, the features make my life a _lot_ easier". _somewhere_ there has to be a "break" between "messages". and you can't stop people from sending data down the pipe (in NtWritePipe). therefore, logically, you have to have a "firewall" between "send" and "receive". and, because you _also_ need "blocking on read" characteristics (across multiple processes and threads), the most sensible way to implement that is with a unix filedescriptor on which all of the clients (ntdll) can block. _but_.. if you also allow any _other_ process to send data down the _same_ unix filedescriptor (from NtWritePipe), you've just gone and screwed with the message-boundaries. ... actually, it may turn out to be the case that you literally need one filedescriptor _per message_. not joking about, or anything, but it may end up being the case that a queue of "struct fd*" pointers is required (in wineserver). in non-message-mode, that would simply be "queue length of 1". in message-mode, you'd go "oh, dear, we got an EPIPE error when trying to read, that means that someone else got that message, wow big deal, let's grab another unix filedescriptor from wineserver and try again". if grabbing another filedescriptor fails, THEN you go "oh, whoops, let's return STATUS_PIPE_DISCONNECTED". by having one filedescriptor per message, you are cast-iron guaranteeing 100% that individual messages will not interfere with each other. and, the neat thing is, you wouldn't need any "buffering". you'd still need to indicate the length (and the easiest way to do that is _still_ to send it as the first 4 bytes). > which is why Alexandre's stated preference has > been to push it into the Linux kernel. well, here's the thing: you can't _guarantee_ that wine will be *exclusively* running on the latest-and-greatest version of the linux kernel, and, also, it would be a bit unfair to the FreeBSD folks (and anyone else who would like to port wine to other OSes) so, this still has to be done in userspace, with an optimisation being "use a kernelspace implementation, if it exists". plus, i think also it would help the reactos guys out because they're in the middle - they will still need something that doesn't rely on a linux kernel that they can't have. > For what it's worth, Steve French has expressed interest in doing just > that. that's veeery good news. i'll look forward to seeing that implemented. > He asked for a clear spec for what filename these sockets > should have, but we didn't have a clear app that we needed to fix, so > we never followed through. You might approach him again. He's the > maintainer of the CIFS kernel module for Linux, and he already has his > own named pipe implementation. _cool_. well, here's where i should explain what my goal is. my goal is to "get things started". these days i tend to get involved in free software projects at "critical juncture" points, where there is clearly cross-project non-communication and/or non-cooperation (accidental or otherwise), and where it's _really_ important that the stuff actually gets done, but is sufficiently complex and misunderstood that nobody really wants to tackle it. message-mode namedpipes falls into that category, which is why i'm doing it. so - once i have _a_ working implementation, then please do not be offended, or surprised, if, when asked to make further enhancements, or if asked to fit specific criteria (such as doing things a "slightly different way"), i decline to do so. [advance notice: any such requests should also be accompanied by an offer of financial or other compensation.] but - of course, anyone who finds that the "working implementation" _isn't_ working, that's a _completely_ different matter and i will immediately act to remedy that (if noone else does). also from that strategic perspective, much as i would love to collaborate with steven on a kernel-level implementation of named pipes, i believe that it's extraneous: it's an optimisation. and if i were to work on that optimisation only, as the _only_ option, it would lock out other possibilities. so, on balance, i'll not be contacting steven right now. that, and the fact that the samba team decided to block all communication on 16th december 2005, and have neither revoked it nor issued a public apology for doing so, means that i cannot contact him _anyway_. l.

Feb. 5, 2009

RE: Stub DDE interface for Progman.exe

by Rolf Kalbermatter

"Jeremiah Flerchinger" <jeremiah.flerchinger(a)gmail.com> wrote: > 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. That would IMHO only be possible if the shell executable, which normally is just explorer creating the actual desktop view had been replaced by a different executable that does not initialize the shell DDE interface properly. Rolf Kalbermatter

Feb. 5, 2009

Re: wine iexplore speed test (JavaScript)

by Jacek Caban

Detlef Riekenberg wrote: > 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 > These tests should be very similar to Firefox 3.1 beta 2. Personally I don't see much point in looking for benchmarks as long as we have so many real applications that don't work due to lacks in our MSHTML implementation. > Is there a way to use our jscript.dll instead of js3250.dll? > We currently use jscript.dll only for documents with 'file:' URLs. > Or a way to use js3250.dll in our jscript.dll? > No, there are too many differences in architecture, that's why I've implemented jscript.dll from scratch. Jacek

Feb. 5, 2009

Re: New Wine Gecko package

by Jacek Caban

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

Feb. 5, 2009

wine iexplore speed test (JavaScript)

by Detlef Riekenberg

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

Feb. 5, 2009

Re: ideas and questions for implementation of MessageMode in Named Pipes

by Juan Lang

> i think i've finally come up with an idea that i believe will work: > double-socketing. (snip) > it'll be ok (and desirable) to allow multiple "readers" of the "read" > socket. what you _don't_ want is more than one reader trying to > indicate "please start sending a new message" whilst there are other > reader(s) still grabbing the previous message. > > so i believe that a critical section (copying the style of the code > around server_get_unix_fd) each around "please start a new message" > and "please send some more read-data" would be sufficient. Out of curiosity, why is this better than a single socket with the length of each message prepended? I'm not advocating that that's a better approach, mind you. It just seems to me that, if you're putting critical sections of a sort into the server anyway, you could block clients just as easily with one socket as with two. One difficulty I'm having trouble getting my head around is, isn't the data removed from a socket once it's ready by any process? Or does it remain for each process to read independently? I guess I'm not that familiar with how reading from a socket works. I'd always assumed that the former was true, and that therefore the only correct approach would be to buffer message-mode named pipe data in the server. This is ugly (and slow), which is why Alexandre's stated preference has been to push it into the Linux kernel. For what it's worth, Steve French has expressed interest in doing just that. He asked for a clear spec for what filename these sockets should have, but we didn't have a clear app that we needed to fix, so we never followed through. You might approach him again. He's the maintainer of the CIFS kernel module for Linux, and he already has his own named pipe implementation. --Juan

Feb. 5, 2009

Re: [PATCH] mshtml: Fixed last argument to MBtoWC

by Rob Shearman

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

Feb. 5, 2009

Re: bugzilla stuck?

by Jeremy Newman

I made some tweaks to the mysqld. It seems to have become more stable and reduced some load on the server in the last 24 hours. -Newman Austin English wrote: > 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. >

Feb. 5, 2009

Re: New Wine Gecko package

by Paul TBBle Hampson

On Thu, Feb 05, 2009 at 12:52:23AM +0100, Jacek Caban wrote: > 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. Still get a crash running iexplore out of the build directory: >From 8e39646ac4d256b813ff69a23ba0c62ab4f08d33 (1.1.14 release) mkdir gecko put above wine_gecko cab in gecko directory mkdir build cd build ../configure make depend && make -j3 programs/iexplore/iexplore And crash inside xul.dll. A quick check suggests it's the same crash as I logged a stacktrace in bug 16785, modulo a constant offset of 0x50 across the xul.dll, and the stack trace is a different depth in xul (but the deep end matches) -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson(a)Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.5/au/ -----------------------------------------------------------

Feb. 5, 2009