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

CVS won't compile with wine/dlls/winsock socket.c ws2_32.spec patch applied

by Tony Lambregts

wine compiles fine with my system until this patch is applied http://www.winehq.com/hypermail/wine-cvs/2002/04/0087.html after it is applied it stops with the following errors > > socket.c: In function `WSASendTo': > socket.c:1990: sizeof applied to an incomplete type > socket.c:2000: arithmetic on pointer to an incomplete type > socket.c:2000: dereferencing pointer to incomplete type > socket.c:2001: arithmetic on pointer to an incomplete type > socket.c:2001: dereferencing pointer to incomplete type > socket.c: In function `WSARecvFrom': > socket.c:3286: sizeof applied to an incomplete type > socket.c:3295: arithmetic on pointer to an incomplete type > socket.c:3295: dereferencing pointer to incomplete type > socket.c:3296: arithmetic on pointer to an incomplete type > socket.c:3296: dereferencing pointer to incomplete type > make: *** [socket.o] Error 1 I changed directory to dlls/winsock and did make clean make depend make I have attached a log of the session if that will help it seems it doesn't like this code and I (moron user ) can't see anything wrong with it . > int i, n, fd, err = WSAENOTSOCK; > struct iovec* iovec; > struct msghdr msghdr; > > TRACE ("socket %04x, wsabuf %p, nbufs %ld, flags %ld, to %p, tolen > %d, ovl %p, func %p\n", > s, lpBuffers, dwBufferCount, dwFlags, > to, tolen, lpOverlapped, lpCompletionRoutine); > > fd = _get_sock_fd(s); > > if ( fd == -1 ) > goto error; > > iovec = WS_ALLOC ( dwBufferCount * sizeof (struct iovec) ); I welcome your advice, fixes or flames Tony Lambregts Script started on Mon Apr 8 11:29:24 2002 [tony(a)tony winsock]$ make clean rm -f *.o *.a *.so *.ln \#*\# *~ *% .\#* *.bak *.orig *.rej *.flc *.spec.c *.spec.def *.glue.c y.tab.c y.tab.h lex.yy.c core tests/testlist.c [tony(a)tony winsock]$ make depend ../../tools/makedep -I. -I. -I../../include -I../../include -C. async.c socket.c -C. [tony(a)tony winsock]$ make LD_LIBRARY_PATH="../../unicode:$LD_LIBRARY_PATH" ../../tools/winebuild/winebuild -fPIC -L../../dlls -o winsock.spec.c -spec winsock.spec gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -fPIC -D__WINE__ -DUSE_WS_PREFIX -D_REENTRANT -I/usr/X11R6/include -o winsock.spec.o winsock.spec.c gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -fPIC -D__WINE__ -DUSE_WS_PREFIX -D_REENTRANT -I/usr/X11R6/include -o async.o async.c gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -fPIC -D__WINE__ -DUSE_WS_PREFIX -D_REENTRANT -I/usr/X11R6/include -o socket.o socket.c socket.c: In function `WSASendTo': socket.c:1990: sizeof applied to an incomplete type socket.c:2000: arithmetic on pointer to an incomplete type socket.c:2000: dereferencing pointer to incomplete type socket.c:2001: arithmetic on pointer to an incomplete type socket.c:2001: dereferencing pointer to incomplete type socket.c: In function `WSARecvFrom': socket.c:3286: sizeof applied to an incomplete type socket.c:3295: arithmetic on pointer to an incomplete type socket.c:3295: dereferencing pointer to incomplete type socket.c:3296: arithmetic on pointer to an incomplete type socket.c:3296: dereferencing pointer to incomplete type make: *** [socket.o] Error 1 [tony(a)tony winsock]$ exit exit Script done on Mon Apr 8 11:30:32 2002

April 8, 2002

Re: Starting application from a directory with some kernel32.dll

by winedev＠admdev.com

