June 2001 - Wine-Devel - list.winehq.org

Re: PATCH: set_thread_buffer fixed

by Marcus Meissner

On Sun, Jun 03, 2001 at 12:34:00AM -0400, Gerard Patel wrote: > At 07:19 PM 02/06/2001 +0200, you wrote: > <snip> > >I have now changed config.h to only enable 64bit support for glibc 2.2 > >or better. > > After applying your patch to current cvs, rm config.cache, ./configure, > make depend && make Wine crashes as before. You need to run 'autoheader -l include' if any change to acconfig.h is submitted. Ciao, Marcus

June 3, 2001

Re: PATCH: set_thread_buffer fixed

by Gerard Patel

At 07:19 PM 02/06/2001 +0200, you wrote: <snip> >I have now changed config.h to only enable 64bit support for glibc 2.2 >or better. After applying your patch to current cvs, rm config.cache, ./configure, make depend && make Wine crashes as before. Did you leave something to for Alexandre Julliard implicit (he certainly knows about this stuff, I don't) ? I don't understand why _FILE_OFFSET_BITS is still defined in config.h.in. Gerard

June 3, 2001

Re: PATCH: set_thread_buffer fixed

by lawson_whitney＠juno.com

On 2 Jun 2001, Alexandre Julliard wrote: > It would be much better to do a configure check. Including features.h > from config.h is very ugly IMO (not to mention that mmap64 seems to > work fine on my glibc 2.1.3...) > > -- > Alexandre Julliard > julliard(a)winehq.com > mmap64 works fine by itself on my glibc 2.1.3 too, but #define _FILE_OFFSET_BITS 64 stops wine from working in some way I don't quite understand yet. I fear a simple ./configure function test won't be enough. I hope I'm wrong, though. Lawson ---end of recorded information--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

June 3, 2001

Re: PATCH: set_thread_buffer fixed

by Ove Kaaven

On Sat, 2 Jun 2001, Marcus Meissner wrote: > -/* This is for glibc on Linux, it will turn on 64 bit file support at compile time */ > -#define _FILE_OFFSET_BITS 64 > +#include <features.h> > +/* This is for glibc on Linux, it will turn on 64 bit file support at > + * compile time > + * Since glibc 2.1.x has various degrees of broken mmap64 prototypes, > + * we do not use this on glibc 2.1.x systems. > + */ > +#if (__GLIBC__ >= 2) && (__GLIBC_MINOR__ > 1) > +# define _FILE_OFFSET_BITS 64 > +#endif > + That's probably not going to work. The features.h is the only header that checks whether _FILE_OFFSET_BITS is defined, and it's protected against multiple inclusion, so _FILE_OFFSET_BITS must be defined *before* you include features.h. If you must check version, use autoconf.

June 3, 2001

Re: PATCH: set_thread_buffer fixed

by Alexandre Julliard

Marcus Meissner <marcus(a)jet.franken.de> writes: > Enable 64bit file operations on Linux only for glibc 2.2 or better, > since mmap64 is broken on glibc 2.1. It would be much better to do a configure check. Including features.h from config.h is very ugly IMO (not to mention that mmap64 seems to work fine on my glibc 2.1.3...) -- Alexandre Julliard julliard(a)winehq.com

June 3, 2001

Re: set_thread_buffer (fwd)

by lawson_whitney＠juno.com

This seems to have bounced once. Hope winehq feels better soon. On Fri, 1 Jun 2001 =?iso-8859-1?Q?G=E9rard_Patel_=3Cgerard.patel=40nerim.net=3E?=(a)tourian.nerim.net wrote: > Just what I have. > > if you verify if you have the same problem as myself, with current cvs > remove the line defining _FILE_OFFSET_BITS. This fixes it for me. > > Gerard > By this I understood to rip #define _FILE_OFFSET_BITS 64 out of config.h (and acconfig.h just to be sure) and rerun make. It recompiles nearly everything, of course, and makes a wine that will run my app again, so I guess it is the same problem. Now, what is the problem? :-/ glibc-2.1.3 - from Mandrake 7.2 - ?? - I am fairly sure I haven't munged any headers myself.. but Mandrake might have. Are <linux/ and <asm/ considered glibc headers? I don't see them in the rpm, but some motorist broke both my legs a while ago and it is too tough to change the CD and see what is in Slackware's glibc-2.1.2. I guess that wouldn't be conclusive anyway. gcc-2.95.2 locally built, with genuine strength-reduce bug. kernel 2.4.4 with devfs? Other? Feels to me like an inconsistancy between headers and library -? Lawson ---cut--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

June 2, 2001

Re:AnimateWindow() constants?

by Eric Pouech

> I am about to implement the AnimateWindow() function, but I don't have up to > date windows headers. I did some trial and error on a win98 box and came up > with what I think are the correct values, but could somebody check? all correct A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________ Voila vous propose une boite aux lettres gratuite sur Voila Mail: http://mail.voila.fr

June 2, 2001

Re: wine-users down?

by Ove Kaaven

On Fri, 1 Jun 2001, Francois Gouget wrote: > I didn't receive any message on wine-users since May 30th. Is the > mailing list down or is it a problem on my end? > There's been many messages since then on the newsgroup. They aren't on Corel's news server, where wine-users gets its feed from. Maybe it's temporary. > Btw, why is the link to the wine-users archive disabled on WineHQ? > (http://www.winehq.com/dev.shtml#ml) The archive links goes to integrita, and they don't have archives of wine-users. As the text above the links explains, the hypermail archives can be accessed by clicking "Subscribe", then there's an "Archives" link from there. The webpages were updated when the mailman/hypermail archives were new and almost empty, and the integrita archives were much more complete. I've wondered whether the archive links should be changed or not, though the integrita archives are still more complete than winehq's. (I had added the "Even older archives..." link below the hypermail archive index in anticipation of changing the links, but had not changed them yet)

June 2, 2001

AnimateWindow() constants?

by Bobby Bingham

I am about to implement the AnimateWindow() function, but I don't have up to date windows headers. I did some trial and error on a win98 box and came up with what I think are the correct values, but could somebody check? AW_SLIDE 0x00040000 AW_ACTIVATE 0x00020000 AW_BLEND 0x00080000 AW_HIDE 0x00010000 AW_CENTER 0x00000010 AW_HOR_POSITIVE 0x00000001 AW_HOR_NEGATIVE 0x00000002 AW_VER_POSITIVE 0x00000004 AW_VER_NEGATIVE 0x00000008 I'm pretty sure about all of them except AW_BLEND because win98 doesn't implement it. Thanks in advance Bobby Bingham uhmmmm(a)ameritech.net

June 2, 2001

Re: Finding (or not) the exact number of args

by 520053692817-0001＠t-online.de

On Fri, Jun 01, 2001 at 04:19:54PM +0000, Gaël de Chalendar wrote: > Le Mercredi 23 Mai 2001 17:19, Andreas Mohr a écrit : > > You get a nice "crash" when the program hits an unimplemented function. > > Do a backtrace, then do a disas of the code that led to the unimplemented > > function. Count the number of pushes before that call. That's usually > > the number of arguments you need to use. > > OK. Just to try I removed the stub for SHLWAPI_16. When asking for a > backtrace (bt) in the wine debugger, I get the following. Where in that di I > find the address where to disassemble ? > > Unhandled exception: unimplemented function shlwapi.16 called > in 32-bit code (0x40765056). > In 32-bit mode. > 0x40765056 (__wine_unimplemented+0x56 [shlwapi.spec.c:40] in SHLWAPI.DLL): > jmp 0 > x40765050 (__wine_unimplemented+0x50 [shlwapi.spec.c:40] in SHLWAPI.DLL) > 43 void __wine_stub_shlwapi_4(void) { __wine_unimplemented("4"); } > Wine-dbg>bt > Backtrace: > =>0 0x40765056 (__wine_unimplemented+0x56(func=0x40770eff) > [shlwapi.spec.c:40] in SHLWAPI.DLL) (ebp=40566cb8) > 1 0x40765170 (__wine_stub_shlwapi_17 [shlwapi.spec.c:53] in SHLWAPI.DLL) > (ebp=40566cc8) > 2 0x00403a1a (<Debugged process>.EntryPoint+0x95c in <Debugged process>) > (ebp=40566e6c) > 3 0x0040312c (<Debugged process>.EntryPoint+0x6e in <Debugged process>) > (ebp=40566ecc) > 4 0x400d0e92 (start_process+0x1d6 [process.c:403] in libntdll.so) > (ebp=40566f30) > 5 0x400d46b9 (SYSDEPS_DoCallOnStack+0x25(func=0x400d0cbc, arg=0x0) > [sysdeps.c:173] in libntdll.so) (ebp=40566ff0) Right before 0x403a1a, of course (since this is where the program calls from). So e.g. a disas 0x403a00 should help. Andreas Mohr -- Microsoft Windows: Made for the Internet The Internet: Made for Unix

June 1, 2001