April 2002 - Wine-Devel - list.winehq.org

[WINE with XIM] help - runtime error

by leanne

Dear all, I have patched the code I was given in wine-16042002. When I ran it, I got the following error. ~~~~~~~~~~~~~~ [leanne(a)leanne73 wine]$ wine /tmp/notepad.exe err:module:BUILTIN32_dlopen failed to load .so lib for builtin x11drv.dll: /usr/X11R6/lib/libX11.so: shared object not open Could not load graphics driver 'x11drv' err:win:GetDesktopWindow Wine init error: either you're trying to use an invalid native USER.EXE config, or some graphics/GUI libraries or DLLs didn't initialize properly. Aborting. ~~~~~~~~~~~~~~ I would like to ask which module/file relates to this error so that I could fix it? If you want to see my code, please welcome. or I can post the .diff later on. Many thanks. Yours sincerely, Leanne

April 19, 2002

Re: Please educate me

by Sylvain Petreolle

> noticed that > > for ac_dir in /sbin:/usr/sbin:$PATH > > was splitting as > 1. /sbin:/usr/sbin:/usr/local/bin > 2. /bin > 3. /usr/bin > etc. it's a normal behaviour, because for uses space as a separator, not ':' ?? > > Now, I know I can force it to work by changing the > for loop to > for ac_dir in /sbin /usr/sbin $PATH ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

April 19, 2002

Re: toolbar.c problem (ATTN: Duane)

by Duane Clark

