- Wine-Devel - list.winehq.org

Re: Resend: [dx9-12 next try] SetStreamSource changes
by Mike Hearn Nov. 23, 2004

Nov. 23, 2004

On Mon, 22 Nov 2004 20:01:03 +0000, Ann and Jason Edmeades wrote: > Was there a problem with this one - Its really holding me up with progress, > so I need to ensure I resolve any issues asap. Apologies if this is still in > your list of patches to work through as I heard you have just moved If the problem is source control related (as opposed to technical direction related) you may want to look at svk, which lets you branch CVS repositories into a local repository then commit to your branch. Unlike arch it doesn't require a gateway and it isn't hard to set up or use. Hope that helps. thanks -mike

2 1

Re: profiling GTA4. question about polling
by Brian Gunlogson Nov. 23, 2004

Nov. 23, 2004

--- Raphael <fenix(a)club-internet.fr> wrote: > Well, drawStriddedSlow is very very very slow (as function name :) ) > because is the software rendering path of wine d3d8 implementation > The only way to have good performances is to add needed support to hardware > rendering path (drawStriddedFast). > > Current version on hardware rendering path doesn't support (see > d3d8/drawprim.c:1590): > - pixel size (rarely used) > - blending weights (low use) > - diffuse color (highly used) > > In this cases the slow rendering path is used instead. > > I have a local "prototype" to have a better support of that cases (using > hardware vertex buffers) who have very good performances. > Ex: i have now a good framerate for UT2004 and Unreal2 (before i had ugly > lags) > > But, as Jason is currently doing a lot of work on splitting/moving code to > wined3d, we'll have to wait to commit it (and i should help him, when i'll > have time). Is this a tedious task or does it require knowledge of the codebase? I might be able to help. > Anyway, can you test what GTA4 want to use: diffuse, psize or/and blending ? > I'll try to send you a patched version of d3d8 to test after that :) GTA uses diffuse color exclusively. This was after playing the game for about 3 minutes on highest settings: pixel size: 0 diffuse: 745455 blending weights: 0 > Regards, > Raphael > > PS: > how have you done to use oprofile on wine ? > i'm very interested :) Just download the latest CVS from http://oprofile.sourceforge.net/download/ and see the README. I assume you know how to get it compiled and installed :) As root: # opcontrol --start # opcontrol --reset '--reset' clears out any old unwanted profiling data # opcontrol --separate=kernel '--separate=kernel' Seperates output by library and kernel [this is the hardest option to understand]. Profiling is on, run the application to profile and do not do anything else. When done: # opcontrol --dump '--dump' flushes remaining data to disk # opreport -l >./myreport.log Stores the flat profile in a file called myreport.log. Brian G __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

2 1

Re: epoll, LSB (was: Re: Problem roundup)
by Dan Kegel Nov. 22, 2004

Nov. 22, 2004

Mike Hearn wrote: >> I'm not aware of e.g. an LSB-1.3 application that doesn't run properly >> on any system that supports LSB-1.3. Are you? > > I'm not aware of any LSB applications at all, actually. But let's take > RealPlayer for example. Let's pretend that Real had made it an LSB app. > > Would that have saved it from being broken by NPTL. No. LSB doesn't > specify (as far as I'm aware) that LSB apps must be linked > against LinuxThreads. Bzzt. In the real world, the distro vendor would have noticed this during LSB certification, and since the shared library loader for LSB 1.3 is /lib/ld-lsb.so.1 rather than /lib/ld-linux.so.2, the vendor can easily force libc to be linuxthreads based even if the default libc is NPTL based. I believe that as people start building LSB-compliant apps, they'll find it quite a useful way to avoid having to package ten different flavors of their apps just to be compatible. It's going to be a lot easier with LSB 3.0, since by that time the C++ ABI will have settled down, but I do think even LSB 2.0 is worth looking at for some applications. Yes, I know, you'll probably want to post something bitter and negative about LSB in response, but I'm going to put my hands over my ears and go "la la la", so I won't notice whether you actually do :-) - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

2 2

epoll, LSB (was: Re: Problem roundup)
by Dan Kegel Nov. 22, 2004

