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

Re: gethostbyname(my_name) and IL2-Sturmovik

by Juan Lang

> Since you're concerned about the performance, which is valid, I've also > removed all the string-conversions. Important question: Is 1.0.0.127 a > valid public IP-Adress? Yes. > If yes, I'd have to furtherly change the code, adding some > htonl, ntohl, or similar. Yes, and that would allow you to do only one comparison. > + BOOL get_public_ip(DWORD* target) This still needs to be static. (static BOOL get_public_ip...) > + for (i = 0; i < ifc.ifc_len / sizeof(struct ifreq); i++) Now I remember why I was concerned about this. This isn't portable. In some systems, struct if_req occupies fixed space in ifc, but in others, the size depends on the amount of data in each struct if_req. You need to use ifreq_len. See e.g.: http://source.winehq.org/source/dlls/iphlpapi/ifenum.c#L201 Or, as I suggested before, you could call iphlpapi.GetAdaptersInfo: it already excludes local interfaces, and winsock already depends on iphlpapi. --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Dec. 14, 2005

Re: chdir to /tmp/.wine-1000/server-307-6930068 : No such file or directory

by Vitaliy Margolen

Wednesday, December 14, 2005, 12:55:13 PM, David Nolden wrote: > To get to another issue.. since a few weeks, the current CVS doesn't work for > me. Whenever I compile it, I get the error mentioned in the subject. > New .wine-dir and wiping /tmp doesn't help. > When I checkout an older version, for example one from the end of november, it > runs fine. Does anyone know the reason for this, or will I have to inspect > the code to find it out? > > Sorry in case this is the wrong mailing-list.. This is a list if you "inspect the code to find it out" and have questions about what you found and how to fix it. Vitaliy

Dec. 14, 2005

chdir to /tmp/.wine-1000/server-307-6930068 : No such file or directory

by David Nolden

To get to another issue.. since a few weeks, the current CVS doesn't work for me. Whenever I compile it, I get the error mentioned in the subject. New .wine-dir and wiping /tmp doesn't help. When I checkout an older version, for example one from the end of november, it runs fine. Does anyone know the reason for this, or will I have to inspect the code to find it out? Sorry in case this is the wrong mailing-list.. greetings, David

Dec. 14, 2005

Re: gethostbyname(my_name) and IL2-Sturmovik

by David Nolden

@Juan Since you're concerned about the performance, which is valid, I've also removed all the string-conversions. Important question: Is 1.0.0.127 a valid public IP-Adress? If yes, I'd have to furtherly change the code, adding some htonl, ntohl, or similar. greetings, David

Dec. 14, 2005

Re: There is no need to offset the source rectangle in the reversedirection before scrolling

by Alexandre Julliard

"Dmitry Timoshkov" <dmitry(a)baikal.ru> writes: > Well, the committed patch 1) does fix a visual glitch in the app I'm working on > and 2) passes all the current tests. The current tests pass with or without your patch, so it doesn't prove anything. What you need is to come up with a test that replicates what the app is doing and that fails without your patch. -- Alexandre Julliard julliard(a)winehq.org

Dec. 14, 2005

Re: Wine: DirectDraw over Direct3D

by Oliver Stieber

--- Aric Cyr <Aric.Cyr(a)gmail.com> wrote: > Raphael <fenix <at> club-internet.fr> writes: > > > > > On Tuesday 13 December 2005 09:28, Stefan Dösinger wrote: > > > Am Dienstag, 13. Dezember 2005 04:25 schrieb Aric Cyr: > > > > What is slow with ATI cards? It seems that you should only need basic 3D > > > > acceleration to do what you propose. Is fglrx missing something that > > > > would be required for 2D rendering? > > > > > > Texture upload is very slow. glReadPixels, glWritePixels and friends take > > > ages. That means that blt, Lock, and Unlock is really slow. > > > There is some hope at least: Xine and Mplayer can play videos over OpenGL > > really fast, maybe we can find out how they do it. > > Texture upload is not too bad with the ATI drivers, but gl{Read/Write}Pixels > will be horribly slow on most any video card. I would hope that DDraw is using > textures and not direct framebuffer writes (which I believe is what Roderick > mentioned). Especially, glTexSubImage2D() which should be even faster than > glTexImage2D(). ATI's driver are strange, sometimes it's quicker to repack the texture so that it's byte aligned before calling glTexSubImage2D() or glTexImage2D(), another way to inmporve performance is only glReadPixels when the data has really changed and to implement clears &co. against a local buffer. One of the main reasons for the slowness is that the data is being sent over the pci buss and not via AGP. An old ATI driver < 8.18 used double buffering to improve the performance, but turning on double buffering doesn't help with newer drivers. Oliver. ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

Dec. 14, 2005

Re: Outreach to windows ISVs

by Francois Gouget

