- Wine-Devel - list.winehq.org

Who is the expert on named_pipe.c
by Bill Medland April 8, 2003

April 8, 2003

I've found a problem with the named_pipe.c in the server. Is there anyone out there who purports to be an expert or is it up to me to fix it? (Basically the server is creating a named pipe, reading from it, writing back to it, flushing and closing, all before the client has read the reply; the wineserver crashes as the client tries to read because it's copy no longer has an fd) -- Bill Medland ACCPAC International, Inc. medbi01(a)accpac.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

2 2

why the wine not use the dll binary?
by Yu Neil April 8, 2003

April 8, 2003

hello: why the wine not use the dll binary? but to rewrite the windows interface? Neil Yu _________________________________________________________________ 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn

2 1

Re: PATCH: client side SuspendThread() handling when using valgrind
by Dimitrie O. Paun April 8, 2003

April 8, 2003

On April 7, 2003 10:41 am, Adam Gundy wrote: > the attached patch is a reworking of the previous valgrind patch's > SuspendThread() changes so that the client only suspends threads locally > when running under valgrind. What about: +#ifdef HAVE_VALGRIND_MEMCHECK_H +#include <valgrind/memcheck.h> +#else +#define RUNNING_ON_VALGRIND 0 +#endif so we can eliminate the ugly ifdefs? -- Dimi.

2 1

Re: Re: --with-nptl and glibc-2.3.2
by fenix＠club-internet.fr April 8, 2003

April 8, 2003

Hi, can you try with preloading? LD_PRELOAD="/usr/local/wine/lib/kernel32.dll.so /usr/local/wine/lib/ntdll.dll.so" wine regedit Regards, Raphael ----Message d'origine---- >De: James Pellow <james(a)alentdesignsolutions.com> >A: wine-devel(a)winehq.com >Sujet: Re: --with-nptl and glibc-2.3.2 >Date: Mon, 7 Apr 2003 17:37:02 +0000 > >On Sunday 06 April 2003 05:48 am, Gregory M. Turner wrote: >> On Saturday 05 April 2003 02:52 pm, James Pellow wrote: >> > Thanks Gregory and Raphael for your answers. So far, I have been using >> > "~x86" for two months now, with only minor glitchs. This is the biggest >> > hangup I have found. >> >> yes, it tends to work just fine, although from time to time it goes south >> :) >> >> It all depends on what the developers are working on, I guess. Typically >> all goes well until glibc upgrades start looming, and then gcc breaks and >> it's time to re-read the gentoo install guide ;) If you are a developer, >> it's a meaningful excercise; it's truly a bleeding edge system and any >> dependencies likely to affect your users in the coming months may hit you >> first. It's also fun to see the very latest efforts from the OSS world and >> beyond... but personally, for desktop use, it's a bit too demanding, I need >> to save my mental energy ;) My only advice would be: habitually use the -b >> flag to emerge so that when and if you kill your system you can revive it >> by untarring old emerges. >> >> > I would be happy to look into the problem myself and >> > provide a fix, but it seems work and taxes are taking up most of my time >> > right now :( so I am curious how far out a fix might be. Is this being >> > worked on? Thank you all for an incredible tool! >> > - James >> >> Tried Piotr Pawlow's recently posted fix? >> >> > Try this: >> > >> > $ sed -e 's/-z,defs/-z=defs/g' <configure.ac >tmp && aclocal && autoconf >> > tmp >configure >> > >> > and then as usual: >> > >> > $ ./configure && make depend && make > >Ok, I have done the first round of testing on my new wine with the above fix. >The above fix does allow wine to compile, but there do seem to be some >runtime problems that remain. > >I have a stand alone installation of wine. First I tried to install an app >and ran into the following message: > >err:module:BUILTIN32_dlopen failed to load .so lib for builtin advapi32.dll: >/usr/local/wine/lib/wine/advapi32.dll.so: undefined symbol: GetComputerNameW >err:module:import_dll Loading module (file) ADVAPI32.dll (which is needed by >D:\setup.exe) failed (error -1073741702). > >I did the following in lib/wine: > >for FILE in `ls *.so`; do objdump -t $FILE | grep GetComputerNameW && ls -l >$FILE; done > >and see that all files that that define this symbol are links to >kernel32.dll.so. > >The problem seems obvious when I do: > >ldd advapi32.dll.so > > libwine.so.1 => /usr/local/wine/lib/libwine.so.1 (0x40042000) > libwine_unicode.so.1 => /usr/local/wine/lib/libwine_unicode.so.1 >(0x4005a000) > libm.so.6 => /lib/libm.so.6 (0x4013b000) > libc.so.6 => /lib/libc.so.6 (0x4015d000) > libdl.so.2 => /lib/libdl.so.2 (0x40285000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) > >It appears that advapi32.dll.so does not claim to need kernel32.dll.so, but it >does! Any ideas on what went wrong? Regedit did not run for a similar >reason. Thanks for your help. > >James Pellow > >

2 1

RH9 & cvsup
by Dimitrie O. Paun April 8, 2003

April 8, 2003

Hi folks, I've just upgraded to RedHat 9, and I run into my first problem. cvsup segfaults: [dimi(a)dimi wine.src]$ cvsup ~/cvsup.sup *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL0 *** use option @M3stackdump to get a stack trace Aborted Now, this is a big problem for me, any other cvsup user out there with this problem (and hopefully a workaround?) -- Dimi.

1 0

Re: cleaning the source tree when compiling outside the source tree
by Alexandre Julliard April 8, 2003

April 8, 2003

Eric Pouech <pouech-eric(a)wanadoo.fr> writes: > ChangeLog: when compiling out of source tree, insure that make clean actually cleans also inside the source tree I don't think we should do that. IMO we must not modify the source tree in any way when building in a separate dir. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: winedos / Small bug fixes
by Jukka Heinonen April 7, 2003

April 7, 2003

Enrico Horn wrote: > With this patch I get an unhandled exception > while trying to run callahans crosstime saloon, > an dos adventure that makes use of vesa. > without the patch the program runs, just with a black picture :-) This problem is likely caused by one of the following reasons: - The program calls int10 from protected mode and expects to get selector based far pointers instead of segment based ones. - The program previously failed to initialize VESA and now, when it initializes VESA correctly, it starts to crash in previously unused code. Separating these two cases would make fixing this crash easier. Do you have some traces that show int10 usage before/after patch or can the game be downloaded for free from some site? -- Jukka Heinonen <http://www.iki.fi/jhei/>

