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

Re: New Wine Gecko package

by James Mckenzie

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

Feb. 5, 2009

Re: New Wine Gecko package

by Rico Schüller

Paul TBBle Hampson schrieb: > 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) > > > ------------------------------------------------------------------------ > > > Yes, still the same for me. I also hit this bug with the not installed wine with the patch applied and the new gecko. Cheers Rico

Feb. 5, 2009

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

by Marcus Meissner

On Thu, Feb 05, 2009 at 03:53:04PM +0000, Rob Shearman wrote: > 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. d'oh, fixed. (now: size/sizeof(WCHAR)-strlenW(url)) Ciao, Marcus

Feb. 5, 2009

Re: New Wine Gecko package

by Jacek Caban

Paul TBBle Hampson wrote: > 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) > Alexandre has found the problem. Gecko can't find fonts when Wine in ran from build dir. As a temporary workaround you may copy content of fonts directory to fonts directory in build dir. Jacek

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 6:38 PM, Juan Lang <juan.lang(a)gmail.com> wrote: >> 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". > > Well, if there are two fds still, but each end is either a client > (reading or writing) and the other is the wineserver, I believe you > could. that was "the plan" > That is, the server would only write complete messages to a > fd, presumably prepended with the length. that would be fine, if it wasn't for one thing: i've seen NT send _eight megabytes_ of data down a named pipe, on a spoolss service. i tried it out, once, with rpcclient. the limit (on NT 4.0) was around 8 mb of PDUs. now, what i _can't_ tell you is whether that eight megabyte limit was in the RPC subsystem (or if it was in the SMB-NP subsystem), with the MSRPC infrastructure breaking it down into PDU-sized chunks [of MTU-size e.g. 1500] and i certainly can't tell you whether those PDUs were put into a single 8mb buffer that was then handed to a single NtWriteFile() call on a Named Pipe, or if it was done on a per-pdu basis.... but, ultimately, i would be _very_ wary of getting wineserver to malloc exactly the amount of memory that it was told was being written down the pipe. not least is the issue that any such large mallocs or writes would put a _significant_ latency onto the response time of other wineserver calls (which is something i wanted to raise as a issue, separately. another time) so, i'm doing it as a loop, and... *thinks*... i like the queue of "struct fd"s more than i like the double-socket idea, the more i think about it. > A reading client would then > block if there weren't any data to read, and there wouldn't be any > data until a complete message were written there by wineserver. yes. this would be _very_ nice. ... except... what do you do when there is another message being written? NtWriteFile (puts the complete message into the fd) NtWriteFile (what do you do now? you can't block the writer) NtReadFile (gets the first complete message) NtReadFile (what do you do now?) this is why having a queue of "struct fd"s, one per message, could end up being the only viable solution. >> 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]. > > Right. There isn't any such mechanism, at least as far as I know. bugger :) mrrm... i encountered async_queue - that looks suspiciously like it's a wake-up mechanism. >> _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. > > Yep, agreed. This discussion is more about what the structure of the > file descriptors is. But in general, my opinion here doesn't carry > much weight, Alexandre's does ;-) And he's unlikely to voice an > opinion except on patches. ha ha :) anyone who helps crystallise ideas is valuable. >> message-mode namedpipes falls into that category, which is why i'm doing it. > > And we appreciate your attention to it. Really, we do :) thanks :) >> 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. > > Yep, that's been my assumption all along. That's why I've nudged you > with respect to tests a couple of times. Thanks for putting some in > the bug, by the way. no problem. there will need to be more - a lot more. e.g. PeekNamedPipe actually does an optional read, and _then_ tells you what's left. wine's implementation, because nobody ever really _does_ that "optional read", they only do the "peek". > Since I assumed it was unlikely you'd have the > patience to work with AJ to get your patches accepted, I thought > having some test cases, along with an implementation that isn't > fundamentally flawed, would help point us in the right direction. ... well... now i'm... deeply impressed (with your foresight). > Pointing out that handles can be shared between processes was a hint > about one fundamental flaw that can trip you up. mrmmrmmm *grumble-about-how-nt-works* yeah that was appreciated, although it won't be until i do some tests using dup on handles, or simply blatantly passing the 32-bit handle pointer value between processes (over a socket or a file), that i'll know what is and isn't possible. > I'll try to look at > what you're doing now and again to point out things that just can't > work. he he. appreciate it. > For the most part, though, I'll assume you know what you're > doing. *cackle*. are you sure that's wise? :) > Well, this is a bit off-topic, but he's a Linux kernel guy, not really > part of the Samba team. ahh. thank you for clarifying. i remember stephen from when he was with ibm, he was always at the cifs conferences. > But I understand that you don't want to go > the Linux-kernel-module-only route, and I respect that. *nods*. thank you, juan. l.