Nov. 22, 2004

Mike Hearn: > 1) The RH9 RPMs are apparently being compiled with epoll support linked > in. This is causing user pain. We should really be using dlsym here, > why are we not again? Alexandre Julliard: > glibc is not backwards compatible, the RH9 RPMs should be built > against the RH9 glibc. There is nothing special about epoll, you can > have the same issue with any glibc symbol, and we can't start > dynamically loading them all. Mike Hearn: > We don't have to be over-general about it, just dynamically loading the > ones that cause problems would be fine (or using syscalls directly). The > vast majority of the symbols are always there and so it doesn't make sense > to use dlsym. Alexandre Julliard: > I think it's much better to ask packagers to build their packages > correctly, it will cause much less trouble in the long run. Or better yet, ask people to download the right package. I just downloaded http://prdownloads.sourceforge.net/wine/wine-20041019-1rh9winehq.i686.rpm and it worked fine on RH9. I wonder, though: the fact that somebody downloaded the wrong package means there are probably too many different versions at sourceforge to download. I count 24 packages! (OK, a few of them are srpms.) Shoot, can't we package Wine as an LSB package? I suspect Wine depends on nothing that isn't in the LSB. That'd make life a lot easier for the users... at least for those whose distros come with LSB support installed by default. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

12 28

Re: epoll, LSB (was: Re: Problem roundup)
by Ivan Leo Puoti Nov. 22, 2004

Nov. 22, 2004

>> I know Dimi is against it, but that looks like a good thing to do to me. > >It's not that I'm against it, I don't much care for the sf.net download page, >really. If people are willing to work on something that is less confusing, >by all means, but let's try to not complicate our current download page, >it is rather nice :) Well, wine.sf.net just redirects to winehq.com, using it for a nvidia like download page instead would be cool. Ivan. ____________________________________________________________ Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. Abbonati subito su http://www.libero.it

1 0

KERNEL32: add a test case for CompareStringW undocumented flag 0x10000000
by Mike McCormack Nov. 22, 2004

Nov. 22, 2004

