March 2008 - Wine-devel - list.winehq.org

Re: 6/6 WineD3D: CheckDeviceFormat remove dead code
by Stefan Dösinger 21 Mar '08

21 Mar '08

Am Freitag, 21. März 2008 22:11:48 schrieb Roderick Colenbrander: > I expect a number of other 'fake' regressions like the one regarding srgb > writing but those can only become visible after this patch. Note that we perfectly well support srgb writing on all formats if ARB or GLSL pixel shaders are supported. We emulate the srgb correction in the shader Note that this is not 100% there, if the game is using the fixed function fragment pipeline we currently have no ARB or GLSL pixel shader which could do the gamma correction. However, many games(like HL2) require srgb correction, so we should keep it enabled.

1 0

Re: winex11.drv: Indirection level fix
by Ken Thomases 21 Mar '08

21 Mar '08

On Mar 21, 2008, at 10:30 AM, Andrew Talbot wrote: > It seems that either "packet" should not be a WTPACKET **, or the > first > parameter to the memcpy() should be *packet. Unable to find this > function being > used anywhere, I guessed the former. It's used in dlls/wintab32/wintab32.c via pGetCurrentPacket and you appear to have guessed correctly. Cheers, Ken

2 1

re: GSoC application
by Dan Kegel 21 Mar '08

21 Mar '08

> I would like to submit my GSoC application link: > http://wiki.winehq.org/LouisLadas Hi Louis, you should probably look for a couple backup apps to implement as I suggested to the other applicant here: http://winehq.org/pipermail/wine-devel/2008-March/063828.html Have you already built wine from source? Also, no reason to wait for SoC to start; you should consider submitting patches ahead of time, it'll help you ramp up. - Dan

1 0

AppDB?
by Christopher 21 Mar '08

21 Mar '08

Who's in charge of AppDB? I sent in a couple requests a week ago, and they still haven't been approved (or denied). The first was for a new application, PhoenixRC, which I'll be happy to maintain. And the other was for a new vendor, Mozy, Inc., so that I could update MozyHome to have the correct vendor. Christopher

1 0

GSoC'08 - Tools - Scriptable Configuration
by Xanf 21 Mar '08

21 Mar '08

Hello, everyone. My name is Illya and I'm interested in taking part in GSoC 2008 for implementing scriptable configuration for wine. So I'd liked to discuss it with community. First of all - why I'm interested in that project? Currently I'm working as a kind of "software consultant" in my city. My primary The primary aim of work - helping migrating from MS Windows platform to Linux & Open Source. Unfortunately, a great number of different applications were written and still heavily used in companies of my city for Windows. And this is a place where Wine makes great help. Need of scriptable configuration is quite critical for helping me quickly perform standard configuration for some apps, and even more - make "install packages" which will help users unfamiliar with Wine quickly run their software. Now - Why me? Quite hard question. First of all, I have a personal interest (see above :) ). Second - now I have strong will and real possibility (as I estimate) to implement that project. I've looked for projects of GSoC'07 year ago - and realized that I wasn't ready for them. Although I'm absolutely new to wine-devel, I've been using Wine (and no windows at my computer at all) for about a year. I have experience working on some big projects (it is mangos WoW emulator (http://mangosproject.org/) and especially ScriptDev2 (scripting engine for mangos) (http://scriptdev2.com) ). Currently I have strong skills in reading and understanding code written by others. I have quite strong C/C++ (mostly C++) skills. I've participated in ACM contests and received 1 place in Ukraine and we (My team) were in top-ten in Eastern Europe Region contests. How I see my future work? First of all, in short term after this message (possibly on weekend) if I receive a positive (or at least non-negative response) from community I plan to create a specification of CLI syntax, which I expect to be implemented by me, divided in stages to have a step-by-step working guide. After obtaining community suggestions that'll become a future work plan for summer. Then I'll spend some time in wine code reading (I've already have experience in some "hacking" for my brother's favorite games, but I need some time for deeper understanding). And after that - the work will start. I expect to make a weekly "reports" how the work going on, and create a series of patches for each step defined above. Thanks for reading probably a bit long letter, and sorry for possibly bad English - it is far away from my mother tongue. Best regards, Illya Klimov

2 1

re: GSoC'08 - Tools - Scriptable Configuration
by Dan Kegel 21 Mar '08