Feb. 5, 2009

Re: Stub DDE interface for Progman.exe

by Jeremiah Flerchinger

On Thu, 2009-02-05 at 18:12 +0000, Rob Shearman wrote: > 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. > Is explorer always running in Wine? I know "wine explorer" does not run ShellDDEInit when it starts. I thought most people were against additional processes, but I want to see the Progman DDE interface working for the different ways of calling it. ShellDDEInit didn't exist before Win 2000 and was in Shdocw.dll and not shell32.dll. Do we want to call ShellDDEInit in shell32 when Wine starts (and ends) then? It is supposed to be called only by the process that is acting as the shell when it registers itself as a DDE host for the shell. I don't think anything else would ever call it then.

Feb. 5, 2009

Re: New Wine Gecko package

by Jacek Caban

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. Also I don't see any point in upgrading Gecko in 1.0 branch. Jacek

Feb. 5, 2009

Re: New Wine Gecko package

by James Mckenzie

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

Feb. 5, 2009

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

by Juan Lang

> 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". Well, if there are two fds still, but each end is either a client (reading or writing) and the other is the wineserver, I believe you could. That is, the server would only write complete messages to a fd, presumably prepended with the length. A reading client would then block if there weren't any data to read, and there wouldn't be any data until a complete message were written there by wineserver. > 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]. Right. There isn't any such mechanism, at least as far as I know. > _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. Yep, agreed. This discussion is more about what the structure of the file descriptors is. But in general, my opinion here doesn't carry much weight, Alexandre's does ;-) And he's unlikely to voice an opinion except on patches. > 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) Sure, that's true. > 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. And we appreciate your attention to it. Really, we do :) > 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. Yep, that's been my assumption all along. That's why I've nudged you with respect to tests a couple of times. Thanks for putting some in the bug, by the way. Since I assumed it was unlikely you'd have the patience to work with AJ to get your patches accepted, I thought having some test cases, along with an implementation that isn't fundamentally flawed, would help point us in the right direction. Pointing out that handles can be shared between processes was a hint about one fundamental flaw that can trip you up. I'll try to look at what you're doing now and again to point out things that just can't work. For the most part, though, I'll assume you know what you're doing. > 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. Okay, fair enough. > 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_. Well, this is a bit off-topic, but he's a Linux kernel guy, not really part of the Samba team. But I understand that you don't want to go the Linux-kernel-module-only route, and I respect that. Thanks, --Juan

Feb. 5, 2009

RE: Stub DDE interface for Progman.exe

by Jeremiah Flerchinger

On Thu, 2009-02-05 at 18:58 +0100, Rolf Kalbermatter wrote: > "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 > DdeConnect, DDeInitialize, and DDeDisconnect can be called directly by including Windows.h and importing the calls from user32 (http://msdn.microsoft.com/en-us/library/ms648745(VS.85).aspx) DDE calls can then be made with SendMessage or PostMessage. I found a couple apps that appear to do this. Wine does not automatically start explorer.exe or initialize the shell DDE interface, nor does it route the DdeConnect routine in user32.dll to the DdeConnect routine in the shell32.dll. The DDE interface in shell32 and user32 will need to call the same set of routines from either method for full functionality of DDE calls, including those to Progman.

Feb. 5, 2009