Hi All, I've written a regression test that shows what the undocumented flag 0x10000000 passed by shlwapi.StrIsIntlEqualW/A to CompareStringW/A does. I discovered the different by writing a short program that compared the output of CompareString with and without the flag for all unicode characters... it took a while to run :) The flag (0x10000000) passed to CompareString reverse the sort order of a number of unicode characters. I've got no idea why it would want to do that... maybe somebody can shed some light on what the reason behind this would be? Mike ChangeLog: * add a test case for CompareStringW undocumented flag 0x10000000 Index: dlls/kernel/tests/locale.c =================================================================== RCS file: /home/wine/wine/dlls/kernel/tests/locale.c,v retrieving revision 1.33 diff -u -r1.33 locale.c --- dlls/kernel/tests/locale.c 21 Nov 2004 15:47:24 -0000 1.33 +++ dlls/kernel/tests/locale.c 21 Nov 2004 17:01:12 -0000 @@ -1410,6 +1410,76 @@ } #endif +static void test_CompareString_undoc(void) +{ + WCHAR table1[] = { + 0x0651, 0x3005, 0x3031, 0x3032, 0x309d, 0x309e, 0x30fc, 0x30fd, + 0x30fe, 0xfe7c, 0xfe7d, 0xff70 + }; + WCHAR table2[] = { + 0x02b9, 0x02ba, 0x02bb, 0x02bc, 0x02bd, 0x02be, 0x02bf, 0x02c0, + 0x02c1, 0x02c2, 0x02c3, 0x02c4, 0x02c5, 0x02c8, 0x02cc, 0x02cd, + 0x02ce, 0x02cf, 0x02d1, 0x02d2, 0x02d3, 0x02d4, 0x02d5, 0x02d6, + 0x02d7, 0x02de, 0x02e4, 0x02e5, 0x02e6, 0x02e7, 0x02e8, 0x02e9, + 0x0300, 0x0301, 0x0302, 0x0303, 0x0304, 0x0305, 0x0306, 0x0307, + 0x0308, 0x0309, 0x030a, 0x030b, 0x030c, 0x030d, 0x030e, 0x030f, + 0x0310, 0x0311, 0x0312, 0x0313, 0x0314, 0x0315, 0x0316, 0x0317, + 0x0318, 0x0319, 0x031a, 0x031b, 0x031c, 0x031d, 0x031e, 0x031f, + 0x0320, 0x0321, 0x0322, 0x0323, 0x0324, 0x0325, 0x0326, 0x0327, + 0x0328, 0x0329, 0x032a, 0x032b, 0x032c, 0x032d, 0x032e, 0x032f, + 0x0330, 0x0331, 0x0332, 0x0333, 0x0334, 0x0335, 0x0336, 0x0337, + 0x0338, 0x0339, 0x033a, 0x033b, 0x033c, 0x033d, 0x033e, 0x033f, + 0x0340, 0x0341, 0x0342, 0x0343, 0x0344, 0x0345, 0x0346, 0x0347, + 0x0348, 0x0370, 0x0371, 0x0372, 0x0483, 0x0484, 0x0485, 0x0486, + 0x0559, 0x055a, 0x0591, 0x0592, 0x0593, 0x0594, 0x0595, 0x0596, + 0x0597, 0x0598, 0x0599, 0x059a, 0x059b, 0x059c, 0x059d, 0x059e, + 0x059f, 0x05a0, 0x05a1, 0x05a2, 0x05a3, 0x05a4, 0x05a5, 0x05a6, + 0x05a7, 0x05a8, 0x05a9, 0x05aa, 0x05ab, 0x05ac, 0x05ad, 0x05ae, + 0x05af, 0x05b0, 0x05b1, 0x05b2, 0x05b3, 0x05b4, 0x05b5, 0x05b6, + 0x05b7, 0x05b8, 0x05b9, 0x05ba, 0x05bb, 0x05bc, 0x05bd, 0x05bf, + 0x05c0, 0x05c1, 0x05c2, 0x093c, 0x0951, 0x0952, 0x0953, 0x0954, + 0x0981, 0x09bc, 0x09c1, 0x09c2, 0x09c3, 0x09c4, 0x09cd, 0x09e2, + 0x09e3, 0x0a02, 0x0a3c, 0x0a41, 0x0a42, 0x0a47, 0x0a48, 0x0a4b, + 0x0a4c, 0x0a70, 0x0a71, 0x0a81, 0x0a82, 0x0abc, 0x0ac1, 0x0ac2, + 0x0ac3, 0x0ac4, 0x0ac5, 0x0ac7, 0x0ac8, 0x0acd, 0x0b01, 0x0b3c, + 0x0b3f, 0x0b41, 0x0b42, 0x0b43, 0x0b4d, 0x0bcd, 0x0c3e, 0x0c3f, + 0x0c40, 0x0c46, 0x0c47, 0x0c48, 0x0c4a, 0x0c4b, 0x0c4c, 0x0c4d, + 0x0c55, 0x0c56, 0x0cbf, 0x0cc6, 0x0ccd, 0x0d41, 0x0d42, 0x0d43, + 0x0d4d, 0x0e47, 0x0e48, 0x0e49, 0x0e4a, 0x0e4b, 0x0e4c, 0x0e4d, + 0x0eb1, 0x0eb4, 0x0eb5, 0x0eb6, 0x0eb7, 0x0eb8, 0x0eb9, 0x0ebb, + 0x0ebc, 0x0ec8, 0x0ec9, 0x0eca, 0x0ecb, 0x0ecc, 0x0ecd, 0x1026, + 0x1027, 0x1028, 0x1029, 0x102a, 0x102e, 0x1030, 0x1036, 0x1037, + 0x103b, 0x103d, 0x103e, 0x104b, 0x104c, 0x20d0, 0x20d1, 0x20d2, + 0x20d3, 0x20d4, 0x20d5, 0x20d6, 0x20d7, 0x20d8, 0x20d9, 0x20da, + 0x20db, 0x20dc, 0x20dd, 0x20de, 0x20df, 0x20e0, 0x20e1, 0x302a, + 0x302b, 0x302c, 0x302d, 0x302e, 0x302f, 0x3099, 0x309a, 0x309b, + 0x309c, 0xfb1e, 0xff9e, 0xff9f + }; + DWORD r,i,j; + WCHAR x[2],y[2]; + BOOL bPass = TRUE; + + x[1]=0; + y[1]=0; + for(i=0; bPass && (i<sizeof table1/sizeof table1[0]); i++) + { + x[0] = table1[i]; + for(j=0; bPass && (j<sizeof table2/sizeof table2[0]); j++ ) + { + y[0] = table2[2]; + r = CompareStringW(LOCALE_SYSTEM_DEFAULT, 0x10000000, x, 2, y, 2 ); + if (r!=CSTR_GREATER_THAN) + bPass = FALSE; + r = CompareStringW(LOCALE_SYSTEM_DEFAULT, 0, x, 2, y, 2 ); + if (r==CSTR_LESS_THAN) + bPass = FALSE; + } + } + todo_wine { + ok(bPass,"undocumented flag 0x10000000 test failed\n"); + } +} + static void test_FoldStringA(void) { int ret, i; @@ -2103,6 +2173,7 @@ test_GetCurrencyFormatA(); /* Also tests the W version */ test_GetNumberFormatA(); /* Also tests the W version */ test_CompareStringA(); + test_CompareString_undoc(); test_LCMapStringA(); test_LCMapStringW(); test_FoldStringA();

