Re: [msvcrt] short tty reads don't imply EOF
On Nov 21, 2007 3:12 PM, Alexandre Julliard <[EMAIL PROTECTED]> wrote: > "Damjan Jovanovic" <[EMAIL PROTECTED]> writes: > > > Changelog: > > * For ttys, short reads don't mean we're at the end of the file. > > That's not limited to ttys, other file types can have short reads too. Yes, but removing the entire block of code that handles short reads causes many msvcrt tests to fail :-). There is no general way to tell you're at the end of the file, before you actually get there (by read() returning 0). But, you can't read ahead, because that won't work for ttys. Suggestions? While on the topic of reading, is there any reason why ReadFile() calls ReadConsoleA() for console handles, but ReadFileEx() does not? > -- > Alexandre Julliard > [EMAIL PROTECTED] > Damjan
Driver-supported DirectX
I don't know the first thing about driver- and DirectX-programming, so please forgive (and point out) any mistakes. As a reader of this list I'm wondering; there are quite a few problems that come from the fact that DirectX isn't 1:1 translatable to OpenGL. How about talking to some guys from the GPU-driver department about creating a driver-interface that gives you the right hooks. I guess Parallels and Transgaming would also be interested in such a development. I can imagine that the Nouveau-devs and Xorg-radeon-devs would be more than happy to listen. This goes beyond the scope of the Wine project I think. But since Wine has the higher level part of DirectX documented and implemented on top of OpenGL, wouldn't this be the place to start an independent library? Codeweavers has a lot of knowledge about Windows, DirectX and Linux. Only Microsoft itself would be a better choice, but I don't think they really care that much about Linux. ;) This would mean that DirectX would be as native to Linux and OSX (and friends) as it would be for Windows. It would be an actual reliable platform that could be used by game developers. It would de-Windows-ize DirectX. Maybe NVIDIA, ATI and Intel would also be interested. They could sell their expensive next-gen cards to those 5% that don't run Windows if games would actually be released for non-Windows OSes. Or are there really compelling technical reasons to wrap around OpenGL? I can think of the Compiz-issue. Similarly, Microsoft stated that they have to wrap OpenGL around DirectX on Windows, to be able to use both OpenGL and DirectX at the same time (for Aero). But I suspect that this implementation just developed naturally because messing with the drivers would be unthinkable way back when. Remco Get easy, one-click access to your favorites. Make Yahoo! your homepage. http://www.yahoo.com/r/hs
Re: Some thoughts about next GSoC
On Thursday 22 November 2007 21:26:49 mark cox wrote: > the FFMpeg project was very successful with it's qualification tasks > http://guru.multimedia.cx/googles-summer-of-code-2007/ If we want to do this, I think the only sane approach is to have people write tests. That's a good idea anyway, and will get them to dig into the windows api. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: Some thoughts about next GSoC
On Thursday 22 November 2007 20:30:46 Jesse Allen wrote: > > Well then it sounds like we want better written proposals. Yeah the > goals for my project were very broad. I didn't intentionally do it > that way, but it was more like at first, get it to work, sort of > thing. And the design wasn't complete until a month in. The only way I > could have done better was to have started earlier. Mind you, I > actually did start in April almost two months early. That's what I was talking about. We can't expect the students to know this. They're just starting out working on real projects. But we as mentoring organization should have more clue about how hard a project could actually be. > If I get to do it > again, I will probably have a much more interesting proposal and have > goals that I will know will have specific results in the timeframe. > This is what I'm already considering, but that is because I am > experienced in the program already. For new people, we will have to > reach out to them and help them get ready early because they won't > know what to do. Maybe we need pre-SoC mentors? Well, that's why I'm beginning to discuss this now, and not a week before the deadline. :) Thanks for your feedback so far. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: Ansi to Unicode
On Nov 22, 2007, at 7:01 AM, [EMAIL PROTECTED] wrote: > Is there any standard function in WINE to transform an Ansi string > into a > Unicode string? > > And the opposite? > > > msdn is your friend... -- James Hawkins
Re: Some thoughts about next GSoC
the FFMpeg project was very successful with it's qualification tasks http://guru.multimedia.cx/googles-summer-of-code-2007/ regards, mark On Nov 23, 2007 6:30 AM, Jesse Allen <[EMAIL PROTECTED]> wrote: > On Nov 22, 2007 10:00 AM, Kai Blin <[EMAIL PROTECTED]> wrote: > > On Thursday 22 November 2007 17:44:09 Jesse Allen wrote: > > > > > From my understanding, the SoC site specifically says that you do not > > > have to work on a project that has to be completed in the allotted > > > time. I think the idea is that google wants to encourage people that > > > were already working on a project before to apply and to encourage > > > people to continue working in the community after the session is > > > complete. Now the mentoring organization could set their own > > > requirements, based on difficulty and scope, but I would be concerned > > > with making time a limiting factor. > > > > I'm not saying that we stop people from working on their stuff > afterwards, nor > > forcing them to e.g. implement the full dll if their project is "Start > an > > implementation of dll x". I was talking about shrinking their proposal > so > > they can actually manage to implement all the features they promise in > their > > proposal in the proposed timeframe. I know that this was really hard for > me. > > > > > The best alternative to the quiz would be to have the student begin > > > working on the project before the application. He can discuss it on > > > the the mailing list and hopefully show some code. This would be a > > > good way to judge coding skill and the project's scope. Now in order > > > for this to work well, we would have to encourage people to get > > > started early, which really hasn't happened before right? > > > > Well, depends on how you want to do this. I think this is overly > restrictive, > > unless you're just talking about a patch or two like Maarten proposed. > > > > > Well then it sounds like we want better written proposals. Yeah the > goals for my project were very broad. I didn't intentionally do it > that way, but it was more like at first, get it to work, sort of > thing. And the design wasn't complete until a month in. The only way I > could have done better was to have started earlier. Mind you, I > actually did start in April almost two months early. If I get to do it > again, I will probably have a much more interesting proposal and have > goals that I will know will have specific results in the timeframe. > This is what I'm already considering, but that is because I am > experienced in the program already. For new people, we will have to > reach out to them and help them get ready early because they won't > know what to do. Maybe we need pre-SoC mentors? > > Jesse > > >
Re: Some thoughts about next GSoC
On Nov 22, 2007 10:00 AM, Kai Blin <[EMAIL PROTECTED]> wrote: > On Thursday 22 November 2007 17:44:09 Jesse Allen wrote: > > > From my understanding, the SoC site specifically says that you do not > > have to work on a project that has to be completed in the allotted > > time. I think the idea is that google wants to encourage people that > > were already working on a project before to apply and to encourage > > people to continue working in the community after the session is > > complete. Now the mentoring organization could set their own > > requirements, based on difficulty and scope, but I would be concerned > > with making time a limiting factor. > > I'm not saying that we stop people from working on their stuff afterwards, nor > forcing them to e.g. implement the full dll if their project is "Start an > implementation of dll x". I was talking about shrinking their proposal so > they can actually manage to implement all the features they promise in their > proposal in the proposed timeframe. I know that this was really hard for me. > > > The best alternative to the quiz would be to have the student begin > > working on the project before the application. He can discuss it on > > the the mailing list and hopefully show some code. This would be a > > good way to judge coding skill and the project's scope. Now in order > > for this to work well, we would have to encourage people to get > > started early, which really hasn't happened before right? > > Well, depends on how you want to do this. I think this is overly restrictive, > unless you're just talking about a patch or two like Maarten proposed. > Well then it sounds like we want better written proposals. Yeah the goals for my project were very broad. I didn't intentionally do it that way, but it was more like at first, get it to work, sort of thing. And the design wasn't complete until a month in. The only way I could have done better was to have started earlier. Mind you, I actually did start in April almost two months early. If I get to do it again, I will probably have a much more interesting proposal and have goals that I will know will have specific results in the timeframe. This is what I'm already considering, but that is because I am experienced in the program already. For new people, we will have to reach out to them and help them get ready early because they won't know what to do. Maybe we need pre-SoC mentors? Jesse
Re: ntdll: Shared manifests should have a less-strict version check performed when loading them as dependencies.
Alexandre Julliard wrote: > Robert Shearman <[EMAIL PROTECTED]> writes: > > >> --- >> dlls/ntdll/actctx.c | 56 >> +++--- >> 1 files changed, 35 insertions(+), 21 deletions(-) >> > > Some test cases would be nice... I've just sent in a pair of patches which test this. I hope they are sufficient. -- Rob Shearman
Re: wineprefixcreate: get xdg-user-dirs environment variables [1/2]
On Wed, 21 Nov 2007, Lei Zhang wrote: [...] > xdg-user-dirs provides xdg_user_dir_lookup() for doing this. [1] Is > this something we can include in Wine? The code is under the MIT > license. As long as our code still works if the relevant xdg library is not present at runtime... -- Francois Gouget <[EMAIL PROTECTED]> http://fgouget.free.fr/ 145 = 1! + 4! + 5!
Re: Some thoughts about next GSoC
On Thursday 22 November 2007 17:44:09 Jesse Allen wrote: > From my understanding, the SoC site specifically says that you do not > have to work on a project that has to be completed in the allotted > time. I think the idea is that google wants to encourage people that > were already working on a project before to apply and to encourage > people to continue working in the community after the session is > complete. Now the mentoring organization could set their own > requirements, based on difficulty and scope, but I would be concerned > with making time a limiting factor. I'm not saying that we stop people from working on their stuff afterwards, nor forcing them to e.g. implement the full dll if their project is "Start an implementation of dll x". I was talking about shrinking their proposal so they can actually manage to implement all the features they promise in their proposal in the proposed timeframe. I know that this was really hard for me. > The best alternative to the quiz would be to have the student begin > working on the project before the application. He can discuss it on > the the mailing list and hopefully show some code. This would be a > good way to judge coding skill and the project's scope. Now in order > for this to work well, we would have to encourage people to get > started early, which really hasn't happened before right? Well, depends on how you want to do this. I think this is overly restrictive, unless you're just talking about a patch or two like Maarten proposed. > I did write a weekly progress, but only to my mentor. Now if there was > a website, then I could have submitted it there. Yes, that's the idea. :) > > 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. > > Maybe I misunderstood that. I only submitted my final report to > google/mentors. In 2006, students were asked to send the reports to wine-devel, and there was some WWN coverage of the projects. That really made it really easy for people to follow. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: Some thoughts about next GSoC
On Nov 22, 2007 3:38 AM, Kai Blin <[EMAIL PROTECTED]> wrote: > 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. >From my understanding, the SoC site specifically says that you do not have to work on a project that has to be completed in the allotted time. I think the idea is that google wants to encourage people that were already working on a project before to apply and to encourage people to continue working in the community after the session is complete. Now the mentoring organization could set their own requirements, based on difficulty and scope, but I would be concerned with making time a limiting factor. > 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? The best alternative to the quiz would be to have the student begin working on the project before the application. He can discuss it on the the mailing list and hopefully show some code. This would be a good way to judge coding skill and the project's scope. Now in order for this to work well, we would have to encourage people to get started early, which really hasn't happened before right? > > 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. I did write a weekly progress, but only to my mentor. Now if there was a website, then I could have submitted it there. > > 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. > Maybe I misunderstood that. I only submitted my final report to google/mentors. > 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. This is probably the most important thing, and then the web log. Jesse
Re: dlls/winedos/int21.c -- type adjustments
On Thu, 22 Nov 2007, Dmitry Timoshkov wrote:
> It wouldn't take more than 30 additional seconds to look up
> the SetFilePointer prototype in include/ and use real type
> instead.
Which I had done -- except that I apparently lost that update when
creating the patch a couple of weeks ago. My bad. Something went
very wrong here. :-(
Thanks for catching this, Dmitry!
Update patch below.
Gerald
ChangeLog:
Use DWORD instead of long for return values of SetFilePointer.
Adjust type of loop variable in INT21_Ioctl_Char().
Index: dlls/winedos/int21.c
===
RCS file: /home/wine/wine/dlls/winedos/int21.c,v
retrieving revision 1.90
diff -u -3 -p -r1.90 int21.c
--- dlls/winedos/int21.c18 Jun 2007 13:07:13 - 1.90
+++ dlls/winedos/int21.c22 Nov 2007 15:43:09 -
@@ -1385,7 +1385,7 @@ static void INT21_SequentialReadFromFCB(
struct XFCB *xfcb;
HANDLE handle;
DWORD record_number;
-long position;
+DWORD position;
BYTE *disk_transfer_area;
UINT bytes_read;
BYTE AL_result;
@@ -1405,7 +1405,7 @@ static void INT21_SequentialReadFromFCB(
record_number = 128 * fcb->current_block_number +
fcb->record_within_current_block;
position = SetFilePointer(handle, record_number *
fcb->logical_record_size, NULL, 0);
if (position != record_number * fcb->logical_record_size) {
-TRACE("seek(%d, %d, 0) failed with %ld\n",
+TRACE("seek(%d, %d, 0) failed with %u\n",
fcb->file_number, record_number * fcb->logical_record_size,
position);
AL_result = 0x01; /* end of file, no data read */
} else {
@@ -1421,7 +1421,7 @@ static void INT21_SequentialReadFromFCB(
AL_result = 0x03; /* end of file, partial record read */
} /* if */
} else {
-TRACE("successful read %d bytes from record %d (position %ld)
of file %d (handle %p)\n",
+TRACE("successful read %d bytes from record %d (position %u)
of file %d (handle %p)\n",
bytes_read, record_number, position, fcb->file_number,
handle);
AL_result = 0x00; /* successful */
} /* if */
@@ -1465,7 +1465,7 @@ static void INT21_SequentialWriteToFCB(
struct XFCB *xfcb;
HANDLE handle;
DWORD record_number;
-long position;
+DWORD position;
BYTE *disk_transfer_area;
UINT bytes_written;
BYTE AL_result;
@@ -1485,7 +1485,7 @@ static void INT21_SequentialWriteToFCB(
record_number = 128 * fcb->current_block_number +
fcb->record_within_current_block;
position = SetFilePointer(handle, record_number *
fcb->logical_record_size, NULL, 0);
if (position != record_number * fcb->logical_record_size) {
-TRACE("seek(%d, %d, 0) failed with %ld\n",
+TRACE("seek(%d, %d, 0) failed with %u\n",
fcb->file_number, record_number * fcb->logical_record_size,
position);
AL_result = 0x01; /* disk full */
} else {
@@ -1496,7 +1496,7 @@ static void INT21_SequentialWriteToFCB(
fcb->file_number, disk_transfer_area,
fcb->logical_record_size, bytes_written);
AL_result = 0x01; /* disk full */
} else {
-TRACE("successful written %d bytes from record %d (position
%ld) of file %d (handle %p)\n",
+TRACE("successful written %d bytes from record %d (position
%u) of file %d (handle %p)\n",
bytes_written, record_number, position, fcb->file_number,
handle);
AL_result = 0x00; /* successful */
} /* if */
@@ -1541,7 +1541,7 @@ static void INT21_ReadRandomRecordFromFC
struct XFCB *xfcb;
HANDLE handle;
DWORD record_number;
-long position;
+DWORD position;
BYTE *disk_transfer_area;
UINT bytes_read;
BYTE AL_result;
@@ -1561,7 +1561,7 @@ static void INT21_ReadRandomRecordFromFC
} else {
position = SetFilePointer(handle, record_number *
fcb->logical_record_size, NULL, 0);
if (position != record_number * fcb->logical_record_size) {
-TRACE("seek(%d, %d, 0) failed with %ld\n",
+TRACE("seek(%d, %d, 0) failed with %u\n",
fcb->file_number, record_number * fcb->logical_record_size,
position);
AL_result = 0x01; /* end of file, no data read */
} else {
@@ -1577,7 +1577,7 @@ static void INT21_ReadRandomRecordFromFC
AL_result = 0x03; /* end of file, partial record read */
} /* if */
} else {
-TRACE("successful read %d bytes from record %d (position %ld)
of file %d (handle %p)\n",
+TRACE("successful read %d bytes from record %d (position %u)
of file %d (handle %p)\n",
bytes_read, record_number, position, fcb->file_number,
handle)
Re: dlls/winedos/int21.c -- type adjustments
"Gerald Pfeifer" <[EMAIL PROTECTED]> 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.
Re: Ansi to Unicode
On Thursday 22 November 2007 16:01:00 [EMAIL PROTECTED] 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
Ansi to Unicode
Is there any standard function in WINE to transform an Ansi string into a Unicode string? And the opposite?
Re: WineD3D: Implement detection of ATI cards with Mesa DRI drivers [try 3]
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.
Re: d3dx8 [patch 7/7] Implement D3DXMatrixTransformation
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?
Disregard earlier ntdll/tests/env.c patches
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) [EMAIL PROTECTED] http://zacbrown.org
Re: Some thoughts about next GSoC
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 developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: Some thoughts about next GSoC
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.
Re: WineD3D: Implement detection of ATI cards with Mesa DRI drivers [try 3]
Hi, > --- a/ChangeLog > +++ b/ChangeLog > @@ -1,3 +1,8 @@ > +2007-11-22 Roman Mamedov <[EMAIL PROTECTED]> > + > +* dlls/wined3d/directx.c: > +wined3d: Implement detection of ATI cards with Mesa DRI drivers. > + Sorry, I missed this in the first patch: You don't have to update the changelog file in the patches. The ChangeLog is autogenerated from the git commit logs(ie, the subject in the patch file). I am not sure if Alexandre's scripts filter that out or if he asks to resend the patch. signature.asc Description: This is a digitally signed message part.
Some thoughts about next GSoC
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 developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: WineD3D: Implement detection of ATI cards with Mesa DRI drivers [try 3]
> 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
Re: Use GCC's -Wtype-limits
Hi Alexandre, On Wed, 21 Nov 2007, Alexandre Julliard wrote: >> If applied, I will commit to address, directly and by engaging others, >> the occurrences of such warnings in Wine. > I'm not opposed to applying it, but you have to fix the warnings first, > as far as possible the default build should not trigger any warnings. I have been submitting patches to address this, and got down the number quite a bit in my internal tree, but many of the patches I sent earlier this month haven't been applied or responded to yet except for those I resent. Should I continue resending the rest as well? GCC 4.3 hasn't been released yet and won't be released for a few months, so regular users/Wine contributors should not see these warnings, that's why I figured it would be good to get them in, for some of the more advanced hackers here to get exposure as well. Gerald 5B
