January 2004 - Wine-Devel - list.winehq.org

Re: bogus patch to bind() dlls/winsock/socket.c (request removal)

by Jeremy White

> Well, the patch apparently helps in some cases and hurts in others, so > the only way to decide is to write a test and determine what the exact > behavior is under Windows. I agree the current behavior looks wrong, > but that doesn't mean anything when dealing with Microsoft code... A quick foo.c shows that even Windows 98 respects the lack of the REUSEADDR flag in meaningful ways; the attached socktest.c shows that binding the same port twice fails on the second request, but emulating the current Wine behavior (which can be done by turning on parm #4) causes a success. As such, Wine is badly broken; any algorithm that relies on iterating through possible ports and doing something meaningful when a port is already in use will be utterly useless with the current code. I'll go ahead and see if I can't figure out how to modify the regression tests to properly test for this. Cheers, Jer

Jan. 11, 2004

Re: [WINEALSA] Add Midi IN support (w/o alloca)

by Christian Costa

Eric Pouech wrote: > Christian Costa a écrit : > >> + for (wDevID = 0; wDevID < MIDM_NumDevs; wDevID++) >> + if ( (ev->source.client == MidiInDev[wDevID].addr.client) && >> (ev->source.client == MidiInDev[wDevID].addr.client) ) >> + break; > > Why do you do twice the same test ? > A+ > > > Indeed this is wrong, the second test should involve the port number! Thanks Eric to point this out. :-) Bye, Christian

Jan. 11, 2004

Re: exception outside of stack limits

by Robert Lunnon

