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

RE: winapi update

by Patrik Stridvall

> Patrik Stridvall <ps(a)leissner.se> writes: > > > The make_filter.diff patch is quite nice. > > > > Try it after applying it with by running: > > make filter > > I'm not sure about the portability of the wildcard rule. Why don't you > have make_filter call make instead of the other way around? This > would avoid the need for changing the makefiles at all. Well, make_filter actually calls make already. :-) Seriously, one reason that I added it to the Makefiles in the first place is that make_filter doesn't know what version of make to use. Sure it is called make on almost all systems and gmake (GNU Make) on most of rest, but since the user knows and calls "make", $(MAKE) contains the correct "make". Oh well, I guess just calling make will work on most platforms, it will on all platforms that I current use. The Wine Makefile is supposed to be portable so I guess it will have to do.

July 26, 2001

Re: Even more misc fixes

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > No it isn't. I'm not sure why it was added in the first place. > It is neither used by Wine, nor defined by Windows. It is in the Windows headers I have. > As you wish, but as I said HOOKPROC can't be fixed with STRICT. Why not? > But OK I will try and compile with -DSTRICT and see what happends. > IIRC somebody tried that but it didn't turn out so well. No it needs a lot of fixes, which is what the warnings are here to remind us of. -- Alexandre Julliard julliard(a)winehq.com

July 26, 2001

RE: Even more misc fixes

by Patrik Stridvall

> The volatile stuff in dplay.h is part of the Windows header, you > cannot remove it. No it isn't. I'm not sure why it was added in the first place. It is neither used by Wine, nor defined by Windows. In fact only a few strange headers use volitile at all, and none of them is supported by Wine. > Most of these are because of the transition to making HANDLE a void* > and compiling with STRICT. Yes, I notice this was the case with TIMERPROC casts. However it is no so with the HOOKPROC casts, and yes it is the same with the real Windows headers. > Please don't add typecasts, consider the > warnings as an incentive to do the right fix... As you wish, but as I said HOOKPROC can't be fixed with STRICT. But OK I will try and compile with -DSTRICT and see what happends. IIRC somebody tried that but it didn't turn out so well. Oh well, lets see what happends.

July 26, 2001

Re: Dose wine people hate Solaris?

by EriK W