Wouldn't using a native kernel32.dll be a bad and a snowballs-chance-in-hell-of-working thing anyway? :) Regards, | It's always bad news in computing.. and beware | of anything claming to be good news - because | its probably a virus. - Salmon Days Ender | (James Brown) | [Nehahra, EasyCuts, PureLS, www.QuakeSrc.org] On Mon, 8 Apr 2002, Uwe Bonnes wrote: > Date: Mon, 8 Apr 2002 16:18:23 +0200 > From: Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> > To: wine-devel(a)winehq.com > Subject: Starting application from a directory with some kernel32.dll > > Hallo, > > when an application is run in a directory, where there is also a kernel32.dll, > and this is _not_ the system directory, MODULE_GetLoadOrder doesn't strip > the path and therefore crashes when native kernel32.dll is loaded. > > While the header of MODULE_GetLoadOrder talks about "any path is stripped", > the function only strips the path for "16 bit modules or if the module > resides in the system directory " > > Is this intended behaviour? > > Bye > > -- > Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- >

April 8, 2002

[PATCH] winemaker + DLL paths

by Martin Wilck

I found that winemaker-generated configure scripts bail out with recent CVS versions of wine. The appended patch fixes this. It may be not exactly what the winemaker authors intended, but at least it generates working configure scripts for me. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy --- tools/winemaker.OLD Tue Apr 2 16:51:51 2002 +++ tools/winemaker Mon Apr 8 16:45:17 2002 @@ -2732,14 +2732,14 @@ WINE_DLL_ROOT="/lib:/lib/dlls:/usr/lib:/usr/lib/dlls:/usr/local/lib:/usr/local/lib/dlls" fi fi -AC_PATH_FILE(WINE_DLL_ROOT,[libntdll.so],[ - AC_MSG_ERROR([Could not find the Wine dlls (libntdll.so)]) +AC_PATH_FILE(WINE_DLL_ROOT,[libntdll.dll.so],[ + AC_MSG_ERROR([Could not find the Wine dlls (libntdll.dll.so)]) ],[$WINE_DLL_ROOT]) -AC_PATH_LIBRARY(WINE_DLL_ROOT,[-lntdll],[$WINE_LIBRARY_PATH -lwine -lwine_unicode],[ - AC_MSG_ERROR([Could not link with the Wine dlls (libntdll.so)]) +AC_PATH_LIBRARY(WINE_DLL_ROOT,[-lntdll.dll],[$WINE_LIBRARY_PATH -lwine -lwine_unicode],[ + AC_MSG_ERROR([Could not link with the Wine dlls (libntdll.dll.so)]) ],[$WINE_DLL_ROOT]) -WINE_DLL_PATH="-L$WINE_DLL_ROOT" +WINE_DLL_PATH="-L$WINE_DLL_ROOT/wine" if test -n "$LD_PATH" then

April 8, 2002

Starting application from a directory with some kernel32.dll

by Uwe Bonnes

Hallo, when an application is run in a directory, where there is also a kernel32.dll, and this is _not_ the system directory, MODULE_GetLoadOrder doesn't strip the path and therefore crashes when native kernel32.dll is loaded. While the header of MODULE_GetLoadOrder talks about "any path is stripped", the function only strips the path for "16 bit modules or if the module resides in the system directory " Is this intended behaviour? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

April 8, 2002

Re: Running tests on windows

by Geoffrey Hausheer

On Monday 08 April 2002 00:23, Francois Gouget wrote: > I think I will work on extending your script to also generate > Makefiles for use with Visual C++. The way it will work with Visual C++ > is that you are supposed to run a batch script provided by Visual C++ > (vcvars32.bat). This script sets a number of environment variables > which point to the location of the headers, etc. and which you can also > use in your Makefiles. > Does Mingw provide something similar? Could we have a way of forcing > the user to set some environment variables or query the values from him? > (my batch-script skills are pretty rusty :-) No mingw does not by default provide anything like that. We could force the user to set an environment variable pointing to the mingw root dir (but we might as well just have them change one line in the Makefile instead). Or we could do something really nasty and try to locate it by searching the path. I can do all of this in cygwin/(mingw w/ msys) using gnu-make specifics (which I think is a bad idea, since I was trying to keep the Makefile as portable as possible). Or maybe this can be done by launching make through a .bat file which locates the necessary headers, though I haven't written one for nearly 10 years, and am probably a bit rusty too. > About using the Mingw headers vs. the Wine headers vs. Visual C++ > headers. I say: use the headers of the environment in which you are. So > when compiling with Mingw use the Mingw headers and when compiling with > Visual C++ use the Visual C++ headers. As long as we don't use the Wine > headers on Windows... > Hopefully the Mingw headers will be complete enough for our tests. It sounds like it is not likely that mingw/cygwin headers will be complete enough for our needs (I already ran into this with OpenThread...which wine got wrong too). However, I was able to work around this for the tests I've written. As a middle gound, I will submit a patch for the perl script that allows the user to use either native or wine's headers. This should make everyone happy. Also, there is no reason not to submit patches to cygwin/mingw. If we ever get a reasonably thorough test suite, it would be just as valid for testing them as it is for testing wine. Of course we'd probably have to send them patches based on the X11 fork, since wine's headers are now all LGPLd (I haven't looked at the mingw/cygwin licenses) Thanks, .Geoff

April 8, 2002

Re: ChangeSet ID: 10178643640749867230924828 - oops.

by Huw D M Davies

On Sat, Apr 06, 2002 at 10:49:55PM -0500, lawson_whitney(a)juno.com wrote: > Log message: > Huw D M Davies <hdavies(a)codeweavers.com> > The horizontal dialog base unit is calculated as the straight average > of a-z,A-Z (tmAveCharWidth is supposed to be a weighted average > according to character usage, so we shouldn't use this). > > Good day! > > I don't pay much attention to GUI, or care much about it, but I noticed > this patch causes my app to display a progress bar (?) with the title > folded down into the progress bar, so it looks kind of lame. > > % xx > transferred: > > Without the patch, it looks more like: > > % transferred: xx > > I have no idea what this app looks like in Windows. I have never run it > with Windows, and I have no intention to buy Windows just to see, but I > think we might not want this bit of code to stay exactly as it is. > > I will gladly make any kind of traces you would like to see, or I can > live with it. The app is in fact obsolete win9x, but it is the most > recent version that can work a modem without requiring DUN or RAS or > some dam' thing. Hmmm, I wonder if a more recent version has the same > problem? Let me check... Hi Lawson, Are you using client side or server side (X11) fonts ? Huw.

April 8, 2002

Re: posting wineconf info to slashdot?

by Michael Cardenas

Steven Edwards wrote: >When is the reactos presentation going to be put up? I know it wasn't >the greatest in the world but we were on the guest list. =P > We haven't really gotten the presentations that were sent to us put up anywhere, because we were busy with our release. We released sp2 on friday, so I'll be getting the presentations put up this week and will be getting the details of the attendees' insider accounts sent out to everyone. michael

April 8, 2002

Re: [PATCH] async IO API, reworked

by Martin Wilck

Dear Alexandre, > > - separate cleanly between async scheduling and file IO related issues, > > - make the API compatible with other types of async requests (e.g. for sockets), > > - remove exports of async IO related functions for DLL separation. > > You cannot add private headers to work around the dll separation > restrictions, this only hides the dependencies between dlls it doesn't > solve them... I have applied the patch for now, but the async.h file > will have to go away eventually (or the functionality will need to be > "officially" exported from ntdll). What would be the correct solution, then? If I understand you right, each DLL that uses async IO must have its own implementation of async calls, i.e. not rely on anything implemented in ntdll except for the officially exported windows functions. To achieve that, we can put functionally equivalent code into each DLL's sources, or we can provide a header that defines only static functions - as the first version of my patch did. That approach has the advantage that we won't have to repeat the same code in source files of different DLLs. What would be wrong with that? The second version I sent (with check_async_list called automatically from call_apcs) re-introduces a hidden dependency on ntdll - obviously async calls from other DLLs won't work anymore if a native ntdll is used. That may be a step back. Still I cannot see a problem with the "static-only" header I used in the first version - can you explain that to me? Martin PS does anybody have an idea how Windows itself handles this, i.e. if the async calls in e.g. the Winsock API call ntdll functions internally? After all, it seems to be legitimate to mix ReadFile() and WSARecv() calls on sockets, although it would certainly be bad programming style. If we could only conceive of a way to implement async calls only on top of "official" windows functions... -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

April 8, 2002

Re: Running tests on windows

by Shachar Shemesh

Geoffrey Hausheer wrote: >On Sunday 07 April 2002 20:29, you wrote: > >>"Geoffrey Hausheer" <i8e7fkwmsl1(a)phracturedblue.com> wrote: >> >>>So is there a better solution than the three I've listed? >>>And why won't wine let me include 'windows.h', but under windows it is >>>required? >>> >>Probably it would be better to use Wine headers to compile Wine tests. >> > >I disagree that this is a good idea. The idea is to test that wine behaves >in the same manner as Windows does. > While I agree with that sentiment, I would like to point out that it may be that WINE has an incorrect function definition that is backed up by an incorrect declaration in the .h file. Such a situation may result in compiling for wine with the wine headers working, as well as compiling for Windows with the windows headers, but missing the binary compatibility support goal.

April 8, 2002

RE: Running tests on windows

by Steven Edwards

I use mingw with the wine headers for the winelib applications and dlls and it worked fine a few months back. Please use the WINELIB headers. We are using wine as our Win32 subsystem under reactos and I want to keep it as self-contained as possible. Mingw32s headers are very incompleate. This is a issue Jason and I discussed a little at wineconf. A good example is the comctrl headers, Mingw32's SUCK. If you want to use mingws header be prepard to send them a lot of patches. Also, certain changes to Winsock have made it a bitch for me to build the current tree under mingw and I've been too busy to track the problems down but have had a lack of time as of late. The DLLs wont work under windows/reactos anyway because of dll seperation issues. You will need to check 2 lines in include/basestd.h and I think include/windef.h and you can get almost everything to compile. I'm still having trouble linking resources built with wrc to the dlls/applications on mingw though. I will submit a patch or two over the next few weeks as I have time. Steven P.S. if you want to see how we have done our port with mingw, you can get our cvs information from reactos.com and just checkout wine instead of reactos. > -----Original Message----- > From: wine-devel-admin(a)winehq.com > [mailto:wine-devel-admin(a)winehq.com] On Behalf Of Francois Gouget > Sent: Monday, April 08, 2002 1:24 AM > To: Geoffrey Hausheer > Cc: wine-devel(a)winehq.com > Subject: Re: Running tests on windows > > > On Sun, 7 Apr 2002, Geoffrey Hausheer wrote: > > > Last week I submitted a perl script that makes a Makefile > (and archive > > bundle) for building tests on Windows boxes under cygwin. Well, it > > works fine with mingw too (when using msys at least), but > there is a > > snag. > > > > In order to compile tests under Windows, I seem to need to include > > windows.h before any other .h files. I did this using the > '-include' > > directive in gcc, but it requires knowledge of the absolute path to > > the windows.h file. This means I need to specify the path in the > > Makefile, which is completely non-portable (especialy with > mingw which > > doesn't really have a default setup like cygwin does). > > > > 1) So it seems I have three options. I can append '#include > > <windows.h>' to each .c file (either wrapped in #define, or through > > the perl script) > > > > 2) I can include the entire wine /include directory in the archive, > > and use that 'windows.h' to build against. > > > > 3) I can just force the user to edit the Makefile to point to the > > correct include directory. > > > > I don't really like any of these options (though 3 is the > the easiest > > to implement, as this is how it works now) > > > > So is there a better solution than the three I've listed? > > I think I will work on extending your script to also > generate Makefiles for use with Visual C++. The way it will > work with Visual C++ is that you are supposed to run a batch > script provided by Visual C++ (vcvars32.bat). This script > sets a number of environment variables which point to the > location of the headers, etc. and which you can also use in > your Makefiles. > Does Mingw provide something similar? Could we have a way > of forcing the user to set some environment variables or > query the values from him? (my batch-script skills are pretty > rusty :-) > > > > And why won't wine let me include 'windows.h', but under > windows it is > > required? > > Because winedows.h includes everythign and anything. We > want Wine files to only include the headers they need. The > problem is that the Wine tests are compiled as if they were > part of the Wine sources instead of being compiled like > Winelib applications, which they are. This means they are > subject to the same restrictions as Wine sources: windows.h > is forbidden, and Xxx is forbidden, you must use XxxA or XxxW > (see IDI_APPLICATION & co for why this is a problem). > > About using the Mingw headers vs. the Wine headers vs. > Visual C++ headers. I say: use the headers of the environment > in which you are. So when compiling with Mingw use the Mingw > headers and when compiling with Visual C++ use the Visual C++ > headers. As long as we don't use the Wine headers on Windows... > Hopefully the Mingw headers will be complete enough for our tests. > > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > The software said it requires Win95 or better, so I > installed Linux. > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

April 8, 2002