February 2005 - Wine-Devel - list.winehq.org

Build on Fedora core 3 on AMD64

by Adrian Harvey

I am having trouble getting wine (latest CVS) to build on my AMD64 box runngin Fedora core3, and I was hoping some autoconf wizard might be able to help. To begin at the beginning, the issue that occurs during build is: gcc -m32 -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack- boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ddraw.dll.dbg.o ddraw.dll.dbg.c .../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./ddraw.spec convert.o dclipper/main.o ddraw/hal.o ddraw/main.o ddraw/thunks.o ddraw/user.o dpalette/hal.o dpalette/main.o dsurface/dib.o dsurface/fakezbuffer.o dsurface/gamma.o dsurface/hal.o dsurface/main.o dsurface/thunks.o dsurface/user.o dsurface/wndproc.o helper.o main.o regsvr.o struct_convert.o ddraw.dll.dbg.o version.res -o ddraw.dll.so -L../../dlls -lole32 -luser32 -lgdi32 -ladvapi32 -lkernel32 - L../../libs/wine -lwine -ldxguid -luuid -L/usr/X11R6/lib64 -lXext - lX11 -L../../libs/port -lwine_port /usr/bin/ld: skipping incompatible /usr/X11R6/lib64/libXext.so when searching for -lXext /usr/bin/ld: skipping incompatible /usr/X11R6/lib64/libXext.a when searching for -lXext /usr/bin/ld: cannot find -lXext collect2: ld returned 1 exit status winegcc: gcc failed. make[2]: *** [ddraw.dll.so] Error 2 make[2]: Leaving directory `/home/adrian/wine/dlls/ddraw' make[1]: *** [ddraw] Error 2 make[1]: Leaving directory `/home/adrian/wine/dlls' make: *** [dlls] Error 2 So it seems that ld is finding the 64-bit version and failing to link it. It seems that the reason for this is that configure uses xmkmf/imake to locate the X11 library directory and that this is always returning the .../lib64 version. I have split out the Imakefile that configure generates, and tried various methods to prevent it seeing the system as 64 bit and handing out the lib64 directory instead of the lib one, but to no avail. running: setarch i386 imake -v -DUseInstalled -I/usr/X11R6/lib/X11/config (to emulate an xmkmf, but with verbosity, which xmkmf doesn't do) gives: gcc -I. -D__amd64__ -D__amd64__ -traditional -Dlinux -DUseInstalled - I/usr/X11R6/lib/X11/config -E -v Imakefile.c Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.2/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man -- infodir=/usr/share/info --enable-shared --enable-threads=posix -- disable-checking --with-system-zlib --enable-__cxa_atexit --disable- libunwind-exceptions --enable-languages=c,c++,objc,java,f77 --enable- java-awt=gtk --host=x86_64-redhat-linux Thread model: posix gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) /usr/libexec/gcc/x86_64-redhat-linux/3.4.2/cc1 -E -traditional-cpp - quiet -v -I. -I/usr/X11R6/lib/X11/config -D__amd64__ -D__amd64__ -Dlinux -DUseInstalled Imakefile.c -mtune=k8 ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat- linux/3.4.2/../../../../x86_64-redhat-linux/include" #include "..." search starts here: #include <...> search starts here: . /usr/X11R6/lib/X11/config /usr/local/include /usr/lib/gcc/x86_64-redhat-linux/3.4.2/include /usr/include End of search list. I can see that gcc is being passed -D__amd64__ but I can't trace where this is coming from... Am I hunting on the right lines, or is there somthing much simpler I have missed? Also, what do we need to change in the autoconf stuff to allow wine to build correctly on x86_64 multi-arch systems? (assuming that it is not just my system being broken somehow) Thanks for any help, Adrian

Feb. 26, 2005

Re: New uninstaller

by Mike McCormack

Jonathan Ernst wrote: > As requested, I'm trying to make a new uninstaller using a dialog > instead of a window. > > It's my first windows program and I have something working but there are > still some issues. > > If someone could help with some of the following problems, I'd be very > thanfull. Cool. Some comments: The dialog box procedure should not handle WM_PAINT or WM_CLOSE, so just delete those cases from the switch statement. Don't send WM_SETFONT messages to the controls in the dialog. Let the dialog template define what the dialog looks like. Your WM_INITDIALOG handler should fill the listbox, not WM_PAINT. You can remove the "No items selected" message if uninstall is clicked without a listbox element select. That's just going to annoy people, and it's not internationalized. Mike

Feb. 26, 2005

Re: How do native win32 apps end up calling into x11drv?

by Mike Hearn

On Fri, 25 Feb 2005 11:00:59 -0500, Adam Connell wrote: > I'm trying to understand how windows drawing gets translated into X in wine > and so I was looking at the {im,ex}ports of x11drv and gdi32. x11drv depends > on gdi32 and just seems to export a good chunk of the api that gdi32 exports > (BitBlt etc). gdi32 doesn't depend on x11drv or even Xlib. How do native > win32 apps end up calling into x11drv? Well, the x11drv is built like a graphics driver would be in real windows. It's loaded in dlls/user/user_main.c, and then the USER and GDI driver table is filled via GetProcAddress. The USER/GDI calls then delegate to the x11drv via these function pointers when necessary. thanks -mike

