November 2007 - Wine-Devel - list.winehq.org

Re: dlls/winedos/int21.c -- type adjustments

by Dmitry Timoshkov

"Gerald Pfeifer" <gerald(a)pfeifer.com> wrote: > ChangeLog: > Use unsigned long instead of long for return values of SetFilePointer. It wouldn't take more than 30 additional seconds to look up the SetFilePointer prototype in include/ and use real type instead. -- Dmitry.

Nov. 22, 2007

Re: Ansi to Unicode

by Alexander Nicolaysen Sørnes

On Thursday 22 November 2007 16:01:00 luis.busquets(a)ilidium.com wrote: > Is there any standard function in WINE to transform an Ansi string into a > Unicode string? > > And the opposite? Same as in Windows: WideCharToMulitByte and MultiByteToWideChar Alexander N. Sørnes

Nov. 22, 2007

Ansi to Unicode

by luis.busquets＠ilidium.com

Is there any standard function in WINE to transform an Ansi string into a Unicode string? And the opposite?

Nov. 22, 2007

Re: WineD3D: Implement detection of ATI cards with Mesa DRI drivers [try 3]

by Roman Mamedov

Roderick Colenbrander wrote: > I would really ask you to use the D3DX_CAPABLE() macros as not using them can result in bad problems. E.g. a game assuming a certain d3d functionality is there while it isn't backed by any GL extension. > You certainly do have a point. I will redo the patch a bit later, but before that, I have a couple of questions. 1) Checking real capabilities surely can be a good way to approximate the level of used hardware. But could these D3DX_CAPABLE() macros be considered reliable enough to use just them alone (and not the DRI module names) for conceiving the card model? If this is so, then checking of the Mesa renderer string could remain only for detection that the card is from ATI (because it does not give any precise info anyway). 2) Are there any plans to add D3D9B_CAPABLE and D3D9C_CAPABLE (and maybe D3D10_CAPABLE too)? These would immensely help to identify the newer cards. Currently, without such macros, the detection code can't safely report that a card is anything more than the ATI's Direct3D 9 lowest-common denominator, Radeon 9500. (See http://en.wikipedia.org/wiki/Radeon for a table of models and their DirectX versions). Thanks for the reply, Roman.

Nov. 22, 2007

Disregard earlier ntdll/tests/env.c patches

by Zac Brown

Hi, Please disregard any patches prior to the latest patch. It seems my mail server has been a little messed up. The only one to consider is the latest one that the wine-patches list has received. Thank you, Zac Brown -- Zac Brown (817-266-6867) zac(a)zacbrown.org http://zacbrown.org

Nov. 22, 2007

Re: d3dx8 [patch 7/7] Implement D3DXMatrixTransformation

by David.Adam＠math.cnrs.fr

Doing that, I shall break the style of the file. I tried to keep a uniformized style for the whole repertory. David > Any chance the formatting can be improved to include whitespace > between blocks and proper indentation?

Nov. 22, 2007

Re: Some thoughts about next GSoC

by Kai Blin

On Thursday 22 November 2007 11:48:10 Maarten Lankhorst wrote: > Sounds like a good idea, the work you have to do in a SoC is usually > underestimated by a factor of 2. :-) That is common industry practice. I want to prevent factor 10 or worse.. ;) > I don't like the idea of a quiz as well, what would be a better test is > to get a small patch into wine, perhaps adding a testcase to the > component they want to work on. It shouldn't be big, but it proves they > can get code into wine. This probably could work, provided we have enough people to give feedback we tend to have to give all new comitters. Might really be worth the effort, though. > > Lots of other projects had their student write a weekly public progress > > report. I think we should require the same. This will probably help > > keeping people updated, and might help spotting problems early. > > Personal experience here, it might be good for some people, but for me I > just told when I made some progress. Perhaps setting up a wine SoC blog > where you post every week what you're doing? There's multiple options for that. There's http://planet-soc.com/, student's could use their own blogs, or send a weekly email to wine-devel. Personally I'd like to collect that stuff and give a short weekly digest of those posts to give the students some more exposure. WWN GSoC edition or the like. Unless someone reanimates WWN anyway, that we could just piggyback there. > > Last year, some of the students set up a public git repo on repo.or.cz. I > > was thinking about making that a requirement for next year. This would > > allow people to review work in progress. > > Agreed, I'm for a public git repo. If it's needed I can write some > instructions on how to set a repo up in the wine wiki. I think a tutorial for setting that up would be a good thing. We just need to make sure they still submit their stuff to wine-patches early and often. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Nov. 22, 2007

Re: Some thoughts about next GSoC

by Maarten Lankhorst