3 3

Re: epoll, LSB (was: Re: Problem roundup)
by Ivan Leo Puoti Nov. 22, 2004

Nov. 22, 2004

>You're forgetting K6 and K6-2 users with i586. Also, RH never provided >i586 packages (except for kernel and glibc), so it'd be foreign to the >distro to offer only that. The why not just 386 and 686, that will fit all. And you could not build devel and srps packages, or build them but hide them, and put a links to them somewhre else than the main download page, so that people that want them can get them but end users who just want runtime stuff can get it easily. Or we could just build some download pages for winehq, and just host the files on sf.net, like that we could make them more user friendly. Or we could make some pages and put them on winehq.sf.net, so that packagers could edit them without having to touch the lostwages cvs. Ivan. ____________________________________________________________ Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. Abbonati subito su http://www.libero.it

3 2

Re: epoll, LSB (was: Re: Problem roundup)
by Ivan Leo Puoti Nov. 21, 2004

Nov. 21, 2004

> Could we show (our own pages) where users could choose distro, then > distro version, then actual package? Instead of pointing them to a few > screenful of files directly... We already partially have this, if you go to http://www.winehq.com/download and click on Red Hat you get this page http://sourceforge.net/project/showfiles.php?group_id=6241&package_id=77396 that only contains RH packages. But I still think you should consider building fewer packages, probably an i586 build would do for almost all users. > Other ideas? Also have you ever tried building an RPM that runs on more than one version of RH? To run on 3 versions of mdk I only had to make very minor changes to the RPM. Ivan. ____________________________________________________________ Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. Abbonati subito su http://www.libero.it

2 1

headers suggestion
by Jonathan Wilson Nov. 21, 2004

Nov. 21, 2004