Hi, Dan Kegel wrote: [...] > The page is at > http://kegel.com/wine/isv/ > Comments, anyone? From this page: > Wine is fully commercially supported. You or your customers can > purchase yearly per-seat support contracts from Codeweavers or > other companies if you need it. While that's quite correct and just what a company who is trying to deploy Linux on its desktop needs, I think an ISV would be more interested in CodeWeavers' porting services, as described on this page: http://www.codeweavers.com/services/engagements/wine_port/ > Because Wine is still in beta, it is likely that it will have some > issues running your application at first. I would say that this will be true even after Wine is no longer in beta. I'd liken it to taking an application that was developped in 1995 when Windows 95 just came out, and trying to run it on Windows XP SP2. It's just and environment the application was never tested in and that may reveal bugs in the application, incorrect assumptions, or differences in the behavior of the two Windows versions. All these issues can exist with Wine just to an even greater degree. The good news there is that you as an ISV one gets to choose whether to modify the application to avoid trouble areas or whether to modify/fix Wine (though the latter is encouraged). Regards, -- Francois Gouget fgouget(a)codeweavers.com

Dec. 14, 2005

Re: gethostbyname(my_name) and IL2-Sturmovik

by Juan Lang

Hi David, thanks for continuing to work on this. > What's wrong with the new version? The first thing to make it acceptable is to write a regression test to go along with it. I think the test should check that gethostbyname(your_host_name) returns something besides 127.0.0.1, _if_ you in fact have a public IP address. Perhaps use SIOCGIFCONF in the test to check whether you do have a public IP. + BOOL getpublicIP(char* target,int size) The name should be spelled get_public_ip or so, and this should be static. + if (skfd < 0) + { + WARN("A socket could not be created"); + return FALSE; + } On any failure you need to SetLastError with an appropriate error. + if(ip[0]==127&&ip[1]==0&&ip[2]==0&&ip[3]==0)continue; /*Exclude 127.0.0.1*/ + + sprintf(buffer,"%i.%i.%i.%i", (int)ip[0],(int)ip[1],(int)ip[2],(int)ip[3]); I think this is specific to little-endian machines, this should succeed on big-endian machines too. (Not all uses of Wine are to run x86 executables.) + if(strcmp(ifr[i].ifr_name,"lo")==0)continue; + if(size>strlen(buffer))strcpy(target,buffer); Some spaces somewhere would be nice :) + char myname[1000]; + gethostname(myname,(size_t)1000); In WS_gethostbyname you pay a penalty of doing a gethostname call every time. I think this could be optimized. For instance, you could only check it if the returned address is 127.0.0.1. Also, I'm not sure about declaring a buffer of 1000 bytes on the stack. It's also unnecessary: according to rfc1035, each name label is at most 255 chars. I assume, at any rate, that gethostname will not return a dotted name, but a single label. To get this off the stack altogether, you could have a static buffer that's set every time WS_gethostname is called. WS_gethostbyname could use this value instead of calling gethostname(2) itself. I'm not sure whether this optimization is worth it. If you use a static buffer, it needs to be protected by a critical section. --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Dec. 14, 2005

Re: 100% CPU usage in Wine-0.9

by Mark Knecht

On 11/15/05, Mark Knecht <markknecht(a)gmail.com> wrote: > On 11/10/05, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > <SNIP> > > > > > LATE BREAKING NEWS: It appears that when I switch to the Alsa > > > driver the CPU usage does down to normal. Were you using Alsa or OSS? > > > I tried both alsa and oss(with oss emulation in alsa), both are working fine. > > I don't use any hw acceleration. So is this program useable for you now with > > alsa? > > > > Stefan, > After having a few people test this it seems that it is not simply > enough to use the Alsa driver. A couple of people have tried that and > continue to see 100% CPU usage, so apparently there is something more > involved. > > In the bug report I have attached some debug info I was asked to > get. Hopefully that will help a developer in some way. > > I am here to test other ideas or do more debug work. I think this > problem is real. > > Cheers, > Mark > Hi, I haven't seen any responses on this in the last month. Did I possibly miss something? Thanks, Mark

Dec. 14, 2005

Re: There is no need to offset the source rectangle in the reversedirection before scrolling

by Dmitry Timoshkov

"Rein Klazes" <wijn(a)wanadoo.nl> wrote: > > /* Then clip again to get the source rectangle that will remain in the > > * clipping rect */ > > rcSrc = rcClip; > >- OffsetRect( &rcSrc, -dx, -dy); > > IntersectRect( &rcSrc, &rcSrc, &rcClip); > > In the first place: with this change the IntersectRect call is a no-op > > I doubt you understand the reason for "to offset the source rectangle > in the reverse direction": > > Scrolling should only occur in the clipping rectangle. When you talk > about the *destination* pixels, a clipping with the cliprect is needed. > Here we are talking about the *source* pixels, from destination to > source is indeed reverse. *that* is what is happening here. Well, the committed patch 1) does fix a visual glitch in the app I'm working on and 2) passes all the current tests. There are a couple of problems with your tests and fixes: it tests child windows with CS_PARENTDC style set, and it doesn't test the case when clipping rect is NULL. In my case both cases are not fulfilled and therefore we see different results. P.S. I think that brackets with multiple if/else statements are mandatory to make it more clear what is going on. -- Dmitry.

Dec. 14, 2005