wine-devel

wine-devel@winehq.org

4 participants
84403 discussions

bug?
by Rikard Björklind 20 Apr '02

20 Apr '02

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 20 Apr '02

20 Apr '02

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 19 Apr '02

19 Apr '02

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 19 Apr '02

19 Apr '02

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 19 Apr '02

19 Apr '02

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 19 Apr '02

19 Apr '02

Thanks for the responses guys, but.. > -----Original Message----- > From: David Laight [mailto:david@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 19 Apr '02

19 Apr '02

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 19 Apr '02

19 Apr '02

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@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

bug in wineinstall script
by Martin 19 Apr '02

19 Apr '02

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$

1 0

[WINE with XIM] help - runtime error
by leanne 19 Apr '02

19 Apr '02

Dear all, I have patched the code I was given in wine-16042002. When I ran it, I got the following error. ~~~~~~~~~~~~~~ [leanne@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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel