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

Re: DIB Engine & GSoC

by Stefan Dösinger

Am Donnerstag 01 März 2007 14:03 schrieb Benoit Pradelle: > Hi, > > I would like participate to the Google Summer Of Code with Wine by > implementing a DIB Engine. I've searched a lot of informations about the > DIB Engine but i still got one question : > for you, how important is a DIB Engine in Wine ? Hard to say, it depends on what applications are needed. If I said now "the most important thing" that would be obviously wrong, otherwise someone would have implemented it already. I'd say it is one of the top ranked items, but it requires a lot of work and a LOT of knowledge by the programmer. From the importance vs work required it is rather low. The DIB engine would help applications which operate on DIB sections with both direct access and GDI commands. For example DirectX games which use IDirect*Surface?::GetDC regularly, or other applications(I think MS powerpoint is one of them). It will not help Direct3D applications which do not use GetDC. It would also allow is a X-Server / <Apple something> independent GDI implementation. Right now our GDI implementation can only do what the X server can do - not more. Another question is if the existing implementation using the X server can't be optimized. One inefficient thing is that always the full DIB section is converted and copied over. That is technically not necessary when a small letter is drawn to the top left corner. Of course optimizations tend to be tricky, and maybe do not compare with the cost/usability of a real DIB engine. Maybe DirectDraw can be optimized too, by moving the depth conversion from GetDC calls to surface locking. This would only shift the problem, but if DDraw can read the state of the DIB section it could choose the most efficient solution depending on the behavior of the game. Another thing that should be checked before starting is if a fluent transition is possible. For example, when a new dibsection DC is created, create a classic dib section and a DC using the server. If the app does something the new code can't do yet, load the data into the server and use the existing X-Server GDI code. This way a fluent transition is possible, with implementing the important calls first, then adding rare things while still keeping full functionality. Just some thoughts from my side. If you want this as a SOC project you will need some menthor, and I think Alexandre is the only one who can do that for implementing a DIB engine :-)

March 1, 2007

Re: [final, sorry] msi: Expand IDL file to contain all OLE automation interfaces.

by James Hawkins

On 3/1/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > On Thu, 2007-03-01 at 12:29 -0800, James Hawkins wrote: > > On 3/1/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > > > Ok, sorry about posting patches to uncomitted patches, I have > > > reintegrated these changes back into my patches. The change in this > > > patch is the IDL file now contains all OLE automation interfaces as of > > > native installer version 3.0 (as opposed to 2.0). > > > > > > As a reminder this is part 2 of 4 of my patchset: > > > > > > 1. > > > http://www.winehq.org/pipermail/wine-patches/2007-February/036359.html > > > 2. This patch > > > 3. Next patch > > > 4. > > > http://www.winehq.org/pipermail/wine-patches/2007-February/036362.html > > > > > > > You need to resubmit the whole series if you resubmit parts of it. > > > > I feel bad crowding the wine-patches list with my posts and I sent > Alexandre an email with the URLs to all four patches. Do you think I > really need to send all four again? > > Misha > > 1. > http://www.winehq.org/pipermail/wine-patches/2007-February/036359.html > 2. http://www.winehq.org/pipermail/wine-patches/2007-March/036541.html > 3. http://www.winehq.org/pipermail/wine-patches/2007-March/036542.html > 4. > http://www.winehq.org/pipermail/wine-patches/2007-February/036362.html > That's the way the submission process works. Also, you should append/prepend a [tryX], where X is the number of times you've tried to send this in before + 1, so we know exactly which patch emails are the most up to date. -- James Hawkins

March 1, 2007

Re: [final, sorry] msi: Expand IDL file to contain all OLE automation interfaces.

by Misha Koshelev

