April 2003 - Wine-devel - list.winehq.org

Re: Re: cleaning the source tree when compiling outside the source tree
by Pouech Eric DMI AEI CAEN 08 Apr '03

08 Apr '03

> 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. It depends which files we're talking about I think that *~ (and any editor backup files), *rej* *orig* (patch leftovers), .#* (cvs update leftovers) should be removed from the source tree perhaps we need to seperate the semantics from clean and distclean. but at least, from a distclean point of view, I do think it would be great to remove the hereabove mentionned files from the source tree A+

2 1

re: hi wine team
by Dan Kegel 08 Apr '03

08 Apr '03

> did the wine team consider construct the win32 support (wine) within a > micro-kernel architecture, just like the microsoft`s interix ? "Just like microsoft's Interix"? We have no idea how Microsoft implemented that stuff; it's not bundled with Windows, so not many people see it, and it's closed source, so it's a bit hard to distinguish a microkernel from a regular kernel. Please post some code so we know you're not a troll :-) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

1 0

--with-nptl and RH 8 : unhappy
by Sylvain Petreolle 08 Apr '03

08 Apr '03

Having RH 8.0 with glibc-2.3.2, I tried to compile Wine wiht --with-nptl. Wine compiles fine but doesnt run at all. Every application I try to run calls the debugger in a loop. [syl(a)snoop c]$ wine --debugmsg +relay notepad trace:relay:RELAY_InitDebugLists RelayInclude = L"user32.CreateWindowA" trace:relay:RELAY_InitDebugLists RelayExclude = L"RtlEnterCriticalSection;RtlLeaveCriticalSection;_LeaveSysLevel;_EnterSysLevel" wine: Unhandled exception, starting debugger... trace:relay:RELAY_InitDebugLists RelayInclude = L"user32.CreateWindowA" trace:relay:RELAY_InitDebugLists RelayExclude = L"RtlEnterCriticalSection;RtlLeaveCriticalSection;_LeaveSysLevel;_EnterSysLevel" wine: Unhandled exception, starting debugger... trace:relay:RELAY_InitDebugLists RelayInclude = L"user32.CreateWindowA" trace:relay:RELAY_InitDebugLists RelayExclude = L"RtlEnterCriticalSection;RtlLeaveCriticalSection;_LeaveSysLevel;_EnterSysLevel" wine: Unhandled exception, starting debugger... trace:relay:RELAY_InitDebugLists RelayInclude = L"user32.CreateWindowA" trace:relay:RELAY_InitDebugLists RelayExclude = L"RtlEnterCriticalSection;RtlLeaveCriticalSection;_LeaveSysLevel;_EnterSysLevel" wine: Unhandled exception, starting debugger... trace:relay:RELAY_InitDebugLists RelayInclude = L"user32.CreateWindowA" trace:relay:RELAY_InitDebugLists RelayExclude = L"RtlEnterCriticalSection;RtlLeaveCriticalSection;_LeaveSysLevel;_EnterSysLevel" wine: Unhandled exception, starting debugger... err:seh:EXC_DefaultHandling Unhandled exception code c000013a flags 0 addr 0x402fec16 err:seh:EXC_DefaultHandling Unhandled exception code c000013a flags 0 addr 0x402fec16 [syl(a)snoop c]$ err:seh:EXC_DefaultHandling Unhandled exception code c000013a flags 0 addr 0x402fec16 err:seh:EXC_DefaultHandling Unhandled exception code c000013a flags 0 addr 0x402fec16 err:seh:EXC_DefaultHandling Unhandled exception code c000013a flags 0 addr 0x402fec98 ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

3 3

winelib/mfc queries
by KK singh 08 Apr '03

08 Apr '03

I am using 20030318 build of wine ... 1. WINE_UNICODE_TEXT is no longer defined anywhere in any of the header files ? What should i do now with OLESTR ? 2. Should i define _AFXDLL while compiling mfc ? Regards kks __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com

2 1

Who is the expert on named_pipe.c
by Bill Medland 08 Apr '03

08 Apr '03

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 08 Apr '03

08 Apr '03

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 08 Apr '03

08 Apr '03

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 08 Apr '03

08 Apr '03

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 08 Apr '03

08 Apr '03

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 08 Apr '03

08 Apr '03

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