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

FW: Please educate me

by Medland, Bill

Thanks for the responses guys, but.. > -----Original Message----- > From: David Laight [mailto:david(a)l8s.co.uk] > Sent: Friday, April 19, 2002 3:33 AM > Cc: Wine devel (E-mail) > Subject: Re: Please educate me > > > On Fri, Apr 19, 2002 at 04:13:03AM +0200, Sylvain Petreolle wrote: > > > 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 > > If you have: > more_path="/sbin:/usr/sbin:$PATH" > you can do: > save_ifs="$IFS" > IFS=" :" > for ac_dir in $more_path > do > IFS="$save_ifs" > ... > done > > So that the shell treats ':' as a separator when > parsing the output of the substitution. > > > David > > -- > David Laight: david(a)l8s.co.uk > So why does "for" use spaces as the separator between the /sbin, the /usr/sbin and the $PATH but $IFS while expanding the $PATH (which is using :)? (And how come configure used to work OK but doesn't now?) (And, of course, it is configure.ac I will have to change so I don't get to change how AC_PATH_PROG gets expanded, and using spaces to separate will go against the documentation on autoconf) Bill

April 19, 2002

ALSA driver

by Marco Pietrobono

Hi, I'm starting to work on a native ALSA driver for wine. Since I remember that Marcus was working (or was planning to work) an that one too, I would like to know if there is already something to work on or to contribute to, or if I need to start from scratch. If there is nothing already written, I would like to discuss what kind of approach we should use with ALSA programming, since FWIK there should be two way to use it: we can use the ALSA devices directly, just like it has been done with OSS, or we can use the alsalib to avoid all direct references to the kernel devices and ioctl, but this solution will add a dependency on the alsalib library itself to wine. Of course, we could add a configure option/check to allow its use at compilation time, but... BTW, Alsalib is LGPL, so the license shouldn't be a problem. bye, /pietrobo -- Stud. Marco Pietrobono | Murphy's Law: if something could v. del Calice, 39 - 00178 ROMA | go wrong, it does. Tel. +39.06.7186329 339.7410893 | Legge di Murphy: se qualcosa può http://www.pietrobo.com | andar male, lo farà. ------------------------------------------------------------------------ Strange game. The only winning move is not to play. What about a nice play of chess ?

April 19, 2002

Re: toolbar.c problem (ATTN: Duane)

by Duane Clark