> The only message I see from you is the one you posted on wine-devel > the 24th, two *days* ago. Actually, before this I posted it to comp.emulators-windows.wine couple times without even a reply. :) And I think I am not the only one encountered this problem, I found exactly same report http://wine.codeweavers.com/cgi-bin/fom?_highlightWords=usr%20local%20lib%20 libwine%20unicode%20so%20open%20failed&file=424 with no any follow up yet, Though I don't know when he reported this problem. Anyway, thanks for your work and replies! > > > Do you guys hate solaris? :) > > I don't think so. But few Wine developpers use Solaris which makes it > harder for them to help you. I myself > > [...] > > Does anybody has even a suggestion for me? pls don't tell me nuke my > > solaris. :) > > No, certainly not. We need you if Wine is going to keep > supporting Solaris :-) > > > So from you previous email: > > [...] > > /usr/openwin/include/X11/Xutil.h:56: warning: ignoring pragma: "@(#)Xutil.h > > 1.2 00/07/05 SMI > > This one does not really matter. > > > > gcc -Wl,-G -Wl,-h,/usr/local/lib/libwine_tsx11.so locking.o ts_xf86dga.o > > ts_xf86dga2.o ts_xf86vmode.o ts_xshm.o ts_xlib.o ts_xresource.o > > ts_xvideo.o ts_xutil.o ts_shape.o ts_xpm.o -o libwine_tsx11.so.1.0 > > rm -f libwine_tsx11.so && ln -s libwine_tsx11.so.1.0 libwine_tsx11.so > > LD_LIBRARY_PATH="../../unicode:$LD_LIBRARY_PATH" > > ../../tools/winebuild/winebuild -fPIC -L../../dlls -o ntdll.spec.c -spec > > ./ntdll.spec > > ld.so.1: ../../tools/winebuild/winebuild: fatal: > > /usr/local/lib/libwine_unicode.so: open failed: No such file or directory > > winebuild is linked with 'libwine_unicode.so' which should have been > compiled previously and should be in 'wine/unicode'. So the > LD_LIBRARY_PATH setting seems correct and yet it seems winebuild cannot > execute because that library cannot be found. > So: > * does unicode/libwine_unicode.so exist? > * in the compilation process you should see Wine go into the unicode > subdirectory and compile stuff there. Do you indeed see something like > that? > * try to start winebuild manually. When in Wine's root directory type > "./tools/winebuild/winebuild'. Does it work? If not try to tweak > LD_LIBRARY_PATH to get it to work. Maybe absolute paths work better than > relative ones? Doesn't work, I guess there is a problem in Makefile. Eventually I copied the file to /usr/local/lib . But then I run into another problem. gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -mpreferred-stack-bou ndary=2 -fPIC -DSTRICT -D_REENTRANT -I/usr/openwin/include -o msc.o msc.c gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -mpreferred-stack-bou ndary=2 -fPIC -DSTRICT -D_REENTRANT -I/usr/openwin/include -o registers.o registers.c gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -mpreferred-stack-bou ndary=2 -fPIC -DSTRICT -D_REENTRANT -I/usr/openwin/include -o source.o source.c gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -mpreferred-stack-bou ndary=2 -fPIC -DSTRICT -D_REENTRANT -I/usr/openwin/include -o stabs.o stabs.c stabs.c:1271: warning: `struct r_debug' declared inside parameter list stabs.c:1271: warning: its scope is only this definition or declaration, which is probably not what you want. stabs.c: In function `DEBUG_WalkList': stabs.c:1274: storage size of `lm' isn't known stabs.c:1284: dereferencing pointer to incomplete type stabs.c:1274: warning: unused variable `lm' stabs.c:1273: warning: `lm_addr' might be used uninitialized in this function stabs.c: In function `DEBUG_RescanElf': stabs.c:1302: storage size of `dbg_hdr' isn't known stabs.c:1309: `RT_CONSISTENT' undeclared (first use in this function) stabs.c:1309: (Each undeclared identifier is reported only once stabs.c:1309: for each function it appears in.) stabs.c:1313: `RT_ADD' undeclared (first use in this function) stabs.c:1315: `RT_DELETE' undeclared (first use in this function) stabs.c:1310: warning: unreachable code at beginning of switch statement stabs.c:1302: warning: unused variable `dbg_hdr' stabs.c: In function `DEBUG_ReadExecutableDbgInfo': stabs.c:1324: `Elf32_Dyn' undeclared (first use in this function) stabs.c:1324: parse error before `dyn' stabs.c:1325: storage size of `dbg_hdr' isn't known stabs.c:1336: `dyn' undeclared (first use in this function) stabs.c:1339: `DT_DEBUG' undeclared (first use in this function) stabs.c:1339: `DT_NULL' undeclared (first use in this function) stabs.c:1325: warning: unused variable `dbg_hdr' make[1]: *** [stabs.o] Error 1 make[1]: Leaving directory `/export/home/system/wine-20010629/debugger' make: *** [debugger/winedbg] Error 2 Compilation failed, aborting install. Any idea? > > > > -- > > > >

July 26, 2001

Re: winapi update

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > The make_filter.diff patch is quite nice. > > Try it after applying it with by running: > make filter I'm not sure about the portability of the wildcard rule. Why don't you have make_filter call make instead of the other way around? This would avoid the need for changing the makefiles at all. -- Alexandre Julliard julliard(a)winehq.com

July 26, 2001