On Thu, 2007-03-01 at 12:29 -0800, James Hawkins wrote: > On 3/1/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > > Ok, sorry about posting patches to uncomitted patches, I have > > reintegrated these changes back into my patches. The change in this > > patch is the IDL file now contains all OLE automation interfaces as of > > native installer version 3.0 (as opposed to 2.0). > > > > As a reminder this is part 2 of 4 of my patchset: > > > > 1. > > http://www.winehq.org/pipermail/wine-patches/2007-February/036359.html > > 2. This patch > > 3. Next patch > > 4. > > http://www.winehq.org/pipermail/wine-patches/2007-February/036362.html > > > > You need to resubmit the whole series if you resubmit parts of it. > I feel bad crowding the wine-patches list with my posts and I sent Alexandre an email with the URLs to all four patches. Do you think I really need to send all four again? Misha 1. http://www.winehq.org/pipermail/wine-patches/2007-February/036359.html 2. http://www.winehq.org/pipermail/wine-patches/2007-March/036541.html 3. http://www.winehq.org/pipermail/wine-patches/2007-March/036542.html 4. http://www.winehq.org/pipermail/wine-patches/2007-February/036362.html

March 1, 2007

Re: [final, sorry] msi: Expand IDL file to contain all OLE automation interfaces.

by James Hawkins

On 3/1/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > Ok, sorry about posting patches to uncomitted patches, I have > reintegrated these changes back into my patches. The change in this > patch is the IDL file now contains all OLE automation interfaces as of > native installer version 3.0 (as opposed to 2.0). > > As a reminder this is part 2 of 4 of my patchset: > > 1. > http://www.winehq.org/pipermail/wine-patches/2007-February/036359.html > 2. This patch > 3. Next patch > 4. > http://www.winehq.org/pipermail/wine-patches/2007-February/036362.html > You need to resubmit the whole series if you resubmit parts of it. -- James Hawkins

March 1, 2007

Re: Forum proposal

by Wojciech 'arab' Arabczyk

Hello > This question has already been answered.. anyway: if you have both a ML > and a forum, you effectively split the community into two parts! (...) Well - one could setup a forum<->mailing list gateway. -- Best regards Wojciech Arabczyk

March 1, 2007

Re: Forum proposal

by Tomas Carnecky

Luis C. Busquets Pérez wrote: > I understand that for some people the mailing list is a far better > thing. May be for some other, a forum is better. > > Why not trying both systems? > This question has already been answered.. anyway: if you have both a ML and a forum, you effectively split the community into two parts! Nobody will be on both the forum and the ML, it will be harder for the users because they'll have to two places to go to, and it will be harder for the developers because bug-reports will be posted two two different places. tom

March 1, 2007

Re: Forum proposal

by Carl-Daniel Hailfinger

On 01.03.2007 20:09, Luis C. Busquets Pérez wrote: > Why not having both? Running a forum does not exclude continuing with > the mailing lists and could add users and developpers who find more easy > coordinate through a forum. > > Configuring phpBB (www.phpbb.com) does not take more than 1 hour . I > have made a try in 30 minutes starting from not knowing anything about > this package: > > http://ns2.ilidium.com:8011/ > > Why not trying both systems? Simple. phpBB has had dozens of security holes in the past. Most other forum solutions have had the same share of problems. Now imagine a breakin on a site hosted on winehq. The consequences would be far worse than for the average toy project. Wine depends on people trusting us that the code is legally clean (especially due to various FUD campaigns claiming otherwise). A breakin will always result in claims that the codebase has been polluted with MS code. Such a PR disaster is not something we need. You're of course free to import all mails to this mailing list into your own private forum and make that somehow accessible. Regards, Carl-Daniel -- http://www.hailfinger.org/

March 1, 2007

Re: Unknown issue with test.winehq.org

by Paul Vriens