On Monday 12 January 2004 07:22, Robert Lunnon wrote: > There is a warning in signal_i368.c > > WARN( "exception outside of stack limits in thread %04lx eip %08lx esp > %08lx stack %p-%p\n", > GetCurrentThreadId(), EIP_sig(sigcontext), > > > Can anyone tell me what this "means" in terms of what would have to go > wrong to generate this warning ?? Hmm answered my own questions apparently my Solaris signal handling patches never made it into the CVS. Under Solaris there are two Stack pointers to be saved across contexts, wine saves only one (The Wrong one). Now a related question Signal handling has changed a bit since June when I last produced a port, now the regs are saved into a structure of type vm86plus_struct, I need to modify this structure to create storage for the extra element, problem is I can't seem to find the declaration of this structure anywhere ?? Can anyone tell me where this declaration is ? Bob

Jan. 11, 2004

Re: shell32 patches to be usable by ReactOS Explorer

by Martin Fuchs

> I'm afraid you'll have to do that. There's no way I can put that patch > in as is, it's way too big and doing way too many different things. It > also has a number of ugly hacks that will have to be cleaned up. > Please submit small self-contained patches that do only one thing, > with a changelog explaining what they do. OK, OK - I feared that. > I know it's a pain, but the real solution for next time is to submit > things as soon as they are done, instead of waiting a month and then > sending a huge patch that cannot possibly be reviewed. This "as soon as they are done" has been the problem. I did not wait a month, I simply could not get some things running at the first try, and had to change some things a number of times. I don't think, you would have been happy with receiving all those forward and backward steps. Perhaps you could commit the biggest but simplest thing in the meanwhile, the new icons. They are nearly independend from the C code, and I would like to avoid resending this big patch file. But please don't the change the icon ID in shres.rc for now: -0 ICON document.ico +1 ICON document.ico This also needs a code change. Regards, Martin

Jan. 11, 2004

Re: exception outside of stack limits

by Alexandre Julliard

Robert Lunnon <bobl(a)optushome.com.au> writes: > WARN( "exception outside of stack limits in thread %04lx eip %08lx esp %08lx > stack %p-%p\n", > GetCurrentThreadId(), EIP_sig(sigcontext), > > > Can anyone tell me what this "means" in terms of what would have to go wrong > to generate this warning ?? It means the stack pointer doesn't fit in the stack limits stored in the TEB, probably because the thread switched to a different stack without updating the TEB, or because of some sort of memory corruption. -- Alexandre Julliard julliard(a)winehq.com

Jan. 11, 2004

Re: shell32 patches to be usable by ReactOS Explorer

by Alexandre Julliard

"Martin Fuchs" <martin-fuchs(a)gmx.net> writes: > Yes, I am aware of that. > This patch is the result of four weeks work (not only of me), spending > most of the time with debugging, as most of those stuff is pretty > undocumented by Microsoft. It's not possible to simply look at the > ReactOS CVS history to separate out patches for every small piece > of change. If you want me to send in it this way, this would take > me another week. I don't think, it's worth that. I'm afraid you'll have to do that. There's no way I can put that patch in as is, it's way too big and doing way too many different things. It also has a number of ugly hacks that will have to be cleaned up. Please submit small self-contained patches that do only one thing, with a changelog explaining what they do. I know it's a pain, but the real solution for next time is to submit things as soon as they are done, instead of waiting a month and then sending a huge patch that cannot possibly be reviewed. -- Alexandre Julliard julliard(a)winehq.com

Jan. 11, 2004

Re: bogus patch to bind() dlls/winsock/socket.c (request removal)

by Alexandre Julliard

Jeremy White <jwhite(a)codeweavers.com> writes: > It's been years since I was a Stevens expert, but there was a day > when I was, and my gut reaction to that patch was one of > shuddering horror. In fact, I really should > argue for the complete reversal of the patch until a regression > test can conclusively prove that Window misbehaves in such > a horrid way (i.e. auto doing a reuseaddr and not using DONTROUTE). Well, the patch apparently helps in some cases and hurts in others, so the only way to decide is to write a test and determine what the exact behavior is under Windows. I agree the current behavior looks wrong, but that doesn't mean anything when dealing with Microsoft code... -- Alexandre Julliard julliard(a)winehq.com

Jan. 11, 2004

exception outside of stack limits

by Robert Lunnon

There is a warning in signal_i368.c WARN( "exception outside of stack limits in thread %04lx eip %08lx esp %08lx stack %p-%p\n", GetCurrentThreadId(), EIP_sig(sigcontext), Can anyone tell me what this "means" in terms of what would have to go wrong to generate this warning ??

Jan. 11, 2004

Correction to wineps spec file

by Vincent Béron

Changelog: CreateDC in wineps is Unicode now, change the spec file accordingly. Vincent

Jan. 11, 2004

Re: [WINEALSA] Add Midi IN support

by Christian Costa

Marcus Meissner wrote: >On Fri, Jan 09, 2004 at 12:03:10PM +0000, Mike Hearn wrote: > > >>On Thu, 08 Jan 2004 16:46:53 -0800, Alexandre Julliard wrote: >> >> >>>You should not use alloca in Wine, it's not portable enough. >>> >>> >>Could we take the glib implementation of alloca and stick it into >>libwine_port? IIRC in glib it uses the system implementation unless it's >>not good enough or missing, in which case it provides an emulation. >> >> > >And I always thought alloca was a compiler builtin. > >But why not just use HeapAlloc() ? > Of course yes. It just comes from an alsa example I saw... Christian > >Ciao, Marcus > >

Jan. 11, 2004

Re: [WINEALSA] Add Midi IN support (w/o alloca)

by Eric Pouech

Christian Costa a écrit : > + for (wDevID = 0; wDevID < MIDM_NumDevs; wDevID++) > + if ( (ev->source.client == MidiInDev[wDevID].addr.client) && (ev->source.client == MidiInDev[wDevID].addr.client) ) > + break; Why do you do twice the same test ? A+

Jan. 11, 2004

Re: Direct3D8 - OpenGL header problem

by Lionel Ulmer

On Sat, Jan 10, 2004 at 03:47:49PM -0500, Vincent Béron wrote: > Maybe Jason or Lionel or Rafael can take a look at how to prevent a > compilation problem here. I recall a push for including a set of GL > headers with Wine to get rid of all those compilation problems... We can't really do this safely and cleanly except by generating our own GL headers... This is a bit what I do in the D3D1/7 code by using _WINE versions of all non-GL 1.2 enums. Basically, it's a mess and will stay like that for a quite long time. Lionel -- Lionel Ulmer - http://www.bbrox.org/

Jan. 11, 2004

Re: shell32 patches to be usable by ReactOS Explorer

by Martin Fuchs

> Martin, sending a bunch of patches compressed and in one message, > makes them almost unreviewable but by the most die hards readers > of wine-patches. It also makes it so much more difficult for > Alexandre to split them up, match the ChangeLog, review them, etc. > Please stick to one-(uncompressed, inlined)-patch-per-email-messsage > rule, it's so much better for everybody. Yes, I am aware of that. This patch is the result of four weeks work (not only of me), spending most of the time with debugging, as most of those stuff is pretty undocumented by Microsoft. It's not possible to simply look at the ReactOS CVS history to separate out patches for every small piece of change. If you want me to send in it this way, this would take me another week. I don't think, it's worth that. It would be better to commit the code changes in one transaction. Shell32 has been quite incomplete before this patch, and it's also far from complete with this patch. Why I have compressed the attachments: Well, I don't think every one on the list wants to read the changes, which are not very readable at their own. And reading through endless hex numbers of shres.rc is also not very interesting. Regards, Martin

Jan. 11, 2004

Re: shell32 patches to be usable by ReactOS Explorer

by Martin Fuchs

Sorry, I forgot to include the new file "shlcpanel.c" into the shell32 patch mail. Changelog: - Implementation of control panel folder in shgell namespace -- Martin Fuchs martin-fuchs(a)gmx.net

Jan. 11, 2004

Re: Build fails for current CVS update

by Sami Aario

----- Original Message ----- From: "Alexandre Julliard" <julliard(a)winehq.com> To: "Sami Aario" <sami.aario(a)surfeu.fi> Cc: <wine-devel(a)winehq.org> Sent: Sunday, January 11, 2004 3:58 AM Subject: Re: Build fails for current CVS update > "Sami Aario" <sami.aario(a)surfeu.fi> writes: > > > I've determined that version 1.73 of tools/winebuild/spec32.c is what is > > causing this. Reverting to 1.72 cures this particular problem for me. My > > system is a Debian woody installation. Does anyone have any ideas on > > what's going on here? > > Do 'make distclean' and rebuild. > This solved my problem, thanks.

Jan. 11, 2004

Re: shell32 patches to be usable by ReactOS Explorer

by Dimitrie O. Paun

On January 11, 2004 08:04 am, Martin Fuchs wrote: > This patch consists of a number of changes we implemented in the ReactOS > CVS tree in order to use Wine's shell32.dll implementation for ReactOS > explorer. Please see the following changelog lists for the individual patch > descriptions: Martin, sending a bunch of patches compressed and in one message, makes them almost unreviewable but by the most die hards readers of wine-patches. It also makes it so much more difficult for Alexandre to split them up, match the ChangeLog, review them, etc. Please stick to one-(uncompressed, inlined)-patch-per-email-messsage rule, it's so much better for everybody. Here are some relevant links: http://www.winehq.org/site/sending_patches http://www.winehq.org/site/docs/wine-devel/patches -- Dimi.

Jan. 11, 2004

Re: bogus patch to bind() dlls/winsock/socket.c (request removal)

by Christoph Frick

On Sun, Jan 11, 2004 at 12:36:46PM +0000, Mike Hearn wrote: > > - /* The game GrandPrixLegends binds more than one time, > > but does > > - * not do a SO_REUSEADDR - Stevens says this is ok */ > > - TRACE( "Setting WS_SO_REUSEADDR on socket before we > > bind it\n"); > > - WS_setsockopt( s, WS_SOL_SOCKET, WS_SO_REUSEADDR, > > (char*)&on, sizeof(on) ); > That looks familiar. In fact, the TRACE was originally a FIXME but it > caused so much spew with so many apps I changed it. I couldn't see > exactly what needed to be fixed given the contents of the message - it > seems to be simply informing us of progress, but it's a possibility > somebody knew this wasn't correct. the patch was originally from me and the wsock maintainer also requested to removed it the day it was submited to the cvs tree. i will provide this patch further on the page i have setup with instructions how to run gpl and NR2002/3. if this patch prevents some facny apps from working i think its better to remove it. all the gpl/nr racers that run the game on linux are die hard fans of the game, who have their windoze only running for this games and are looking for a way det rid of it complete. they will not care for quicktime as they use <put some linux sofware here>. i dont have not time and also not the slightest motivation to look for a proper solution on the M$ or Papyrus end. -- cu

Jan. 11, 2004

Re: bogus patch to bind() dlls/winsock/socket.c (request removal)

by Jeremy White

Ivan Leo Murray-Smith wrote: >>With this change, we can use the 6.3 version of Quicktime >>to see streamed video from Wineconf... > > This would break Grand Prix Legends and Nascar 2002 (Thats why the patch was > written in the first place), maybe you should contact the author of the patch, a > proper fix would be better, why should we chose between 2 games and quicktime? > It should be possible to run all these apps. Jeremy Shaw already argued that the patch was incorrect, and I am near dead certain that he is right. It's been years since I was a Stevens expert, but there was a day when I was, and my gut reaction to that patch was one of shuddering horror. In fact, I really should argue for the complete reversal of the patch until a regression test can conclusively prove that Window misbehaves in such a horrid way (i.e. auto doing a reuseaddr and not using DONTROUTE). If Windows *does* allow you to double bind an address, it can only be the case that it does so in limited circumstances, and we should implement those limited circumstances, rather than applying a shotgun to the problem. Cheers, Jer

Jan. 11, 2004

Re: bogus patch to bind() dlls/winsock/socket.c (request removal)

by Mike Hearn

That looks familiar. In fact, the TRACE was originally a FIXME but it caused so much spew with so many apps I changed it. I couldn't see exactly what needed to be fixed given the contents of the message - it seems to be simply informing us of progress, but it's a possibility somebody knew this wasn't correct. On Sat, 10 Jan 2004 17:09:52 -0600, Jeremy White wrote: > Index: dlls/winsock/socket.c > =================================================================== > RCS file: /home/wine/wine/dlls/winsock/socket.c,v > retrieving revision 1.144 > diff -u -r1.144 socket.c > --- dlls/winsock/socket.c 2 Jan 2004 20:12:00 -0000 1.144 > +++ dlls/winsock/socket.c 10 Jan 2004 22:56:57 -0000 > @@ -1302,10 +1302,6 @@ > else > { > int on = 1; > - /* The game GrandPrixLegends binds more than one time, > but does > - * not do a SO_REUSEADDR - Stevens says this is ok */ > - TRACE( "Setting WS_SO_REUSEADDR on socket before we > bind it\n"); > - WS_setsockopt( s, WS_SOL_SOCKET, WS_SO_REUSEADDR, > (char*)&on, sizeof(on) ); > > if (bind(fd, uaddr, uaddrlen) < 0) > {

Jan. 11, 2004

Re: bogus patch to bind() dlls/winsock/socket.c (request removal)

by Daniel Kegel

Ivan Leo Murray-Smith wrote: >>With this change, we can use the 6.3 version of Quicktime >>to see streamed video from Wineconf... > > This would break Grand Prix Legends and Nascar 2002 (Thats why the patch was > written in the first place), maybe you should contact the author of the patch, a > proper fix would be better, why should we chose between 2 games and quicktime? > It should be possible to run all these apps. Sounds like somebody needs to look at Stevens and see if it's really ok to bind multiple times, and if so, whether this is a bug in Linux. I might, but then again, Alex might have already chewed up that page :-) - Dan

Jan. 11, 2004

Re: Build fails for current CVS update

by Alexandre Julliard

"Sami Aario" <sami.aario(a)surfeu.fi> writes: > I've determined that version 1.73 of tools/winebuild/spec32.c is what is > causing this. Reverting to 1.72 cures this particular problem for me. My > system is a Debian woody installation. Does anyone have any ideas on > what's going on here? Do 'make distclean' and rebuild. -- Alexandre Julliard julliard(a)winehq.com

Jan. 11, 2004

Re: Build fails for current CVS update

by Vincent Béron

Le sam 10/01/2004 à 20:05, Sami Aario a écrit : > > ----- Original Message ----- > From: "Sami Aario" <sami.aario(a)surfeu.fi> > To: <wine-devel(a)winehq.org> > Sent: Saturday, January 10, 2004 1:55 AM > Subject: Build fails for current CVS update > > > > Hi, > > > > Building with tools/wineinstall fails with the latest CVS update on my > > system with the following: > > > > > gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINE > > > SRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-stri > > ct-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ddraw.spec.o ddraw.spec.c > > {standard input}: Assembler messages: > > {standard input}:654: Error: no such instruction: `yes "ddraw.dll"' > > {standard input}:655: Error: no such instruction: `yes > > "DDHAL32_VidMemAlloc"' > > {standard input}:656: Error: no such instruction: `yes > "DDHAL32_VidMemFree"' > > {standard input}:657: Error: no such instruction: `yes "DDInternalLock"' > > > > and so on, lots more of the same. Anyone else getting these? > > > > I've determined that version 1.73 of tools/winebuild/spec32.c is what is > causing this. Reverting to 1.72 cures this particular problem for me. My > system is a Debian woody installation. Does anyone have any ideas on > what's going on here? Could you provide an excerpt of a gcc -E (rather than gcc -c) run, around the lines mentionned? Or post it somewhere on the web? Which gcc version? Vincent

Jan. 11, 2004

Re: Build fails for current CVS update

by Sami Aario

----- Original Message ----- From: "Sami Aario" <sami.aario(a)surfeu.fi> To: <wine-devel(a)winehq.org> Sent: Saturday, January 10, 2004 1:55 AM Subject: Build fails for current CVS update > Hi, > > Building with tools/wineinstall fails with the latest CVS update on my > system with the following: > > gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINE > SRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-stri > ct-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ddraw.spec.o ddraw.spec.c > {standard input}: Assembler messages: > {standard input}:654: Error: no such instruction: `yes "ddraw.dll"' > {standard input}:655: Error: no such instruction: `yes > "DDHAL32_VidMemAlloc"' > {standard input}:656: Error: no such instruction: `yes "DDHAL32_VidMemFree"' > {standard input}:657: Error: no such instruction: `yes "DDInternalLock"' > > and so on, lots more of the same. Anyone else getting these? > I've determined that version 1.73 of tools/winebuild/spec32.c is what is causing this. Reverting to 1.72 cures this particular problem for me. My system is a Debian woody installation. Does anyone have any ideas on what's going on here?

Jan. 11, 2004

Re: bogus patch to bind() dlls/winsock/socket.c (request removal)

by Ivan Leo Murray-Smith

> With this change, we can use the 6.3 version of Quicktime > to see streamed video from Wineconf... This would break Grand Prix Legends and Nascar 2002 (Thats why the patch was written in the first place), maybe you should contact the author of the patch, a proper fix would be better, why should we chose between 2 games and quicktime? It should be possible to run all these apps. Ivan.

Jan. 10, 2004

Re: bogus patch to bind() dlls/winsock/socket.c (request removal)

by Jeremy White

Jeremy Shaw wrote: > As a result of this patch (which is currently applied in cvs head): > > http://www.winehq.com/hypermail/wine-patches/2002/12/0009.html This also makes the Quicktime player unable to view streaming video, although I have to confess I do not know why, except that the bind failure seems to make the player take a slightly different path. With this change, we can use the 6.3 version of Quicktime to see streamed video from Wineconf... In the hopes it'll get noticed, here's a patch to remove it: Changelog: Jeremy Shaw <jeremy.shaw(a)lindows.com> Remove forced WS_SO_REUSEADDR on all binds Index: dlls/winsock/socket.c =================================================================== RCS file: /home/wine/wine/dlls/winsock/socket.c,v retrieving revision 1.144 diff -u -r1.144 socket.c --- dlls/winsock/socket.c 2 Jan 2004 20:12:00 -0000 1.144 +++ dlls/winsock/socket.c 10 Jan 2004 22:56:57 -0000 @@ -1302,10 +1302,6 @@ else { int on = 1; - /* The game GrandPrixLegends binds more than one time, but does - * not do a SO_REUSEADDR - Stevens says this is ok */ - TRACE( "Setting WS_SO_REUSEADDR on socket before we bind it\n"); - WS_setsockopt( s, WS_SOL_SOCKET, WS_SO_REUSEADDR, (char*)&on, sizeof(on) ); if (bind(fd, uaddr, uaddrlen) < 0) {

Jan. 10, 2004