In light of e.g. http://reactos.com:8080/archives/public/ros-dev/2004-November/000658.html I would like to suggest the following header ideas. Currently MingW has: 1.A set of headers that contain a copy of part of the platform SDK 2.Some extra stuff (like that ntdll.h) 3.A set of headers that contain a copy of part of the windows DDK 4.Mabie again some extra stuff MS doesnt have (I dont know) 5.A set of headers that contain a copy of part of the visual C++ runtime library 6.Some extra stuff (mainly bits required to deal with differences between GCC and Visual C I think) WINE has: 1.A set of headers that are supposed to contain a copy of part of the platform SDK (although some things have been claimed to be wrong) 2.A set of headers that are supposed to contain a copy of part of the visual C++ runtime library (although again there may be things that are wrong) and 3.Extra definitions for stuff in both header sets microsoft doesnt define in the platform SDK (e.g. internal bits, functions microsoft doesnt document etc) ReactOS has: w32api (the ROS import of it) include/ddk (the ReactOS version of the windows DDK) include/wine (the WINE windows API headers) include/msvcrt (the MSVCRT headers ROS uses to build and link with msvcrt) include (various misc ReactOS specific headers) What I suggest for ReactOS (and I think some of this is already being done) is as follows: grab any headers from include/* that are public DDK headers (if there are any) and make sure they are all in include/ddk grab everything from the current WINE headers MingW is missing. Check that its all correct and stuff and add it to the ReactOS import of w32api. (if anything is found to be wrong in the wine headers, it should be fixed) grab anything from include itself and add to w32api as needed Get permission to relicence the stuff and contribute back to the main w32api tree. grab contents of include/msvcrt on ReactOS plus include/msvcrt on WINE and also mingw-runtime. Create one set of header files from the 3 sets such that it matches the microsoft headers as closely as possible. Merge w32api DDK headers with ROS DDK headers and create one set that, again, matches the MS headers. For w32api/mingw-runtime, the suggestion is that they look at all the "new stuff" generated by the merging of the 3 sets of msvcrt headers plus the ROS/WINE/w32api merger plus the DDK merger and look at acccepting it. For WINE, I suggest they start using the new "merged" headers if at all possible. Basicly, the idea is that mingw-runtime would become the "definitive" set of msvcrt.dll headers out there and that ReactOS, MingW and WINE would start using it for any case where you are talking to msvcrt.dll from the public side. both ROS and WINE would then have their own internal msvcrt headers as necessary to build their msvcrt* builds Then, w32api would become the "definitive" set of win32 api headers and would contain as much of the Microsoft Platform SDK as people have legally cloned. All userland components of ReactOS (as well as kernel-side bits that need the stuff in the userland headers e.g. win32k.sys) would use this. Be nice if WINE were to use this too but because of what WINE is and how it is built/used, there may be reasons for the WINE team not to use w32api as the build headers used to build WINE. And, there would be one "definitive" set of DDK headers which would be good enough for building ReactOS with. And for building any kernel-side stuff WINE decides to add (e.g. that stuff to load the device drivers for vaerious copy protection systems that was being worked on). And for anyone using MingW and MingW GCC to build kernel-mode stuff. Anything private or project specific would go into a set of private headers as needed for the different projects and sub-sections (dlls etc) within them Anything exported by microsoft but undocumented would go into a set of "undocumented" headers (which could then be shared between ReactOS and WINE since I dont think w32api would accept anything not documented in MSDN) Just suggestions btw, if they are good, say so If they are bad, say so (and say why) If there are issues with my idea, say what they are.

3 2

Re: epoll, LSB (was: Re: Problem roundup)
by Dan Kegel Nov. 21, 2004

Nov. 21, 2004

Mike Hearn wrote: > [The LSB] really doesn't deal with anything useful at all that isn't already > stable and on every Linux system anyway. Correct. When a commonly-needed package becomes "stable", a snapshot of its interface specification is taken, and added to the LSB. LSB applications can then rely on that interface being available. That might sound like a no-op, but the painstaking attention to detail involved in nailing down the interfaces of the LSB offers a lot of stability. > The LSB is toothless while upstream > projects continue to treat platform stability as a trivial detail. I'm not aware of e.g. an LSB-1.3 application that doesn't run properly on any system that supports LSB-1.3. Are you? > Note: the LSB did nothing to avoid the NPTL fiasco The transition to NPTL, like many other transitions in Linux's history, was painful, but that's exactly the kind of pain the LSB saves applications from. > and it's doing nothing to > avoid the COMPOSITE ARGB mess despite both libc and Xlibs being a part of > the supposedly "stable" base. http://freedesktop.org/pipermail/xorg/2004-August/002326.html says "COMPOSITE is experimental, users of it should expect things to break." I believe that the COMPOSITE extension is not part of LSB, so any application using it is not LSB-conformant. Here again, applications that conform to the LSB are saved from the pain of unstable interfaces changing. > The LSB process moves so slowly though that there's > no chance of them ever having an up to date desktop specification. That's ok. All we need is that they have a useful, working desktop specification. Mike, I get the feeling you want the LSB to be something it's not. Relax, let the LSB folks do their thing. Yes, LSB applications will always be using stable old interfaces, but *that's the point*. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

2 1