Peter Oberndorfer wrote: > On Thursday 01 March 2007 08:30, Paul Vriens wrote: >> Alexandre Julliard wrote: >>> Paul Vriens <paul.vriens.wine(a)gmail.com> writes: >>> >>>> exception: 42 tests executed (0 marked as todo, 0 failures), 0 skipped. >>>> exception: 279 tests executed (0 marked as todo, 5 failures), 0 skipped. >>>> >>>> The first one triggers the 'end of this test' in dissect. The second >>>> one is thus not accepted as dissect expects a 'start' line (and a line >>>> in between actually). >>>> >>>> The question now is: should dissect handle these cases or is this >>>> particular test-case wrong? >>> It's because some of the tests are run in a child process. dissect >>> should probably handle it, ideally by reporting the sum of the test >>> counts as the results for the whole test. >>> >> So what's the difference between this one and for example the following ones >> running in child processes: >> >> kernel32:process start dlls/kernel32/tests/process.c 1.10 >> tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. >> tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. >> tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. >> tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. >> tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. >> tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. >> tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. >> tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. >> tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. >> tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. >> tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. >> tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. >> tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. >> tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. >> tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. >> tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. >> tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. >> process: 396 tests executed (0 marked as todo, 6 failures), 0 skipped. >> >> or: >> >> msvcrt:file start dlls/msvcrt/tests/file.c 1.45 >> tests/file.c: 3 tests executed (0 marked as todo, 0 failures), 0 skipped. >> tests/file.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. >> file: 361 tests executed (0 marked as todo, 0 failures), 0 skipped. >> >> or better yet: >> >> shell32:shellpath start dlls/shell32/tests/shellpath.c 1.16 >> tests/shellpath.c: 10 tests executed (0 marked as todo, 4 failures), 0 skipped. >> tests/shellpath.c: 4 tests executed (0 marked as todo, 0 failures), 0 skipped. >> shellpath: 452 tests executed (0 marked as todo, 0 failures), 0 skipped. >> >> Obviously the start of line is a filename for these ones, whereas the start of >> the line for the exception one is the test itself. >> >> Should we consolidate the above ones as well? I think yes, cause the shell32 >> example is reflected as 0 errors on test.winehq.org. >> >> Cheers, >> >> Paul. >> > Hi, > sorry for not replying earlier, i didn't check mail yesterday. > > If the problem is only the prefix of the test result line the following trivial patch will make the tests work again. > Output is now: > > ... more traces.... > exception.c:644:excpetion 0xc0000008 at 00000000 firstchance=0 Eip=0x24000b, Eax=0xf00f00f0 > tests/exception.c: 42 tests executed (22 marked as todo, 0 failures), 0 skipped. > exception: 280 tests executed (13 marked as todo, 0 failures), 0 skipped. > > Will send to wine-patches. > Sorry for breaking tests :-/ > > Greetings Peter > > > ------------------------------------------------------------------------ > > diff --git a/dlls/ntdll/tests/exception.c b/dlls/ntdll/tests/exception.c > index 08ec9c6..9a70264 100644 > --- a/dlls/ntdll/tests/exception.c > +++ b/dlls/ntdll/tests/exception.c > @@ -600,7 +600,7 @@ static void test_debugger(void) > return; > } > > - sprintf(cmdline, "%s %s %s", my_argv[0], my_argv[1], "debuggee"); > + sprintf(cmdline, "%s %s %s", my_argv[0], "tests/exception.c", "debuggee"); > ok(CreateProcess(NULL, cmdline, NULL, NULL, FALSE, DEBUG_PROCESS, NULL, NULL, > &si, &pi) != 0, "error: %u\n", GetLastError()); > Hi, I actually sent in a patch (for the website) earlier today that should deal with this as well. My patch makes it possible to have both types of result-lines and the number will be added for every single test (this wasn't the case before). Don't know if both should go in? We definitely need mine (or something alike if Jeremy, or anybody for that matter, doesn't like it) to cope with these multiple lines. Cheers, Paul.

March 1, 2007

Re: Re: Forum proposal

by John Smith

