- Wine-Devel - list.winehq.org

Re: MSVCRT: Generating relay stubs for libc forwards/varargs
by Jon Griffiths Feb. 26, 2005

Feb. 26, 2005

Hi Uwe, >I think it would be helpfull, if we could generate debug stubs for >these functions. Can anybody help? If you have the SDK headers, winedump in spec mode can generate this for you. Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250

2 2

MSVCRT: Generating relay stubs for libc forwards/varargs
by Uwe Bonnes Feb. 26, 2005

Feb. 26, 2005

Hallo, in msvcrt a lot of functions are of type vararg (e.g. printf) or are forwards into the Linux libc (e.g. strstr) and so leave no trace in a +relay log. This makes it harder to debug. I think it would be helpfull, if we could generate debug stubs for these functions. Can anybody help? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: Relax test requirements to accomodate fuzz of msacm
by Robert Reif Feb. 26, 2005

Feb. 26, 2005

Jeremy White wrote: > Robert has persuaded me that msacm on Windows does make 'fuzzy' > conversions; > an 8,000 byte buffer is up sampled to a 47,992 byte buffer instead of > the logical (and correct seeming) 48,000 byte buffer. This means that > when we go to get the position after playing the answer comes up as > 47992 instead of 48,000, which causes a winmm test failure. The real fix is to fix the wave mapper to do another conversion when the previous one is incomplete. We will have to do this anyway if we ever try to support non PCM formats.

2 3

Re: Problem using winelib to compile Std Lib strings
by Jon Griffiths Feb. 26, 2005

Feb. 26, 2005

Hi Rob, >I get a few errors like the following: >error: ::div has not been declared >error: ::ldiv has not been declared div and ldiv may or may not be included in the std namespace. Try changing the calls to either remove the scope resolution from their calls or adding std before it. >And tons about /usr/include/pthread.h like the following: >error: uintptr_t does not name a type >error: caddr_t has not been declared You may need to rebuild your gcc supplied headers, check out: http://supportforum.sun.com/sunos/index.php?t=msg&th=2097&start=0&rid=0 for details. If you need/needed to make any fixes to Wine to get it working under Solaris, please consider sending any changes to wine-patches or documenting the process (AFAIK not many ppl are using Wine under solaris). Hope this helps, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250

1 0

Re: USER32: GetScrollBarInfo
by Alexandre Julliard Feb. 26, 2005

Feb. 26, 2005

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

2 1

Build on Fedora core 3 on AMD64
by Adrian Harvey Feb. 26, 2005

Feb. 26, 2005

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

2 1

Space Empires: Starfury
by Adam Babcock Feb. 26, 2005

Feb. 26, 2005

I have posted to the list before about this game. Anyway, a group of us over at the publisher's forum really want to see this game running, so we will be getting in #starfury on freenode this saturday to try and get it to run. We would really appreciate the help if anyone from the list with a more technical background on the inner workings of wine would join in and help. We've set a starting time of around 15h00 UTC, so if any of you wanted to join in, would be greatly appreciated.

2 1

How do native win32 apps end up calling into x11drv?
by Adam Connell Feb. 25, 2005

Feb. 25, 2005

Greetings, 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? Cheers, Adam

2 1

Re: setupapi: enumerate serial ports
by Alexandre Julliard Feb. 25, 2005

Feb. 25, 2005

Juan Lang <juan_lang(a)yahoo.com> writes: > +/* 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. -- Alexandre Julliard julliard(a)winehq.org

2 2

using safe string functions in wine
by James Hawkins Feb. 25, 2005

Feb. 25, 2005

Hey, While perusing msdn recently, I stumbled across string safe functions. These functions were created to replace the standard c string handling routines. The following are some design criteria of string safe functions (msdn): * Always NULL-terminate the string. * Always take a destination buffer size. * Always return consistent return codes (an HRESULT). * Support 32-bit and 64-bit environments. * Flexibility. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/h… 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? -- James Hawkins

3 2