2 1

--with-nptl and glibc-2.3.2
by James Pellow April 7, 2003

April 7, 2003

Hi all, After reading the comments on the list reguarding glibc-2.3.2, it appears all I need to do is ./configure --with-nptl. Today, gave this a try and am having the following error messages repeated many times when trying to link d3d8: shader.o(.text+0x19f8): In function `IDirect3DVertexShaderImpl_ParseProgram': /home/pellja/cvs/wine/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' stateblock.o(.text+0x1064): In function `IDirect3DDeviceImpl_CreateStateBlock': /home/pellja/cvs/wine/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' stateblock.o(.text+0x1402): In function `IDirect3DDeviceImpl_DeleteStateBlock': /home/pellja/cvs/wine/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' stateblock.o(.text+0x14ed): In function `IDirect3DDeviceImpl_BeginStateBlock': /home/pellja/cvs/wine/dlls/d3d8/../../include/winbase.h:1932: undefined --snip-- I have had this problem for the last couple of releases... My setup is an up to date gentoo, todays wine-cvs, glibc-2.3.2 and gcc-3.2.2. on an AMD thunderbird. Any ideas? On the gentoo formums, they all say downgrade to glibc-2.3.1, and hear I read use --with-nptl, but it doesn't work... I would rather not downgrade my glibc... Thanks for your help. Sorry if this is becomming a FAQ, but it still didn't seem clear to me. James

4 7

[announce] QEMU x86 emulator version 0.1
by Fabrice Bellard April 7, 2003

April 7, 2003

Hi, The first release of the QEMU x86 emulator is available at http://bellard.org/qemu/. QEMU achieves a fast user space Linux x86 emulation on x86 and PowerPC Linux hosts by using dynamic translation. Its main goal is to be able to run the Wine project on non-x86 architectures. Fabrice.

3 5

Re: valgrind for WINE
by Adam Gundy April 7, 2003

April 7, 2003

At 10:15 03/04/03 -0800, Alexandre Julliard wrote: >Adam Gundy <arg(a)cyberscience.com> writes: > >> anything that uses SuspendThread is inherently racy and unpleasant. Even the Microsoft >> documentation says "don't use this!". Of course, they ignore themselves and do it (twice) >> during MFC thread creation, but... >> >> We aren't currently adding _any_ race condition that isn't already there - the wineserver >> sends a signal to the client process in the current code - who knows when that will be delivered? >> there could be a big gap between the server sending the signal, and the signal being processed. > >There may be a delay, but the thread is still effectively suspended >since it's not running any user-mode code. The signal will get >delivered on the next switch to that thread, so we still get the >correct behavior. If the signal is sent in the client the suspended >thread can still run arbitrary amounts of code while the server >believes it is already suspended. you can't reason like this - it all falls apart with SMP. Both threads can happily be running at the same time - we are using clone() after all. I can currently produce this race (without my patch applied) by adding a "Sleep( 1000 )" to the USR1 signal handler in ntdll/signal_i386.c. The wineserver is convinced that the thread is suspended, but it isn't (sleeping is a bad example - assume that a context switch occurred, or heavy processing happened before the signal was delivered). this 'race' doesn't have ANY effect, because suspending a thread is not a precise operation - it doesn't matter whether 1 or 1000 instructions are executed by the thread before it stops. Windows threads don't give guarantees about thread suspension (unlike pthreads). to summarize: a) there is already a race condition in the current code - it _probably_ only triggers on SMP or heavily loaded UP. b) my patch won't make things any worse c) the race doesn't matter because Windows threads don't guarantee what happens when a thread is suspended (read Microsoft's docs - they practically say "don't use this call" for this very reason). Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions.

2 4