Perhaps there is some middle ground in that support could be improved to make the mailing list archive a bit more forum like and allow posting to the mailing list from the pages on which the mailing list messages would be published? It wouldn't be that different except perhaps the flow and display of conversation would be more easily caught up on by new comers. As it is right now its hard to find out what has been or is being discussed without waiting a few weeks and then puzzling it out. To sum up, mailing list stays, but the archive of it on webpages would get more of an interface to allow better collection and organization of past conversations (very forum like). John On 3/1/07, brettholcomb(a)bellsouth.net <brettholcomb(a)bellsouth.net> wrote: > > I fully agree with Jonathan - the mail lists that have gone to forums I've > dropped off. I can check the mail lists quickly, easily, filter as > necessary and get what I need without having to sign on and wade through a > bunch of posts. If people really want forums setup a forum and let those > who want it use it. > > > > > From: Jonathan Allen <jonathan(a)barumtrading.co.uk> > > Date: 2007/03/01 Thu AM 11:20:18 EST > > To: wine-devel(a)winehq.org > > Subject: Re: Forum proposal > > > > On Thu, Mar 01, 2007 at 05:15:03PM +0100, Luis Carlos Busquets Pérez > wrote: > > > Instead of having the mailing lists, I think that a "forum" would > increase > > > and facilitate the group working. > > > > I could agree less. IMHO a mailing list works well by making sure that > > everyone gets everything, without them needing to go anywhere to get it. > > A forum wil immediately disenfranchise all thsoe who have no immediate > > need to go and visit the forum site every day and so will miss important > > annoucements and so on. Bad idea. > > > > Jonathan > > > > > > > > > >

March 1, 2007

Re: Unknown issue with test.winehq.org

by Peter Oberndorfer

On Thursday 01 March 2007 08:30, Paul Vriens wrote: > Alexandre Julliard wrote: > > Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > > > >> exception: 42 tests executed (0 marked as todo, 0 failures), 0 skipped. > >> exception: 279 tests executed (0 marked as todo, 5 failures), 0 skipped. > >> > >> The first one triggers the 'end of this test' in dissect. The second > >> one is thus not accepted as dissect expects a 'start' line (and a line > >> in between actually). > >> > >> The question now is: should dissect handle these cases or is this > >> particular test-case wrong? > > > > It's because some of the tests are run in a child process. dissect > > should probably handle it, ideally by reporting the sum of the test > > counts as the results for the whole test. > > > So what's the difference between this one and for example the following ones > running in child processes: > > kernel32:process start dlls/kernel32/tests/process.c 1.10 > tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. > tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. > tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. > tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. > tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. > tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. > tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. > tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. > tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. > tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. > tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. > tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. > tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. > tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. > tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. > tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. > tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. > process: 396 tests executed (0 marked as todo, 6 failures), 0 skipped. > > or: > > msvcrt:file start dlls/msvcrt/tests/file.c 1.45 > tests/file.c: 3 tests executed (0 marked as todo, 0 failures), 0 skipped. > tests/file.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. > file: 361 tests executed (0 marked as todo, 0 failures), 0 skipped. > > or better yet: > > shell32:shellpath start dlls/shell32/tests/shellpath.c 1.16 > tests/shellpath.c: 10 tests executed (0 marked as todo, 4 failures), 0 skipped. > tests/shellpath.c: 4 tests executed (0 marked as todo, 0 failures), 0 skipped. > shellpath: 452 tests executed (0 marked as todo, 0 failures), 0 skipped. > > Obviously the start of line is a filename for these ones, whereas the start of > the line for the exception one is the test itself. > > Should we consolidate the above ones as well? I think yes, cause the shell32 > example is reflected as 0 errors on test.winehq.org. > > Cheers, > > Paul. > Hi, sorry for not replying earlier, i didn't check mail yesterday. If the problem is only the prefix of the test result line the following trivial patch will make the tests work again. Output is now: ... more traces.... exception.c:644:excpetion 0xc0000008 at 00000000 firstchance=0 Eip=0x24000b, Eax=0xf00f00f0 tests/exception.c: 42 tests executed (22 marked as todo, 0 failures), 0 skipped. exception: 280 tests executed (13 marked as todo, 0 failures), 0 skipped. Will send to wine-patches. Sorry for breaking tests :-/ Greetings Peter

March 1, 2007