Dusan Vujosevic wrote: >>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. > > That is true. If release the left mouse button anywhere else except over the > toolbars the flyout will stick. The reason is that TOOLBAR_LButtonUp() > doesn't get executed in that case and the WM_COMMAND is not sent. > (Everything works perfectly under any Windows as you have noticed because > Win32 doesn't send the WM_COMMAND as I said before). I think you misunderstood my explanation. Once the menu is stuck and the button released, I slide the mouse into the flying menu and back out again, without pressing any mouse buttons. When the cursor leaves the flying menu, it disappears, but without calling TOOLBAR_LButtonUp(). This is the second behavior, which may not be related. >>Unfortunately >>for me, my real work is once again interfering severely with the amount >>of time I have to spend on Wine :-( > > > I'd be all too happy to help. I will take off my own time to test & fix > this. I'll try give you something over the weekend (patch). > > >> 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. A suggestion I made a couple weeks ago would make things easier, I would think. That would be to duplicate your flying menus within ControlSpy. I don't know how easy that would be to implement, but once implemented, it would likely make debugging much easier.

April 19, 2002

Re: Re: CoGetClassObject and SHQueryValueEx A/W/AW fixxes

by Leo van den Berg

hi Juergen, I chose SHGetRegPathW from shlwapi, because that seemed to be the best matching function for getting the registry string. I did not call a *AW function directly. I fixed the SHQueryValueExW to convert the incoming strings to ascii, _because_ the SHQueryValueExAW function had a bug in handling ExpandEnviromentStringsA (always failed) and was ascii-only (it doesn't seem to handle unicode at all). That was also the part i was not completely happy about. I must say i'm not to happy about including shlwapi either, but i think it is better than reinventing the wheel. What would you suggest i do? Move SHGetRegPath into a libwine and make a dependency from shlwapi and compobj(ole32) to that library? reimplement SHGetRegPathW and SHQueryValueExW in place in compobj.c ? Especially with the lib seperation going on.. there will be more and more inter-dll dependencys, must we avoid that at all cost? regards, leo juergen.schmied(a)debitel.net wrote: >Hmm, I think ole32 must not import shlwapi.dll... >Instead after the RegQueryValue call it should do a ExpandEnvironmentStrings when returned lpType is REG_EXPAND_SZ. > >... and never ever call a *AW Function internally, it will behave differently (one time it takes ASCII one time UNICODE) depending on the OSVERSION ... > >Juergen > >On 12 Apr 2002 at 20:17, 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 19, 2002

Re: [WINE with XIM] help - runtime error

by Ulrich Czekalla

Hi Leanne, This error is usually caused by unresolved symbols in the libx11drv.so. Look for compile warnings about implicitly defined symbols when building the x11drv. By the way, I'm also looking into XIM support. Unfortunately my code isn't complete yet. How far along are you? Could you post or send me your diff. Perhaps we could work together. /Ulrich >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: toolbar.c problem (ATTN: Duane)

by Dusan Vujosevic

----- 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 7:18 PM Subject: Re: toolbar.c problem (ATTN: Duane) > 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. That is true. If release the left mouse button anywhere else except over the toolbars the flyout will stick. The reason is that TOOLBAR_LButtonUp() doesn't get executed in that case and the WM_COMMAND is not sent. (Everything works perfectly under any Windows as you have noticed because Win32 doesn't send the WM_COMMAND as I said before). > 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. I will spy on Acrobat 4 over the weekend (don't have Word ...). That *probably* isn't a TBSTYLE_DROPDOWN button (just judging from its looks). > >>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. I will try that as well. > Unfortunately > for me, my real work is once again interfering severely with the amount > of time I have to spend on Wine :-( I'd be all too happy to help. I will take off my own time to test & fix this. I'll try give you something over the weekend (patch). > 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. Thanks, Dusan

April 19, 2002

Re: ALSA driver

by Marcus Meissner

On Fri, Apr 19, 2002 at 05:57:07PM +0200, Marco Pietrobono wrote: > Hi, > > I'm starting to work on a native ALSA driver for wine. Since I > remember that Marcus was working (or was planning to work) an that one > too, I would like to know if there is already something to work on or to > contribute to, or if I need to start from scratch. I was not planning to work on it as of this time. Ciao, Marcus

April 19, 2002

bug in wineinstall script

by Martin

make[1]: Leaving directory `/home/src/wine/programs/wineconsole' Wine build complete. Performing 'make install' as root to install binaries, enter root password Password: /bin/bash: - : unrecognized option Either you entered an incorrect password or we failed to run 'make install' correctly. If you didn't enter an incorrect password then please report this error to wine-devel(a)winehq.com. Installation failed, aborting. bash-2.05$ uname -a Linux hexa 2.4.17 #7 SMP Wed Jan 23 15:19:41 CET 2002 i686 unknown bash-2.05$ /bin/bash --version GNU bash, version 2.05.0(1)-release (i386-slackware-linux-gnu) Copyright 2000 Free Software Foundation, Inc. bash-2.05$

April 19, 2002

Re: Please educate me

by David Laight

On Fri, Apr 19, 2002 at 04:13:03AM +0200, Sylvain Petreolle wrote: > > 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 If you have: more_path="/sbin:/usr/sbin:$PATH" you can do: save_ifs="$IFS" IFS=" :" for ac_dir in $more_path do IFS="$save_ifs" ... done So that the shell treats ':' as a separator when parsing the output of the substitution. David -- David Laight: david(a)l8s.co.uk

April 19, 2002

Re: CoGetClassObject and SHQueryValueEx A/W/AW fixxes

by juergen.schmied＠debitel.net

Hmm, I think ole32 must not import shlwapi.dll... Instead after the RegQueryValue call it should do a ExpandEnvironmentStrings when returned lpType is REG_EXPAND_SZ. ... and never ever call a *AW Function internally, it will behave differently (one time it takes ASCII one time UNICODE) depending on the OSVERSION ... Juergen On 12 Apr 2002 at 20:17, 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 19, 2002