Andreas Mohr wrote: > On Thu, Apr 18, 2002 at 04:18:47PM -0700, Duane Clark wrote: > >>Dusan Vujosevic wrote: >> >>>I use Spy++ on it... What was the problem? >> >>I tried APIS32, but it barfed on this particular program. Unfortunately >>for me, my real work is once again interfering severely with the amount >>of time I have to spend on Wine :-( But I will try to get in a couple >>of tests with ControlSpy with the TBSTYLE_DROPDOWN style, since it >>should not take much time, perhaps this weekend. > > Did you *really* only enable logging when arriving at this part ?? > Or maybe you did not enable logging even though you should have > at some critical part or another... As I recall, the program would not even run. It was the first time I tried APIS32, though, so it could easily be operator error. I did try running another program under APIS32, and was able to get it that one to work.

April 19, 2002

Re: toolbar.c problem (ATTN: Duane)

by Andreas Mohr

On Thu, Apr 18, 2002 at 04:18:47PM -0700, Duane Clark wrote: > Dusan Vujosevic wrote: > > I use Spy++ on it... What was the problem? > > I tried APIS32, but it barfed on this particular program. Unfortunately > for me, my real work is once again interfering severely with the amount > of time I have to spend on Wine :-( But I will try to get in a couple > of tests with ControlSpy with the TBSTYLE_DROPDOWN style, since it > should not take much time, perhaps this weekend. Did you *really* only enable logging when arriving at this part ?? Or maybe you did not enable logging even though you should have at some critical part or another... -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.arcor.de/andi.mohr/

April 18, 2002

Is Wine server request serialization broken ?

by Laurent Pinchart

Hi everybody, I ran into a pretty serious problem. I'm trying to run a program which creates a child process. I noticed that the call to the server request init_process_done returned erroneus information about the debugger state. After some investigation, here's what I found. I put a few fprintfs in the start_process(), wine_server_call() and send_request() functions. I also tweaked the init_process_done request to return an unsigned int equal to 0x12345678 in the reply structure just after the debugger member. Here's what a 'normal' call to start_process() looks like calling wine_server_call req=0x405a6ec4 wine_server_call req=0x405a6ec4 request_header.req=6 wine_server_call checkpoint 1 send_request checkpoint 1 send_request checkpoint 2 wine_server_call checkpoint 2 wine_server_call req=0x405a6ec4 wine_server_call 00 00 00 00 00 00 00 00 wine_server_call 00 00 00 00 78 56 34 12 wine_server_call returned req=0x405a6ec4 wine_server_call returned 00 00 00 00 00 00 00 00 wine_server_call returned 00 00 00 00 78 56 34 12 There is one 'checkpoint' in wine_server_call just before the call to send_request(), and one right after. There are 2 checkpoints in send_request, the first one right before the call to writev() and the second one right after. The hex dump in the above trace is the content of the 16 first bytes of reply. Please notice the '78 56 34 12' at the end, being the extra member I added to the init_process_done_reply structure. Here's now what the 'broken' call to start_process() looks like calling wine_server_call req=0x40556ec4 wine_server_call req=0x40556ec4 request_header.req=6 wine_server_call checkpoint 1 send_request checkpoint 1 wine_server_call req=0x40555254 request_header.req=90 wine_server_call checkpoint 1 send_request checkpoint 1 send_request checkpoint 2 wine_server_call checkpoint 2 wine_server_call req=0x40555254 wine_server_call 00 00 00 00 00 00 00 00 wine_server_call 00 00 00 00 78 56 34 12 wine_server_call req=0x4055601c request_header.req=90 wine_server_call checkpoint 1 send_request checkpoint 1 send_request checkpoint 2 wine_server_call checkpoint 2 wine_server_call req=0x4055601c wine_server_call 00 00 00 00 00 00 00 00 wine_server_call 20 00 00 00 00 00 00 00 wine_server_call req=0x40555f2c request_header.req=94 wine_server_call checkpoint 1 send_request checkpoint 1 send_request checkpoint 2 wine_server_call checkpoint 2 wine_server_call req=0x40555f2c wine_server_call 00 00 00 00 00 00 00 00 wine_server_call 28 00 00 00 00 00 00 00 wine_server_call req=0x4055607c request_header.req=20 wine_server_call checkpoint 1 send_request checkpoint 1 wine_server_call checkpoint 2 wine_server_call req=0x4055607c wine_server_call 34 00 00 c0 00 00 00 00 wine_server_call ff ff ff ff 00 00 00 00 send_request checkpoint 2 wine_server_call checkpoint 2 wine_server_call req=0x40556ec4 wine_server_call 00 00 00 00 00 00 00 00 wine_server_call ff ff ff ff 00 00 00 00 wine_server_call returned req=0x40556ec4 wine_server_call returned 00 00 00 00 00 00 00 00 wine_server_call returned ff ff ff ff 00 00 00 00 As you can see, the call to writev() seems to trigger something registry-related (90 is open_key, 94 is get_key_value and 20 is close_handle). I have absolutely no idea about where those calls come from (Wine internal registry calls or external calls). Remember that there are two processes running, start_process() being called for the second one. As you can see for the hex dump, the open_key request receives the answer of the init_process_done request ! I'm completely clueless about that problem. If someone has any idea, or needs more information, please send me a mail. Laurent Pinchart

April 18, 2002

Re: toolbar.c problem (ATTN: Duane)

by Duane Clark

Dusan Vujosevic wrote: > Hello, > > ----- Original Message ----- > From: "Duane Clark" <dclark(a)akamail.com> > ... >>It is not "the correct way", since I have tested it with control spy >>under WinNT and Wine. That is not to say that my patch is correct >>either, but it fixes two different applications I have and in my mind is >>closer to the correct way. There may well be some conditions under which >>the message should not be sent, but the previous way was not correct. > > > How about we test whether the button has TBSTYLE_DROPDOWN > style set and not send the message in that case??? Okay by me. I certainly did not test for that case. >>And there is more going on in your app, because the flying toolbars also >>disappear when the mouse is simply slid over them, without clicking. > > > Wine or Windows? I don't follow this / can't reproduce it under either one. Under Wine, I can make the flying toolbar stick (even with my patch) by holding the mouse button down and sliding it out of the main toolbar. Once out of the toolbar, I can let up the mouse button without the toolbar going away. Once stuck, if I simply slide the mouse across the flying toolbar, it disappears. This does not happen under Windows. Note that I have my window manager set for "focus follows mouse", which perhaps could possibly have some effect here. However, other programs I have tried with flying toolbars, including Word2000 and Acroread, do not have this problem (nor the mouseup problem), so it is not a simple generic problem. >>This behavior is not there under Windows, and has nothing to do with the >>ButtonUp change I made. The two may not be related, but I cannot help >>thinking they are. Unfortunately, I was not able to get a spy program to >>work with your app in windows, so I have not been able to figure out >>what messages should really be sent, and when. > > > I use Spy++ on it... What was the problem? I tried APIS32, but it barfed on this particular program. Unfortunately for me, my real work is once again interfering severely with the amount of time I have to spend on Wine :-( But I will try to get in a couple of tests with ControlSpy with the TBSTYLE_DROPDOWN style, since it should not take much time, perhaps this weekend.

April 18, 2002

Please educate me

by Medland, Bill

Can anyone explain what is going on here please; this is obviously an area of bash etc I don't understand. This morning I was doing a fresh install on a totally clean machine from the Wine-20020411 tarball under Redhat 7.1. All went reasonable well until I saw a "..<something not write> .." go flashing past as I ran wineinstall and later on the regapi failed because it couldn't find libntdll.dll.so. OK so I guess it was the ldconfig that failed!! So I thought "lets fix it". Yes; in the last fix to wineinstall where we went with using "su root" instead the ldconfig was hard-coded (and wasn't on the path for simply "su root"). So I followed up on the machine I normally use and started messing about with $ac_cv_path_LDCONFIG. I got that working, consistant on hand-editing the config.cache to change "true" to "/sbin/ldconfig". So the remaining thing was to get the cache entry generated correctly. This is where the problem is. (I still don't understand why it should get set either to the name of an executable or to the value "true"; I dislike variables holding dissimilar types). Anyway I was watching the loop so see why it wasn't finding the /sbin/ldconfig and I noticed that for ac_dir in /sbin:/usr/sbin:$PATH was splitting as 1. /sbin:/usr/sbin:/usr/local/bin 2. /bin 3. /usr/bin etc. Now, I know I can force it to work by changing the for loop to for ac_dir in /sbin /usr/sbin $PATH However the original form used to work (I guess, since the cache is correct on my other machine) so I'd rather know why it isn't working currently and fix that Can anyone explain why it isn't splitting the for the way we want it to TIA Bill

April 18, 2002

Re: toolbar.c problem (ATTN: Duane)

by Dusan Vujosevic

Hello, ----- Original Message ----- From: "Duane Clark" <dclark(a)akamail.com> To: "Dusan Vujosevic" <dusanv(a)cadlink.com> Cc: <wine-devel(a)winehq.com> Sent: Thursday, April 18, 2002 12:44 PM Subject: Re: toolbar.c problem (ATTN: Duane) > Dusan Vujosevic wrote: > > Hi, > > > > I am having a problem with the way toolbar.c was modified between > > revisions 1.107 & 1.108. My application (Signlab) pops flyout toolbars > > that stay around until they lose focus. The parent toolbar receives a > > 'TBN_DROPDOWN' message when someone clicks on one of its flyout buttons > > (button style: TBSTYLE_DROPDOWN). It creates a flyout at that point. > > > > With revision 1.108 of toolbar.c in Wine the parent toolbar also > > receives an WN_COMMAND after TBN_DROPDOWN message which causes Wine > > (rightly so) to send an WM_SETFOCUS (and WM_ACTIVATE). That causes the > > parent to regain focus and kills the flyout. The line that sends > > the WN_COMMAND is in toolbar.c at line 4540 (TOOLBAR_LButtonUp() function): > > SendMessageA (infoPtr->hwndNotify, WM_COMMAND, > > MAKEWPARAM(infoPtr->buttons[nHit].idCommand, 0), (LPARAM)hwnd); > > In revision 1.107 it used to be: > > > > if (bSendMessage) > > SendMessageA (infoPtr->hwndNotify, WM_COMMAND, > > MAKEWPARAM(btnPtr->idCommand, 0), (LPARAM)hwnd); > > > > And that worked fine because it would never send WM_COMMAND for a flyout > > button. Note that WinXP (that's where I tested) doesn't send WM_COMMAND > > after TBN_DROPDOWN has been handled. I would like to suggest revert that > > line back to 1.106 because it is the correct way. > > It is not "the correct way", since I have tested it with control spy > under WinNT and Wine. That is not to say that my patch is correct > either, but it fixes two different applications I have and in my mind is > closer to the correct way. There may well be some conditions under which > the message should not be sent, but the previous way was not correct. How about we test whether the button has TBSTYLE_DROPDOWN style set and not send the message in that case??? > So > I guess Alexandre gets to pick which incorrect version to use ;) Hm :/ > And there is more going on in your app, because the flying toolbars also > disappear when the mouse is simply slid over them, without clicking. Wine or Windows? I don't follow this / can't reproduce it under either one. > This behavior is not there under Windows, and has nothing to do with the > ButtonUp change I made. The two may not be related, but I cannot help > thinking they are. Unfortunately, I was not able to get a spy program to > work with your app in windows, so I have not been able to figure out > what messages should really be sent, and when. I use Spy++ on it... What was the problem? > Certainly a common > problem is that a fix in one area exposes a problem elsewhere, and that > possibly is what happened here. Probably. I am really intersted in helping track this one down (although I can work around it in SL and that's what I'll do for the time being ...). Cheers, Dusan

April 18, 2002

Re: CoGetClassObject and SHQueryValueEx A/W/AW fixxes

by Leo van den Berg

please hold this one off, i have to add some changes to Makefiles to enable a clean complete build.. (only tried incremental) will be fixxed, sorry bout this. regards, leo Leo van den berg wrote: >Cleaned up and fixxed Registry Path finding of Inprocess32 & LocalServer32, >registry entrys like '%SystemRoot%' don't break programs anymore now. >Found that SHQueryValueEx - family of functions were broken (and derived >functions as well ofcourse). Not 100% happy about the result, but it seems >to *work* now. > >any comments welcome ofcourse, > Leo van den Berg >

April 18, 2002

Re: COMI

by Sylvain Petreolle

http://appdb.codeweavers.com/appview.php?appId=121&versionId=169 --- Johan Gill <johane(a)lysator.liu.se> a écrit : > I test Curse of Monkey Island now and then, and with > the latest CVS > update, and some before, starting the game yields a > black screen. However, > moving the mouse around causes > err:ntdll:RtlpWaitForCriticalSection section > 0x40360be8 "?" wait timed > out, retrying (60 sec) fs=027f > and when the debugger starts later on the game > starts. > > Any ideas? > > /Johan Gill, johane(a)lysator.liu.se > > ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

April 18, 2002