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

Re: Some thoughts about next GSoC

by Kai Blin

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 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 Kai Blin

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 developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Nov. 22, 2007

Re: Ansi to Unicode

by James Hawkins

On Nov 22, 2007, at 7:01 AM, 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? > > > msdn is your friend... -- James Hawkins

Nov. 22, 2007

Re: Some thoughts about next GSoC

by mark cox

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 <the3dfxdude(a)gmail.com> wrote: > On Nov 22, 2007 10:00 AM, Kai Blin <kai.blin(a)gmail.com> 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 > > >

Nov. 22, 2007

Re: Some thoughts about next GSoC

by Jesse Allen

On Nov 22, 2007 10:00 AM, Kai Blin <kai.blin(a)gmail.com> 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

Nov. 22, 2007

Re: ntdll: Shared manifests should have a less-strict version check performed when loading them as dependencies.

by Robert Shearman

Alexandre Julliard wrote: > Robert Shearman <rob(a)codeweavers.com> 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

Nov. 22, 2007

Re: wineprefixcreate: get xdg-user-dirs environment variables [1/2]

by Francois Gouget

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 <fgouget(a)free.fr> http://fgouget.free.fr/ 145 = 1! + 4! + 5!

Nov. 22, 2007

Re: Some thoughts about next GSoC

by Kai Blin

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 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 Jesse Allen

On Nov 22, 2007 3:38 AM, Kai Blin <kai.blin(a)gmail.com> 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

Nov. 22, 2007

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

by Gerald Pfeifer

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.c 18 Jun 2007 13:07:13 -0000 1.90 +++ dlls/winedos/int21.c 22 Nov 2007 15:43:09 -0000 @@ -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); AL_result = 0x00; /* successful */ } /* if */ @@ -1614,7 +1614,7 @@ static void INT21_WriteRandomRecordToFCB struct XFCB *xfcb; HANDLE handle; DWORD record_number; - long position; + DWORD position; BYTE *disk_transfer_area; UINT bytes_written; BYTE AL_result; @@ -1634,7 +1634,7 @@ static void INT21_WriteRandomRecordToFCB } 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; /* disk full */ } else { @@ -1645,7 +1645,7 @@ static void INT21_WriteRandomRecordToFCB 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 */ @@ -1689,7 +1689,7 @@ static void INT21_RandomBlockReadFromFCB struct XFCB *xfcb; HANDLE handle; DWORD record_number; - long position; + DWORD position; BYTE *disk_transfer_area; UINT records_requested; UINT bytes_requested; @@ -1713,7 +1713,7 @@ static void INT21_RandomBlockReadFromFCB } 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); records_read = 0; AL_result = 0x01; /* end of file, no data read */ @@ -1734,7 +1734,7 @@ static void INT21_RandomBlockReadFromFCB 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); records_read = records_requested; AL_result = 0x00; /* successful */ @@ -1780,7 +1780,7 @@ static void INT21_RandomBlockWriteToFCB( struct XFCB *xfcb; HANDLE handle; DWORD record_number; - long position; + DWORD position; BYTE *disk_transfer_area; UINT records_requested; UINT bytes_requested; @@ -1804,7 +1804,7 @@ static void INT21_RandomBlockWriteToFCB( } 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); records_written = 0; AL_result = 0x01; /* disk full */ @@ -1819,7 +1819,7 @@ static void INT21_RandomBlockWriteToFCB( records_written = bytes_written / fcb->logical_record_size; AL_result = 0x01; /* disk full */ } else { - TRACE("successful write %d bytes from record %d (position %ld) of file %d (handle %p)\n", + TRACE("successful write %d bytes from record %d (position %u) of file %d (handle %p)\n", bytes_written, record_number, position, fcb->file_number, handle); records_written = records_requested; AL_result = 0x00; /* successful */ @@ -2733,7 +2733,7 @@ static void INT21_IoctlHPScanHandler( CO */ static void INT21_Ioctl_Char( CONTEXT86 *context ) { - int status, i; + int status; int IsConsoleIOHandle = 0; IO_STATUS_BLOCK io; FILE_INTERNAL_INFORMATION info; @@ -2750,6 +2750,7 @@ static void INT21_Ioctl_Char( CONTEXT86 return; } } else { + UINT i; for (i = 0; i < NB_MAGIC_DEVICES; i++) { if (!magic_devices[i].handle) continue;

Nov. 22, 2007