Feb. 25, 2005

Re: USER32: GetScrollBarInfo

by Alexandre Julliard

Vitaly Lipatov <lav(a)etersoft.ru> writes: > +static BOOL SCROLL_GetScrollBarInfo(HWND hwnd, LONG idObject, LPSCROLLBARINFO psbi) > +{ > + RECT rect; > + INT arrowSize, thumbSize, thumbPos, nBar, vertical; > + FIXME("check me"); This doesn't sound very encouraging... -- Alexandre Julliard julliard(a)winehq.org

Feb. 25, 2005

Re: setupapi: enumerate serial ports

by Alexandre Julliard

Juan Lang <juan_lang(a)yahoo.com> writes: > I'm not sure it is. I just tried it, and QueryDosDevice returns success > for every COMx passed to it, even though only com1 exists in my dosdevices > directory. Unless QueryDosDevice is also wrong (I don't know.) You don't necessarily need symlinks, by default it will fallback to /dev/ttyS?. So if the corresponding ttyS? device exists QueryDosDevice will succeed, which is correct since you do have that serial port. -- Alexandre Julliard julliard(a)winehq.org

Feb. 25, 2005

Re: setupapi: enumerate serial ports

by Juan Lang

--- Alexandre Julliard <julliard(a)winehq.org> wrote: > > +/* Based on code from winspool's info.c */ > > +static UINT SETUP_CountSerialPorts(void) > > +{ > > + UINT i, ret; > > + > > + /* FIXME: it should be possible for more than four COM ports to > exist, not > > + * sure why we retain that limit, but winspool does too so go > with it. > > + */ > > + for (i = 0, ret = 0; i < 4; i++) > > + { > > + if (SETUP_SerialPortExists(i)) > > + ret++; > > + } > > + TRACE("returning %d\n", ret); > > + return ret; > > +} > > It would probably be better to use QueryDosDevice here. I'm not sure it is. I just tried it, and QueryDosDevice returns success for every COMx passed to it, even though only com1 exists in my dosdevices directory. Unless QueryDosDevice is also wrong (I don't know.) --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250

Feb. 25, 2005

status of winetest.exe

by Stefan Leichter

Hello Paul, i have noticed that the winetest are not longer built since the middle of the week. Can you take a look if something is broken? Thanks Stefan

Feb. 25, 2005

Re: New uninstaller

by Ivan Leo Puoti

Jonathan Ernst wrote: > 4) Please tell me if you see things that are bad in the attached code, > so that I'll fix it before submitting a patch. I think you probably want to pass a valid HINSTANCE to DialogBox, to do this you should start your program with WinMain() instead of main(). Ivan.

Feb. 25, 2005

Re: using safe string functions in wine

by Alexandre Julliard

James Hawkins <truiken(a)gmail.com> writes: > What is your opinion on whether we should implement and use either the > user-mode or kernel-mode (or both) string safe functions? Using these > functions instead of the standard c string functions would promote > consistency and security in the wine code base. On the other hand, > using these functions adds another layer of calls to the code. What > are other pro's and con's of using string safe functions? The main con is that these functions are not standard, and ugly as hell. Also, all they do is allow someone to write bad code without opening too many security holes; IMHO writing good code instead is a better way to achieve that. -- Alexandre Julliard julliard(a)winehq.org

Feb. 25, 2005

New uninstaller

by Jonathan Ernst

As requested, I'm trying to make a new uninstaller using a dialog instead of a window. It's my first windows program and I have something working but there are still some issues. If someone could help with some of the following problems, I'd be very thanfull. 1) Strange problem with UpdateWindow uninstaller.c, line 264 I implemented a search/filter field and I want to repaint the window after each input in the EDITTEXT control. However, when I call UpdateWindow on this line, the value returned is 1 so that a WM_PAINT message should be sent right ? But strangly no message is sent and I have to make something else (like moving the dialog) to force the window to repaint and filter the entries. The funny thing is that UpdateWindow on line 279 works just fine. I guess it's a bug in my code and not in Wine so I'd be glad if you could help me. 2) Improve filter code Currently I filter the entries that match exactly the filter string. I would like to at least make a case insensitive strstr on the string. What's the best way to do it (See uninstaller.c, line 235) 3) Stringtables a)Is there a way to load localized strings without having to guess beforehand the size of the string in each language ? b)Is there a way to not call LoadString for each string ? c)Where is the best place to load every string of a stringtable ? in main(), just before calling DialogBox() ? 4) Please tell me if you see things that are bad in the attached code, so that I'll fix it before submitting a patch. Thanks you for your help

Feb. 25, 2005