Hi Kai, Kai Blin schreef: > I was thinking about strongly encouraging people to post their project > proposal to wine-devel prior to applying, so more developers can have a look > at it and see if it's doable or not and offer suggestions. > Sounds like a good idea, the work you have to do in a SoC is usually underestimated by a factor of 2. :-) > I know some projects did an introductory quiz to figure out the student's > coding skills, I'm not convinced the knowledge needed for Wine can be tested > in a quiz. What do you think? > I don't like the idea of a quiz as well, what would be a better test is to get a small patch into wine, perhaps adding a testcase to the component they want to work on. It shouldn't be big, but it proves they can get code into wine. > Another thing that didn't turn out too well last time is that it was really > hard to figure out what was going on during the summer. I have a few ideas on > how we could address this. > > Lots of other projects had their student write a weekly public progress > report. I think we should require the same. This will probably help keeping > people updated, and might help spotting problems early. > Personal experience here, it might be good for some people, but for me I just told when I made some progress. Perhaps setting up a wine SoC blog where you post every week what you're doing? > According to the wiki page, we already require a post-mortem report on the > project, however I can't remember seeing much of those this year. We should > make sure those are written next time. We might think of a better name for > the report, post-mortem sounds like the project is dead after the summer, we > want people to keep working. > I'm all for it. Perhaps call it reflection report? > Last year, some of the students set up a public git repo on repo.or.cz. I was > thinking about making that a requirement for next year. This would allow > people to review work in progress. > Agreed, I'm for a public git repo. If it's needed I can write some instructions on how to set a repo up in the wine wiki. Cheers, Maarten.

Nov. 22, 2007

Some thoughts about next GSoC

by Kai Blin

Hi folks, from what we discussed at the last WineConf, we wanted to work on our procedures for the Google Summer of Code a little. I'm sending this email in hope to start some discussion about this, so we have it out of the way until the 2008 version is announced so we can talk about proposed projects then. The goal of Wine's SoC procedures should be to get high-quality proposals that can be completed by the student proposing the project in the time allocated for GSoC, so both scope and difficulty should be checked. I haven't been on the mentoring side of things, but my understanding from the WineConf side of things was that we had some problems getting this right the past years. I was thinking about strongly encouraging people to post their project proposal to wine-devel prior to applying, so more developers can have a look at it and see if it's doable or not and offer suggestions. I know some projects did an introductory quiz to figure out the student's coding skills, I'm not convinced the knowledge needed for Wine can be tested in a quiz. What do you think? Another thing that didn't turn out too well last time is that it was really hard to figure out what was going on during the summer. I have a few ideas on how we could address this. Lots of other projects had their student write a weekly public progress report. I think we should require the same. This will probably help keeping people updated, and might help spotting problems early. According to the wiki page, we already require a post-mortem report on the project, however I can't remember seeing much of those this year. We should make sure those are written next time. We might think of a better name for the report, post-mortem sounds like the project is dead after the summer, we want people to keep working. Last year, some of the students set up a public git repo on repo.or.cz. I was thinking about making that a requirement for next year. This would allow people to review work in progress. Comments? Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Nov. 22, 2007

Re: WineD3D: Implement detection of ATI cards with Mesa DRI drivers [try 3]

by Roderick Colenbrander

> Presently, if an ATI card uses open-source DRI drivers from the Mesa > project ( http://dri.freedesktop.org/wiki/ATI ), Wine will report it to > Windows applications as being some generic nVIDIA model, based on D3D > capabilities of the card. > > This patch adds detection of the used ATI video card, based on Mesa DRI > module name, which is returned by drivers in GL Renderer string. In my > opinion, returning even an approximate ATI card model should be better, > than the present condition, disguising the ATI card as some equally > generic model from nVIDIA. Also, the patch adds detection of VENDOR_MESA > >from GL Renderer string, as Mesa DRI drivers may have various things as > GL Vendor, but the GL Renderer name always contains the string "Mesa". > This patch resolves the bug #7267, "Lineage 2 complains about outdated > NVIDIA drivers using ATI card with Mesa drivers" - > http://bugs.winehq.org/show_bug.cgi?id=7267 . The idea behind the whole code is that we detect a 'compatible' card based on the OpenGL capabilites. That stuff is done using the D3DX_CAPABLE() macros. The extension I check directly correspond to D3D functionality. In the end the result is further refind by checking the opengl renderer string. The reason why it is all done this way is because we need to detect the card based on OpenGL / GLX information and they don't export the pci id (which is good) but bad for D3D. Retrieving the real card name and so on from /proc or whatever isn't guaranteed to get good results and it also doesn't scale with remote X and if the system uses multiple videocards. It is very tricky. I would really ask you to use the D3DX_CAPABLE() macros as not using them can result in bad problems. E.g. a game assuming a certain d3d functionality is there while it isn't backed by any GL extension. The reason we default to Nvidia cards is that they are very generic and have quite solid drivers, so from an application point of view that is nice. Second games don't really need the exact GPU but they just use the info to get an impression of the features / performance. You can debate whether reporting Nvidia or ATI on totally different drivers matters (I would say no). So at least use the D3DX_CAPABLE macros as those are correct. Roderick -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Nov. 22, 2007