- Wine-Devel - list.winehq.org

Re: [mscms/tests/profile.c] Add another possible error
by Saulius Krasuckas Dec. 15, 2005

Dec. 15, 2005

* On Wed, 14 Dec 2005, Paul Vriens wrote: > > GetStandardColorSpaceProfileW with a non-NULL machinename will return > ERROR_NOT_SUPPORTED on 2000/WinXP/2003 (and maybe more). > > --- a/dlls/mscms/tests/profile.c > +++ b/dlls/mscms/tests/profile.c > @@ -515,7 +515,7 @@ static void test_GetStandardColorSpacePr > /* Parameter checks */ > > todo_wine > - fail_GSCSPW(machineW, 0, newprofile, &size, 0, (GLE == ERROR_INVALID_PARAMETER)); > + fail_GSCSPW(machineW, 0, newprofile, &size, 0, (GLE == ERROR_INVALID_PARAMETER || GLE == ERROR_NOT_SUPPORTED)); Hm, while I believe you, Paul, I don't like testing of several invalid parameters in one check. If different versions of mscms.dll are coded in different ways, we'll be getting one GLE on one platforms and another GLE on anothers. IMHO this way we can test algorithmic (conditional) branching of GetStandardColorSpaceProfile(), which won't be the same on all platforms. So I offer to skip it and test only single parameter in one check. I'll try to send a patch.

1 0

Re: sysparams : nonclient metric fixes
by Alexandre Julliard Dec. 15, 2005

Dec. 15, 2005

Rein Klazes <wijn(a)wanadoo.nl> writes: > Changelog: > dlls/user : sysparams.c > dlls/user/tests : sysparams.c > Implement saving and fix reading of nonclient metrics with conformance > tests. The test fails here: sysparams.c:195: Test failed: Wrong action got 42 expected 47 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: PATCH: msvcrt.wctime
by Alexandre Julliard Dec. 15, 2005

Dec. 15, 2005

Marcus Meissner <marcus(a)jet.franken.de> writes: > Used by Google Earth. If anyone has a better > idea on the static buffer handling please speak up.. ;) It should go in the per-thread data structure (cf. msvcrt_get_thread_data). -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: setupapi: Added stubs for SetupGetInfInformation and SetupQueryInfFileInformation [RESEND]
by Alexandre Julliard Dec. 15, 2005

Dec. 15, 2005

James Hawkins <truiken(a)gmail.com> writes: > Is there anything wrong with this patch? Yes, the patch file is truncated. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: comctl32: Create the compatible bitmap from the screen, not the bitmap we're copying
by Paul Vriens Dec. 15, 2005

Dec. 15, 2005

> Hi, > > This patch fixes bug 1715. > > Changelog > * Create the compatible bitmap from the screen, not the bitmap we're > copying. > > dlls/comctl32/toolbar.c | 12 ++++++++---- > 1 files changed, 8 insertions(+), 4 deletions(-) > > -- > James Hawkins > > Hi James, somehow you managed to attach an empty file. (I think). Paul.

2 1

Re: chdir to /tmp/.wine-1000/server-307-6930068 : No such file or directory
by David Nolden Dec. 15, 2005

Dec. 15, 2005

> There is no change in Wine that would have caused this. I seem to > remember that this or a similar error was caused by threading problems > in glibc in the past. Perhaps you upgraded glibc or the kernel on your > system? But when I checkout a cvs from the end of november, it runs.. when I checkout a current one it doesn't. I didn't upgrade glibc, nor the kernel. (I checked out and compiled a cvs from november just an hour ago, and it ran fine) greetings, David

2 1

Printf Integer Conversions update
by Jesse Allen Dec. 14, 2005

Dec. 14, 2005