Re: Even more misc fixes

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > * include/commctrl.h, > include/dplay.h: > Cleanup/removal of unnessary things that would have made > winapi_* parsing more complicated. The volatile stuff in dplay.h is part of the Windows header, you cannot remove it. > * dlls/comctl32/commctrl.c, > dlls/comctl32/tab.c, > dlls/dinput/dinput_main.c, > dlls/dsound/dsound_main.c, > dlls/ole32/clipboard.c, > dlls/ole32/ole2.c, > dlls/wineps/ps.c, > dlls/winmm/joystick.c, > dlls/winmm/wineoss/midi.c, > loader/dos/dosmod.c, > windows/caret.c: > Fixed some warnings. Most of these are because of the transition to making HANDLE a void* and compiling with STRICT. Please don't add typecasts, consider the warnings as an incentive to do the right fix... -- Alexandre Julliard julliard(a)winehq.com

July 26, 2001

Re: Prevent excessive clipping in SysListView32

by Ulrich Weigand

Uwe Bonnes wrote: > >>>>> "Medland," == Medland, Bill <Bill.Medland(a)accpac.com> writes: > > Medland,> I am not very comfortable with this one but strange as it may > Medland,> seem it solves the problem. I'd love to know why. > Medland,> <<diff13.txt>> Bill Medland (medbi01(a)accpac.com) Prevents > Medland,> excessive clipping in SysListView32. > > Medland,> > Medland,>-static inline int perfect_graphics(void) > Medland,>+static int perfect_graphics(void) > Medland,> { > Medland,> static int perfect = -1; > Medland,> if (perfect == -1) > Medland,> > > Some C-Expert is requested here, but I suspect that in the old function the > variable "perfect" was created in every instantiation of the > "perfect_graphics" inlined function. Could you perhaps try to declare the > "perfect" outside the inlined function, like > > static int perfect = -1; > static inline int perfect_graphics(void) No, 'inline' must not change the semantics of the routine in any way, including static variables. If the app behaves differently when 'perfect_graphics' is inlined, this is a compiler bug. Which compiler version are you using? Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

July 26, 2001

How do I stop clipping?

by Bill Medland

I don't like submitting incomplete code but I may have little choice unless someone can point me in the correct direction here. As you may guess from the following, my Windows experience is not that extensive but I think it's enough to allow me to make sensible contributions. I am working on correcting the LISTVIEW_DrawLargeItem function, especially when the item text is large. I have already got most of the way. However the problem is this. When a user selects a large icon the text should be written completely (by calling DrawText with DT_NOCLIP). It is doing so; I can prove it by resizing the window and I will see the full text being displayed for a selected item. However when drawing it at the moment of selecting it, the text is being clipped to the usual two and a bit rows. Presumably this means that there is a clipping rectangle in the DC or the window that I need to inflate. Or Do I simply invalidate that rectangle (from within the WM_PAINT handler!!!). Any help would be appreciated. Bill

July 26, 2001

Re: Handling X errors using exception handlers

by Alexandre Julliard

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: > Do you plan to implement it or should I do it (be warned though that I can > work on it only if the weather is bad this week-end :-) ). I'll do it. I had a version working some time ago, I just need to adapt it to the new per-thread displays. -- Alexandre Julliard julliard(a)winehq.com

July 26, 2001

Re: Handling X errors using exception handlers

by Lionel Ulmer

> > - it cannot 'expect' more than one kind of error at the same time > > I was thinking you could use a special value as a "wildcard" for the > error codes, in which case it wouldn't be tested for a match. Hmmm, yes, nice and clean :-) > > - I am not sure that the parameters thing are really a good idea. Are we > > sure that the error code are the same on all X servers ? Are they > > standardized ? > > They are part of the X spec AFAICT, so yes it should be pretty much > standard. Yeah, now that I think of it, it should be part of the spec, except for the extension errors... But as we store the 'error base', it should work also for these cases. Do you plan to implement it or should I do it (be warned though that I can work on it only if the weather is bad this week-end :-) ). Lionel -- Lionel Ulmer - http://www.bbrox.org/

July 26, 2001