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

su to root failure in wineinstall
by Thomas Hardman April 21, 2002

April 21, 2002

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. earthops:/usr/src/wine-20020411$ -- T. Jr. Hardman thardman(a)earthops.org

2 1

ALSA driver
by Marco Pietrobono April 21, 2002

April 21, 2002

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 ?

10 17

bug?
by Rikard Björklind April 20, 2002

April 20, 2002

Hi, I tried to use ./tools/wineinstall: Performing 'make install' as root to install binaries, enter root password Password: [here I wrote the password] /bin/bash: - : unrecognized option What's wrong?

1 0

Is Wine server request serialization broken ?
by Laurent Pinchart April 20, 2002

April 20, 2002

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

1 1

(no subject)
by Ann and Jason Edmeades April 19, 2002

April 19, 2002

I've noticed a small bug when using wcmd, in the changing to a directory, eg c:\windows and doing 'dir \' fails to show the root directory. Its annoyed me to the point of investigating and the problem seems to lie further down inside the DOSFS_DoGetFullPathName routine. A simple testpgm shows the problem: #include <windows.h> void main() { char A[] = "\\"; char B[1024]; int rc; rc = GetFullPathName (A, sizeof(B), B, NULL); printf("rc = %d, a=%s, b=%s\n", rc, A, B); } (Note: Testpgm run on w2k) Unfortunately I also noticed how often this routine is called and how many cases it appears to be trying to handle, so am slightly nervous about touching it! I am going to do some more investigation but does anyone have any thoughts in the meantime? Thanks Jason jason @ the-edmeades.demon.co.uk

1 0

Using WineLib directly
by Zavada, Ed April 19, 2002

April 19, 2002

I've seen this question asked before, but there was never a response to the newsgroup. We'd like to use WineLib to provide implementations of the Windows calls in our application's Linux build while we work on a full blown port. So far, all the documentation requires that we use winebuild and generate a .so that is loaded by the wine server. Is this truely the only way to do this? Is there no way to just use the various libraries independent of wine server? For instance, I'd like to be able to make a call to MessageBox() from a native linux binary, then later eliminate the need for it (since this will ultimately be a console app). Thanks, Ed Zavada Lead Server Engineer The Sims Online Maxis East

2 1

Re: small patch for ./tools/wineinstall
by Speeddymon April 19, 2002

April 19, 2002

my first patch fixes that problem and quite a few others --- Tony Lambregts <tony_lambregts(a)telusplanet.net> wrote: > I seems with all the changes to ./tools/wineinstall > the installation of > the default wine registries does not happen when we > have a no windows > install. This little patch seems to do the trick > > Tony Lambregts > > > > > ? wineinstall.dif > Index: wineinstall > =================================================================== > RCS file: /home/wine/wine/tools/wineinstall,v > retrieving revision 1.26 > diff -u -r1.26 wineinstall > --- wineinstall 1 Apr 2002 20:56:51 -0000 1.26 > +++ wineinstall 17 Apr 2002 20:56:27 -0000 > @@ -578,7 +578,7 @@ > # (not to be done if windows registry exists) > if [ "$DOREG" = 'auto' ] > then { > - CROOT=`sed -n '/^\[Drive C\]$/,/^\[.*\]$/ > s/^Path=$.*$/\1/p' $CONF` > + CROOT=`awk -F\" '/\[Drive C]/ {if (getline) print > $4}' $LCONF` > echo "Checking for real Windows registry..." > if [ -f "$CROOT/windows/system.dat" ] > then DOREG=no > __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/

2 1

FW: Please educate me
by Medland, Bill April 19, 2002

April 19, 2002

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

1 0

Re: CoGetClassObject and SHQueryValueEx A/W/AW fixxes
by juergen.schmied＠debitel.net April 19, 2002

April 19, 2002

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 >

2 1

Re: [WINE with XIM] help - runtime error
by Ulrich Czekalla April 19, 2002

April 19, 2002

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

1 0