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

winsock.h portability patch causing portability problem

by Gerald Pfeifer

Alexandre, I am afraid the following patch revision 1.52 date: 2003/03/31 23:56:35; author: julliard; state: Exp; lines: +63 -60 Try to make winsock.h more portable (based on a patch by Francois Gouget). actually caused a portability problem for FreeBSD. /usr/bin/gcc -c -I. -I. -I../../../include -I../../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -gstabs+ -Wpointer-arith -fPIC -D_REENTRANT -o pipe.o pipe.c In file included from ../../../include/winsock2.h:47, from ../../../include/windows.h:62, from ../../../include/rpc.h:22, from ../../../include/wtypes.h:2, from pipe.c:34: ../../../include/winsock.h:925: conflicting types for `htonl' /usr/include/machine/endian.h:63: previous declaration of `htonl' ../../../include/winsock.h:926: conflicting types for `htons' /usr/include/machine/endian.h:64: previous declaration of `htons' ../../../include/winsock.h:927: conflicting types for `ntohl' /usr/include/machine/endian.h:65: previous declaration of `ntohl' ../../../include/winsock.h:928: conflicting types for `ntohs' /usr/include/machine/endian.h:66: previous declaration of `ntohs' gmake[3]: *** [pipe.o] Error 1 gmake[3]: Leaving directory `/.amd_mnt/nashira/files5/test/wine/dlls/kernel/tests' gmake[2]: *** [tests] Error 2 gmake[2]: Leaving directory `/.amd_mnt/nashira/files5/test/wine/dlls/kernel' The FreeBSD declarations are unsigned long htonl __P((unsigned long)); unsigned short htons __P((unsigned short)); unsigned long ntohl __P((unsigned long)); unsigned short ntohs __P((unsigned short)); Sorry, Gerald

April 1, 2003

Re: resent: menu capture tracking fix

by Alexandre Julliard

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > [I don't know why this wasn't applied, without any comment; > resending it] You don't really expect me to apply a patch that adds a #ifdef FUBAR_CODE, do you? -- Alexandre Julliard julliard(a)winehq.com

April 1, 2003

Visual FoxPro 8 / Wine20030318 crash

by Paul McNett

I crash when building an EXE in the new version of Visual Foxpro. Any ideas? "windows" = "nt351", all dlls built-in. Here's the output leading up to the crash: fixme:hook:NotifyWinEvent (32769,0x50032,1,0)-stub! fixme:pidl:SHLogILFromFSIL (pidl=0x4032b090) fixme:dc:LockWindowUpdate (0x50033), partial stub! fixme:shell:ISVBgCm_fnGetCommandString unknown command string fixme:shell:ISVBgCm_fnGetCommandString unknown command string fixme:shell:ISVBgCm_fnGetCommandString unknown command string fixme:dc:LockWindowUpdate ((nil)), partial stub! fixme:shell:ReadCabinetState 0x4071e2e0 0x000c stub fixme:hook:NotifyWinEvent (32773,0x30031,7,1)-stub! fixme:hook:NotifyWinEvent (32768,0x90032,1,0)-stub! fixme:hook:NotifyWinEvent (32769,0x90032,256,0)-stub! fixme:hook:NotifyWinEvent (32769,0x90032,1,0)-stub! fixme:ole:DispCallFunc Do not know how to handle pvargResult 0x4071e5cc. Expect crash ... fixme:ole:DispCallFunc Method returned 0 err:ole:TLB_ReadTypeLib Loading of typelib L"E:\\src\\vfp\\sbs\\sbs.exe" failed with error 0 fixme:seh:EXC_RtlRaiseException call to unimplemented function kernel32.dll.BeginUpdateResourceA fixme:process:CreateProcessA (E:\prg\vfp8\dw15.exe,...): NORMAL_PRIORITY_CLASS ignored fixme:process:CreateProcessA (E:\prg\vfp8\dw15.exe,...): CREATE_DEFAULT_ERROR_MODE ignored fixme:win32:PE_CreateModule Security directory ignored fixme:ntdll:NtQuerySystemInformation (0x00000005,0x4028d858,0x00010000,(nil)) stub fixme:win32:PE_CreateModule Security directory ignored fixme:advapi:RegisterEventSourceW ((null),L"Microsoft Visual FoxPro"): stub fixme:advapi:ReportEventA stub fixme:advapi:DeregisterEventSource (0x1): stub fixme:wininet:InternetGetConnectedState always returning LAN connection. -- Paul McNett Liberal Earthling

April 1, 2003

Re: I/O Completion Ports (1 of 2)

by Robert Shearman

I will try to fix this sometime in the next week, depending on whether I can get CVS access to take advantage of the work Eric Pouech has done. >>> Alexandre Julliard <julliard(a)winehq.com> 03/28/03 01:56 AM >>> "Robert Shearman" <R.J.Shearman(a)warwick.ac.uk> writes: > +static int io_completion_send_data( struct thread *thread, void *cookie, struct io_completion_data * data ) > +{ > + struct io_completion_send_data_reply reply; > + int ret; > + > + reply.cookie = cookie; > + reply.signaled = STATUS_SUCCESS; > + reply.bytes_transferred = data->bytes_transferred; > + reply.completion_key = data->completion_key; > + reply.overlapped = data->overlapped; > + if ((ret = write( get_unix_fd( thread->wait_fd ), &reply, sizeof(reply) )) == sizeof(reply)) > + return 0; You cannot send different message sizes into the wait_fd pipe, this won't work since pipes don't preserve message boundaries. I'd suggest simply using the normal wait mechanism and then doing a separate call to retrieve the rest of the info. -- Alexandre Julliard julliard(a)winehq.com

April 1, 2003

Re: valgrind for WINE

by Alexandre Julliard

Adam Gundy <arg(a)cyberscience.com> writes: > a new version of the valgrind patch has been uploaded to sourceforge - > the only change is a small fix to the signal handling which should > prevent "signal handler frame" uninitialized errors. > > http://sourceforge.net/tracker/index.php?func=detail&aid=710006&group_id=46… > > comments? bug reports? success stories? I played a bit with it, it works pretty well, and I have already fixed a few bugs found with it. Great work! I have also applied those of your fixes that seemed correct, the rest will need a bit more work The signal stuff in particular is not going to work properly with NPTL, it would be really better if we could somehow make valgrind use real threads. I have no idea if this is possible though. -- Alexandre Julliard julliard(a)winehq.com

April 1, 2003

Re: A few questions on the mingw port.

by Steven Edwards

Alexandre Julliard wrote: >The winsock.h issues should hopefully be fixed now. I'm not sure we >should disable 16-bit code by default, you will want to support that >at some point. >I added a fix for that, hope it will work. The ultimate goal is to use >winegcc etc. in the Wine build process, so it's better if they can >work for you too. > Cool, I will test your fixes tommrow. >It seems that mingw atexit handling is not Windows compatible. I'm not >sure why they did it that way, but IMO this should be considered a >mingw bug. > > > Ok I will also file a bug report with them and spam that list for a few days till someone answers <g> Thanks Steven

April 1, 2003

Re: Compiling Wine sources with duplicated include parameters

by Alexandre Julliard

"Dimitrie O. Paun" <dimi(a)intelliware.ca> writes: > True, but why do we need the -I.? Do we need to ever include anything > from the current build dir? Yes, some headers are generated, for instance the y.tab.h files. -- Alexandre Julliard julliard(a)winehq.com

April 1, 2003

Re: valgrind for WINE

by Eric Pouech

Adam Gundy wrote: > a new version of the valgrind patch has been uploaded to sourceforge - > the only change is a small fix to the signal handling which should > prevent "signal handler frame" uninitialized errors. > > http://sourceforge.net/tracker/index.php?func=detail&aid=710006&group_id=46… > > comments? bug reports? success stories? did test it yet. As a global note, I think it would be appreciated breaking the patch in smaller bits... it makes it easier to track/follow what happens. For example, I don't see any reason for including the msvcrtd patches into this patch I think that Alexandre is currently integrating (bit per bit) your changes into wine. look for the patch about zeroing the request zones (which is another implementation of your structure packing), as well as local availability of the thread PID on a more minor side of things, I would keep the VALGRIND prefix in heap.c last point, using the .vg extension to the wine script may not be optimal. it won't work (as it is written) for winelib programs (which got started also thru the wine script) one solution would be (to follow your idea) to link (for a winelib app called foo) foo.vg to script wine (and change your rule something like *.vg|*/*.vg). another option would be to embed this support as an option to the wine script (like --valgrind) how are your patches doing on the "other side" (I mean valgrind's) ? A+ -- Eric Pouech

April 1, 2003

Re: wine/ tools/winewrap.c tools/winegcc.c include ...

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > OK, here's a patch to add _spawnvp to the portability lib. There > are still a few questions: > -- Should we provide the entire family (I wouldn't, unless we > really need them, but that can wait for that need :))? Yep that can wait. > -- What about conflicts with stuff in dlls/msvcrt/process.c? > What if we need wine/port. in process.c in the future > (not a big deal, we can fudge it then)? What about winelib > apps that link with msvcrt? If they link with msvcrt then they are not supposed to use wine/port.h. To avoid trouble with process.c I'd suggest naming the function spawnvp, without the underscore prefix, and making it call the real _spawnvp on Windows. -- Alexandre Julliard julliard(a)winehq.com

April 1, 2003

Re: Compiling Wine sources with duplicated include parameters

by Alexandre Julliard

Rolf Kalbermatter <rolf.kalbermatter(a)citeng.com> writes: > While downloading and compiling the latest CVS sources I noticed that the > command line for each (most?) source files reads like > > gcc -c -I. -I. -I../../include -I../../include ............. or similar > > This is not a serious problem but the duplication of the two include parameters > strikes me as odd and definitely unnecessary, making the command line unnecessarily > long. It's needed for out of tree builds, in that case the include paths are all different. -- Alexandre Julliard julliard(a)winehq.com

April 1, 2003