Hi All, I've updated my patch and need comments on it. The patch is for a portible method for integer conversions in printf. Since it's primarily intended for I64 sizes that it is all it is used for to avoid breaking anything else, even though, it should be able to handle all integers. You can find it at http://www.chez.com/alors/ along with lots of tests. Since last time, I was wondering what to do about %I64e, and well, testing it out it seems to be just like %e on windows so I decided to not worry about our own float I64 conversion since it's the same. So only I64 integer types get fowarded to pf_integer_conv and floats just get put through libc's printf. I still wonder about %I64e versus %e just because libc's %lle and %e are different hmmmm. This time I use pf_output_format_A to handle the field output. I had to modify it to account for the extra sign and alternate formatting. I guess I need to modify pf_output_format_W the same way, but some one let me know if it is needed and whether just copying what I have over is ok. I added pf_is_integer_format to detect when I have an integer and I64 size case. I modified the others so each uppercase and lowercase type is explicit: static inline BOOL pf_is_valid_format( char fmt ) { - char float_fmts[] = "acdefginoux"; + char float_fmts[] = "acCdeEfgGinouxX"; if (!fmt) return FALSE; - fmt = tolower( fmt ); return strchr( float_fmts, fmt ) ? TRUE : FALSE; } Because D is not a valid conversion type, and especially 'I'. If we get passed %I0d for example, it should print I0d. If I didn't do this, then it tries to convert 'I' as an 'i' type, which would be a bug. I don't know if this will cause other things to regress, so I could back out the change. In my testing of I64 on windows 2k3 (x86), I hit an obscure bug? '%#+25.22I64u' for -1 prints ' 18446744073709551615' returning 21 but normally it should be ' 0018446744073709551615' returning 25. It only does it only for I64 types, and only in this exact combination -- precision and field doesn't matter what number, but #+ must be there and be unsigned. If I try '%+#25.22I64u' then I get correct output. You can see this in the tests and try it out. I tried about 20-30 other combinations and it only happens this way. I haven't built in support of the bug yet, but it is there. So I'm thinking, great, we have to support this obscure I64 with bugs too. Jesse

1 0

chdir to /tmp/.wine-1000/server-307-6930068 : No such file or directory
by David Nolden Dec. 14, 2005

Dec. 14, 2005

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

3 3

Re: gethostbyname(my_name) and IL2-Sturmovik
by Juan Lang Dec. 14, 2005

Dec. 14, 2005

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

2 2

Re: Wine: DirectDraw over Direct3D
by Stefan Dösinger Dec. 14, 2005

Dec. 14, 2005

Hello, > Following your mail on wine-devel about DDRAW, I now understand better > what's going on behind the scenes. Below is the result of an experiment I > did at the beginning of this month. Reading your message, I wanted to share > it with you. First, thanks for your comments, and one suggestion: You should also CC the mails to wine-devel(a)winehq.org, so others can read it too. > I'm an occasional wine user for games, and an experienced developper in > other projects. Age of Empires II has always been really slow, so I finally > decided to run an oprofile session. The results are attached to this > message (wine cvs of 2005-12-04). When I saw the results, I immediately > thought "put that conversion on the GPU". It seems you found that solution > long ago :) Yes, this is known quite well, and if you search the archives, you'll see that it has been mentioned over and over > Of course, there still are the ~35% used by X11, but even if these are not > compressible (DC stuff), a potential x5 increase in game speed due to DIB > would make it much more playable. The need for a better DIB engine is also known, and there are 2 DIB engines ready to be included into Wine: One was sponsored by Transgaming, and the other one is the DIB engine from ReactOS. The ReactOS engine is said to be faster, and it's favored. We'll see, perhaps we can include it with the DirectDraw re-work. The other problem is hardware 2D accelleration: Most DirectDraw functionality is handled by the GPU on Windows, since the beginning of DirectDraw, long before 3D accellerators were around. In Wine, there are 2 ways: The first is to use X calls, which is safe, but slow. The other one is the use of DGA, which is as fast as the Windows way, but it requires root preveliges, or at least write access to /dev/mem, which is a HORRIBLE security risk. That's were OpenGL comes into play: It is hardware accellerated, and doesn't require /dev/mem access. But the drawback is, that it needs a 3D accellerator, and a decent driver. It works fine for nvidia cards, but it is horribly slow for ati cards. > it seems using 3D as > the 2D backend it the only option that makes sense nowadays and in the near > future. In Wine case, this supports your DDraw using D3D idea. Yeah, that perfectly true for current hardware, rumors even have it, that today's GPUs don't have a 2D engine any more, and whatever you do, it will make use of the 3D functionality. The problem are older cards: It would be nice, if games worked on systems for which they were designed for, for example, I'd love to see Anno 1602 working in Wine on my old Acer Extensa 660 with an 120 MHZ Pentium CPU, and a Chips and Technologies 65000 GPU. Thanks for your interest, and I'd appreciate performance tests once my work is stable ;) Stefan

6 8