21 Mar '08

Illya wrote: >Currently I'm working as a kind of "software consultant" in my city. >My primary The primary aim of work - helping migrating from MS >Windows platform to Linux & Open Source. Unfortunately, a great number >of different applications were written and still heavily used in >companies of my city for Windows. And this is a place where Wine >makes great help. >Need of scriptable configuration is quite critical for helping me >quickly perform standard configuration for some apps, and even more - >make "install packages" which will help users unfamiliar with Wine >quickly run their software. Can you give some examples? This sounds kind of like the wine-robot, wine-doors, and wpkg.org efforts. And there might be a lot of overlap with the automated application test idea from http://wiki.winehq.org/SummerOfCode - Dan

1 0

Re: [4/22] WineD3D: A shader backend descriptor for the ati fragment shader backend
by Ivan Gyurdiev 21 Mar '08

21 Mar '08

I don't quite understand why it's necessary to write ARB, GLSL, and NONE shader descriptors inside the ati_shader file. How will this infrastructure scale to a new shader backend added a year from now ? For such a large patchset maybe there should be a high level design diagram that explains how it works ? I very much like that backend-specific functionality ends up in the appropriate backend - as per patches 10, 11, and 14. However, it seems those patches stand on their own, independent of the rest of the patchset and this feature. Ivan

3 33

Re: loader: more stringent sanity check
by Alexandre Julliard 21 Mar '08

21 Mar '08

"Dan Kegel" <dank(a)kegel.com> writes: > + if (!strcmp( argv[1], "--nosanitycheck" )) > + { > + perform_sanity_check = 0; > + > + /* Delete --nosanitycheck from argv */ > + > + /* Size of argv before is argc +1 for argv[0], +1 for argv[argc]=0 */ > + /* Size of argv afterwards is one less */ > + argv = malloc((argc + 1) * sizeof (char *)); > + argv[0] = (*pargv)[0]; > + memcpy(argv+1, *pargv + 2, argc * sizeof(char *)); /* final 0, too */ > + argc--; > + *pargc = argc; > + *pargv = argv; > + } > + > + if (perform_sanity_check && !geteuid()) > + { > + fprintf( stderr, "%s\n%s\n", > + "Please don't run wine as root! See http://wiki.winehq.org/NoRoot", > + usage ); > + exit(1); > + } I hope you are not seriously suggesting that we do this... I'm not at all convinced that we need even a warning, there doesn't seem to be much concrete evidence that running as root is actually harmful, and it's necessary in many cases. Refusing to run is clearly not an option. If we really need to have something then it should be at most a one-time warning (in a message box so people have a chance to see it) at wineprefixcreate time, with an easy way to disable it. -- Alexandre Julliard julliard(a)winehq.org

9 15

Re: Implement ID3DXRenderToSurface*
by tony.wasserka＠freenet.de 21 Mar '08

21 Mar '08

> It would probably be better to avoid doing that. It isn't quite the > same as disassembling the native implementation, but in general you > want to avoid looking at how the native implementation is implemented > rather than how it behaves. I have to admit that I didn't think of these kind of things, however for D3DXCreateRenderToSurface this isn't a problem as all what I got from the output was that I have to call no d3d functions. > ...and that's pretty much unacceptable. I see, this will probably need a fixed patch. > It might be true that on wine the device never becomes invalid, but > that might not always remain true, and IMO our d3dx9 dlls should work > on native win32 as well. The code should run on native windows, too, though it isn't that well tested. (IMO there isn't much to test about a few release calls anyways). Also, ResetDevice is the same as D3DXCreateRenderToSurface, as it doesn't do anything either. But thank you for the time you spent on reviewing my patches :) Best regards Tony Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/i…

1 0

Re: d3dx9: Implement ID3DXRenderToSurface_OnLostDevice/OnResetDevice [PATCH 7/7]
by H. Verbeet 21 Mar '08

21 Mar '08

On 20/03/2008, tony.wasserka(a)freenet.de <tony.wasserka(a)freenet.de> wrote: > These are not very interesting... > On winehackers I was told that under wine the device won't ever get invalid anyways so these patches are just > for having the implementation complete. > It might be true that on wine the device never becomes invalid, but that might not always remain true, and IMO our d3dx9 dlls should work on native win32 as well.

1 0