August 2010 - Wine-Devel - list.winehq.org

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized

by GOUJON Alexandre

On 08/30/2010 12:34 AM, Octavian Voicu wrote: > Try running: > > git config --global color.ui auto > > This will activate colorful output for all git commands (in particular > for `git diff' too). > > Then, when you run `git diff' from a terminal you will see whitespace > errors (eg. trailing whitespace) highlighted with a red background. > Hey, that's pretty cool. Can someone add this here http://wiki.winehq.org/GitWine#head-b20b05157175835751686365f9818ae978ceca23 ? Thanks for the tip Octavian !

Aug. 30, 2010

Re: msvcrt:locale Properly fix setlocale and clean up tests

by Alexandre Julliard

GOUJON Alexandre <ale.goujon(a)gmail.com> writes: > On 08/30/2010 11:21 AM, Alexandre Julliard wrote: >> Now you are overdoing it. I said to remove broken() for minor spelling >> differences, not for everything. For instance confusing 936 and 950 >> codepages for Chinese is broken, it's not just a spelling difference > Sorry, I'm trying to do my best but >> Not all of them, but those that don't make sense > was too vague so I considered the following as a rule >> are both OK since they both appear on Windows > (appeared on window = ok() ) The whole point of broken() is for things that appear on Windows but are not considered valid. > So, just to be clear > > - todo_wine ok(!strcmp(ret, "Chinese (Simplified)_People's Republic of China.936") > - || broken(!strcmp(ret, "Chinese_People's Republic of China.936")) > - || broken(!strcmp(ret, "Chinese_Taiwan.950")), "ret = %s\n", ret); > + ok(!strcmp(ret, "Chinese (Simplified)_People's Republic of China.936") > + || !strcmp(ret, "Chinese_People's Republic of China.936") > + || broken(!strcmp(ret, "Chinese_Taiwan.950")), "ret = %s\n", ret); > is correct Yes. > And what about not returned strings e.g. > > - ok(!strcmp(ret, "English_New Zealand.1252") > - || broken(!strcmp(ret, "English_United States.1252")), "ret = %s\n", ret); > + ok(!strcmp(ret, "English_New Zealand.1252"), "ret = %s\n", ret); > > Should I keep them ? (in this case, transform the broken() in ok() ) > Or delete them as I did ? You can't delete them since they appear on Windows (otherwise they wouldn't be marked as broken). And clearly "New Zealand" is not a different spelling of "United States" ;-) so it should remain broken. -- Alexandre Julliard julliard(a)winehq.org

Aug. 30, 2010

Re: DIB clarification

by Michael Stefaniuc

Jeff Cook wrote: > On Sun, Aug 29, 2010 at 7:12 PM, Jeremy White <jwhite(a)codeweavers.com> wrote: >>> This could also help. If I recall correctly, Jeremy White mentioned >>> at Wineconf 2008 that this was a major reason they haven't invested >>> serious energy into one themselves: they had a hard time finding an >>> application that they cared about that benefited significantly from a >>> DIB engine. Usually, bottlenecks were elsewhere. Whether they didn't >>> care about AutoCAD, or whether they hadn't tested with it, or whether >>> my memory is just faulty, I'm not sure. >> Yes, that's essentially right, although note that we did invest some >> fairly serious energy into the DIB engine prior to coming to that conclusion. >> (I remember how pleased Huw was that his benchmarks were 1000 times >> faster, and how displeased he was when it made Powerpoint slower...) >> >> That effort all went into Wine, and I hope and believe that it has >> helped others as they have worked on the DIB engine. >> >> But we don't have any secret stash of DIB engine code to further our >> evil plans for world domination. We rely on our gorgeous femme bots >> and Alexandre's magic 'all' patch for that <grin>. >> > To clarify, it's not about having secret DIB engine code, it's about > saying "I guess we just won't find time to provide useful feedback > until some company sponsors it...", as I saw several times during the > old threads. This is a misunderstanding. Codeweavers figured out that they do not *need* the DIB engine aka it isn't the bottleneck. The estimates to get it implemented/merged where 6-12 man month of "architect level" Wine developer time. A huge time investment for little gain and thus Codeweavers decided to invest their resources in other areas that have a higher return of investment. Now people keep asking about the DIB engine and how to motivate Codeweavers to work on that. I replied to that that in my *personal* opinion they won't do that unsexy and costly work unless somebody is waiving at them with some serious amount of money. That's the standard way in the enterprise world of rising the priority of a bug. But this is my *personal* opinion; I never ever have seen a Codeweavers employee say something like that. And I know Jeremy, he would *love* to get a DIB engine for free, especially as he knows its value in $$$ ;) Now that "that waive with $$$" isn't very likely as the cost/benefit ratio isn't very good. More likely is that Codeweavers will start working on a Quartz driver and that work will make the DIB engine "cheaper" to implement. Again, this is my *personal* opinion. bye michael

Aug. 30, 2010

Re: msvcrt:locale Properly fix setlocale and clean up tests

by GOUJON Alexandre

On 08/30/2010 11:21 AM, Alexandre Julliard wrote: > Now you are overdoing it. I said to remove broken() for minor spelling > differences, not for everything. For instance confusing 936 and 950 > codepages for Chinese is broken, it's not just a spelling difference Sorry, I'm trying to do my best but > Not all of them, but those that don't make sense was too vague so I considered the following as a rule > are both OK since they both appear on Windows (appeared on window = ok() ) So, just to be clear - todo_wine ok(!strcmp(ret, "Chinese (Simplified)_People's Republic of China.936") - || broken(!strcmp(ret, "Chinese_People's Republic of China.936")) - || broken(!strcmp(ret, "Chinese_Taiwan.950")), "ret = %s\n", ret); + ok(!strcmp(ret, "Chinese (Simplified)_People's Republic of China.936") + || !strcmp(ret, "Chinese_People's Republic of China.936") + || broken(!strcmp(ret, "Chinese_Taiwan.950")), "ret = %s\n", ret); is correct - todo_wine ok(!strcmp(ret, "Chinese (Traditional)_Taiwan.950") - || broken(!strcmp(ret, "Chinese_Taiwan.950")), "ret = %s\n", ret); + ok(!strcmp(ret, "Chinese (Traditional)_Taiwan.950") + || !strcmp(ret, "Chinese_Taiwan.950"), "ret = %s\n", ret); this one too And what about not returned strings e.g. - ok(!strcmp(ret, "English_New Zealand.1252") - || broken(!strcmp(ret, "English_United States.1252")), "ret = %s\n", ret); + ok(!strcmp(ret, "English_New Zealand.1252"), "ret = %s\n", ret); Should I keep them ? (in this case, transform the broken() in ok() ) Or delete them as I did ? Thanks

Aug. 30, 2010

Re: msvcrt:locale Properly fix setlocale and clean up tests

by Alexandre Julliard

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > I removed all broken() and ran the tests on all WineTestBot machines > (https://testbot.winehq.org/JobDetails.pl?Key=4829) > Then, I cleaned up tests accordingly : removed superflous broken() and extending ok(). > (https://testbot.winehq.org/JobDetails.pl?Key=4831) Now you are overdoing it. I said to remove broken() for minor spelling differences, not for everything. For instance confusing 936 and 950 codepages for Chinese is broken, it's not just a spelling difference. -- Alexandre Julliard julliard(a)winehq.org

Aug. 30, 2010

Re: DIB clarification

by Austin English

On Sun, Aug 29, 2010 at 7:00 PM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > One additional note: We should, as a project, not accept 'broken' code. I > work with a real-time project and get paid for this that soon will have this > policy in effect. No broken code, it is way to hard to go back and fix it > later. This is one thing I like AJ for. The DIB engine is his one > execption in that he wants it fully implemented and all in one piece. > > Also, Max's code has shown up in another 'for pay' project and where > implementation was done, works. Where implementation is not complete, it is > seriously broken. The problem is where it works and does not work is not > cleanly defined. Lots of 'surprises' and 'gotchas'. > > Anyway, Jeff, please look at Max's code and then ask AJ for specific > guidance on the how to work on this. This is a MAJOR part of the project > that needs to be implemented. Don't feel insulted when you get reject after > reject from AJ. As specific questions, and he does give answers. If he > states "it's broken" he wants you to figure it out and the brokenness is > very obvious. Yes, I've had patches rejected by him and that is all he > said. I figured out the brokenness and fixed it. I've had to back off the > patch as it used code that was rejected and now I know why. James, I hate to be blunt, but you've been repeatedly told to stop giving advice while implying that you are a senior wine developer with lots of experience on the project. I've seen several (potential) new contributors take your advice, submit patches based on it, then have to rework a lot of it based on faulty advice. Lots of people on wine-devel aren't wine developers, or contribute infrequently, but still give good advice, based on what they know and their experience. However, giving authoritative answers when you lack that authority/experience is damaging not only to those contributors, but to wine as a whole. I think http://www.winehq.org/pipermail/wine-devel/2010-July/085495.html sums it up very nicely. /rant -- -Austin

Aug. 30, 2010

Re: DIB clarification

by Tom Wickline

On Mon, Aug 30, 2010 at 8:00 AM, James McKenzie <jjmckenzie51(a)earthlink.net>wrote: > > Also, Max's code has shown up in another 'for pay' project and where > implementation was done, works. Where implementation is not complete, it is > seriously broken. The problem is where it works and does not work is not > cleanly defined. Lots of 'surprises' and 'gotchas'. > > Hello, Max's DIB Engine is built into Bordeaux : http://www.bordeauxgroup.com/mostly for nontechnical people who want to test Max's work in progress. The DIB Engine is turned off by default and unsupported apps can only be installed via the command line at this time. As for CodeWeavers... They are some of the nicest people you will ever meet in your life, not to mention some of the brightest people on this planet. Jeremy did whoever offer to buy the "evil empire" last year for $1 down and the rest payed from future profits if memory serves me right. I'm not sure if Ballmer ever got back to them on the offer. :) See : http://www.codeweavers.com/about/general/press/20090724/ I think my sig pretty much says everything else.. Cheers, Tom -- Wine is not a conclusion but a process...

Aug. 29, 2010

Re: [PATCH 4/6] winealsa.drv: Append hw address to handle to prevent name collision. (resend)

by Vitaliy Margolen

On 08/29/2010 12:43 AM, Jeff Cook wrote: > On Tue, Aug 3, 2010 at 7:49 AM, Vitaliy Margolen > <wine-devel(a)kievinfo.com> wrote: >>> + memcpy(ww->ds_desc.szDesc, description, >>> + min( (sizeof(ww->ds_desc.szDesc) - 1), strlen(description)) >>> ); >> >> This does not guarantee that ww->ds_desc.szDesc will be \0 terminated. >> >> Vitaliy. >> > What do you want me to do? This looks pretty safe to me and I just > copied the block from elsewhere and replaced the variables. Do you > want me to manually read to the end of ww->ds_desc.szDesc and replace > with a \0? Sorry for the noobness. strlen returns number of characters without terminating \0. If you using memcpy to copy strings you must add additional byte (if destination is big enough). Or explicitly zero terminate the destination string (if result was truncated). What you really want is a strlcpy() which unfortunately not present on all platforms. And don't even think using strncpy - it's the worst string function ever made. Just the fact that you copied the exact code doesn't automatically make it correct. Vitaliy.

Aug. 29, 2010

Re: DIB clarification

by Jeff Cook

On Sun, Aug 29, 2010 at 7:12 PM, Jeremy White <jwhite(a)codeweavers.com> wrote: >> This could also help. If I recall correctly, Jeremy White mentioned >> at Wineconf 2008 that this was a major reason they haven't invested >> serious energy into one themselves: they had a hard time finding an >> application that they cared about that benefited significantly from a >> DIB engine. Usually, bottlenecks were elsewhere. Whether they didn't >> care about AutoCAD, or whether they hadn't tested with it, or whether >> my memory is just faulty, I'm not sure. > > Yes, that's essentially right, although note that we did invest some > fairly serious energy into the DIB engine prior to coming to that conclusion. > (I remember how pleased Huw was that his benchmarks were 1000 times > faster, and how displeased he was when it made Powerpoint slower...) > > That effort all went into Wine, and I hope and believe that it has > helped others as they have worked on the DIB engine. > > But we don't have any secret stash of DIB engine code to further our > evil plans for world domination. We rely on our gorgeous femme bots > and Alexandre's magic 'all' patch for that <grin>. > > Cheers, > > Jeremy > To clarify, it's not about having secret DIB engine code, it's about saying "I guess we just won't find time to provide useful feedback until some company sponsors it...", as I saw several times during the old threads. From Jeff

Aug. 29, 2010

Re: DIB clarification

by Jeremy White

> This could also help. If I recall correctly, Jeremy White mentioned > at Wineconf 2008 that this was a major reason they haven't invested > serious energy into one themselves: they had a hard time finding an > application that they cared about that benefited significantly from a > DIB engine. Usually, bottlenecks were elsewhere. Whether they didn't > care about AutoCAD, or whether they hadn't tested with it, or whether > my memory is just faulty, I'm not sure. Yes, that's essentially right, although note that we did invest some fairly serious energy into the DIB engine prior to coming to that conclusion. (I remember how pleased Huw was that his benchmarks were 1000 times faster, and how displeased he was when it made Powerpoint slower...) That effort all went into Wine, and I hope and believe that it has helped others as they have worked on the DIB engine. But we don't have any secret stash of DIB engine code to further our evil plans for world domination. We rely on our gorgeous femme bots and Alexandre's magic 'all' patch for that <grin>. Cheers, Jeremy

Aug. 29, 2010

Re: DIB clarification

by James McKenzie

Juan Lang wrote: > Hi Jeff, > > this has in fact come up before, and been addressed. The main problem > with the current attempt, as far as I know, is that the risk of > regressions is so high that only very high quality changes stand any > chance of getting accepted. In the case of a DIB engine, the attempts > have usually required accepting a large piece of new code wholesale, > with a promise of future fixes. This is a very risky way to make a > change, and Alexandre has repeatedly shown his preference for small, > incremental changes wherever possible. > > Juan and others: One additional note: We should, as a project, not accept 'broken' code. I work with a real-time project and get paid for this that soon will have this policy in effect. No broken code, it is way to hard to go back and fix it later. This is one thing I like AJ for. The DIB engine is his one execption in that he wants it fully implemented and all in one piece. Also, Max's code has shown up in another 'for pay' project and where implementation was done, works. Where implementation is not complete, it is seriously broken. The problem is where it works and does not work is not cleanly defined. Lots of 'surprises' and 'gotchas'. Anyway, Jeff, please look at Max's code and then ask AJ for specific guidance on the how to work on this. This is a MAJOR part of the project that needs to be implemented. Don't feel insulted when you get reject after reject from AJ. As specific questions, and he does give answers. If he states "it's broken" he wants you to figure it out and the brokenness is very obvious. Yes, I've had patches rejected by him and that is all he said. I figured out the brokenness and fixed it. I've had to back off the patch as it used code that was rejected and now I know why. James McKenzie

Aug. 29, 2010

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized

by James McKenzie

Octavian Voicu wrote: > Try running: > > git config --global color.ui auto > > This will activate colorful output for all git commands (in particular > for `git diff' too). > > Then, when you run `git diff' from a terminal you will see whitespace > errors (eg. trailing whitespace) highlighted with a red background. > I've got to try that. Thanks Octavian. James McKenzie

Aug. 29, 2010

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized

by James McKenzie

David Adam wrote: Looks like you are trying very hard to avoid the [try 4] moniker. Please add this to each version of the patch you are submitting. Use the notes feature of git commit to put in why you are submitting a new try. Second, if the patch will NOT apply due to whitespace issues, it will NOT be approved. Please read the Wiki page on Patches. Third, it really appears that you are avoiding the friendly advise given here. We are trying to help you prevent resubmit and then another resubmit for the same problem. You have already aggravated one reviewer that has attempted to help you get this patch accepted. James McKenzie

Aug. 29, 2010

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized

by Octavian Voicu

Try running: git config --global color.ui auto This will activate colorful output for all git commands (in particular for `git diff' too). Then, when you run `git diff' from a terminal you will see whitespace errors (eg. trailing whitespace) highlighted with a red background. Hope it helps, Octavian

Aug. 29, 2010

Re: DIB clarification

by Juan Lang

Hi Jeff, this has in fact come up before, and been addressed. The main problem with the current attempt, as far as I know, is that the risk of regressions is so high that only very high quality changes stand any chance of getting accepted. In the case of a DIB engine, the attempts have usually required accepting a large piece of new code wholesale, with a promise of future fixes. This is a very risky way to make a change, and Alexandre has repeatedly shown his preference for small, incremental changes wherever possible. Without knowing the area in depth, I can only offer this commentary on Massimo's work: Massimo doesn't have a proven track record in the community, so I personally wouldn't trust his ability to minimize regressions, or to maintain his code until regressions he's caused have been fixed. This is nothing to do with him personally, I'd have the same expectations of any relatively new contributor. As to the first, minimizing regressions, this is something a new developer can address by testing an area thoroughly. Often, the best path forward for new code is to introduce substantial new tests in the area before beginning to make functional changes. > I hate to stir the pot, especially as an unknown in the community, but > I've spent the last few hours reading WINE's history regarding DIB > engines and it is pretty distressing. If you hate to do it, why do you do it? It's hard to maintain equanimity when you describe CodeWeavers as evil. Even if you do ascribe that to someone else, why on earth do you bother to repeat it? Such a sentiment is so absurd, it could best be accepted as a joke, but a bad one. Think about it: who has contributed the most, in real dollars, to Wine's development over time? Who releases their own Wine tree in source form? Who employs the most Wine contributors? Just because some pissed off slashdotter said something doesn't make it worthy of a second's thought. Full disclosure: I once did a very small amount of contract work for CodeWeavers, approximately 6 years ago. > AJ's terseness on the issue is puzzling. I find it really weird that such a > major and long-standing thing would just be left to languish without > any detailed reasons. Though I do not believe it, you can start to see > why the slashdotter described Codeweavers' corporate agenda as "evil"; Maybe to you, because you're new around here. When has Alexandre ever been long-winded? He's terse here just as he is elsewhere. If there is any single reason to reject a piece of code, that's enough. See e.g. Henri's comment on a patch the other day [1]: when we give negative feedback on a patch here, we usually don't point out every instance of an error, and expect the contributor to generalize from the feedback. Hence negative feedback here is usually terse. > it almost feels like Codeweavers is holding DIB hostage, just waiting > for someone to get fed up and fork over the cash for it. You can only hold hostage something that exists. There is no such beast as a working DIB engine. > . Alexandre's single major standing complaints seem to be a lack of > test cases and Massimo not establishing a good record with simple > patches. Are those still valid reasons? Yes, of course they are. That's a valid reason for rejection of simple patches. Why shouldn't it be for major, high-risk-of-regression patches? > 1) Write more gdi32 and any other relevant test cases to prove that > the DIB engine is generally well-behaved Yes, this is certainly needed. > Others mentioned that benchmarks that prove the usefulness of a DIB > engine might help. Do those still need to be performed? This could also help. If I recall correctly, Jeremy White mentioned at Wineconf 2008 that this was a major reason they haven't invested serious energy into one themselves: they had a hard time finding an application that they cared about that benefited significantly from a DIB engine. Usually, bottlenecks were elsewhere. Whether they didn't care about AutoCAD, or whether they hadn't tested with it, or whether my memory is just faulty, I'm not sure. Hope that helps, --Juan [1] http://www.winehq.org/pipermail/wine-devel/2010-August/086207.html

Aug. 29, 2010

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized

by Henri Verbeet

On 29 August 2010 20:45, David Adam <david.adam.cnrs(a)gmail.com> wrote: > - You clearly ignored my previous comments about trailing spaces. - This patch changes a lot more things than just allowing DDSCL_NORMAL | DDSCL_FULLSCREEN. E.g. the call to IWineD3DDevice_AcquireFocusWindow(). - Still needs more tests. For example, is the whole wndproc replacement stuff a property of DDSCL_EXCLUSIVE or a property of DDSCL_FULLSCREEN? - I'm not going to look at or comment on any patch with basic whitespace issues anymore.

Aug. 29, 2010

Re: ddraw [patch 2/2]: Add more combinaison tests for SetCooperativeLevels

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4844 Your paranoid android. === W98SE (32 bit ddrawmodes) === No test summary line found === W7PROX64 (64 bit ddrawmodes) === Timeout

Aug. 29, 2010

Re: [PATCH 1/1] gameux/tests: verifying registry values created by GameExplorer (try 4)

by Mariusz Pluciński

W dniu 29.08.2010 18:33, Octavian Voicu pisze: > 2010/8/29 Mariusz Pluciński<vshader(a)gmail.com>: >> Could you tell me is there proper way to tell make to track changes in my >> custom file? Expected effect is running wrc while build if there was >> modification in my .gdf.xml file (currently, it is started only if .rc file >> was modified). Of course, Makefiles in Wine are auto-generated, so the >> solution would add code only to Makefile.in file. > > You need to add a @makedep directive in gameux/tests/rsrc.rc: > > /* @makedep: test.gdf.xml */ > ID_GDF_XML DATA "test.gdf.xml" > > This should include test.gdf.xml as a dependency for rsrc.res in the > automatically generated Makefile. See dlls/cards/cards.rc for more > examples. > > Octavian > Thanks Octavian, it works exactly as I expected.

Aug. 29, 2010

Re: [PATCH 1/1] gameux/tests: verifying registry values created by GameExplorer (try 4)

by Octavian Voicu

2010/8/29 Mariusz Pluciński <vshader(a)gmail.com>: > Could you tell me is there proper way to tell make to track changes in my > custom file? Expected effect is running wrc while build if there was > modification in my .gdf.xml file (currently, it is started only if .rc file > was modified). Of course, Makefiles in Wine are auto-generated, so the > solution would add code only to Makefile.in file. You need to add a @makedep directive in gameux/tests/rsrc.rc: /* @makedep: test.gdf.xml */ ID_GDF_XML DATA "test.gdf.xml" This should include test.gdf.xml as a dependency for rsrc.res in the automatically generated Makefile. See dlls/cards/cards.rc for more examples. Octavian

Aug. 29, 2010

Re: [PATCH 1/1] gameux/tests: verifying registry values created by GameExplorer (try 4)

by Mariusz Pluciński

W dniu 26.08.2010 18:34, (Marvin) pisze: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > http://testbot.winehq.org/JobDetails.pl?Key=4793 > > Your paranoid android. > > > === W7PRO (32 bit gameexplorer) === > gameexplorer.c:453: Test failed: failed while checking registry value (error 0x1) > gameexplorer.c:471: Test failed: failed while checking registry value (error 0x1) > > === W7PROX64 (32 bit gameexplorer) === > gameexplorer.c:453: Test failed: failed while checking registry value (error 0x1) > gameexplorer.c:471: Test failed: failed while checking registry value (error 0x1) > > === W7PROX64 (64 bit gameexplorer) === > gameexplorer.c:453: Test failed: failed while checking registry value (error 0x1) > gameexplorer.c:471: Test failed: failed while checking registry value (error 0x1) > It seems that test bot did not rebuild the .gdf.xml file which I attached as resource (I don't see call of wrc in WINEBUILD log). I also notified similar behavior on my machine. It is because there's no rule in Makefile which depends on this file. Could you tell me is there proper way to tell make to track changes in my custom file? Expected effect is running wrc while build if there was modification in my .gdf.xml file (currently, it is started only if .rc file was modified). Of course, Makefiles in Wine are auto-generated, so the solution would add code only to Makefile.in file.

Aug. 29, 2010

Re: HEAP and FarCry installer

by Henri Verbeet

2010/8/29 <wylda(a)volny.cz>: > > Hope i don't bother you much, but i guess you would tell me... > > I still have a problem with FarCry installer. During that i found > HEAP issue - based on assumption, that message "Heap invalid in-use > arena magic 00eefeee" is unhealthy. > > So program allocates 6fc bytes at 0x14c160 and free those bytes at > the end of the following list, but immediately tries to free another > heap at 14c188 which belongs to the freed area already, right?. Also > there is no trace, that the program allocates that 14c188 memory. Is > that bug or nothing unusual? > Yeah, that looks like a bug, but from the log it's not clear that it isn't just the application doing that. A good start would be to check to what module the "ret" addresses for both the HeapAlloc() and the HeapFree() (7dfef944 and 7dfefa1e in the log) belong. If that's the application or one of its dlls it's likely just an application bug, if on the other hand it's a Wine dll (e.g. msi) that's where you should be looking.

Aug. 29, 2010

Re: d3d9 equivalent of D3DXFVFFromDeclarator?

by Henri Verbeet

On 28 August 2010 23:35, Misha Koshelev <misha680(a)gmail.com> wrote: > One point of clarification if possible. > > The need for D3DXFVFFromDeclarator() from the standpoint ID3DXMesh is > for the GetFVF() function. > > It seems, per dlls/d3d9/tests/vertexdeclaration.c test_decl_to_fvf > that the same functionality (to return an FVF from a device) exists in > d3d9 as well. > Possibly. If you look at the tests in (d3d9) test_fvf_decl_conversion() you'll see that only the first two declarations return anything other than 0 (D3DFVF_XYZ and D3DFVF_XYZRHW), and those are marked as todo_wine. This is "implemented" by vertexdeclaration_init() *not* setting convFVF, and IDirect3DDevice9Impl_GetFVF() returning "decl->convFVF" when a vertex declaration is set. So declarations created by the application will always have 0 for FVF, while the ones created by getConvertedDecl() will have a non-zero FVF associated. It may well be the case that the test is simply flawed; I wouldn't call any of the declarations that return a 0 FVF reasonable. Most of them don't include position data, and the ones that do can't be expressed as an FVF at all. Nevertheless, the simple fact is that d3d9 doesn't currently implement conversion of vertex declarations to FVFs.

Aug. 29, 2010

Re: DIB clarification

by Jesse Allen

On Sun, Aug 29, 2010 at 6:18 AM, Jeff Cook <jeff(a)deserettechnology.com> wrote: > Alexandre is right that the > architecture is a lot of work, but I am not asking for him to write > out a complete spec, and I don't think the community is, either; the > main thing, as far as I can tell, is that the interaction and feedback > on a major step forward for WINE has been minimal. I know it seems frustrating of the lack of response. When I went through the summer of code, the most I got from Alexandre was, 'it doesn't work'. Well what doesn't work? And the honest answer from my own assessment was my engine wasn't finished--which is why I didn't push for a merge then. The school I went to required too much time for me to continue the work, so I put it on hold. That is when Max came in. He found that the code was useful for speeding up his AutoCad. And with the work he has done since then, others have found it useful. So it is not a waste. > > The most feedback I was able to find from Alexandre was on May 2009's > DIB engine passing all tests thread at > http://www.winehq.org/pipermail/wine-devel/2009-May/thread.html#75864 > . Alexandre's single major standing complaints seem to be a lack of > test cases and Massimo not establishing a good record with simple > patches. Are those still valid reasons? > Yes, very much so. The thread shows that there are problems exhibited by the engine which there are no test case for. So passing all tests that have been previously provided are not enough. That would be an area where simple patches can be done. The dib engine 'blob' outside of the tree might be a maintenance issue for someone with the lack of time, and will be very hard to review. So something else will have to be done to get it mainline, if we ignore the implementation choice at the moment. But certainly not all is lost. We now know more than we did before. Jesse

Aug. 29, 2010

DIB clarification

by Jeff Cook

I hate to stir the pot, especially as an unknown in the community, but I've spent the last few hours reading WINE's history regarding DIB engines and it is pretty distressing. I have seen expressions of frustration from many regarding the handling of the mostly-functional DIB engine that Massimo wrote. AJ's terseness on the issue is puzzling. I find it really weird that such a major and long-standing thing would just be left to languish without any detailed reasons. Though I do not believe it, you can start to see why the slashdotter described Codeweavers' corporate agenda as "evil"; it almost feels like Codeweavers is holding DIB hostage, just waiting for someone to get fed up and fork over the cash for it. This wouldn't be a problem of course if it appeared that Alexandre was willing to work with external developers on the DIB engine, but he has given very sparse criticism. Should we all just accept that Massimo's engine is yet another DIB engine gone to waste and there is no future hope for it at all? Max's statements to that effect can be confusing out of context because of his non-native English, but everything I have seen indicates that he is totally willing to work on upstream merging if Alexandre is willing to cooperate. All cases of saying "it won't get merged" etc. by Max seem to reference AJ's reluctance to provide useful criticism on the code that gets posted. It is not my intention to start another huge flamewar or thread on the matter. I just want to promote a reliable roadmap and help resolve this -- it seems like a total shame that there have been multiple DIB engines written and no parts of any of them were deemed worthy of inclusion in WINE. Max at least has indicated a desire to modify the code as necessary if a useful road map or ideation were provided, so why is it so hard to get the road map? Alexandre is right that the architecture is a lot of work, but I am not asking for him to write out a complete spec, and I don't think the community is, either; the main thing, as far as I can tell, is that the interaction and feedback on a major step forward for WINE has been minimal. People are still reporting major speedups on bug #421 so I don't think this is a lost cause unworthy of effort as some suggest. The most feedback I was able to find from Alexandre was on May 2009's DIB engine passing all tests thread at http://www.winehq.org/pipermail/wine-devel/2009-May/thread.html#75864 . Alexandre's single major standing complaints seem to be a lack of test cases and Massimo not establishing a good record with simple patches. Are those still valid reasons? The complaint regarding driver loading was addressed, but it sounds like Alexandre wants it in the opposite direction (forwarding calls from winex11.drv (or whatever driver) to winedib.drv instead of the other way around). Is that a very serious problem? So, if we can, let's get a few points down on what needs to be modified for DIB to make it into WINE, even as an experimental branch: 1) Write more gdi32 and any other relevant test cases to prove that the DIB engine is generally well-behaved 2) Reverse the DIB ordering and call winedib.drv only as needed, instead of passing everything through winedib.drv first. 3) ? Or, in the case that Max's DIB is gone forever and is considered irreparable, why don't we discuss what's needed for a different DIB engine? 1) Write more gdi32 and any other relevant test cases to prove that the DIB engine is generally well-behaved 2) Works well with any wine display driver. (already in Max's code) 3) Applied and developed cooperatively and incrementally with the WINE community 4) Easily disabled / non-disruptive (already in Max's code) 5) ? What else needs to go here? Is this accurate? Others mentioned that benchmarks that prove the usefulness of a DIB engine might help. Do those still need to be performed? Thanks for reading. From Jeff

Aug. 29, 2010

Re: msvcrt:string Avoid size_t in ok()

by GOUJON Alexandre

On 08/29/2010 02:36 AM, James McKenzie wrote: > Alexandre: > > Can we avoid a typo by substituting: > > "Did not returned <value>\n" > > with > > "Did not return <value>\n" > > for each instance in the file? > > Thank you. > > James McKenzie > Sorry for the typo, I guess I wrote it too fast. And no problem, I'll send a try2.

Aug. 29, 2010