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

Re: [PATCH 2/3] winex11.drv: set global key state

by Rafał Miłecki

Hi Alexandre, W dniu 11 września 2009 13:22 użytkownik Alexandre Julliard <julliard(a)winehq.org> napisał: > Rafał Miłecki <zajec5(a)gmail.com> writes: > >> @@ -1250,6 +1250,21 @@ void X11DRV_send_keyboard_input( WORD wVk, WORD wScan, DWORD event_flags, DWORD >> key_state_table[wVkStripped] = key_state_table[wVkL] | key_state_table[wVkR]; >> } >> >> + SERVER_START_REQ( set_global_key_state ) >> + { >> + req->key = wVk; >> + req->state = key_state_table[wVk]; >> + wine_server_call( req ); >> + } >> + SERVER_END_REQ; >> + SERVER_START_REQ( set_global_key_state ) >> + { >> + req->key = wVkStripped; >> + req->state = key_state_table[wVkStripped]; >> + wine_server_call( req ); >> + } >> + SERVER_END_REQ; >> + > > You don't want to add 2 extra server calls for every key, especially > since the server already receives the necessary information through the > key event. It's prehistoric thread already, but issue still isn't solved. I wanted to rework that old patch but I noticed set_key_state was already changed and it doesn't change single key state, but instead sets whole array at every call. This was I can not use set_key_state handler to update my "global_keystate" array, as I have no idea which key actually has been changed. Do you see some nice solution for this problem? -- Rafał

Aug. 16, 2010

Re: [4/6] ipconfig: Partially implement basic adapter information output.

by Andrew Nguyen

On 08/16/2010 01:24 PM, Juan Lang wrote: > Hi Andrew, > + static const WCHAR ethernetW[] = {'E','t','h','e','r','n','e','t',0}; > + static const WCHAR unknownW[] = {'U','n','k','n','o','w','n',0}; > shouldn't these be resources instead? > --Juan Hmm, I suppose they probably should be. I was being "lazy", but I can make it happen.

Aug. 16, 2010

Re: [PATCH 1/5] d3d10: Fix d3dcommon.h inclusion.

by James Mckenzie

Henri Verbeet <hverbeet(a)gmail.com> wrote: >Sent: Aug 16, 2010 11:06 AM >To: Rico Schüller <kgbricola(a)web.de> >Cc: wine-devel(a)winehq.org >Subject: Re: [PATCH 1/5] d3d10: Fix d3dcommon.h inclusion. > >2010/8/16 Rico Schüller <kgbricola(a)web.de>: >> Yes, this replaces the earlier patch series. I thought this was clear from >> the discussion for try 2. >> >At the very least it's obvious that the other series isn't going to >happen. Whether this series replaces it or is independent doesn't >matter a whole lot at that point. > If the other series is cancelled, it would be nice to state so as well. This conserves AJ's time and efforts. This has happened to me (I found that my code was seriously broken.) James McKenzie

Aug. 16, 2010

Re: [4/6] ipconfig: Partially implement basic adapter information output.

by Juan Lang

Hi Andrew, + static const WCHAR ethernetW[] = {'E','t','h','e','r','n','e','t',0}; + static const WCHAR unknownW[] = {'U','n','k','n','o','w','n',0}; shouldn't these be resources instead? --Juan

Aug. 16, 2010

WineAPI structure plans

by Max TenEyck Woodbury

I think I have a usable structure for the pages on the WineAPI wiki which I am about to lay before you, but first a discussion of the project name... ---- I understand that some people do not particularly approve of the name I have given this project. It is on Sourceforge and a short relevant name was needed. Much of the information to be presented is specific to Wine and will be based on the contents of the Wine repository. The name reflects that dependence. Other projects may want to use the information presented. They are welcome to do so as far as I am concerned. They may also wish to present information specific to their projects. That is an excellent idea and I will help where I can, but I have two reservations: First, I am unlikely to be familiar with the structure of other projects; I will not be able to maintain those contributions. Someone from the other projects will have to take responsibility for maintaining those contributions and coordinate with the members of the project from Wine. Second, where there are differences between the projects, and the other projects are invited to provide their information but not at the expense of the Wine information. I also included a reference to 'API'. More than just the API will be covered, but the API will definitely be included. While Wine is intended to provide an interface functionally equivalent to the Microsoft products, it will differ from their interface in small ways. One of the most important differences will be that this API is open and *not* particularly designed to promote Microsoft's products. References to the Microsoft documentation will be included, but infringement of Microsoft's copyrights is *not* intended and will be corrected as quickly as it can be verified. The project name can be changed if really necessary, but requests to change it should be constructive with an emphasis on how the new name meets the projects needs. ---- There are two major types of information that will be presented. One type of information is annotation, opinion, discussion, description and so on. This will be managed by people. Another type of information is technical and is tied directly to the contents of the Wine project (and other projects when the details have been worked out). My intention is to write scripts that extract and report this kind of information. This information will change as Wine changes. It will be difficult for the scripts to work around the human generated content. To allow the two major kinds of information to mix, they will be kept on separate pages. Specifically, the editable information will be kept on what MediaWiki calls 'sub-pages'. The places where sub-pages are included will be controlled by the scripts. The script writers will need to be informed of where these inclusions should be placed. Also, to keep the number of 'red-links' under control, The scripts will generate initial versions of the sub-pages. Some structure is needed to make the scripts work and to allow people to check the scripts. For that reason, all script generated pages will start with a comment describing the main script responsible for generating the page along with revision information for the script and script components. The comment will also identify the revision of the repository used to generate the page. (Note, the revision information will be for the last time the page content has to be changed, and will not be updated unless the page content, and not the revision information, is changed. Some structure will also be needed for sub-pages and will be set up in the generated initial versions of those pages. That structure consists of a link back to the article that included the sub-page, markings that the page is editable and at least one section header to serve as a handle to enable easy editing of the sub-page. -Max

Aug. 16, 2010

Re: [PATCH 1/5] d3d10: Fix d3dcommon.h inclusion.

by Henri Verbeet

2010/8/16 Rico Schüller <kgbricola(a)web.de>: > Yes, this replaces the earlier patch series. I thought this was clear from > the discussion for try 2. > At the very least it's obvious that the other series isn't going to happen. Whether this series replaces it or is independent doesn't matter a whole lot at that point.

Aug. 16, 2010

Re: [PATCH 1/5] d3d10: Fix d3dcommon.h inclusion.

by James Mckenzie

Rico Schüller <kgbricola(a)web.de> wrote: >Sent: Aug 16, 2010 10:21 AM >To: wine-devel(a)winehq.org >Subject: Re: [PATCH 1/5] d3d10: Fix d3dcommon.h inclusion. > >Am 15.08.2010 18:26, schrieb James McKenzie: >> Rico Schüller wrote: >>> Hi, >>> >>> this patch series implements the ID3DBlob interface. This time the >>> interface is implemented in the d3dcompiler_43.dll. The function >>> D3D10CreateBlob from d3d10 is forwarded to the D3DCreateBlob function >>> in the d3dcompiler_43.dll. >> >> Does this replace the ten patch series you submitted on 8/11? This is >> not clear here. >> >Yes, this replaces the earlier patch series. I thought this was clear >from the discussion for try 2. > I've learned the hard way to never assume anything and to document everything. If something can be misunderstood it will and will in the most damaging manner. James McKenzie James McKenzie

Aug. 16, 2010

Re: [PATCH 1/5] d3d10: Fix d3dcommon.h inclusion.

by Rico Schüller

Am 15.08.2010 18:26, schrieb James McKenzie: > Rico Schüller wrote: >> Hi, >> >> this patch series implements the ID3DBlob interface. This time the >> interface is implemented in the d3dcompiler_43.dll. The function >> D3D10CreateBlob from d3d10 is forwarded to the D3DCreateBlob function >> in the d3dcompiler_43.dll. > > Does this replace the ten patch series you submitted on 8/11? This is > not clear here. > > James McKenzie > > > Yes, this replaces the earlier patch series. I thought this was clear from the discussion for try 2. Cheers Rico

Aug. 16, 2010

RE: Wine users with a CD-ROM drive, please test

by Ge van Geldorp

> From: Joerg Hoehle > > There's no mention of win95/98 in the attachment so I assume these > were not included, or was that because there was no error? Right, they were not included. I ran into some problems trying to attach the .iso to those VMs and gave up. Win9x should die :-). Ge.

Aug. 16, 2010

Wine users with a CD-ROM drive, please test

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Greg Geldorp wrote: >I ran mcicda_test from TestBot job 4436 on the TestBot VMs, with a >data .iso connected as CD-ROM. Thank you very much for your excellent support. It's good to have such tests executed on a broad range of OS prior to submission. There's no mention of win95/98 in the attachment so I assume these were not included, or was that because there was no error? Don't worry, I don't need further tests from w9x (or others). >On NT4, Win2000, XP, W2K3 >mcicda.c:397: Test failed: STATUS position: MCIERR_HARDWARE IMHO this shows that a vmware machine has a different timing than native with a real CD-ROM. There's already a comment in the tests about: Status position -> ok Sleep 2seconds Status position -> MCIERR_HARDWARE Your vmware boxes appear to deliver the latter immediately ;) I'll add a broken() to account for this. >On NT4, Win2000: >mcicda.c:318: Test failed: resume without play: 0=NOERROR Weird, since a real w2k machine with a data only CD returns MCIERR_HARDWARE. Adding a broken() here would annoy me as it would shadow every successful return from any other machine (with a real CD). Let's see what test.winrhq.org will reveal when I'll submit the tests. Thanks to all you people who contributed test results, Jörg Höhle

Aug. 16, 2010

Re: [3/3] wined3d: Remove isInDraw hack from context_setup_target.

by Stefan Dösinger

Am 16.08.2010 um 13:58 schrieb Henri Verbeet: > On 16 August 2010 13:25, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >> It is conceptually wrong and actually broken too (as the comment there >> said). Just remove the hack now and properly fix any regression >> that may come up later by explicitely acquiring the right context where >> needed (so, in surface_internal_preload and its callees). > Note that isInDraw is mildly awful in itself, and we should probably > get rid of it eventually. In most places where it's used it's probably > an artifact of the old context management, but that needs to be > checked. Vertex buffer preloads are a problem. Between two draw calls the stateblock may be in an invalid state(e.g. a stream referenced by the vdecl is still set to NULL), so it may be unsafe for VB_PreLoad to attempt to find out which vertex attrib types are in the buffer. Now that mechanism has changed a while ago too. Nowadys the VBO code uses the cached strided data from the device, rather than parsing it on its own. There are also some places where isInDraw is used to avoid redundant "give me a context, any render target, any state" context_acquire calls.

Aug. 16, 2010

Re: [3/3] wined3d: Remove isInDraw hack from context_setup_target.

by Henri Verbeet

On 16 August 2010 13:25, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > It is conceptually wrong and actually broken too (as the comment there > said). Just remove the hack now and properly fix any regression > that may come up later by explicitely acquiring the right context where > needed (so, in surface_internal_preload and its callees). Note that isInDraw is mildly awful in itself, and we should probably get rid of it eventually. In most places where it's used it's probably an artifact of the old context management, but that needs to be checked.

Aug. 16, 2010

Re: [1/3] wined3d: Call set_render_offscreen at the end of context_setup_target.

by Henri Verbeet

I'm ok with this, but for future reference, if the change isn't entirely obvious a small comment is usually appropriate.

Aug. 16, 2010

Re: [PATCH 2/2] jscript: Throw TypeError in in_eval.

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=4470 Your paranoid android. === W98SE (32 bit) === No test summary line found === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found

Aug. 16, 2010

Re: urlmon: Return failures from progress callback

by Jacek Caban

Hi Juan, On 8/4/10 11:44 PM, Juan Lang wrote: > Partial fix for bug 21032. > --Juan if(!This->callback) - return; + return E_POINTER; This doesn't seem right. It's fine to call URLDownloadToFile without callback AFAIR. Thanks, Jacek

Aug. 16, 2010

Re: [PATCH 1/2] jscript: Throw TypeError in instanceof_expression_eval.

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=4469 Your paranoid android. === W98SE (32 bit) === No test summary line found === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found

Aug. 16, 2010

Re: Some statistics about the 1.0->1.2 development cycle

by Francois Gouget

On Sun, 15 Aug 2010, Marcus Meissner wrote: [...] > Similar for me ... "marcus(a)jet.franken.de" is my private account and means > private work. > > (The meissner(a)suse.de account is however for work I have done on SUSE time.) Same split here: fgouget(a)codeweavers.com patches were for work and fgouget(a)free.fr are for personal stuff. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.

Aug. 16, 2010

Re: [PATCH 1/1] d3dx9: Add tests for FVF <-> declaration conversion.

by Henri Verbeet

This is for the most part just a copy of the corresponding d3d9 test, so I guess it should work, but it also contains most of the flaws from that test, like e.g. returning E_FAIL from a function returning int. There's probably room for improvement in the test setup itself as well.

Aug. 16, 2010

kernel32/tests: GetVolumeInformationA X: succeeds iff drive's default dir is root. (try 2)

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Greg Geldorp wrote: >I ... ran the test, >In short: everything passes. This is excellent news. Hopefully somebody will jump in and write code for kernel32/volume.c that satisfies the tests and get fame for fixing bug #23355 and help #20887. I'm nominating the bugfix for 1.2.1 Regards, Jörg Höhle.

Aug. 16, 2010

Re: comctl32: Simplify is_textT by omitting isW.

by Gerald Pfeifer

On Mon, 10 May 2010, Nikolay Sivov wrote: >> -static inline BOOL is_textT(LPCWSTR text, BOOL isW) >> +static inline BOOL is_textT(LPCWSTR text) >> > There's no reason to keep this helper then. It's better to rename > is_textW() to is_text() and remove is_textT(). Excellent idea. I'll submit a patch to the extent in a minute (and sorry that this has taken three months). Gerald

Aug. 15, 2010

Re: Some statistics about the 1.0->1.2 development cycle

by Wolfram Sang

> you'll have to reassign my patches to the "(None)" category. While I do Will do, of course. Also for all the other requests I get/got. > for that; even my trips to the WineConfs are payed out of my own pocket. Sounds familiar ;) Regards, Wolfram

Aug. 15, 2010

Re: Some statistics about the 1.0->1.2 development cycle

by Wolfram Sang

> But just for accuracy, I'm a frenchman. Ah, now I remember what I wanted to add to the README :) I did not change anything in the built-in country-detection which is still quite experimental, even upstream. Please just ignore it. I once thought about removing it, might do so later on. Thanks, Wolfram

Aug. 15, 2010

Re: Some statistics about the 1.0->1.2 development cycle

by GOUJON Alexandre

Rather interesting , thanks ! But just for accuracy, I'm a frenchman.

Aug. 15, 2010

Re: Some statistics about the 1.0->1.2 development cycle

by Henri Verbeet

On 15 August 2010 19:28, Marcus Meissner <marcus(a)jet.franken.de> wrote: > Similar for me ... "marcus(a)jet.franken.de" is my private account and means > private work. > Similar split for me, although the amount of patches from hverbeet(a)gmail.com after 1.0 is probably trivial.

Aug. 15, 2010

Re: Some statistics about the 1.0->1.2 development cycle

by Marcus Meissner

On Sun, Aug 15, 2010 at 07:13:12PM +0200, Michael Stefaniuc wrote: > Hello Wolfram, > > On 08/15/2010 05:42 PM, Wolfram Sang wrote: >> I am going to speak about my "getting into wine development" at FrosCon >> (near Bonn/Germany) next weekend. During preparation, I was interested >> in some numbers, so I roughly modified 'kps' (kernel patch statistics) >> for wine. The outcome for the 1.0->1.2 cycle can be found here, if >> somebody is interested (just make sure you read the README first): >> >> http://www.the-dreams.de/wine/winekpsstats10-12.tar.gz >> >> So far, not too surprising IMHO, although I probably missed a number of >> people. I am open for comments, if there are some. > you'll have to reassign my patches to the "(None)" category. While I do > work for Red Hat I'm working there as a network engineer, not as a > developer. Wine is pure hobby for me and Red Hat doesn't pay me a cent for > that; even my trips to the WineConfs are payed out of my own pocket. Similar for me ... "marcus(a)jet.franken.de" is my private account and means private work. (The meissner(a)suse.de account is however for work I have done on SUSE time.) Ciao, Marcus

Aug. 15, 2010

Re: Some statistics about the 1.0->1.2 development cycle

by Michael Stefaniuc

Hello Wolfram, On 08/15/2010 05:42 PM, Wolfram Sang wrote: > I am going to speak about my "getting into wine development" at FrosCon > (near Bonn/Germany) next weekend. During preparation, I was interested > in some numbers, so I roughly modified 'kps' (kernel patch statistics) > for wine. The outcome for the 1.0->1.2 cycle can be found here, if > somebody is interested (just make sure you read the README first): > > http://www.the-dreams.de/wine/winekpsstats10-12.tar.gz > > So far, not too surprising IMHO, although I probably missed a number of > people. I am open for comments, if there are some. you'll have to reassign my patches to the "(None)" category. While I do work for Red Hat I'm working there as a network engineer, not as a developer. Wine is pure hobby for me and Red Hat doesn't pay me a cent for that; even my trips to the WineConfs are payed out of my own pocket. bye michael

Aug. 15, 2010

Re: [PATCH 1/5] d3d10: Fix d3dcommon.h inclusion.

by James McKenzie

Rico Schüller wrote: > Hi, > > this patch series implements the ID3DBlob interface. This time the > interface is implemented in the d3dcompiler_43.dll. The function > D3D10CreateBlob from d3d10 is forwarded to the D3DCreateBlob function > in the d3dcompiler_43.dll. Does this replace the ten patch series you submitted on 8/11? This is not clear here. James McKenzie

Aug. 15, 2010

Some statistics about the 1.0->1.2 development cycle

by Wolfram Sang

Hello, I am going to speak about my "getting into wine development" at FrosCon (near Bonn/Germany) next weekend. During preparation, I was interested in some numbers, so I roughly modified 'kps' (kernel patch statistics) for wine. The outcome for the 1.0->1.2 cycle can be found here, if somebody is interested (just make sure you read the README first): http://www.the-dreams.de/wine/winekpsstats10-12.tar.gz So far, not too surprising IMHO, although I probably missed a number of people. I am open for comments, if there are some. Have a nice sunday, Wolfram

Aug. 15, 2010

Re: Wine users with a CD-ROM drive, please test

by James McKenzie

Matijn Woudt wrote: > On Fri, Aug 13, 2010 at 3:03 PM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > >> Hi, >> >> I found out that some machines ignore >> set c audio all off >> which was in the testsuite, while others react to it and even >> update the system preferences volume mixer control if >> it happens to be open. >> >> I don't know whether that difference depends on the HW (CD-ROM >> driver) or the OS. You can find it out by posting your results here. >> >> I'm now using >> set c audio all on >> (which should be the default) >> such that all users running the testsuite get to hear something. >> >> https://testbot.winehq.org/JobDetails.pl?Key=4434 >> mcicda.c:612: Test failed: STOP all returned MCIERR_HARDWARE >> (I fixed that, but not yet on testbot). >> >> Regards, >> Jörg Höhle >> > > That fixed playback. > One thing, with my Beethoven CD: > mcicda.c:300: Test failed: status position initially 00:03:00 > mcicda.c:306: Test failed: status position start 00:03:00 > mcicda.c:350: Test failed: status position initially 3001ms > > IIRC, it can be anything, but should atleast be 2 seconds. > It is. 3001 ms is one ms more than three seconds.... James McKenzie

Aug. 15, 2010

Re: [7/13] comctl32/imagelist: Fail to create imagelist with zero or negative image dimensions

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=4453 Your paranoid android. === WVISTAADM (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W2K8SE (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PRO (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (64 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000

Aug. 15, 2010

Re: [6/13] comctl32/imagelist: Fail in ImageList_GetIconSize on null parameters

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=4452 Your paranoid android. === WVISTAADM (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W2K8SE (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PRO (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (64 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000

Aug. 15, 2010

Re: [5/13] comctl32/tests: More imagelist tests to show broken parameter validation

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=4451 Your paranoid android. === WVISTAADM (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W2K8SE (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PRO (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (64 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000

Aug. 15, 2010

Re: [4/13] comctl32/imagelist: Fix failure code for IImageList_Remove()

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=4450 Your paranoid android. === WVISTAADM (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W2K8SE (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PRO (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (64 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000

Aug. 15, 2010

Re: [3/13] comctl32/imagelist: Fix failure code for IImageList_Draw()

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=4449 Your paranoid android. === WVISTAADM (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W2K8SE (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PRO (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (64 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000

Aug. 15, 2010

Re: [2/13] comctl32/tests: Use reduced IMAGELISTDRAWPARAMS structure size for tests

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=4448 Your paranoid android. === WVISTAADM (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W2K8SE (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PRO (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (64 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000

Aug. 15, 2010

Re: Wine users with a CD-ROM drive, please test

by Matijn Woudt

On Fri, Aug 13, 2010 at 3:03 PM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Hi, > > I found out that some machines ignore > set c audio all off > which was in the testsuite, while others react to it and even > update the system preferences volume mixer control if > it happens to be open. > > I don't know whether that difference depends on the HW (CD-ROM > driver) or the OS. You can find it out by posting your results here. > > I'm now using > set c audio all on > (which should be the default) > such that all users running the testsuite get to hear something. > > https://testbot.winehq.org/JobDetails.pl?Key=4434 > mcicda.c:612: Test failed: STOP all returned MCIERR_HARDWARE > (I fixed that, but not yet on testbot). > > Regards, > Jörg Höhle That fixed playback. One thing, with my Beethoven CD: mcicda.c:300: Test failed: status position initially 00:03:00 mcicda.c:306: Test failed: status position start 00:03:00 mcicda.c:350: Test failed: status position initially 3001ms IIRC, it can be anything, but should atleast be 2 seconds. - Matijn

Aug. 15, 2010

Re: [1/13] comctl32/tests: Use better names for test functions, discover some new test failures

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=4447 Your paranoid android. === WVISTAADM (32 bit imagelist) === imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W2K8SE (32 bit imagelist) === imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PRO (32 bit imagelist) === imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (32 bit imagelist) === imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (64 bit imagelist) === imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000

Aug. 15, 2010

Re: avifil32: Fix EditStreamSetInfo wine checks

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=4442 Your paranoid android. === W98SE (32 bit api) === No test summary line found === WNT4WSSP6 (32 bit api) === No test summary line found === W2KPROSP4 (32 bit api) === No test summary line found === W2K3R2SESP2 (32 bit api) === No test summary line found === WVISTAADM (32 bit api) === No test summary line found === W2K8SE (32 bit api) === No test summary line found === W7PRO (32 bit api) === No test summary line found === W7PROX64 (32 bit api) === No test summary line found === W7PROX64 (64 bit api) === Timeout

Aug. 15, 2010

iPod synced with iTunes v7.6!

by Russ Mannex

Hello Maarten! I read your post on the WineHQ site. I was wondering if you know whether I am attempting something that simply will not work yet. I am running iTunes 7.7.1 on Wine 1.1.42. These are running on Ubuntu 10.04. iTunes is not showing my iPod. I have tried setting an autodetect drive E: to /media/IPOD, but iTunes seems to not see it there. Any help will be greatly appreciated, even if the answer is "will not work." Thanks. -- Russ Mannex Russ(a)Mannex.com

Aug. 15, 2010

Re: [2/2] ws2_32, WS2_sendto: Avoid error when sending zero byte buffer (try 2)

by Mike Kaplinskiy

Several things: - Don't set errno. For good practice it's more or less read-only. - All the tests have to pass after each patch, so if your tests fail (which they probably should) without your patch, add todo_wine and then remove them in the followup patch (or just send the tests second). - The tests you provided pass without this patch so I'm not convinced that your fix is necessary. errno 107 = ENOTCONN, so while 0 length sends work just fine, they only work when non-zero sends also work. i.e. invalid sends get turned to valid sends on windows when the length is 0. It might be better to test calling WSASendTo with 0 length on unconnected tcp (or udp if tcp doesn't work) sockets. Good luck, Mike. On Sat, Aug 14, 2010 at 5:45 AM, Wolfgang Schwotzer <wolfgang.schwotzer(a)gmx.net> wrote: > This solves #19397. > > > > >

Aug. 14, 2010

Re: kernel32/tests: GetVolumeInformationA X: succeeds iff drive's default dir is root. (try 2)

by Greg Geldorp

Hi Joerg, I temporarily attached a second disk to all TestBot VMs and ran the test, both from the C: drive and from the (new) E: drive. Full results attached. In short: everything passes. Ge.

Aug. 14, 2010

RE: Wine users with a CD-ROM drive, please test

by Greg Geldorp

Hi Joerg, > From: Joerg Hoehle > > I found out that some machines ignore > set c audio all off > which was in the testsuite, while others react to it and even > update the system preferences volume mixer control if > it happens to be open. > > I don't know whether that difference depends on the HW (CD-ROM > driver) or the OS. You can find it out by posting your results here. > > I'm now using > set c audio all on > (which should be the default) > such that all users running the testsuite get to hear something. > > https://testbot.winehq.org/JobDetails.pl?Key=4434 > mcicda.c:612: Test failed: STOP all returned MCIERR_HARDWARE > (I fixed that, but not yet on testbot). I ran mcicda_test from TestBot job 4436 on the TestBot VMs, with a data .iso connected as CD-ROM. Full results in attachment. In short: On NT4, Win2000: mcicda.c:318: Test failed: resume without play: 0=NOERROR On NT4, Win2000, XP, W2K3 mcicda.c:397: Test failed: STATUS position: MCIERR_HARDWARE Ge.

Aug. 14, 2010

Re: Wine users with a CD-ROM drive, please test

by Jeff Zaroyko

On Fri, Aug 13, 2010 at 11:03 PM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > I'm now using > set c audio all on > (which should be the default) > such that all users running the testsuite get to hear something. > > https://testbot.winehq.org/JobDetails.pl?Key=4434 > mcicda.c:612: Test failed: STOP all returned MCIERR_HARDWARE > (I fixed that, but not yet on testbot). I hear the playback, no more failures here with the same media as tested before, except for the one you mention 612 which only occurred with a blank cd. Nice work!

Aug. 13, 2010

Wine users with a CD-ROM drive, please test

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, I found out that some machines ignore set c audio all off which was in the testsuite, while others react to it and even update the system preferences volume mixer control if it happens to be open. I don't know whether that difference depends on the HW (CD-ROM driver) or the OS. You can find it out by posting your results here. I'm now using set c audio all on (which should be the default) such that all users running the testsuite get to hear something. https://testbot.winehq.org/JobDetails.pl?Key=4434 mcicda.c:612: Test failed: STOP all returned MCIERR_HARDWARE (I fixed that, but not yet on testbot). Regards, Jörg Höhle

Aug. 13, 2010

Re: [(try 2) 02/11] d3d10: Implement D3D10CreateBlob().

by Henri Verbeet

On 12 August 2010 22:01, Rico Schüller <kgbricola(a)web.de> wrote: > The whole structure (d3d10_blob) could be put in d3d10_main.c. Or should I > use a separate file for the ID3D10Blob interface as it is done with the > ID3DXBuffer interface in d3dx9_36.dll? Then the location in the header would > be fine. > I think D3D10CreateBlob() should forward to d3dcompiler (D3DCreateBlob()).

Aug. 13, 2010

Re: Fwd: Should we expect Liberation fonts to be installed?

by Paul "TBBle" Hampson

2010/8/12 André Hentschel <nerv(a)dawncrow.de>: > Wow, can you please update http://wiki.winehq.org/FontLoadOrder with these great informations? I'm not sure that's the _best_ page for it (this isn't about font loading, but font substitution) but I'll see about writing it all up properly this weekend. (And if I'm feeling enthused, see if I can make fontconfig aliases work, although a brief glace at the API suggests there's nothing specifically for fetching the alias list) -- Paul "TBBle" Hampson, Paul.Hampson(a)Pobox.com

Aug. 12, 2010

Re: [(try 2) 02/11] d3d10: Implement D3D10CreateBlob().

by Rico Schüller

Am 11.08.2010 22:19, schrieb Stefan Dösinger: > Am 11.08.2010 um 21:51 schrieb Rico Schüller: > >> --- a/dlls/d3d10/d3d10_private.h >> +++ b/dlls/d3d10/d3d10_private.h >> @@ -212,6 +212,17 @@ struct d3d10_effect >> struct d3d10_effect_technique *techniques; >> }; >> >> >> +extern const struct ID3D10BlobVtbl d3d10_blob_vtbl DECLSPEC_HIDDEN; >> > Do you need the declaration of the vtable in the header? As far as I can see you're not using it anywhere outside d3d10_main.c. > > Yeah, I don't need it in the header. The whole structure (d3d10_blob) could be put in d3d10_main.c. Or should I use a separate file for the ID3D10Blob interface as it is done with the ID3DXBuffer interface in d3dx9_36.dll? Then the location in the header would be fine.

Aug. 12, 2010

Re: Windows Imaging Component

by Roderick Colenbrander

On Thu, Aug 12, 2010 at 8:42 AM, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > On Thu, Aug 12, 2010 at 4:54 AM, Georgij Kirichenko > <kirichenkoga(a)gmail.com> wrote: >> This patch add support for decoding Dds, Ppm(and pgm, pbm) and Tga files th >> Windows Imaging Component. > > Each format you are adding requires its own patch. > >> This patch use dynamic linked FreeImage library, but i'am can't static link >> this library. > > First of all, I'm not so sure we want to use FreeImage. The initial > thing about which I'm not sure is the license. You can use it under > either a commercial license or under the GPL. The last one at least is > usable for us as it would make all of Wine GPL when you link to it. > I'm not sure about the 'free image public license terms'. It is not > something like a BSD license, but more complicated. Someone would have > to look at it whether that would even be usable (commercial versions > like Crossover would have issues). > > From what I remember TGA, and the PPM family are at least easy (not > sure about DDS though, but I believe it is easy as well). If there are > good standalone libs like libjpeg, libpng and friends for such > libraries which are either BSD or LGPL licensed (or something similar > that would be fine). We might also want to do them ourselves if we > wanted (and they are relatively trivial). > > Lets wait for what others are saying. > > Roderick > I missed this bit from the website: When using FreeImage in your open source or commercial application, you are REQUIRED to : " distribute the license (GNU GPL or FIPL) you choosed with your application (i.e. the TXT file) provide a suitable acknowledgement, either in the program's "About" box or in the user's manual (or both), for example : This software uses the FreeImage open source image library. See http://freeimage.sourceforge.net for details. FreeImage is used under the (GNU GPL or FIPL), version (license version)." Apparently they want you to mention that you are using their library which is not something we do in Wine (as far as I know) for anything else. (If we were using the GPL version, I'm not sure if the GPL even requires to such an advertising clause which I believe it doesn't) Roderick

Aug. 12, 2010

Re: Windows Imaging Component

by Roderick Colenbrander

On Thu, Aug 12, 2010 at 4:54 AM, Georgij Kirichenko <kirichenkoga(a)gmail.com> wrote: > This patch add support for decoding Dds, Ppm(and pgm, pbm) and Tga files th > Windows Imaging Component. Each format you are adding requires its own patch. > This patch use dynamic linked FreeImage library, but i'am can't static link > this library. First of all, I'm not so sure we want to use FreeImage. The initial thing about which I'm not sure is the license. You can use it under either a commercial license or under the GPL. The last one at least is usable for us as it would make all of Wine GPL when you link to it. I'm not sure about the 'free image public license terms'. It is not something like a BSD license, but more complicated. Someone would have to look at it whether that would even be usable (commercial versions like Crossover would have issues). >From what I remember TGA, and the PPM family are at least easy (not sure about DDS though, but I believe it is easy as well). If there are good standalone libs like libjpeg, libpng and friends for such libraries which are either BSD or LGPL licensed (or something similar that would be fine). We might also want to do them ourselves if we wanted (and they are relatively trivial). Lets wait for what others are saying. Roderick

Aug. 12, 2010

Re: Windows Imaging Component

by Kirill K. Smirnov

Aug. 12, 2010

Re: [PATCH 1/2] dmime/tests: Added tests for IDirectMusicPerformance.

by Vitaliy Margolen

On 08/12/2010 12:09 AM, Austin Lund wrote: > On 12 August 2010 15:48, Vitaliy Margolen<wine-devel(a)kievinfo.com> wrote: >> You can't test that. All you can test is that you got the IDirectMusicPort >> back or not. What exactly inside is irrelevant. >> >> And if IDirectMusicPerformance8_PChannelInfo succeeds and you getting not >> null pDirectMusicPort back but it points to bogus data or is unchanged (as >> it is now), it's outright invalid behavior that should be fixed. No tests >> needed for that. > > OK. How about this: > > static void test_PChannelInfo(void) > { > IDirectMusicPort *pDirectMusicPort; > HRESULT hr; > > pDirectMusicPort = NULL; > hr = IDirectMusicPerformance8_PChannelInfo(idmusicperformance, 0, > &pDirectMusicPort, NULL, NULL); > ok(hr == S_OK, "Failed to call PChannelInfo (%x)\n", hr); > todo_wine ok(pDirectMusicPort != NULL, "IDirectMusicPort not set\n"); > } This looks much better. > I'll take on other comments and resubmit tomorrow as suggested. > +static void test_GetDefaultAudioPath(void) > +{ > + hr = IDirectMusicPerformance8_GetDefaultAudioPath(idmusicperformance,&pDirectMusicAudioPath); You leaking pDirectMusicAudioPath here. You should free it after test. Same for idmusicperformance. And CoInitialize() needs a matching CoUninitialize(). Vitaliy.

Aug. 12, 2010

Wine users with a CD-ROM drive, please test

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, >mcicda.c:541: Test failed: status mode after play is playing >mcicda.c:548: Test failed: status mode after play is playing >mcicda: 105 tests executed (0 marked as todo, 2 failures), 1 skipped. Here I don't know what to do. Even after the former Sleep(3900ms), status mode reported playing. Perhaps some drives just enjoy spinning? If you look at the source, you'll see it does set c time format tmsf play c from 1 to 1:00:00:21 notify Sleep status c mode Within almost 4 seconds time, I'd have expect the drive to spin up, play for 280ms and stop again. I'm tempted to a) leave the test as is, so that test.winehq.org will slowly show how often this happens among users. Or do people think I should rather b) silence the error and don't care. After all, it tells me nothing about how to implement. BTW, in the next version, the 00:02:33 start position will not be flagged as error any more. Regards, Jörg Höhle

Aug. 12, 2010

Re: Fwd: Should we expect Liberation fonts to be installed?

by André Hentschel

Am 12.08.2010 06:11, schrieb Paul "TBBle" Hampson: > Sorry, I failed at Gmail again. >_< > > ---------- Forwarded message ---------- > From: Paul "TBBle" Hampson <Paul.Hampson(a)pobox.com> > Date: 12 August 2010 13:52 > Subject: Re: Should we expect Liberation fonts to be installed? > To: Scott Ritchie <scott(a)open-vote.org> > > > On 8 August 2010 13:02, Scott Ritchie <scott(a)open-vote.org> wrote: >> On 08/03/2010 01:57 PM, Scott Ritchie wrote: >>> I was looking through our fairly large collection of open font bugs and >>> realized that things might be a lot simpler if we took some opinionated >>> positions and just declared certain fonts to be dependencies and >>> expected all packagers to provide them. >>> >>> This is similar to bundling our own Tahoma, except much less work. >>> >>> >>> This bug, for instance, prevents Photoshop from working unless there is >>> an Arial font installed: http://bugs.winehq.org/show_bug.cgi?id=9623 >>> >>> Wine doesn't seem to respect system-level fontconfig aliases, so even >>> though Liberation Sans is installed on the system Photoshop won't try to >>> use it in place of Arial. >>> >>> But if however we assumed that Liberation Sans was installed, we could >>> make things much better: a link/substitution for Arial->Liberation Sans >>> could be provided in our own registry (and similarly for Times New Roman >>> and Courier). An alternative is to simply symlink to the Liberation >>> Fonts in /usr/share/wine/fonts as though they were our own shipped fonts >>> (like Tahoma). >>> >>> This would make Photoshop think Arial was present and keep it >>> functional. Ideally the real Arial would be displayed if it was >>> installed (eg through winetricks corefonts or by installing the >>> distro-provided corefonts package). >>> >>> >>> A related question is whether to show "Arial" in the list of fonts (eg >>> notepad) when we're actually just providing a substituted Arial. My >>> inclination says no, however I'm not sure how it works internally and >>> what an application would expect. >>> >> >> Assuming for a moment this is a good idea, what's the best >> implementation? My inclination is to say some registry font links, but >> I'm not completely familiar with how that works. >> >> Will font links in the registry be ignored when the real font is present? > > (Wine-specific) Font Replacements will be ignored when the real font > is present. Those're the ones in HKCU\Software\Wine\Fonts\Replacements > and probably the ones you want to use. (Which could be supplanted or > supplemented by working FontConfig alias support...) > > (GDI) Font Links (ie. the same registry entries Windows uses) are > fallbacks for missing glyphs. Those're the ones in > HKLM\SOFTWARE\Microsoft\FontLink\SystemLink > > Font Substitutes _probably_ don't get ignored if a real font with that > name exists. Those're the ones in HKLM\SOFTWARE\Microsoft\Windows > NT\CurrentVersion\FontSubstitutes and they're pretty purpose-specific. > The only entries we want for them in Wine are the ones described at > http://blogs.msdn.com/b/michkap/archive/2005/03/20/399322.aspx (which > should probably be the default in Wine anyway, at least the Tahoma > entry.) Wow, can you please update http://wiki.winehq.org/FontLoadOrder with these great informations? -- Best Regards, André Hentschel

Aug. 12, 2010

Re: shell32/tests: Test that a folder can be named when clicking "Make New Folder"

by Frank Richter

On 10.08.2010 20:22, Michael Mc Donnell wrote: > When a user clicks the "Make New Folder" button a new folder is created. > The name of the folder is selected, and the dialog box waits for the user > to either accept the name or type in a new one. The test types in a > new folder name and checks that the new folder gets that name. Also, you seem to emit “Alt+M” as part of the test. This is rather fragile, as the hotkey for “Make new folder” is most likely _not_ M on Windows or Wine translated to other than English. I believe the safe way to deal with that is to send a WM_COMMAND message with the ID of the “Make new folder” button. Wine test bot has a number of non-English VMs, so make sure you try your patches there. -f.r.

Aug. 12, 2010

CD-ROM ioctl support on MacOS?

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Charles Davis wrote: >> 1. READ_RAW >That's implemented. I implemented it myself in >6368dbbd5939bf71b04f3c441dd3af8cd027b7fb. It doesn't work here ("early 2009" mini with 10.5.8) as I mention in http://bugs.winehq.org/show_bug.cgi?id=20323#c4 Perhaps it can read data tracks only, no audio? Regards, Jörg Höhle

Aug. 12, 2010

Re: Re : [PATCH 1/2] dmime/tests: Added tests for IDirectMusicPerformance.

by Dmitry Timoshkov

paulo lesgaz <jeremielapuree(a)yahoo.fr> wrote: > Some compilers complain about the lack of a return in a void function. Don't > forget to add it in each void function. That compilers are buggy, there is no need to add statements without a real reason. At least it helps to list those compilers, and send a bug report if you think that's appropriate. -- Dmitry.

Aug. 12, 2010

Re : [PATCH 1/2] dmime/tests: Added tests for IDirectMusicPerformance.

by paulo lesgaz

Some compilers complain about the lack of a return in a void function. Don't forget to add it in each void function. A+ David ________________________________ De : Austin Lund <austin.lund(a)gmail.com> À : Vitaliy Margolen <wine-devel(a)kievinfo.com> Cc : wine-devel(a)winehq.org Envoyé le : Jeu 12 août 2010, 8h 09min 44s Objet : Re: [PATCH 1/2] dmime/tests: Added tests for IDirectMusicPerformance. On 12 August 2010 15:48, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > You can't test that. All you can test is that you got the IDirectMusicPort > back or not. What exactly inside is irrelevant. > > And if IDirectMusicPerformance8_PChannelInfo succeeds and you getting not > null pDirectMusicPort back but it points to bogus data or is unchanged (as > it is now), it's outright invalid behavior that should be fixed. No tests > needed for that. OK. How about this: static void test_PChannelInfo(void) { IDirectMusicPort *pDirectMusicPort; HRESULT hr; pDirectMusicPort = NULL; hr = IDirectMusicPerformance8_PChannelInfo(idmusicperformance, 0, &pDirectMusicPort, NULL, NULL); ok(hr == S_OK, "Failed to call PChannelInfo (%x)\n", hr); todo_wine ok(pDirectMusicPort != NULL, "IDirectMusicPort not set\n"); } I'll take on other comments and resubmit tomorrow as suggested. Thanks.

Aug. 12, 2010

Re: [PATCH 1/2] dmime/tests: Added tests for IDirectMusicPerformance.

by Austin Lund

On 12 August 2010 15:48, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > You can't test that. All you can test is that you got the IDirectMusicPort > back or not. What exactly inside is irrelevant. > > And if IDirectMusicPerformance8_PChannelInfo succeeds and you getting not > null pDirectMusicPort back but it points to bogus data or is unchanged (as > it is now), it's outright invalid behavior that should be fixed. No tests > needed for that. OK. How about this: static void test_PChannelInfo(void) { IDirectMusicPort *pDirectMusicPort; HRESULT hr; pDirectMusicPort = NULL; hr = IDirectMusicPerformance8_PChannelInfo(idmusicperformance, 0, &pDirectMusicPort, NULL, NULL); ok(hr == S_OK, "Failed to call PChannelInfo (%x)\n", hr); todo_wine ok(pDirectMusicPort != NULL, "IDirectMusicPort not set\n"); } I'll take on other comments and resubmit tomorrow as suggested. Thanks.

Aug. 12, 2010

Re: [PATCH 1/2] dmime/tests: Added tests for IDirectMusicPerformance.

by Vitaliy Margolen

On 08/11/2010 11:11 PM, Austin Lund wrote: > On 12 August 2010 14:23, Vitaliy Margolen<wine-devel(a)kievinfo.com> wrote: >> On 08/11/2010 09:14 PM, Austin Lund wrote: >>> >>> On 11 August 2010 20:12, David Adam<david.adam.cnrs(a)gmail.com> wrote: >>> I wasn't sure of the best way to do this. But basically I want to >>> check that the Vtbl had been set. I cannot cast to >>> IDirectMusicPortImpl and I'm still confused by the COM macros. >> >> You shouldn't be checking for any vtbl, it's all object's internal stuff. If >> you must check a pointer if it's null or not, then do that explicitly. >> Pointers have different size in 32-bit and 64-bit architectures. >> >> Also you don't need two things pointing to one another. IDirectMusicPort is >> a pointer in a first place. So no need for memset either. And no need for >> all the extra traces that print the same stuff. You already checking if it's >> null or not. The value of the pointer won't be of any use. > > The setting (or not) of the Vtbl is exactly why the crash in bug 22598 > occurs. So if I'm not allowed to test for this, then this bug > shouldn't have a test written for it? The IDirectMusicPort is a pointer. To zero it you do "ptr = NULL". Don't mention any vtbs in test. Think of it an (void*) pointer - what it points to shouldn't matter. > The test I wrote for this bug just ensures that the object has > something put into it to avoid the segfault. You can't test that. All you can test is that you got the IDirectMusicPort back or not. What exactly inside is irrelevant. And if IDirectMusicPerformance8_PChannelInfo succeeds and you getting not null pDirectMusicPort back but it points to bogus data or is unchanged (as it is now), it's outright invalid behavior that should be fixed. No tests needed for that. Vitaliy.

Aug. 12, 2010

Re: [PATCH 1/2] dmime/tests: Added tests for IDirectMusicPerformance. (try 2)

by Vitaliy Margolen

On 08/11/2010 11:16 PM, Austin Lund wrote: > On 12 August 2010 14:32, Vitaliy Margolen<wine-devel(a)kievinfo.com> wrote: >> >> What are those magic numbers? Please use constants. If they are missing, add >> them to appropriate header file first. > > They are the numbers passed to the InitAudio method from bug 22598. 1 is DMUS_APATH_SHARED_STEREOPLUSREVERB, 0x3f is DMUS_AUDIOF_ALL. > I've seen quite a few places where "magic" numbers are used in tests > with no references. I thought it would be ok to start the test off > this way. If they are a defined constant it's not a good thing to have them even in tests. Of course you won't have a constant for for things like 128 in your test (which is a number of performance channels). > What is the best way to resubmit for another round of review? To > wine-patches again (try 3)? Or on wine-devel? Or something else. Send to wine-patches, as long as you have all the problems fixed. Just wait a day to see if anyone else has any additional questions. Vitaliy.

Aug. 12, 2010

Re: [PATCH 1/2] dmime/tests: Added tests for IDirectMusicPerformance. (try 2)

by Austin Lund

On 12 August 2010 14:32, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > > What are those magic numbers? Please use constants. If they are missing, add > them to appropriate header file first. They are the numbers passed to the InitAudio method from bug 22598. I've seen quite a few places where "magic" numbers are used in tests with no references. I thought it would be ok to start the test off this way. What is the best way to resubmit for another round of review? To wine-patches again (try 3)? Or on wine-devel? Or something else.

Aug. 12, 2010

Re: [PATCH 1/2] dmime/tests: Added tests for IDirectMusicPerformance.

by Austin Lund

On 12 August 2010 14:23, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > On 08/11/2010 09:14 PM, Austin Lund wrote: >> >> On 11 August 2010 20:12, David Adam<david.adam.cnrs(a)gmail.com> wrote: >> I wasn't sure of the best way to do this. But basically I want to >> check that the Vtbl had been set. I cannot cast to >> IDirectMusicPortImpl and I'm still confused by the COM macros. > > You shouldn't be checking for any vtbl, it's all object's internal stuff. If > you must check a pointer if it's null or not, then do that explicitly. > Pointers have different size in 32-bit and 64-bit architectures. > > Also you don't need two things pointing to one another. IDirectMusicPort is > a pointer in a first place. So no need for memset either. And no need for > all the extra traces that print the same stuff. You already checking if it's > null or not. The value of the pointer won't be of any use. The setting (or not) of the Vtbl is exactly why the crash in bug 22598 occurs. So if I'm not allowed to test for this, then this bug shouldn't have a test written for it? The test I wrote for this bug just ensures that the object has something put into it to avoid the segfault. The sanest way I could think of doing this is to zero out the memory (hence memset) and check that the function actually put something at the start of the object. I got rid of the traces in the second go. They were left over from when I was using crosstest to see what was going on.

Aug. 12, 2010

Re: [PATCH 1/2] dmime/tests: Added tests for IDirectMusicPerformance. (try 2)

by Vitaliy Margolen

On 08/11/2010 08:58 PM, Austin Lund wrote: > > > +static BOOL test_InitAudio(void) > +{ > + hr = IDirectMusicPerformance8_InitAudio(idmusicperformance,NULL,&pDirectSound,NULL,1,128,0x3f,NULL); > + if (hr != S_OK) return FALSE; > + else return TRUE; > +} Please put spaces after comas, as you do in the rest of the file. What are those magic numbers? Please use constants. If they are missing, add them to appropriate header file first. Same thing with return as in prior function.. > +static void test_PChannelInfo(void) Already covered in another thread. Vitaliy.

Aug. 12, 2010

Re: [PATCH 1/2] dmime/tests: Added tests for IDirectMusicPerformance.

by Vitaliy Margolen

On 08/11/2010 09:14 PM, Austin Lund wrote: > On 11 August 2010 20:12, David Adam<david.adam.cnrs(a)gmail.com> wrote: > I wasn't sure of the best way to do this. But basically I want to > check that the Vtbl had been set. I cannot cast to > IDirectMusicPortImpl and I'm still confused by the COM macros. You shouldn't be checking for any vtbl, it's all object's internal stuff. If you must check a pointer if it's null or not, then do that explicitly. Pointers have different size in 32-bit and 64-bit architectures. Also you don't need two things pointing to one another. IDirectMusicPort is a pointer in a first place. So no need for memset either. And no need for all the extra traces that print the same stuff. You already checking if it's null or not. The value of the pointer won't be of any use. Vitaliy.

Aug. 12, 2010

Re: kernel32/tests: GetVolumeInformationA X: succeeds iff drive's default dir is root. (try 2)

by Vitaliy Margolen

On 08/11/2010 05:03 AM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > what happened to this patch? It's still marked new. > Is the discovery too surprising? > (Maybe it's the wrong time to ask with AJ still on vacation) According to this: http://www.winehq.org/pipermail/wine-devel/2010-August/085802.html you won't see any commits until Aug 16 at best. Vitaliy.

Aug. 12, 2010

Fwd: Should we expect Liberation fonts to be installed?

by Paul "TBBle" Hampson

Sorry, I failed at Gmail again. >_< ---------- Forwarded message ---------- From: Paul "TBBle" Hampson <Paul.Hampson(a)pobox.com> Date: 12 August 2010 13:52 Subject: Re: Should we expect Liberation fonts to be installed? To: Scott Ritchie <scott(a)open-vote.org> On 8 August 2010 13:02, Scott Ritchie <scott(a)open-vote.org> wrote: > On 08/03/2010 01:57 PM, Scott Ritchie wrote: >> I was looking through our fairly large collection of open font bugs and >> realized that things might be a lot simpler if we took some opinionated >> positions and just declared certain fonts to be dependencies and >> expected all packagers to provide them. >> >> This is similar to bundling our own Tahoma, except much less work. >> >> >> This bug, for instance, prevents Photoshop from working unless there is >> an Arial font installed: http://bugs.winehq.org/show_bug.cgi?id=9623 >> >> Wine doesn't seem to respect system-level fontconfig aliases, so even >> though Liberation Sans is installed on the system Photoshop won't try to >> use it in place of Arial. >> >> But if however we assumed that Liberation Sans was installed, we could >> make things much better: a link/substitution for Arial->Liberation Sans >> could be provided in our own registry (and similarly for Times New Roman >> and Courier). An alternative is to simply symlink to the Liberation >> Fonts in /usr/share/wine/fonts as though they were our own shipped fonts >> (like Tahoma). >> >> This would make Photoshop think Arial was present and keep it >> functional. Ideally the real Arial would be displayed if it was >> installed (eg through winetricks corefonts or by installing the >> distro-provided corefonts package). >> >> >> A related question is whether to show "Arial" in the list of fonts (eg >> notepad) when we're actually just providing a substituted Arial. My >> inclination says no, however I'm not sure how it works internally and >> what an application would expect. >> > > Assuming for a moment this is a good idea, what's the best > implementation? My inclination is to say some registry font links, but > I'm not completely familiar with how that works. > > Will font links in the registry be ignored when the real font is present? (Wine-specific) Font Replacements will be ignored when the real font is present. Those're the ones in HKCU\Software\Wine\Fonts\Replacements and probably the ones you want to use. (Which could be supplanted or supplemented by working FontConfig alias support...) (GDI) Font Links (ie. the same registry entries Windows uses) are fallbacks for missing glyphs. Those're the ones in HKLM\SOFTWARE\Microsoft\FontLink\SystemLink Font Substitutes _probably_ don't get ignored if a real font with that name exists. Those're the ones in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes and they're pretty purpose-specific. The only entries we want for them in Wine are the ones described at http://blogs.msdn.com/b/michkap/archive/2005/03/20/399322.aspx (which should probably be the default in Wine anyway, at least the Tahoma entry.) (Which by-the-by highlights a mistake in my previous suggestion towards bug 13829) -- Paul "TBBle" Hampson, Paul.Hampson(a)Pobox.com On 12 August 2010 13:52, Paul "TBBle" Hampson <Paul.Hampson(a)pobox.com> wrote: > (Wine-specific) Font Replacements will be ignored when the real font > is present. Those're the ones in HKCU\Software\Wine\Fonts\Replacements > and probably the ones you want to use. (Which could be supplanted or > supplemented by working FontConfig alias support...) To be clear, I think the best first-step solution for this bug is for Wine's Font Replacements code to read the aliases from FontConfig as well as its own registry keys when building its list. (The latter being taken over the former) That would make the problem magically go away on systems that do include appropriately-substitutable fonts. -- Paul "TBBle" Hampson, Paul.Hampson(a)Pobox.com

Aug. 12, 2010

Re: [PATCH 1/2] dmime/tests: Added tests for IDirectMusicPerformance. (try 2)

by Austin Lund

On 12 August 2010 13:16, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > Austin Lund wrote: > > Why the try2? It is always nice to put why you are doing this in the git > commit notes. I was responding to review. I'm sorry if I've done something confusing.

Aug. 12, 2010

Re: [PATCH 1/2] dmime/tests: Added tests for IDirectMusicPerformance. (try 2)

by James McKenzie

Austin Lund wrote: Why the try2? It is always nice to put why you are doing this in the git commit notes. AJ is on vakay and will not be back until next week so there are NO reviews ongoing this week, except developer peer ones. James McKenzie

Aug. 12, 2010

Re: [PATCH 1/2] dmime/tests: Added tests for IDirectMusicPerformance.

by Austin Lund

On 11 August 2010 20:12, David Adam <david.adam.cnrs(a)gmail.com> wrote: > Hello, thanks for the comments. I've resent. > + todo_wine ok(*(ULONG *)pDirectMusicPort != 0, "IDirectMusicPort not > set\n"); > > Why is this cast useful? I wasn't sure of the best way to do this. But basically I want to check that the Vtbl had been set. I cannot cast to IDirectMusicPortImpl and I'm still confused by the COM macros.

Aug. 12, 2010

Re: [(try 2) 02/11] d3d10: Implement D3D10CreateBlob().

by Stefan Dösinger

Am 11.08.2010 um 21:51 schrieb Rico Schüller: > --- a/dlls/d3d10/d3d10_private.h > +++ b/dlls/d3d10/d3d10_private.h > @@ -212,6 +212,17 @@ struct d3d10_effect > struct d3d10_effect_technique *techniques; > }; > > > +extern const struct ID3D10BlobVtbl d3d10_blob_vtbl DECLSPEC_HIDDEN; Do you need the declaration of the vtable in the header? As far as I can see you're not using it anywhere outside d3d10_main.c.

Aug. 11, 2010

Re: [PATCH] qmgr/tests: Detect, when the service is disabled

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=4405 Your paranoid android. === W98SE (32 bit qmgr) === qmgr.c:46: Test failed: CoCreateInstance failed: 80040154

Aug. 11, 2010

Re: Wine users with a CD-ROM drive, please test

by Erik Inge Bolsø

On Wed, 11 Aug 2010, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > testbot.winehq.org job #4404 now contains another patch and binary. I removed the call to > set c door closed > estimating that this was the most likely among the three suspects to cause the error > (I also reduced the Sleep() time). Yay, no more MCIERR_HARDWARE! Some others, though. Win7 64bit. Z:\test>mcicda_test_4404.exe mcicda.c:287: CD length 60:42:06 mcicda.c:351: track #1 length 245334ms mcicda.c:423: Tests skipped: Got no mixed data+audio CD. mcicda.c:441: last track length: 06m:46s:25frames mcicda.c:449: last track position: 53m:57s:56frames mcicda.c:541: Test failed: status mode after play is playing mcicda.c:548: Test failed: status mode after play is playing mcicda: 105 tests executed (0 marked as todo, 2 failures), 1 skipped. > Please test yet once again. I've not changed anything about the 00:02:33 start position > which I'll leave in until testbot gathers more data from users. I had that one too, for one out of five test cds or so. -- -erik http://useofwords.blogspot.com/

Aug. 11, 2010

Re: [PATCH 1/2] dmime/tests: Added tests for IDirectMusicPerformance.

by Chris Robinson

On Wednesday, August 11, 2010 3:12:23 am David Adam wrote: > Hello, > > some comments about this patch > + if (hr != S_OK) return FALSE; > + else return TRUE; > > could be simplified as > return SUCCEEDED(hr); SUCCEEDED encompasses more than just S_OK (S_FALSE, for instance; basically anything that doesn't have the high bit set). Whether to test SUCCEEDED or S_OK explicitly depends on what the function can return and what it means. The original behavior could instead be simplified as: return hr==S_OK;

Aug. 11, 2010

Wine users with a CD-ROM drive, please test

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, testbot.winehq.org job #4404 now contains another patch and binary. I removed the call to set c door closed estimating that this was the most likely among the three suspects to cause the error (I also reduced the Sleep() time). Please test yet once again. I've not changed anything about the 00:02:33 start position which I'll leave in until testbot gathers more data from users. Thank you very much, Jörg Höhle

Aug. 11, 2010

kernel32/tests: GetVolumeInformationA X: succeeds iff drive's default dir is root. (try 2)

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, what happened to this patch? It's still marked new. Is the discovery too surprising? (Maybe it's the wrong time to ask with AJ still on vacation) Is it not robust enough (lacking testing with network drives)? It explains bugs #20887 and #23355. It may explain intermittent failures in test.winehq/kernel/volume.ok, as success depends on where the test was launched from. >Tests pass on w95,w98,w2k,xp,7. I forgot to add "without skipping the one relevant section", i.e. when started from another drive than C: Of course I invite people here to also perform the test on native. Regards, Jörg Höhle

Aug. 11, 2010

Re: [PATCH 1/2] dmime/tests: Added tests for IDirectMusicPerformance.

by David Adam

Hello, some comments about this patch + if (hr != S_OK) return FALSE; + else return TRUE; could be simplified as return SUCCEEDED(hr); + trace("HRESULT when creating instance (%x)\n", hr); Since tests are assumed to pass, we dont care about debug informations. So, traces are useless in tests. [It is my opinion. Better developpers could give an opposite opinion] + todo_wine ok(*(ULONG *)pDirectMusicPort != 0, "IDirectMusicPort not set\n"); Why is this cast useful? A+ David 2010/8/9 Austin Lund <austin.lund(a)gmail.com> > > > > >

Aug. 11, 2010

Wine users with a CD-ROM drive, please test

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, No more MCIERR_HARDWARE in David's latest test result, hurray! The difference with prior tests is that I temporarily eliminated 3 commands a) resume c b) set c video audio all off c) set c door closed notify We are not done yet. Users who saw that error please feed the following scripts into the mcishell to see which of those 3 commands causes the failure. The mcishell is attached to bug #20232 at http://bugs.winehq.org/show_bug.cgi?id=20232#c10 http://bugs.winehq.org/attachment.cgi?id=24529 wintest.exe mcishell mci.c:1363: Type your commands to the MCI, end with Ctrl-Z The 5 test failures in David's report are unrelated to MCIERR_HARDWARE. >mcicda.c:540: Test failed: status mode after play is playing Weird. I'd have expected Play to terminate within Sleep(3900ms) time. >mcicda.c:297: Test failed: status position initially 00:02:33 I'll take care of that another day. For now I'll just remember that there are disks that don't start at position 00:02:00. Please copy&paste these lines as one piece into a cmd shell so that there's as little delay as possible between commands. # a) resume open cdaudio alias c notify shareable status c mode status c position play c from 00:02:00 to 00:01:00 notify resume c status c mode seek c to start notify status c mode seek c to end # # testsuite uses seek c to MM:SS:FF instead set c time format tmsf play c from 1 stop c Don't forget after each one close c # b) set video audio open cdaudio alias c notify shareable status c mode status c position play c from 00:02:00 to 00:01:00 notify seek c to start notify set c video audio all off status c mode seek c to end # # testsuite uses seek c to MM:SS:FF instead set c time format tmsf play c from 1 stop c # c) set door closed open cdaudio alias c notify shareable status c mode status c position play c from 00:02:00 to 00:01:00 notify seek c to start notify set c door closed notify status c mode seek c to end # # testsuite uses seek c to MM:SS:FF instead set c time format tmsf play c from 1 stop c Thank you for testing, Jörg Höhle

Aug. 11, 2010

Re: Request for comments - d3dx9: Add tests for FVF <-> declaration conversion.

by misha680

Stefan Dösinger wrote: > > Hi, > The tests look OK. Since a part of the code was taken from > dlls/d3d9/tests/vertexdeclaration.c(which is OK) you should copy the > copyright lines along as well. > Thanks, how about this guy? I have added the copyright notices. http://wine.1045685.n5.nabble.com/file/n2471349/0001-d3dx9-Add-tests-for-FV… 0001-d3dx9-Add-tests-for-FVF-declaration-conversion.txt I will send to wine-patches pending Henri's approval/ok (as my understanding is that this will be necessary for patch acceptance to GIT - please correct me if I am mistaken). I have cc'ed him on this email. Thank you Misha -- View this message in context: http://wine.1045685.n5.nabble.com/Request-for-comments-d3dx9-Add-tests-for-… Sent from the Wine - Devel mailing list archive at Nabble.com.

Aug. 10, 2010

Re: Request for comments - d3dx9: Add tests for FVF <-> declaration conversion.

by Stefan Dösinger

Hi, The tests look OK. Since a part of the code was taken from dlls/d3d9/tests/vertexdeclaration.c(which is OK) you should copy the copyright lines along as well. Am 10.08.2010 um 23:25 schrieb misha680: > > Dear All: > > I have become more busy with schoolwork than I had imagined. > > However, I would still like, if possible, to finish work on > http://bugs.winehq.org/show_bug.cgi?id=22918 > > It has been suggested that I send patches to the wine-devel list first for > feedback. This way, I hope to be able to get developer expertise in these > areas, and to be able to understand exactly what is necessary for a given > patch. > > I have, per this comment from Henri: > http://bugs.winehq.org/show_bug.cgi?id=22918#c51 > written a draft patch for FVF <-> declaration conversion tests. > > It can be found at the Nabble link below. I will appreciate comments as to > what is necessary for this patch (or a similar one) to get accepted. > http://wine.1045685.n5.nabble.com/file/n2471306/0001-d3dx9-Add-tests-for-FV… > 0001-d3dx9-Add-tests-for-FVF-declaration-conversion.txt > > I realize there are already three tests for conversion in one direction. I > have decided at the moment to leave those as is and focus on getting > necessary feedback for getting an appropriate patch accepted. If you have > any guidance with regards to this, much appreciated. > > Thank you > Misha > > p.s. I have uploaded some shell scripts that I use for Wine development > here: > http://groups.google.com/group/misha680-wine/files > I don't know how useful they will be to anyone else, but if anything, it > provides an nice backup for my computer. > -- > View this message in context: http://wine.1045685.n5.nabble.com/Request-for-comments-d3dx9-Add-tests-for-… > Sent from the Wine - Devel mailing list archive at Nabble.com. > >

Aug. 10, 2010

re: winex11.drv: Fix uninitialised values. (valgrind) (try 2)

by Dan Kegel

That's for http://bugs.winehq.org/show_bug.cgi?id=20335 , right? Alexandre's reply to that was "It sounds like it's hashing padding bytes. Probably should be reported to the X.org folks." X is old code, and I don't think anyone has cleaned it up for valgrind yet. That's why I use suppression files like http://winezeug.googlecode.com/svn/trunk/valgrind/valgrind-suppressions which contain blanket suppressions like { bogus_X11_1 Memcheck:Param write(buf) obj:* obj:/usr/lib*/libX11.so.6.2.0 } { bogus_X11_2 Memcheck:Param write(buf) obj:* obj:* obj:/usr/lib*/libX11.so.6.2.0 }

Aug. 10, 2010

Request for comments - d3dx9: Add tests for FVF <-> declaration conversion.

by misha680

Dear All: I have become more busy with schoolwork than I had imagined. However, I would still like, if possible, to finish work on http://bugs.winehq.org/show_bug.cgi?id=22918 It has been suggested that I send patches to the wine-devel list first for feedback. This way, I hope to be able to get developer expertise in these areas, and to be able to understand exactly what is necessary for a given patch. I have, per this comment from Henri: http://bugs.winehq.org/show_bug.cgi?id=22918#c51 written a draft patch for FVF <-> declaration conversion tests. It can be found at the Nabble link below. I will appreciate comments as to what is necessary for this patch (or a similar one) to get accepted. http://wine.1045685.n5.nabble.com/file/n2471306/0001-d3dx9-Add-tests-for-FV… 0001-d3dx9-Add-tests-for-FVF-declaration-conversion.txt I realize there are already three tests for conversion in one direction. I have decided at the moment to leave those as is and focus on getting necessary feedback for getting an appropriate patch accepted. If you have any guidance with regards to this, much appreciated. Thank you Misha p.s. I have uploaded some shell scripts that I use for Wine development here: http://groups.google.com/group/misha680-wine/files I don't know how useful they will be to anyone else, but if anything, it provides an nice backup for my computer. -- View this message in context: http://wine.1045685.n5.nabble.com/Request-for-comments-d3dx9-Add-tests-for-… Sent from the Wine - Devel mailing list archive at Nabble.com.

Aug. 10, 2010

Re : Wine users with a CD-ROM drive, please test

by paulo lesgaz

You will attached the results of the tests on my real vista box As the last time, I used the original CD of Police: Greatest hits David ________________________________ De : "Joerg-Cyril.Hoehle(a)t-systems.com" <Joerg-Cyril.Hoehle(a)t-systems.com> À : wine-devel(a)winehq.org Cc : tijnema(a)gmail.com; jeffzaroyko(a)gmail.com; jeremielapuree(a)yahoo.fr; knan-wine(a)anduin.net Envoyé le : Mar 10 août 2010, 17h 50min 39s Objet : Wine users with a CD-ROM drive, please test Hi, http://testbot.winehq.org/JobDetails.pl?Key=4395 contains a new patch and binary where I eliminated a few commands that might cause the MCIERR_HARDWARE observed with the second Seek and first Play, as well as a few more calls to "status c mode" to verify the current state. Thank you for testing, Jörg Höhle

Aug. 10, 2010

Re: [PATCH 1/5] ddraw/tests: Add test for bad size of surface caps in CreateSurface. (try 5)

by Stefan Dösinger

Am 10.08.2010 um 17:42 schrieb Oldrich Jedlicka: > Ok, I understand. I'm just sending the whole patchset with changed/unchanged patches (the number of patches changed, because some of them had been applied and some of them I removed, because they don't implement things properly). Admittedly I didn't look at the other patches, I looked at patches 1-2 and thought that I've seen this in exactly the same form before. In your specific situation it is probably better to send just patch 1, wait until it is applied, then send patch 2, etc, and send bigger patchsets once you've a few patches in Wine. To answer the general questions, this is how I deal with problems in a part of the patchset: *) Generally write a mail stating that the patch is broken and shouldn't be applied to wine-devel. If follow-up patches are independent of this patch I can state so in the mail. If the issue was quick to fix(e.g. whitespace problems) and I am confident that the patch should work now I'll attach the new patch and send the mail to wine-patches only. Otherwise, if I can't attach a fixed patch right away the options are as follows: *) Resend the entire patchset, probably on the following day. *) Let the first patches be applied, resend the remaining patches the next day. Basically it is better to push forward a bit slower and let the patches of the day settle and resend the next day to avoid confusion. Also a (try X) with X > 4 usually often leads to skepticism, because people don't know how many more tries will be needed. I am personally critical of this because of my own experience on gcc-patches. I needed about 10 tries to get the gcc patch for the Steam overlay, I would never have been able to do it with just 4 or 5 iterations. > Is there some recommended way to send updated patchsets when only some patches need to be improved (but the sequence of applying should stay)? Would the "introductionary" mail describing changes and patches as follow-ups help? This can be helpful, but it is also possible to mention what changes you made in the new patch version in the patch description itself. A separate overview description(or description in patch 1) can be helpful if the overall direction of the changes is not easy to understand from the patches themselves, e.g. if more patches are going to come after those are applied. In this situation it is also recommended to send all patches in a packed archive to wine-devel for review, so everyone can see where you're headed.

Aug. 10, 2010

Wine users with a CD-ROM drive, please test

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, http://testbot.winehq.org/JobDetails.pl?Key=4395 contains a new patch and binary where I eliminated a few commands that might cause the MCIERR_HARDWARE observed with the second Seek and first Play, as well as a few more calls to "status c mode" to verify the current state. Thank you for testing, Jörg Höhle

Aug. 10, 2010

Re: [PATCH 1/5] ddraw/tests: Add test for bad size of surface caps in CreateSurface. (try 5)

by Oldrich Jedlicka

Hi Stefan, > 10.8.2010 15:40:40, Stefan Dösinger <stefandoesinger(a)gmx.at>: > Diff -u doesn't find any difference between try 4 and try 5, and probably older > tries. If you're resending them because the older ones weren't applied, that's > futile - Alexandre is on vacation. > > Also it is generally a bad idea to keep resending a unchanged patch. If you > think the patch has been lost(e.g. Alexandre is waiting for my review and I am > not at home, etc) it is better to ask on Wine-devel what is up with the > patches. Ok, I understand. I'm just sending the whole patchset with changed/unchanged patches (the number of patches changed, because some of them had been applied and some of them I removed, because they don't implement things properly). Is there some recommended way to send updated patchsets when only some patches need to be improved (but the sequence of applying should stay)? Would the "introductionary" mail describing changes and patches as follow-ups help? Thanks, Oldřich. > Am Sonntag 08 August 2010, 07:09:24 schrieb Oldřich Jedlička: > > --- > > dlls/ddraw/tests/dsurface.c | 138 > > +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 138 > > insertions(+), 0 deletions(-) > > > > diff --git a/dlls/ddraw/tests/dsurface.c b/dlls/ddraw/tests/dsurface.c > > index 76bfc7e..8cdcd92 100644 > > --- a/dlls/ddraw/tests/dsurface.c > > +++ b/dlls/ddraw/tests/dsurface.c > > @@ -25,6 +25,7 @@ > > > > #include <assert.h> > > #include "wine/test.h" > > +#include "wine/exception.h" > > #include "ddraw.h" > > #include "d3d.h" > > #include "unknwn.h" > > @@ -3569,6 +3570,142 @@ static void BackBufferAttachmentFlipTest(void) > > DestroyWindow(window); > > } > > > > +static void CreateSurfaceBadCapsSizeTest(void) > > +{ > > + DDSURFACEDESC ddsd_ok; > > + DDSURFACEDESC ddsd_bad1; > > + DDSURFACEDESC ddsd_bad2; > > + DDSURFACEDESC ddsd_bad3; > > + DDSURFACEDESC ddsd_bad4; > > + DDSURFACEDESC2 ddsd2_ok; > > + DDSURFACEDESC2 ddsd2_bad1; > > + DDSURFACEDESC2 ddsd2_bad2; > > + DDSURFACEDESC2 ddsd2_bad3; > > + DDSURFACEDESC2 ddsd2_bad4; > > + IDirectDrawSurface *surf; > > + IDirectDrawSurface4 *surf4; > > + IDirectDrawSurface7 *surf7; > > + HRESULT hr; > > + IDirectDraw2 *dd2; > > + IDirectDraw4 *dd4; > > + IDirectDraw7 *dd7; > > + > > + const DWORD caps = DDSCAPS_OFFSCREENPLAIN; > > + > > + memset(&ddsd_ok, 0, sizeof(ddsd_ok)); > > + ddsd_ok.dwSize = sizeof(ddsd_ok); > > + ddsd_ok.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; > > + ddsd_ok.dwWidth = 64; > > + ddsd_ok.dwHeight = 64; > > + ddsd_ok.ddsCaps.dwCaps = caps; > > + memcpy(&ddsd_bad1, &ddsd_ok, sizeof(ddsd_bad1)); > > + ddsd_bad1.dwSize--; > > + memcpy(&ddsd_bad2, &ddsd_ok, sizeof(ddsd_bad2)); > > + ddsd_bad2.dwSize++; > > + memcpy(&ddsd_bad3, &ddsd_ok, sizeof(ddsd_bad3)); > > + ddsd_bad3.dwSize = 0; > > + memcpy(&ddsd_bad4, &ddsd_ok, sizeof(ddsd_bad4)); > > + ddsd_bad4.dwSize = sizeof(DDSURFACEDESC2); > > + > > + memset(&ddsd2_ok, 0, sizeof(ddsd2_ok)); > > + ddsd2_ok.dwSize = sizeof(ddsd2_ok); > > + ddsd2_ok.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; > > + ddsd2_ok.dwWidth = 64; > > + ddsd2_ok.dwHeight = 64; > > + ddsd2_ok.ddsCaps.dwCaps = caps; > > + memcpy(&ddsd2_bad1, &ddsd2_ok, sizeof(ddsd2_bad1)); > > + ddsd2_bad1.dwSize--; > > + memcpy(&ddsd2_bad2, &ddsd2_ok, sizeof(ddsd2_bad2)); > > + ddsd2_bad2.dwSize++; > > + memcpy(&ddsd2_bad3, &ddsd2_ok, sizeof(ddsd2_bad3)); > > + ddsd2_bad3.dwSize = 0; > > + memcpy(&ddsd2_bad4, &ddsd2_ok, sizeof(ddsd2_bad4)); > > + ddsd2_bad4.dwSize = sizeof(DDSURFACEDESC); > > + > > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_ok, &surf, NULL); > > + ok(SUCCEEDED(hr), "IDirectDraw_CreateSurface failed: 0x%08x\n", hr); > > + IDirectDrawSurface_Release(surf); > > + > > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_bad1, &surf, NULL); > > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface > > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_bad2, &surf, NULL); > > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface > > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_bad3, &surf, NULL); > > + ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface didn't return > > 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_bad4, &surf, NULL); > > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface > > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + > > + hr = IDirectDraw_QueryInterface(lpDD, &IID_IDirectDraw2, (void **) > > &dd2); + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: > > 0x%08x\n", hr); + > > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_ok, &surf, NULL); > > + ok(SUCCEEDED(hr), "IDirectDraw2_CreateSurface failed: 0x%08x\n", hr); > > + IDirectDrawSurface_Release(surf); > > + > > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_bad1, &surf, NULL); > > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw2_CreateSurface > > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_bad2, &surf, NULL); > > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw2_CreateSurface > > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_bad3, &surf, NULL); > > + ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw2_CreateSurface didn't > > return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_bad4, &surf, NULL); > > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw2_CreateSurface > > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + > > + IDirectDraw2_Release(dd2); > > + > > + hr = IDirectDraw_QueryInterface(lpDD, &IID_IDirectDraw4, (void **) > > &dd4); + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: > > 0x%08x\n", hr); + > > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_ok, &surf4, NULL); > > + ok(SUCCEEDED(hr), "IDirectDraw4_CreateSurface failed: 0x%08x\n", hr); > > + IDirectDrawSurface4_Release(surf4); > > + > > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_bad1, &surf4, NULL); > > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw4_CreateSurface > > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_bad2, &surf4, NULL); > > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw4_CreateSurface > > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_bad3, &surf4, NULL); > > + ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw4_CreateSurface didn't > > return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_bad4, &surf4, NULL); > > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw4_CreateSurface > > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + > > + IDirectDraw4_Release(dd4); > > + > > + hr = IDirectDraw_QueryInterface(lpDD, &IID_IDirectDraw7, (void **) > > &dd7); + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: > > 0x%08x\n", hr); + > > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_ok, &surf7, NULL); > > + ok(SUCCEEDED(hr), "IDirectDraw7_CreateSurface failed: 0x%08x\n", hr); > > + IDirectDrawSurface7_Release(surf7); > > + > > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_bad1, &surf7, NULL); > > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw7_CreateSurface > > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_bad2, &surf7, NULL); > > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw7_CreateSurface > > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_bad3, &surf7, NULL); > > + ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw7_CreateSurface didn't > > return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_bad4, &surf7, NULL); > > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw7_CreateSurface > > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + > > + IDirectDraw7_Release(dd7); > > +} > > + > > START_TEST(dsurface) > > { > > HRESULT ret; > > @@ -3624,5 +3761,6 @@ START_TEST(dsurface) > > GetDCFormatTest(); > > BackBufferCreateSurfaceTest(); > > BackBufferAttachmentFlipTest(); > > + CreateSurfaceBadCapsSizeTest(); > > ReleaseDirectDraw(); > > } > > > > > >

Aug. 10, 2010

Re: X Presentation and Synchronization - will it help Wine performance

by Roderick Colenbrander

On Tue, Aug 10, 2010 at 6:53 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 10 August 2010 15:27, Groeschel, Volker <volker.groeschel(a)sap.com> wrote: >> I wonder if Wine will profit from the new X Presentation and Synchronization >> feature NVIDIA is working on: >> >> >> >> http://people.freedesktop.org/~aplattner/x-presentation-and-synchronization… >> > I doubt it, unless it will somehow make the drivers themselves faster. > >> e.g. when I start several instances of my game with Wine on my computer (AMD >> X2 with Ubuntu and proprietary NVIDIA graphic drivers), performance breaks >> down dramatically. >> > Yeah, that's a fairly well known issue with the nvidia drivers, you > can also see that when e.g. comparing fps from running two glxgears > instances with running just a single instance. Running two instances > at the same time will get you much less than half the performance. > That issue may be unique to nvidia's setup, I don't get it with the > free r600 driver. Though it should be said that performance there > isn't quite at the level where it's fair to compare yet. > > > In my experience on Nvidia Fermi hardware performance scales linearly at least in modern shader limited applications like the Heaven benchmark. In four instances at relatively heavy settings, (I believe each was running at 1024x768 or higher) the fps is fps/4 and by adding each window I saw a linear drop. I don't remember for sure but I think I saw the same on games on Wine, though I would have to recheck it. Older non-Fermi hardware didn't seem to scale as well, but I haven't done that much testing on those GPUs. Yesterday I talked with Nvidia guys and they also said that typically performance should scale linearly but there can be exceptions in which some things might be time sliced. I might be able to do some more testing and if it shows anything interesting I will reply here. Roderick

Aug. 10, 2010

Re: X Presentation and Synchronization - will it help Wine performance

by Henri Verbeet

On 10 August 2010 15:27, Groeschel, Volker <volker.groeschel(a)sap.com> wrote: > I wonder if Wine will profit from the new X Presentation and Synchronization > feature NVIDIA is working on: > > > > http://people.freedesktop.org/~aplattner/x-presentation-and-synchronization… > I doubt it, unless it will somehow make the drivers themselves faster. > e.g. when I start several instances of my game with Wine on my computer (AMD > X2 with Ubuntu and proprietary NVIDIA graphic drivers), performance breaks > down dramatically. > Yeah, that's a fairly well known issue with the nvidia drivers, you can also see that when e.g. comparing fps from running two glxgears instances with running just a single instance. Running two instances at the same time will get you much less than half the performance. That issue may be unique to nvidia's setup, I don't get it with the free r600 driver. Though it should be said that performance there isn't quite at the level where it's fair to compare yet.

Aug. 10, 2010

Re: New and subtle ddraw:dsurface test failure

by Stefan Dösinger

Am Montag 09 August 2010, 21:41:18 schrieb Oldřich Jedlička: > ok(hr==DD_OK || broken(hr != DD_OK && SUCCEEDED(hr)), > "text...") I think as long as no native app is found that depends on DD_OK it's ok just use ok(SUCCEEDED(hr)) for the sake of readability.

Aug. 10, 2010

Re: [PATCH 1/5] ddraw/tests: Add test for bad size of surface caps in CreateSurface. (try 5)

by Stefan Dösinger

Diff -u doesn't find any difference between try 4 and try 5, and probably older tries. If you're resending them because the older ones weren't applied, that's futile - Alexandre is on vacation. Also it is generally a bad idea to keep resending a unchanged patch. If you think the patch has been lost(e.g. Alexandre is waiting for my review and I am not at home, etc) it is better to ask on Wine-devel what is up with the patches. Am Sonntag 08 August 2010, 07:09:24 schrieb Oldřich Jedlička: > --- > dlls/ddraw/tests/dsurface.c | 138 > +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 138 > insertions(+), 0 deletions(-) > > diff --git a/dlls/ddraw/tests/dsurface.c b/dlls/ddraw/tests/dsurface.c > index 76bfc7e..8cdcd92 100644 > --- a/dlls/ddraw/tests/dsurface.c > +++ b/dlls/ddraw/tests/dsurface.c > @@ -25,6 +25,7 @@ > > #include <assert.h> > #include "wine/test.h" > +#include "wine/exception.h" > #include "ddraw.h" > #include "d3d.h" > #include "unknwn.h" > @@ -3569,6 +3570,142 @@ static void BackBufferAttachmentFlipTest(void) > DestroyWindow(window); > } > > +static void CreateSurfaceBadCapsSizeTest(void) > +{ > + DDSURFACEDESC ddsd_ok; > + DDSURFACEDESC ddsd_bad1; > + DDSURFACEDESC ddsd_bad2; > + DDSURFACEDESC ddsd_bad3; > + DDSURFACEDESC ddsd_bad4; > + DDSURFACEDESC2 ddsd2_ok; > + DDSURFACEDESC2 ddsd2_bad1; > + DDSURFACEDESC2 ddsd2_bad2; > + DDSURFACEDESC2 ddsd2_bad3; > + DDSURFACEDESC2 ddsd2_bad4; > + IDirectDrawSurface *surf; > + IDirectDrawSurface4 *surf4; > + IDirectDrawSurface7 *surf7; > + HRESULT hr; > + IDirectDraw2 *dd2; > + IDirectDraw4 *dd4; > + IDirectDraw7 *dd7; > + > + const DWORD caps = DDSCAPS_OFFSCREENPLAIN; > + > + memset(&ddsd_ok, 0, sizeof(ddsd_ok)); > + ddsd_ok.dwSize = sizeof(ddsd_ok); > + ddsd_ok.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; > + ddsd_ok.dwWidth = 64; > + ddsd_ok.dwHeight = 64; > + ddsd_ok.ddsCaps.dwCaps = caps; > + memcpy(&ddsd_bad1, &ddsd_ok, sizeof(ddsd_bad1)); > + ddsd_bad1.dwSize--; > + memcpy(&ddsd_bad2, &ddsd_ok, sizeof(ddsd_bad2)); > + ddsd_bad2.dwSize++; > + memcpy(&ddsd_bad3, &ddsd_ok, sizeof(ddsd_bad3)); > + ddsd_bad3.dwSize = 0; > + memcpy(&ddsd_bad4, &ddsd_ok, sizeof(ddsd_bad4)); > + ddsd_bad4.dwSize = sizeof(DDSURFACEDESC2); > + > + memset(&ddsd2_ok, 0, sizeof(ddsd2_ok)); > + ddsd2_ok.dwSize = sizeof(ddsd2_ok); > + ddsd2_ok.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; > + ddsd2_ok.dwWidth = 64; > + ddsd2_ok.dwHeight = 64; > + ddsd2_ok.ddsCaps.dwCaps = caps; > + memcpy(&ddsd2_bad1, &ddsd2_ok, sizeof(ddsd2_bad1)); > + ddsd2_bad1.dwSize--; > + memcpy(&ddsd2_bad2, &ddsd2_ok, sizeof(ddsd2_bad2)); > + ddsd2_bad2.dwSize++; > + memcpy(&ddsd2_bad3, &ddsd2_ok, sizeof(ddsd2_bad3)); > + ddsd2_bad3.dwSize = 0; > + memcpy(&ddsd2_bad4, &ddsd2_ok, sizeof(ddsd2_bad4)); > + ddsd2_bad4.dwSize = sizeof(DDSURFACEDESC); > + > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_ok, &surf, NULL); > + ok(SUCCEEDED(hr), "IDirectDraw_CreateSurface failed: 0x%08x\n", hr); > + IDirectDrawSurface_Release(surf); > + > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_bad1, &surf, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_bad2, &surf, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_bad3, &surf, NULL); > + ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface didn't return > 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_bad4, &surf, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + > + hr = IDirectDraw_QueryInterface(lpDD, &IID_IDirectDraw2, (void **) > &dd2); + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: > 0x%08x\n", hr); + > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_ok, &surf, NULL); > + ok(SUCCEEDED(hr), "IDirectDraw2_CreateSurface failed: 0x%08x\n", hr); > + IDirectDrawSurface_Release(surf); > + > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_bad1, &surf, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw2_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_bad2, &surf, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw2_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_bad3, &surf, NULL); > + ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw2_CreateSurface didn't > return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_bad4, &surf, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw2_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + > + IDirectDraw2_Release(dd2); > + > + hr = IDirectDraw_QueryInterface(lpDD, &IID_IDirectDraw4, (void **) > &dd4); + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: > 0x%08x\n", hr); + > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_ok, &surf4, NULL); > + ok(SUCCEEDED(hr), "IDirectDraw4_CreateSurface failed: 0x%08x\n", hr); > + IDirectDrawSurface4_Release(surf4); > + > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_bad1, &surf4, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw4_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_bad2, &surf4, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw4_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_bad3, &surf4, NULL); > + ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw4_CreateSurface didn't > return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_bad4, &surf4, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw4_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + > + IDirectDraw4_Release(dd4); > + > + hr = IDirectDraw_QueryInterface(lpDD, &IID_IDirectDraw7, (void **) > &dd7); + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: > 0x%08x\n", hr); + > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_ok, &surf7, NULL); > + ok(SUCCEEDED(hr), "IDirectDraw7_CreateSurface failed: 0x%08x\n", hr); > + IDirectDrawSurface7_Release(surf7); > + > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_bad1, &surf7, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw7_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_bad2, &surf7, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw7_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_bad3, &surf7, NULL); > + ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw7_CreateSurface didn't > return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_bad4, &surf7, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw7_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + > + IDirectDraw7_Release(dd7); > +} > + > START_TEST(dsurface) > { > HRESULT ret; > @@ -3624,5 +3761,6 @@ START_TEST(dsurface) > GetDCFormatTest(); > BackBufferCreateSurfaceTest(); > BackBufferAttachmentFlipTest(); > + CreateSurfaceBadCapsSizeTest(); > ReleaseDirectDraw(); > }

Aug. 10, 2010

X Presentation and Synchronization - will it help Wine performance

by Groeschel, Volker

Hi, I wonder if Wine will profit from the new X Presentation and Synchronization feature NVIDIA is working on: http://people.freedesktop.org/~aplattner/x-presentation-and-synchronization… According to the Phoronix article the feature is planed for X.Org Server 1.10: http://www.phoronix.com/scan.php?page=news_item&px=ODM3Ng e.g. when I start several instances of my game with Wine on my computer (AMD X2 with Ubuntu and proprietary NVIDIA graphic drivers), performance breaks down dramatically. As of three instances the third windows freezes or gets near 0 FPS while the same computer with Win XP can run up to eight instances. Many thanks for your good work which helps me to get rid of Windows in my home office ☺

Aug. 10, 2010

Wine users with a CD-ROM drive, please test

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Eric Pouech wrote: >may be the driver doesn't support TMSF, and from/to fields must be provided in MSF >would you mind trying that ? Me? The others ;) The 5 machines I've had access to all pass the tests. I somehow doubt it'll help because Jeff Zaroyko wrote: >> set c time format tmsf >> seek c to start >> play c from 1 to 2 wait >This works - I hear music. So TMSF works for Jeff, even though the testsuite yields MCIERR_HARDWARE there. Furthermore the failing Seek before Play uses MSF in the proposed testsuite. Nevertheless worth a try. Any hint may work. Perhaps also add the "wait" flag to the tests: seek c to start notify WAIT Perhaps the cause is one of the unusual commands: set c video audio all off set c door closed notify # # Perhaps add status c mode after that? On some machines, inserting an audio CD starts the media player. Perhaps this interacts with the tests? Thank you for your help, Jörg Höhle

Aug. 10, 2010

Re: winex11.drv: Fix uninitialised values. (valgrind) (try 2)

by Michael Stefaniuc

Hello Austin, Austin Lund wrote: > On 10 August 2010 18:05, Michael Stefaniuc <mstefani(a)redhat.com> wrote: >> Hello Austin, >> >> Austin Lund wrote: >>> ------------------------------------------------------------------------ > >> both functions are heavily used and you don't want to waste time >> HEAP_ZERO_MEMORY just to please valgrind. I even wonder why valgrind >> complains as e.g. in X11DRV_SetBitmapBits() only the default switch case >> won't initialize the memory at all. > > Thanks for the comment. I ran winemine in valgrind to get this. > Somehow that must trigger the default case. no, you would see a FIXME in that case. I wonder if Dan Kegel might know more on why valgrind triggers in that case. bye michael

Aug. 10, 2010

Re: winex11.drv: Fix uninitialised values. (valgrind) (try 2)

by Austin Lund

On 10 August 2010 18:05, Michael Stefaniuc <mstefani(a)redhat.com> wrote: > Hello Austin, > > Austin Lund wrote: >> >> ------------------------------------------------------------------------ > both functions are heavily used and you don't want to waste time > HEAP_ZERO_MEMORY just to please valgrind. I even wonder why valgrind > complains as e.g. in X11DRV_SetBitmapBits() only the default switch case > won't initialize the memory at all. Hi Michael, Thanks for the comment. I ran winemine in valgrind to get this. Somehow that must trigger the default case.

Aug. 10, 2010

Re: winex11.drv: Fix uninitialised values. (valgrind) (try 2)

by Michael Stefaniuc

Hello Austin, Austin Lund wrote: > > ------------------------------------------------------------------------ > From 07bc18edc35c68c8e0da58a70ccd5c8f03584a1a Mon Sep 17 00:00:00 2001 > From: Austin Lund <austin.lund(a)gmail.com> > Date: Tue, 10 Aug 2010 13:03:14 +1000 > Subject: [PATCH] winex11.drv: Fix uninitialised values. (valgrind) > > --- > dlls/winex11.drv/bitmap.c | 2 +- > dlls/winex11.drv/dib.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/winex11.drv/bitmap.c b/dlls/winex11.drv/bitmap.c > index 4683fd9..af6c00b 100644 > --- a/dlls/winex11.drv/bitmap.c > +++ b/dlls/winex11.drv/bitmap.c > @@ -351,7 +351,7 @@ LONG CDECL X11DRV_SetBitmapBits( HBITMAP hbitmap, const void *bits, LONG count ) > wine_tsx11_lock(); > image = XCreateImage( gdi_display, visual, physBitmap->pixmap_depth, ZPixmap, 0, NULL, > bitmap.bmWidth, height, 32, 0 ); > - if (!(image->data = HeapAlloc( GetProcessHeap(), 0, image->bytes_per_line * height ))) > + if (!(image->data = HeapAlloc( GetProcessHeap(), HEAP_ZERO_MEMORY, image->bytes_per_line * height ))) > { > WARN("No memory to create image data.\n"); > XDestroyImage( image ); > diff --git a/dlls/winex11.drv/dib.c b/dlls/winex11.drv/dib.c > index 11157f1..eda064e 100644 > --- a/dlls/winex11.drv/dib.c > +++ b/dlls/winex11.drv/dib.c > @@ -3535,7 +3535,7 @@ static int X11DRV_DIB_SetImageBits( const X11DRV_DIB_IMAGEBITS_DESCR *descr ) > else { > bmpImage = XCreateImage( gdi_display, visual, descr->depth, ZPixmap, 0, NULL, > descr->infoWidth, lines, 32, 0 ); > - bmpImage->data = HeapAlloc( GetProcessHeap(), 0, lines * bmpImage->bytes_per_line ); > + bmpImage->data = HeapAlloc( GetProcessHeap(), HEAP_ZERO_MEMORY, lines * bmpImage->bytes_per_line ); > if(bmpImage->data == NULL) { > ERR("Out of memory!\n"); > XDestroyImage( bmpImage ); > both functions are heavily used and you don't want to waste time HEAP_ZERO_MEMORY just to please valgrind. I even wonder why valgrind complains as e.g. in X11DRV_SetBitmapBits() only the default switch case won't initialize the memory at all. bye michael

Aug. 10, 2010

Re: New and subtle ddraw:dsurface test failure

by Oldřich Jedlička

Hi W, On Monday 09 August 2010 12:31:45 wylda(a)volny.cz wrote: > Hi, > > > Do you mean this problem? > > ddraw:dsurface start ... > > Nope and nothing about 64bit (there was no change). I was initially > talking about changed result from last Friday. To be precise this > new information showed up under WinXP 32bit on nvidia 8600GT: > > > dsurface.c:3511: Test failed: IDirectDrawSurface_Flip returned > 0x00000003 > dsurface.c:3528: Test failed: IDirectDrawSurface_Flip returned > 0x00000003 > > And i had a slight feeling, that i saw you, Oldrich, doing some > changes in this are. Thus decided to substitute "paranoid android" > aka testbot(a)testbot.winehq.org. > > Last note, intel card i915gm does not fail on this "Surface_Flip" > and thus i decided to pinpoint this issue for nvidia. Ah, now I see (just describe the full problem the first time, I don't have a witch ball :-)). The nvidia driver doesn't return DD_OK like it should (see http://msdn.microsoft.com/en-us/library/aa915446.aspx) but other non-error code. I cannot say if this is somehow/totally wrong, but for the test purposes this can be work-around by changing the mentioned "ok" line to something like ok(hr==DD_OK || broken(hr != DD_OK && SUCCEEDED(hr)), "text...") This tells the wine to be correct (hr==DD_OK), but allows windows tests to fail with the alternative result code. Could you please try it/test it? Thanks, Oldřich. > > > Regards, > W.

Aug. 9, 2010

Re: [PATCH] quartz: implement AsyncReader_FindPin

by Anton Khirnov

On Sat, Aug 07, 2010 at 11:53:36AM +0200, David Adam wrote: > Hi, > > what about if ppPin is NULL? then it will crash spectacularly, which is exactly what the client throwing around invalid pointers deserves ;) the surrounding code assumes that it's passed valid pointers too. anyway, dshow seems to require this, so added a check locally > I think that this patch needs test cases to prove that it is correct? I'll try to write something, but i'm not familiar with wine/quartz API (i just wanted to get video playback in a game working :) ) so it might be problematic. anyway, i've looked around some more and it seems that this function can be shared for all IBaseFilter subclasses. same probably goes for some other, e.g. IBaseFilter_EnumPins. is there a reason they're not? Anton Khirnov

Aug. 9, 2010

Re: Wine users with a CD-ROM drive, please test

by Eric Pouech

Jörg-Cyril : may be the driver doesn't support TMSF, and from/to fields must be provided in MSF would you mind trying that ? A+ -- -- Eric Pouech

Aug. 9, 2010

Re: Should we expect Liberation fonts to be installed?

by Brian Vincent

On Sun, Aug 8, 2010 at 8:58 PM, Scott Ritchie <scott(a)open-vote.org> wrote: >> This might work for Linux, but these fonts are not installed on any >> MacOSX version that I'm aware of. This might break Wine useage for >> Macs. It might also break it for Solaris as well. > > It should only break in a way that makes it as bad as it currently is. Macs should already have the proper fonts installed, but it might take some config changes to use them properly. Seems more like a packaging issue. Along those lines, the hard drive space is cheap on this one. Seems like Wine packagers could just include the fonts and install them locally in c:\windows\fonts. More properly, we should probably try to detect a system installation of them since it'll probably exist and then fall back on installing them if it doesn't. Fonts are a pretty big usability issue, apps really don't behave properly without them. -Brian

Aug. 9, 2010

Wine users with a CD-ROM drive, please test

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Thank you for your test results so far. >>>mcicda.c:425: Test failed: SEEK to 00203A43 position last + length: MCIERR_HARDWARE >>>mcicda.c:436: Test failed: PLAY from 1 notify: MCIERR_HARDWARE >> Same as Jeff, please see if one of you can identify which prior MCI command causes this. >Do you have any instructions how I can identify this? This sequence of commands worked for Jeff: open cdaudio alias c status c type track 1 set c time format tmsf seek c to start play c from 1 to 2 wait The sequence of commands that the tests use is below. I don't see anything there that explains MCIERR_HARDWARE. Perhaps it's a timing issue and the suite would work after adding a couple of Sleep()? Copy&Paste of this sequence into the mcishell (see bug 20232, comment #10) works for me. Does it generate MCIERR_HARDWARE on your machine? Can you try and eliminate commands until you reach a minimal set that generates the error (start with removing capability, info and notify)? open cdaudio alias c notify shareable capability c has video notify capability c can play capability c capability c 16385 capability c device type status c time format info c product wait notify status c media present status c mode status c mode status c ready info c product identity info c identity info c upc status c number of tracks status c length status c position status c position start notify status c position start track 1 notify play c from 00:02:00 to 00:01:00 notify resume c seek c wait seek c to start notify # # Perhaps use seek c to start notify wait set c video audio all off set c time format ms status c position start status c position start track 1 status c notify wait status c length track 1 set c door closed notify status c type track 1 # # skipping data track tests set c time format msf status c length track 20 # # Replace 20 with number of tracks here status c position track 20 # # Perhaps add status c mode (still seeking?) seek c to 24:55:74 # # Replace with position last track start + length seek c to 24:56:00 set c time format tmsf play c from 1 Thank you for your help, Jörg Höhle

Aug. 9, 2010

Re: winepath bug without arguments?

by Paul Chitescu

On Monday 09 August 2010 01:23:24 pm Jerome Leclanche wrote: > Hi > > After fixing a bug in MPQEdit related to opening directories, I > noticed winepath returns a different result with and without quotes: > > adys(a)azura:~/.wine/drive_c$ winepath -w > adys(a)azura:~/.wine/drive_c$ winepath -w "" > C:\ > > With quotes it returns the current directory. Is that intended? If not > I'll open a bug... > > > > J. Leclanche Yes, it's intended. winepath converts zero or more arguments. An empty argument means "start from current dir... and print!" [paulc(a)bussard drive_c]$ winepath -w "" users "Program Files" C:\ C:\users C:\Program Files Paul

Aug. 9, 2010

Re: New and subtle ddraw:dsurface test failure

by wylda＠volny.cz

Hi, > Do you mean this problem? > ddraw:dsurface start ... Nope and nothing about 64bit (there was no change). I was initially talking about changed result from last Friday. To be precise this new information showed up under WinXP 32bit on nvidia 8600GT: dsurface.c:3511: Test failed: IDirectDrawSurface_Flip returned 0x00000003 dsurface.c:3528: Test failed: IDirectDrawSurface_Flip returned 0x00000003 And i had a slight feeling, that i saw you, Oldrich, doing some changes in this are. Thus decided to substitute "paranoid android" aka testbot(a)testbot.winehq.org. Last note, intel card i915gm does not fail on this "Surface_Flip" and thus i decided to pinpoint this issue for nvidia. Regards, W.

Aug. 9, 2010

winepath bug without arguments?

by Jerome Leclanche

Hi After fixing a bug in MPQEdit related to opening directories, I noticed winepath returns a different result with and without quotes: adys(a)azura:~/.wine/drive_c$ winepath -w adys(a)azura:~/.wine/drive_c$ winepath -w "" C:\ With quotes it returns the current directory. Is that intended? If not I'll open a bug... J. Leclanche

Aug. 9, 2010

Re: New and subtle ddraw:dsurface test failure

by Reece Dunn

2010/8/9 Roderick Colenbrander <thunderbird2k(a)gmail.com>: > 2010/8/8 Oldřich Jedlička <oldium.pro(a)seznam.cz>: >> Hi W, >> >> On Sunday 08 August 2010 11:21:35 wylda(a)volny.cz wrote: >>> Hi, >>> >>> i >> just noticed some new and subtle failure in ddraw:dsurface >>> tests. I don't >> know how closely you watch and study tests >>> results, so i thought it might >> be a good idea bring it the >>> the light. Sorry if not ;-) >>> >>> Compared >> WinXP 277040d92454 vs 8b2a403a7dc3 (latest vs last >>> Friday). >>> >>> >> Interestingly does not happen on Intel and nVidia 64bit. So >>> the only >> affected is nVidia 32bit. >> >> Do you mean this problem? >> >> ddraw:dsurface start - >> - >> dsurface.c:419: Tests skipped: Failed to create surface >> dsurface.c:801: >> Test failed: IDirectDraw7_QueryInterface returned 80004002 >> dsurface.c:808: >> this is the last test seen before the exception >> dsurface: unhandled >> exception c0000005 at 00413A29 >> ddraw:dsurface done (4294967295) >> >> I've seen >> this also during my first tests. From my understanding the problem of >> unhandled exception is caused by query interface failure. For me it looks >> like that DirectDraw7 isn't supported on the system >> (E_NOINTERFACE). >> >> Oldřich. >> > > I'm not sure how usable 64-bit DirectDraw is. At the time XP64 came > out, DirectDraw was already deprecated and Direct3D9 was the standard. > I'm not sure how much effort Microsoft put in 64-bit DirectDraw (it > wouldn't make sense to use it). Perhaps some IE plugins (or IE itself) > use DirectDraw and that could be why there is some support. > > More investigation is needed on what is supported in 64-bit > DirectDraw. The DirectDraw 3D tests seem to fail correctly, so at > least 3D is not around. There is likely some limited 2D support > though. It shouldn't be that hard to fix the tests. Something like this -- I haven't tested this on affected Win64 systems. - Reece

Aug. 9, 2010

Re: New and subtle ddraw:dsurface test failure

by Roderick Colenbrander

2010/8/8 Oldřich Jedlička <oldium.pro(a)seznam.cz>: > Hi W, > > On Sunday 08 August 2010 11:21:35 wylda(a)volny.cz wrote: >> Hi, >> >> i > just noticed some new and subtle failure in ddraw:dsurface >> tests. I don't > know how closely you watch and study tests >> results, so i thought it might > be a good idea bring it the >> the light. Sorry if not ;-) >> >> Compared > WinXP 277040d92454 vs 8b2a403a7dc3 (latest vs last >> Friday). >> >> > Interestingly does not happen on Intel and nVidia 64bit. So >> the only > affected is nVidia 32bit. > > Do you mean this problem? > > ddraw:dsurface start - > - > dsurface.c:419: Tests skipped: Failed to create surface > dsurface.c:801: > Test failed: IDirectDraw7_QueryInterface returned 80004002 > dsurface.c:808: > this is the last test seen before the exception > dsurface: unhandled > exception c0000005 at 00413A29 > ddraw:dsurface done (4294967295) > > I've seen > this also during my first tests. From my understanding the problem of > unhandled exception is caused by query interface failure. For me it looks > like that DirectDraw7 isn't supported on the system > (E_NOINTERFACE). > > Oldřich. > I'm not sure how usable 64-bit DirectDraw is. At the time XP64 came out, DirectDraw was already deprecated and Direct3D9 was the standard. I'm not sure how much effort Microsoft put in 64-bit DirectDraw (it wouldn't make sense to use it). Perhaps some IE plugins (or IE itself) use DirectDraw and that could be why there is some support. More investigation is needed on what is supported in 64-bit DirectDraw. The DirectDraw 3D tests seem to fail correctly, so at least 3D is not around. There is likely some limited 2D support though. It shouldn't be that hard to fix the tests. Roderick

Aug. 9, 2010

Re: New and subtle ddraw:dsurface test failure

by Oldřich Jedlička

Hi W, On Sunday 08 August 2010 11:21:35 wylda(a)volny.cz wrote: > Hi, > > i just noticed some new and subtle failure in ddraw:dsurface > tests. I don't know how closely you watch and study tests > results, so i thought it might be a good idea bring it the > the light. Sorry if not ;-) > > Compared WinXP 277040d92454 vs 8b2a403a7dc3 (latest vs last > Friday). > > Interestingly does not happen on Intel and nVidia 64bit. So > the only affected is nVidia 32bit. Do you mean this problem? ddraw:dsurface start - - dsurface.c:419: Tests skipped: Failed to create surface dsurface.c:801: Test failed: IDirectDraw7_QueryInterface returned 80004002 dsurface.c:808: this is the last test seen before the exception dsurface: unhandled exception c0000005 at 00413A29 ddraw:dsurface done (4294967295) I've seen this also during my first tests. From my understanding the problem of unhandled exception is caused by query interface failure. For me it looks like that DirectDraw7 isn't supported on the system (E_NOINTERFACE). Oldřich. > (For my education) Generally, when the test fails in Windows > world, it means that the test is wrongly written or not > supported under the tested Windows version? (not blaming > anyone, just asking how things work;) > And the last question is about MSI failures and timeouts > which some boxes suffers... In my case the "powerful" > succeeds and the "weak" timeouts here (and not just mine). > Shouldn't be the timeout prolonged? > > > Regards, > W. > > PS: I probably missed "gratulation time" for v1.2, so at > least i wish all the goodness to 1.3.xx line! And hope i > find another free time for buzilla soon.

Aug. 9, 2010

Re: Should we expect Liberation fonts to be installed?

by Scott Ritchie

On 08/08/2010 06:56 AM, James McKenzie wrote: > Scott Ritchie wrote: >> I was looking through our fairly large collection of open font bugs and >> realized that things might be a lot simpler if we took some opinionated >> positions and just declared certain fonts to be dependencies and >> expected all packagers to provide them. >> >> This is similar to bundling our own Tahoma, except much less work. >> > This might work for Linux, but these fonts are not installed on any > MacOSX version that I'm aware of. This might break Wine useage for > Macs. It might also break it for Solaris as well. > > James McKenzie > It should only break in a way that makes it as bad as it currently is. Thanks, Scott Ritchie

Aug. 9, 2010

'winetricks python' and user-submitted small testcases

by Dan Kegel

Waaaay back in 2002, the wine project experimented with writing win32 conformance tests in Perl. Nobody liked it; it was dropped in favor of conformance tests in C, and there was much rejoicing. Today I noticed http://bugs.winehq.org/show_bug.cgi?id=23940 which has a simple win32 test case written in Python. Surprisingly, with 'winetricks python', the test case ran and demonstrated the problem (though since the python script expected you to start another app first, and edit the python to have the other app's window title, it wasn't an unattended test). That particular bug isn't anything special, but I was happy to see that a user who preferred Python was able to successfully send a minimal test case for a win32 problem written in his favorite language, and have someone else successfully run it.

Aug. 8, 2010

New and subtle ddraw:dsurface test failure

by wylda＠volny.cz

Hi, i just noticed some new and subtle failure in ddraw:dsurface tests. I don't know how closely you watch and study tests results, so i thought it might be a good idea bring it the the light. Sorry if not ;-) Compared WinXP 277040d92454 vs 8b2a403a7dc3 (latest vs last Friday). Interestingly does not happen on Intel and nVidia 64bit. So the only affected is nVidia 32bit. (For my education) Generally, when the test fails in Windows world, it means that the test is wrongly written or not supported under the tested Windows version? (not blaming anyone, just asking how things work;) And the last question is about MSI failures and timeouts which some boxes suffers... In my case the "powerful" succeeds and the "weak" timeouts here (and not just mine). Shouldn't be the timeout prolonged? Regards, W. PS: I probably missed "gratulation time" for v1.2, so at least i wish all the goodness to 1.3.xx line! And hope i find another free time for buzilla soon.

Aug. 8, 2010

Re: [PATCH 5/5] ddraw: Allow creating back buffer for DirectX 1 interfaces. (try 5)

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=4356 Your paranoid android. === W2KPROSP4 (32 bit visual) === visual.c:1742: Test failed: Got color 000a246a, expected 00000000 visual.c:1748: Test failed: Got color 006b8bbd, expected 00ff0000 or near visual.c:1751: Test failed: Got color 00ffffff, expected 00000000 visual.c:1757: Test failed: Got color 00ffffff, expected 00800000 or near === W98SE (32 bit dsurface) === No test summary line found

Aug. 8, 2010

Re: Right-To-Left (RTL) languages and Wine

by Shachar Shemesh

Paul Vriens wrote: > Hi, > > I've been in talks with a Hebrew translator for some time now and I'd > like to have Wine being able to start doing more RTL stuff. > > I'm looking for example at http://bugs.winehq.org/show_bug.cgi?id=1158 > > If I run an English winmine.exe on an Arabic box (thanks to the > testbot) the main window will shows as normal LTR window layout with > the menu's left justified as well. > > So eventhough the locale is set to Arabic it doesn't turn 'everything' > into RTL. > > If we don't change the resource files for the RTL languages, that same > logic will give us LTR Wine applications or am I wrong here? > An English app running on a Hebrew Windows does not automatically get entirely reversed. There are two parts to this question, and I believe that Wine should handle those parts differently. One part are the Windows decorations - close button, minimize, maximize, etc. Under Windows, if an application is reversed, so are these. I believe Wine should not attempt to replicate this behavior for the following reasons: * It is a broken design decision. Its implications are that on the same desktop, some windows have their close button on the left, others on the right. In my experience, this does nothing to enhance the user's experience. * It is difficult to implement. The decorations on Wine windows are drawn by the X window manager. We would have to convince each window manager to reverse the window decorations on our say so. I am not aware of such an API existing, which means lots and lots and lots of bugs. * As an aggregate of the above two - the window decorations are, today, not defined by Wine to be part of the "windows experience", and as such, if the Windows behavior is broken, we need not replicate it. The other part is the actual content of the window. Here there is a need to support exactly what Windows is doing, as that is the API. As a side note, I'll add that I think that is broken too. Mirroring should not be done automatically, and reading the MSDN article that Dmitry references just shows how many ways it can, indeed, break. That said, Wine did commit to being bug-compatible with Windows, so that part should, *eventually*, be implemented. I do agree with Alexandre that there are many things more pressing on the BiDi front to handle. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com

Aug. 8, 2010

Re: gdi32: use usp10 to optionally generate glyphs for bidi strings

by Shachar Shemesh

Alexandre Julliard wrote: > Which of course demonstrates that gdi32 calls usp10 on native too. Maybe > it does it indirectly through lpk.dll, but the end result is the same, > you have a dependency on usp10. > > I know I'm coming a bit late into the discussion, but just for the record, this is how Windows does it (as of Windows 2000): * GDI has a soft dependency on LPK.DLL. It tries to load it using LoadLibrary. * If it succeeds, and if there are no breakout flags, each call to ExtTextOut is redirected to the LPK version of that same call * LPK links with uniscribe for the actual BiDi processing, and also with GDI for the actual rendering of the result. Yes, this means a circular dependency. * The breakout flags are ETO_IGNORELANGUAGE and ETO_GLYPH_INDEX. If these are passed, GDI handles the request itself, without forwarding it to LPK. This prevents the infinite recursion that might, otherwise, happen. I believe the reason for this twisted design is twofold. First, in Windows 2000, CTL (complex text layout) was an optional component, to be installed by a checkbox in the regional settings dialog. This meant that the entire LPK dll could just be dropped in, along with some fonts, and the system would start supporting BiDi. The second reason is because BiDi is a rather multi-layered process. With BiDi, support for multi line rendering (as done by DrawText in User32) requires some fairly complex processing before the text could be passed off to ExtTextOut for actual rendering. This way, all the BiDi code could be placed in one place. Another reason, I believe, for this separation is that pre-Windows 2000 (and more importantly, pre-uniscribe) Windows still had BiDi code, which was scattered all over the place, and which became obsolete (for one example - GetCharacterPlacement, which supposedly does BiDi, has no mechanism to choose the paragraph direction, without which no BiDi processing makes sense. The MSDN docs even explicitly state it is obsolete). I believe the best route forward is to use an LPK *like* DLL. Not LPK itself, as that would require of us to reverse engineer a whole set of APIs that no one but us even call, but another DLL, injected into the dependency order at the same location, carrying a similar functionality. I would suggest "winelpk.dll" as the name, but that is, of course, entirely open. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com

Aug. 8, 2010

Re: [PATCH 1/5] ddraw/tests: Add test for bad size of surface caps in CreateSurface. (try 5)

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=4352 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found

Aug. 8, 2010

Re: Should we expect Liberation fonts to be installed?

by Scott Ritchie

On 08/03/2010 01:57 PM, Scott Ritchie wrote: > I was looking through our fairly large collection of open font bugs and > realized that things might be a lot simpler if we took some opinionated > positions and just declared certain fonts to be dependencies and > expected all packagers to provide them. > > This is similar to bundling our own Tahoma, except much less work. > > > This bug, for instance, prevents Photoshop from working unless there is > an Arial font installed: http://bugs.winehq.org/show_bug.cgi?id=9623 > > Wine doesn't seem to respect system-level fontconfig aliases, so even > though Liberation Sans is installed on the system Photoshop won't try to > use it in place of Arial. > > But if however we assumed that Liberation Sans was installed, we could > make things much better: a link/substitution for Arial->Liberation Sans > could be provided in our own registry (and similarly for Times New Roman > and Courier). An alternative is to simply symlink to the Liberation > Fonts in /usr/share/wine/fonts as though they were our own shipped fonts > (like Tahoma). > > This would make Photoshop think Arial was present and keep it > functional. Ideally the real Arial would be displayed if it was > installed (eg through winetricks corefonts or by installing the > distro-provided corefonts package). > > > A related question is whether to show "Arial" in the list of fonts (eg > notepad) when we're actually just providing a substituted Arial. My > inclination says no, however I'm not sure how it works internally and > what an application would expect. > Assuming for a moment this is a good idea, what's the best implementation? My inclination is to say some registry font links, but I'm not completely familiar with how that works. Will font links in the registry be ignored when the real font is present? Thanks, Scott Ritchie

Aug. 8, 2010

Re: [PATCH 5/5] ddraw: Allow creating back buffer for DirectX 1 interfaces. (try 4)

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=4348 Your paranoid android. === W2KPROSP4 (32 bit visual) === visual.c:2970: Test failed: IDirectDraw_CreateSurface returned: 80070057 visual.c:2986: Test failed: IDirectDraw_CreateSurface returned: 88760091 === W98SE (32 bit dsurface) === No test summary line found

Aug. 7, 2010

Re: [PATCH 2/5] ddraw/tests: New visual back buffer flipping tests. (try 4)

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=4345 Your paranoid android. === W2KPROSP4 (32 bit visual) === visual.c:2970: Test failed: IDirectDraw_CreateSurface returned: 80070057 visual.c:2986: Test failed: IDirectDraw_CreateSurface returned: 88760091

Aug. 7, 2010

Re: [PATCH 1/5] ddraw/tests: Add test for bad size of surface caps in CreateSurface. (try 4)

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=4344 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found

Aug. 7, 2010

Re: user32: Don't crash for unknown button styles

by André Hentschel

Am 07.08.2010 14:06, schrieb Nikolay Sivov: > On 8/7/2010 15:54, André Hentschel wrote: >> Am 06.08.2010 20:44, schrieb Nikolay Sivov: >>> On 8/6/2010 22:22, André Hentschel wrote: >>>> got that case with an MFC application which had a 3state radiobutton >>>> with buttonstyle 15(decimal) >>>> with this fix everything is fine as the painting of the button is >>>> handled elsewhere, without that fix it crashes as it reads bad data >>>> behind the array. >>>> >>>> --- >>>> dlls/user32/button.c | 2 +- >>>> 1 files changed, 1 insertions(+), 1 deletions(-) >>>> >>>> diff --git a/dlls/user32/button.c b/dlls/user32/button.c >>>> index 54d54dc..4f629f0 100644 >>>> --- a/dlls/user32/button.c >>>> +++ b/dlls/user32/button.c >>>> @@ -197,7 +197,7 @@ static inline UINT get_button_type( LONG >>>> window_style ) >>>> /* paint a button of any type */ >>>> static inline void paint_button( HWND hwnd, LONG style, UINT >>>> action ) >>>> { >>>> - if (btnPaintFunc[style]&& IsWindowVisible(hwnd)) >>>> + if (style<= MAX_BTN_TYPE&& btnPaintFunc[style]&& >>>> IsWindowVisible(hwnd)) >>>> { >>>> HDC hdc = GetDC( hwnd ); >>>> btnPaintFunc[style]( hwnd, hdc, action ); >>> This needs a test to see what happens visually for style 0xf, maybe we >>> need just to duplicate an entry in paint function table; also while >>> you're at it: >>> >>> static inline UINT get_button_type( LONG window_style ) >>> { >>> return (window_style& 0x0f); >>> } >>> >>> here BS_TYPEMASK should be used instead of 0xf. >>> >> Ok ill do. Also it was a 3state checkbox not a radiobutton. Further i >> made a typo in my oneline patch :) >> But i am still not sure if we really should paint in that case >> (unless some peoble come up with "invisible checkboxes"), >> because in my case the dialog style was that "ms office 2007 style", >> so mfc or the app handled the paint. if we would have drawn something >> it would have make it worse. > All I mean is that you need a small test app that creates button > directly without any mfc wrappers or anything. > Probably such style is even not accepted by control, or replaced with > some other style. > > If style is not accepted or replaced this should go directly to button > tests, if it's accepted we need visually guess how it works and add a > handler. i tested it on win7_x64 and it gets invisible after some dialog interaction, style gets accepted and is not replaced. So my initial patch was mostly correct. -- Best Regards, André Hentschel

Aug. 7, 2010

Re: Configuring with -Werror

by André Hentschel

> Configuring with -Werror used to work a while back for me; now that > -Wno-unused-result has been fixed I gave it another try and got this: > > configure: libxrandr 32-bit development files not found, XRandr won't > be supported. > configure: WARNING: Old Mesa headers detected. Consider upgrading your > Mesa libraries. > OpenGL and Direct3D won't be supported. > configure: WARNING: No sound system was found. Windows applications > will be silent. > > After a quick investigation, turns out many configure checks produce > warnings; patch below hacks around it, but I've never dealt with > configure before and apparently fixes need to go in configure.ac -- > anyone wants to give it a proper shot? Sorry for the noise on wine-patches, this should have been gone here... Patch looks ok, but that should only be changed in configure.ac... And the chance to get that in is not very high because AJ not always suppports different compilerflags. -- Best Regards, André Hentschel

Aug. 7, 2010

Re: user32: Don't crash for unknown button styles

by André Hentschel

Am 07.08.2010 14:06, schrieb Nikolay Sivov: > On 8/7/2010 15:54, André Hentschel wrote: >> Am 06.08.2010 20:44, schrieb Nikolay Sivov: >>> On 8/6/2010 22:22, André Hentschel wrote: >>>> got that case with an MFC application which had a 3state radiobutton >>>> with buttonstyle 15(decimal) >>>> with this fix everything is fine as the painting of the button is >>>> handled elsewhere, without that fix it crashes as it reads bad data >>>> behind the array. >>> This needs a test to see what happens visually for style 0xf, maybe we >>> need just to duplicate an entry in paint function table; also while >>> you're at it: >>> >>> static inline UINT get_button_type( LONG window_style ) >>> { >>> return (window_style& 0x0f); >>> } >>> >>> here BS_TYPEMASK should be used instead of 0xf. >>> >> Ok ill do. Also it was a 3state checkbox not a radiobutton. Further i >> made a typo in my oneline patch :) >> But i am still not sure if we really should paint in that case >> (unless some peoble come up with "invisible checkboxes"), >> because in my case the dialog style was that "ms office 2007 style", >> so mfc or the app handled the paint. if we would have drawn something >> it would have make it worse. > All I mean is that you need a small test app that creates button > directly without any mfc wrappers or anything. > Probably such style is even not accepted by control, or replaced with > some other style. > > If style is not accepted or replaced this should go directly to button > tests, if it's accepted we need visually guess how it works and add a > handler. Ok i see. -- Best Regards, André Hentschel

Aug. 7, 2010

Re: user32: Don't crash for unknown button styles

by Nikolay Sivov

On 8/7/2010 15:54, André Hentschel wrote: > Am 06.08.2010 20:44, schrieb Nikolay Sivov: >> On 8/6/2010 22:22, André Hentschel wrote: >>> got that case with an MFC application which had a 3state radiobutton >>> with buttonstyle 15(decimal) >>> with this fix everything is fine as the painting of the button is >>> handled elsewhere, without that fix it crashes as it reads bad data >>> behind the array. >>> >>> --- >>> dlls/user32/button.c | 2 +- >>> 1 files changed, 1 insertions(+), 1 deletions(-) >>> >>> diff --git a/dlls/user32/button.c b/dlls/user32/button.c >>> index 54d54dc..4f629f0 100644 >>> --- a/dlls/user32/button.c >>> +++ b/dlls/user32/button.c >>> @@ -197,7 +197,7 @@ static inline UINT get_button_type( LONG >>> window_style ) >>> /* paint a button of any type */ >>> static inline void paint_button( HWND hwnd, LONG style, UINT action ) >>> { >>> - if (btnPaintFunc[style]&& IsWindowVisible(hwnd)) >>> + if (style<= MAX_BTN_TYPE&& btnPaintFunc[style]&& >>> IsWindowVisible(hwnd)) >>> { >>> HDC hdc = GetDC( hwnd ); >>> btnPaintFunc[style]( hwnd, hdc, action ); >> This needs a test to see what happens visually for style 0xf, maybe we >> need just to duplicate an entry in paint function table; also while >> you're at it: >> >> static inline UINT get_button_type( LONG window_style ) >> { >> return (window_style& 0x0f); >> } >> >> here BS_TYPEMASK should be used instead of 0xf. >> > Ok ill do. Also it was a 3state checkbox not a radiobutton. Further i > made a typo in my oneline patch :) > But i am still not sure if we really should paint in that case > (unless some peoble come up with "invisible checkboxes"), > because in my case the dialog style was that "ms office 2007 style", > so mfc or the app handled the paint. if we would have drawn something > it would have make it worse. All I mean is that you need a small test app that creates button directly without any mfc wrappers or anything. Probably such style is even not accepted by control, or replaced with some other style. If style is not accepted or replaced this should go directly to button tests, if it's accepted we need visually guess how it works and add a handler.

Aug. 7, 2010

Re: user32: Don't crash for unknown button styles

by André Hentschel

Am 06.08.2010 20:44, schrieb Nikolay Sivov: > On 8/6/2010 22:22, André Hentschel wrote: >> got that case with an MFC application which had a 3state radiobutton >> with buttonstyle 15(decimal) >> with this fix everything is fine as the painting of the button is >> handled elsewhere, without that fix it crashes as it reads bad data >> behind the array. >> >> --- >> dlls/user32/button.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/dlls/user32/button.c b/dlls/user32/button.c >> index 54d54dc..4f629f0 100644 >> --- a/dlls/user32/button.c >> +++ b/dlls/user32/button.c >> @@ -197,7 +197,7 @@ static inline UINT get_button_type( LONG >> window_style ) >> /* paint a button of any type */ >> static inline void paint_button( HWND hwnd, LONG style, UINT action ) >> { >> - if (btnPaintFunc[style]&& IsWindowVisible(hwnd)) >> + if (style<= MAX_BTN_TYPE&& btnPaintFunc[style]&& >> IsWindowVisible(hwnd)) >> { >> HDC hdc = GetDC( hwnd ); >> btnPaintFunc[style]( hwnd, hdc, action ); > This needs a test to see what happens visually for style 0xf, maybe we > need just to duplicate an entry in paint function table; also while > you're at it: > > static inline UINT get_button_type( LONG window_style ) > { > return (window_style & 0x0f); > } > > here BS_TYPEMASK should be used instead of 0xf. > Ok ill do. Also it was a 3state checkbox not a radiobutton. Further i made a typo in my oneline patch :) But i am still not sure if we really should paint in that case (unless some peoble come up with "invisible checkboxes"), because in my case the dialog style was that "ms office 2007 style", so mfc or the app handled the paint. if we would have drawn something it would have make it worse. -- Best Regards, André Hentschel

Aug. 7, 2010

Re: [PATCH] quartz: implement AsyncReader_FindPin

by David Adam

Hi, what about if ppPin is NULL? I think that this patch needs test cases to prove that it is correct? David 2010/8/6 Anton Khirnov <wyskas(a)gmail.com> > --- > dlls/quartz/filesource.c | 32 ++++++++++++++++++++++++++++++-- > 1 files changed, 30 insertions(+), 2 deletions(-) > > diff --git a/dlls/quartz/filesource.c b/dlls/quartz/filesource.c > index 110415d..00a91c8 100644 > --- a/dlls/quartz/filesource.c > +++ b/dlls/quartz/filesource.c > @@ -548,9 +548,37 @@ static HRESULT WINAPI AsyncReader_EnumPins(IBaseFilter > * iface, IEnumPins **ppEn > > static HRESULT WINAPI AsyncReader_FindPin(IBaseFilter * iface, LPCWSTR Id, > IPin **ppPin) > { > - FIXME("(%s, %p)\n", debugstr_w(Id), ppPin); > + IEnumPins *enumpins; > + HRESULT hr; > > - return E_NOTIMPL; > + hr = AsyncReader_EnumPins(iface, &enumpins); > + if (FAILED(hr)) > + return S_FALSE; > + > + while (hr == S_OK) { > + IPin *pin; > + LPWSTR pinname; > + > + hr = IEnumPins_Next(enumpins, 1, &pin, NULL); > + if (FAILED(hr)) > + break; > + > + hr = IPin_QueryId(pin, &pinname); > + if (SUCCEEDED(hr)) { > + if (!strcmpW(pinname, Id)) { > + *ppPin = pin; > + IPin_AddRef(*ppPin); > + CoTaskMemFree(pinname); > + break; > + } > + CoTaskMemFree(pinname); > + } > + } > + > + IEnumPins_Release(enumpins); > + if (SUCCEEDED(hr)) > + return S_OK; > + return S_FALSE; > } > > static HRESULT WINAPI AsyncReader_QueryFilterInfo(IBaseFilter * iface, > FILTER_INFO *pInfo) > -- > 1.7.1 > > > >

Aug. 7, 2010

Wine 1.3 packaged for Ubuntu, must be installed explicitly

by Scott Ritchie

I have added a new series of Wine 1.3 packages to the Wine PPA: https://launchpad.net/~ubuntu-wine/+archive/ppa These are for 10.04 (Lucid) only and must be explicitly installed: sudo apt-get install wine1.3 Users who simply install the wine or wine1.2 packages (as in, all existing users) will instead get the stable Wine 1.2 release, which is still packaged there. Thanks, Scott Ritchie

Aug. 7, 2010

Configuring with -Werror

by Jerome Leclanche

Configuring with -Werror used to work a while back for me; now that -Wno-unused-result has been fixed I gave it another try and got this: configure: libxrandr 32-bit development files not found, XRandr won't be supported. configure: WARNING: Old Mesa headers detected. Consider upgrading your Mesa libraries. OpenGL and Direct3D won't be supported. configure: WARNING: No sound system was found. Windows applications will be silent. After a quick investigation, turns out many configure checks produce warnings; patch below hacks around it, but I've never dealt with configure before and apparently fixes need to go in configure.ac -- anyone wants to give it a proper shot? Jerome L. diff --git a/configure b/configure index 05a9317..ae29fe4 100755 --- a/configure ++ J. Leclanche / Adys+ b/configure @@ -8430,7 +8430,7 @@ int main () { static typeof(XRRSetScreenConfigAndRate) * func; - ; + if(func); return 0; } _ACEOF @@ -8685,7 +8685,7 @@ int main () { GLenum test = GL_UNSIGNED_SHORT_5_6_5; - ; + if(test); return 0; } _ACEOF @@ -10517,8 +10517,8 @@ if test "x$ac_cv_lib_asound_snd_pcm_hw_params_get_access" = x""yes; then : int main () { -int ret = snd_pcm_hw_params_get_access(NULL, NULL) - ; +int ret = snd_pcm_hw_params_get_access(NULL, NULL); + if(ret); return 0; } _ACEOF

Aug. 7, 2010

Re: Wine users with a CD-ROM drive, please test

by Erik Inge Bolsø

On Fri, 6 Aug 2010, Erik Inge Bolsø wrote: > No failures on my winxp laptop. No mixed cd handy, so only audio cd > tested. Though on the win7-64 desktop, I get the same failures as everyone else. mcicda.c:270: CD length 73:35:54 mcicda.c:325: track #1 length 35694ms mcicda.c:392: Tests skipped: Got no mixed data+audio CD. mcicda.c:410: last track length: 04m:25s:41frames mcicda.c:418: last track position: 69m:12s:13frames mcicda.c:425: Test failed: SEEK to 00362549 position last + length: MCIERR_HARDWARE mcicda.c:436: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:439: Tests skipped: Cannot manage to play track 1. mcicda: 64 tests executed (0 marked as todo, 2 failures), 2 skipped. Same cd. -- -erik http://useofwords.blogspot.com/

Aug. 6, 2010

Re: Wine users with a CD-ROM drive, please test

by Erik Inge Bolsø

No failures on my winxp laptop. No mixed cd handy, so only audio cd tested. mcicda.c:270: CD length 73:35:54 mcicda.c:325: track #1 length 35694ms mcicda.c:392: Tests skipped: Got no mixed data+audio CD. mcicda.c:410: last track length: 04m:25s:41frames mcicda.c:418: last track position: 69m:12s:13frames mcicda: 102 tests executed (0 marked as todo, 0 failures), 1 skipped. -- -erik http://useofwords.blogspot.com/

Aug. 6, 2010

Re: user32: Don't crash for unknown button styles

by Nikolay Sivov

On 8/6/2010 22:22, André Hentschel wrote: > got that case with an MFC application which had a 3state radiobutton with buttonstyle 15(decimal) > with this fix everything is fine as the painting of the button is handled elsewhere, without that fix it crashes as it reads bad data behind the array. > > --- > dlls/user32/button.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/user32/button.c b/dlls/user32/button.c > index 54d54dc..4f629f0 100644 > --- a/dlls/user32/button.c > +++ b/dlls/user32/button.c > @@ -197,7 +197,7 @@ static inline UINT get_button_type( LONG window_style ) > /* paint a button of any type */ > static inline void paint_button( HWND hwnd, LONG style, UINT action ) > { > - if (btnPaintFunc[style]&& IsWindowVisible(hwnd)) > + if (style<= MAX_BTN_TYPE&& btnPaintFunc[style]&& IsWindowVisible(hwnd)) > { > HDC hdc = GetDC( hwnd ); > btnPaintFunc[style]( hwnd, hdc, action ); This needs a test to see what happens visually for style 0xf, maybe we need just to duplicate an entry in paint function table; also while you're at it: static inline UINT get_button_type( LONG window_style ) { return (window_style & 0x0f); } here BS_TYPEMASK should be used instead of 0xf.

Aug. 6, 2010

Re: [PATCH 1/6] d3dx9_36/tests: Added HLSL test suite.

by Henri Verbeet

On 5 August 2010 00:05, Travis Athougies <iammisc(a)gmail.com> wrote: > +#define CINTERFACE Why do you need this? > +#include <d3d9.h> d3d9.h should be implied by d3dx9.h > +#include <assert.h> > +#include <stdio.h> I don't think you need these either. > +struct vertex > +{ > + float x, y, z; > + float tx, ty; > +}; > + > +const struct vertex quad_vertices[4] = { > + {-1, -1, 0, 0, 1}, > + {-1, 1, 0, 0, 0}, > + {1, -1, 0, 1, 1}, > + {1, 1, 0, 1, 0} > +}; Those aren't floating point values. Also, please use consistent formatting. > +const struct vertex quad_vertices[4] = { ... > +static IDirect3DVertexBuffer9 *quad_geometry; > +static IDirect3DVertexShader9 *vshader_passthru; > +static IDirect3DVertexDeclaration9 *vdeclaration; > +static IDirect3DDevice9 *device; Why is all of that global? > + hres = IDirect3D9_CreateDevice(d3d9_ptr, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, NULL, D3DCREATE_HARDWARE_VERTEXPROCESSING, &present_parameters, &device_ptr); Please break long lines. I realize this particular one is probably somehow my fault because I added it back in 2005 with c26ad82e75e408c302c21228ef08c1af0482326c, and everyone has been (blindly) copying it since, but there are other examples like setup_device() as well. Use 120 as maximum line length, 100 to be safe. > + hres = IDirect3DVertexBuffer9_Lock(quad_geometry, 0, sizeof(quad_vertices), (void**)&temp_geometry_vertices, 0); You don't need that cast. > + hres = D3DXCompileShader(vshader_passthru_hlsl, strlen(vshader_passthru_hlsl), > + NULL, NULL, "vshader", "vs_1_1", 0, > + &compiled, &errors, 0); > + if(FAILED(hres)) > + { > + vshader_passthru = NULL; That doesn't make sense, vshader_passthru is already NULL at that point. > + hr = D3DXCompileShader(shader, strlen(shader), > + NULL, NULL, "test", profile, > + 0, &compiled, &errors, constants); > + ok (hr == D3D_OK, "Pixel shader %s compilation failed: %s\n", shader, (char*) (errors?ID3DXBuffer_GetBufferPointer(errors):"")); This casts away const. > diff --git a/include/d3dx9shader.h b/include/d3dx9shader.h > index c8380bc..c54d27c 100644 > --- a/include/d3dx9shader.h > +++ b/include/d3dx9shader.h > @@ -296,6 +296,17 @@ HRESULT WINAPI D3DXAssembleShader(LPCSTR data, > LPD3DXBUFFER* shader, > LPD3DXBUFFER* error_messages); > > +HRESULT WINAPI D3DXCompileShader(LPCSTR src_data, > + UINT data_len, > + const D3DXMACRO* defines, > + LPD3DXINCLUDE include, > + LPCSTR function_name, > + LPCSTR profile, > + DWORD flags, > + LPD3DXBUFFER* shader, > + LPD3DXBUFFER* error_messages, > + LPD3DXCONSTANTTABLE* constant_table); > + This should be in a separate patch. The patch has some more issues, they shouldn't be hard to spot.

Aug. 6, 2010

Re: [PATCH 2/5] gameux: Add stub of IGameStatisticsMgr implementation (try 2)

by Mariusz Pluciński

W dniu 04.08.2010 20:45, Jerome Leclanche pisze: > Just resend this one, it's easier that way. > > > J. Leclanche / Adys > > > > 2010/8/3 Mariusz Pluciński<vshader(a)gmail.com>: >> W dniu 03.08.2010 13:28, Nikolay Sivov pisze: >>> >>> On 8/3/2010 13:58, Mariusz Pluciński wrote: >>>> >>>> --- >>>> dlls/gameux/Makefile.in | 1 + >>>> dlls/gameux/factory.c | 5 ++ >>>> dlls/gameux/gamestatistics.c | 153 >>>> ++++++++++++++++++++++++++++++++++++++++++ >>>> dlls/gameux/gameux_private.h | 1 + >>>> dlls/gameux/regsvr.c | 9 +++ >>>> 5 files changed, 169 insertions(+), 0 deletions(-) >>>> create mode 100644 dlls/gameux/gamestatistics.c >>>> + TRACE("(%p, %s, 0x%x, %p, %p)\n", iface, debugstr_w(GDFBinaryPath), >>>> openType, pOpenResult, ppiStats); >>>> + FIXME("stub\n"); >>>> + return E_NOTIMPL; >>> >>> No need for duplicated traces, add one FIXME with full parameter output >>> in it. >>> >> I hope my patches are acceptable despite of this. But in the future I'll >> avoid it, thanks. >> >> >> > You may be right. I'll do it, thanks.

Aug. 6, 2010

Re: The WineAPI wiki.

by Max TenEyck Woodbury

On 08/06/2010 05:44 AM, Francois Gouget wrote: > On Thu, 5 Aug 2010, Max TenEyck Woodbury wrote: > [...] >>> Here's roughly what I have in mind: >>> >>> 1. Win32 API >>> 1. Overview >>> 2. acledit API >>> 1. Overview >>> 2. Functions >>> 1. Func1 >>> 2. Func2 >>> ... >>> 3. Interfaces >>> 1. Interface 1 >>> 1. Method1 >>> 2. Method2 >>> ... >>> 2. Interface 2 >>> 1. Method1 >>> 2. Method2 >>> ... >>> 4. Datastructures >>> 1. Struct1 >>> 2. Struct2 >>> 3. Enum1 >>> ... >>> 3. aclui API >>> ... >>> 2. Standard Windows tools >>> 1. attrib command line options >>> 2. cacls command line options >>> ... >>> 3. General platform-specific notes >>> 1. Windows 9x >>> Talks about interaction with DOS, etc. >>> 2. Windows 95 >>> More Win 9x specific general notes >>> 3. Windows NT and greater >>> Kernel stuff >>> 4. Wine >>> 1. Wine architecture documentation >>> 2. Wine-specific dlls >>> 3. Wine-specific tools like winebuild, winemenubuilder, etc) >>> 5. Mingw >>> Stuff about Mingw, etc. >>> 6. ReactOS >>> Stuff about ReactOS, etc. >>> >> Ah! That is where the misunderstanding is. You are thinking of this as >> a *document*, a single coherent document. > > I am not thinking of this as a single document. Each of the above line > would be a separate wiki page. > > [...] >> Those names are what the scripts maintain. > > I'm not sure what there is to maintain. > I think we are almost in agreement. The problem is the numbers. The numbers *will* change as things evolve. Hopefully, the basic reference *names* will be fairly stable. There will also be indexes from different points of view and the indexes will have sub-pages that redirect to the appropriate basic page. Maintenance will consist of keeping those redirects up-do-date. >> The pages will also contain sub-pages. Those sub-pages are where the >> user-editable content are stored. > > Do you mean that the documentation for an API like CreateFile() would be > a collection of pages? That seems counterproductive to me. > >> There is also technical content. Such things as the names of the entry >> points, the return type, the number of parameters and their types. >> That information really should not be subject to debate. It is >> determined by the implementation. > > Well, yes. That's what Func1, Func2 are above. And on their pages you > would get the signature, general documentation of the function, > description of what each parameter is for, links to the pages describing > the types of the parameters if they're complex, what the function > returns, finer points about how the function behaves in corner cases if > appropriate, and platform-specific details about how it behaves. > >> That might be something the scripts can maintain, however I will leave >> that maintenance until later. > > However while it would be easy for scripts to create a skeleton page, > once the page exists and has been editied they may have a hard time > changing stuff like correcting the type of an output parameter. > > But I guess that's why you want to have sub pages I guess. Though I > really would not want to have to go through multiple pages for each of > the documentation aspects I mentioned above. > I believe I understand your concern. From observation it is not going to actually be a problem. The sub-pages are 'transcluded' into the base page. The sub-pages will contain the section headings and when you edit the section, you in fact edit the sub-page. There is a problem that you end up on the sub-page when you finish editing. I'll add a link back to the main article page, and that should make the problem smaller. >> I suspect that the meta-information will in fact have to be duplicated. >> It can be different for the different projects. For example Wine is >> similar to the Microsoft stuff at the file level. They each have DLLs >> with corresponding names. On the other hand, WinGW consists of a single >> DLL, if I understand its structure correctly. > > My mingw-runtime package has a lot of separate 'dlls': libaclui.a, > libadvapi32.a, libgdi32.a, etc. Besides, how does that matter? > CreateFile() is a kernel32 fnuction, no matter what, and the > documentation should reflect that. > OK, but they are called 'aclui' in the Wine repository, not 'libaclui.a'. I think each project will want to maintain seperate meta-structure sub-pages so we do not change something about another project's meta structure when we update our own meta-structure. >> There is complication here no matter how it is done. There is simply >> too much stuff to keep it really simple. Category markers should be >> used extensively. Redirection links will be needed to provide views >> from different perspectives without having to actually replicate >> articles. > > That's one of the things I don't like in msdn. Want do know what's the > API provided by a given dll? Good luck with that because they seem bent > on hiding that kind of information. > > I think we should really have per-dll documentation and the general > articles about 'how to do sound', 'what COM is' should be in a separate > section. Otherwise your documentation of CoCreateInstance() is going to > keep moving from OLE to COM to DCOM and to whatever today's fashionable > marketing term is. > Yes, that is along the lines I planned on. The 'how to's would not be 'managed', but there would be indexes and redirects for each 'API' to the place where the documentation is. In particular, there should be a 'Category:API' sorted alphabetically with links to the correct page. If a 'how to' wants to link to a particular API, it would link to the sub-page of the API index and that would redirect to the actual page. This does require planning and I am glad it is being discussed now, before things become too embedded to change. - Max

Aug. 6, 2010

Re: Wine users with a CD-ROM drive, please test

by Matijn Woudt

Test results from Windows 7 x64: I tried with original audio CD, and a burned copy, mcicda_test.exe and mcicda_test64.exe, and they all give: mcicda.c:270: CD length 46:20:53 mcicda.c:325: track #1 length 118107ms mcicda.c:392: Tests skipped: Got no mixed data+audio CD. mcicda.c:410: last track length: 04m:15s:37frames mcicda.c:418: last track position: 42m:07s:16frames mcicda.c:425: Test failed: SEEK to 0035162E position last + length: MCIERR_HARDWARE mcicda.c:436: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:439: Tests skipped: Cannot manage to play track 1. mcicda: 64 tests executed (0 marked as todo, 2 failures), 2 skipped. > David c/o paulo lesgaz wrote: >>mcicda.c:425: Test failed: SEEK to 00203A43 position last + length: MCIERR_HARDWARE >>mcicda.c:436: Test failed: PLAY from 1 notify: MCIERR_HARDWARE > Same as Jeff, please see if one of you can identify which prior MCI command causes this. Do you have any instructions how I can identify this?

Aug. 6, 2010

Wine users with a CD-ROM drive, please test

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, David c/o paulo lesgaz wrote: >mcicda.c:425: Test failed: SEEK to 00203A43 position last + length: MCIERR_HARDWARE >mcicda.c:436: Test failed: PLAY from 1 notify: MCIERR_HARDWARE Same as Jeff, please see if one of you can identify which prior MCI command causes this. >mcicda.c:275: Test failed: status position initially 00:02:33 >mcicda.c:280: Test failed: status position start 00:02:33 Interesting, thank you. Will change the tests. I once read there must be a 2 second gap but it seems it need not be exactly 2 seconds. Greg Geldorp wrote: >I can attach a .iso to each VM and run your tests. Would that help? AFAIK, a .iso contains a data CD only, not music tracks. If that's right, then it would not be very interesting, as data-only CDs are already skipped. >Keep in mind that almost none of the VMs have sound support. Thanks for reminding me to temporarily disable sound on a native system and see how that changes test results. From what I remember, disabling sound in the preferences (XP then wants to reboot) achieved the same results as sound-less machines in the MCI tests. Regards, Jörg Höhle

Aug. 6, 2010

Re: Wine users with a CD-ROM drive, please test

by Greg Geldorp

> From: <Joerg-Cyril.Hoehle(a)t-systems.com> > > this is my second call for participation, as only Jeff Zaroyko responded to the first one. > > I wrote a testsuite for mcicda (play music from CD-ROM using the MCI). > Wine's testbot job #4330 at > https://testbot.winehq.org/JobDetails.pl?Key=4330 > contains both a patch and binary of what I'd initially want to test about mcida.dll, > solely lacking compatibility fixes that testing on YOUR machine will show to be necessary. I can attach a .iso to each VM and run your tests. Would that help? Keep in mind that almost none of the VMs have sound support. Ge.

Aug. 6, 2010

Re : Wine users with a CD-ROM drive, please test

by paulo lesgaz

Here is my result on a real Vista box using the CD: Police -Greatest hits mcicda.c:270: CD length 67:55:74 mcicda.c:275: Test failed: status position initially 00:02:33 mcicda.c:280: Test failed: status position start 00:02:33 mcicda.c:314: Test failed: status position initially 2441ms mcicda.c:325: track #1 length 192667ms mcicda.c:392: Tests skipped: Got no mixed data+audio CD. mcicda.c:410: last track length: 04m:12s:27frames mcicda.c:418: last track position: 63m:46s:05frames mcicda.c:425: Test failed: SEEK to 00203A43 position last + length: MCIERR_HARDWARE mcicda.c:436: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:439: Tests skipped: Cannot manage to play track 1. mcicda: 64 tests executed (0 marked as todo, 5 failures), 2 skipped. David ________________________________ De : "Joerg-Cyril.Hoehle(a)t-systems.com" <Joerg-Cyril.Hoehle(a)t-systems.com> À : wine-devel(a)winehq.org Envoyé le : Ven 6 août 2010, 11h 24min 55s Objet : Wine users with a CD-ROM drive, please test Hi, this is my second call for participation, as only Jeff Zaroyko responded to the first one. I wrote a testsuite for mcicda (play music from CD-ROM using the MCI). Wine's testbot job #4330 at https://testbot.winehq.org/JobDetails.pl?Key=4330 contains both a patch and binary of what I'd initially want to test about mcida.dll, solely lacking compatibility fixes that testing on YOUR machine will show to be necessary. Please download the executable or compile the patch and execute it in MS-Windows: mcicda_test.exe mcicda mcicda.c:270: CD length 69:23:66 mcicda.c:325: track #1 length 989547ms mcicda.c:375: track #1 length: 16m:29s:41frames mcicda.c:410: last track length: 03m:28s:19frames mcicda.c:418: last track position: 65m:57s:47frames mcicda: 112 tests executed (0 marked as todo, 0 failures), 0 skipped. BTW, I wrote patches to make all these tests succeed in Wine. Before submission, I'd appreciate some more test data. Thank you for your participation, Jörg Höhle

Aug. 6, 2010

Wine users with a CD-ROM drive, please test

by Joerg-Cyril.Hoehle＠t-systems.com

Jeff Zaroyko wrote: >Blank CD: >mcicda.c:252: Test failed: info upc: MCIERR_HARDWARE >mcicda.c:255: Test failed: info identity: MCIERR_HARDWARE >mcicda.c:263: Test failed: STATUS number of tracks: MCIERR_HARDWARE >mcicda.c:266: Test failed: number of tracks=0 I'll select an appropriate test based on Linux (and MacOS) results in Wine and add a skip. >mcicda.c:425: Test failed: SEEK to 003B0436 position last + length: MCIERR_HARDWARE >mcicda.c:436: Test failed: PLAY from 1 notify: MCIERR_HARDWARE I believe both errors have the same origin. Here you really need to find out what command in the testsuite causes the seek&play tests to fail with MCIERR_HARDWARE since you said you could play music using MCI commands typed into the shell. Why can't the testsuite? Luckily, almost all mciSendCommand can be converted to an equivalent string form. Sadly, I have no clue what command may influence this -- perhaps MCI_RESUME? >It's composed of two "sessions" That'll make for an interesting testcase once we get rid of the above MCIERR_HARDWARE issue. Thank you again, Jörg Höhle

Aug. 6, 2010

Re: Wine users with a CD-ROM drive, please test

by Jeff Zaroyko

On Fri, Aug 6, 2010 at 7:24 PM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Hi, > > this is my second call for participation, as only Jeff Zaroyko responded to the first one. > > I wrote a testsuite for mcicda (play music from CD-ROM using the MCI). > Wine's testbot job #4330 at > https://testbot.winehq.org/JobDetails.pl?Key=4330 > contains both a patch and binary of what I'd initially want to test about mcida.dll, > solely lacking compatibility fixes that testing on YOUR machine will show to be necessary. > > Please download the executable or compile the patch and execute it in MS-Windows: Take #2. I had a look at the CD I claimed was data+audio with a CDBurnerXP. It's composed of two "sessions" one with audio tracks and the second session is composed of only a data track. C:\Users\jeffz\Desktop>mcicda_test.exe mcicda.c:270: CD length 54:02:59 mcicda.c:325: track #1 length 76134ms mcicda.c:392: Tests skipped: Got no mixed data+audio CD. mcicda.c:410: last track length: 04m:37s:09frames mcicda.c:418: last track position: 49m:27s:50frames mcicda.c:425: Test failed: SEEK to 003B0436 position last + length: MCIERR_HARDWARE mcicda.c:436: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:439: Tests skipped: Cannot manage to play track 1. mcicda: 64 tests executed (0 marked as todo, 2 failures), 2 skipped. For comparison, I checked Jedi Knight: Dark Forces II CD1, it is shown to have one session with a data track followed by audio tracks: C:\Users\jeffz\Desktop>wintest.exe mcishell mci.c:178: Type your commands to the MCI, end with Ctrl-Z/^D open cdaudio alias c mci.c:188: command: open cdaudio alias c mci.c:193: Response: 1 status c type track 1 mci.c:188: command: status c type track 1 mci.c:193: Response: other status c type track 2 mci.c:188: command: status c type track 2 mci.c:193: Response: audio C:\Users\jeffz\Desktop>mcicda_test.exe mcicda.c:270: CD length 69:42:40 mcicda.c:325: track #1 length 3022801ms mcicda.c:375: track #1 length: 50m:22s:60frames mcicda.c:410: last track length: 02m:10s:50frames mcicda.c:418: last track position: 67m:33s:65frames mcicda.c:425: Test failed: SEEK to 00282C45 position last + length: MCIERR_HARDWARE mcicda.c:436: Test failed: PLAY from 8 notify: MCIERR_HARDWARE mcicda.c:439: Tests skipped: Cannot manage to play track 8. mcicda: 74 tests executed (0 marked as todo, 2 failures), 1 skipped. And for the same cd as used earlier with only audio: C:\Users\jeffz\Desktop>mcicda_test.exe mcicda.c:270: CD length 24:53:74 mcicda.c:325: track #1 length 252067ms mcicda.c:392: Tests skipped: Got no mixed data+audio CD. mcicda.c:410: last track length: 04m:54s:52frames mcicda.c:418: last track position: 20m:01s:22frames mcicda.c:425: Test failed: SEEK to 004A3718 position last + length: MCIERR_HARDWARE mcicda.c:436: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:439: Tests skipped: Cannot manage to play track 1. mcicda: 64 tests executed (0 marked as todo, 2 failures), 2 skipped. Blank CD: C:\Users\jeffz\Desktop>mcicda_test.exe mcicda.c:252: Test failed: info upc: MCIERR_HARDWARE mcicda.c:255: Test failed: info identity: MCIERR_HARDWARE mcicda.c:263: Test failed: STATUS number of tracks: MCIERR_HARDWARE mcicda.c:266: Test failed: number of tracks=0 mcicda.c:269: Test failed: status length: MCIERR_HARDWARE mcicda.c:274: Test failed: status position: MCIERR_HARDWARE mcicda.c:279: Test failed: status position start: MCIERR_HARDWARE mcicda.c:288: Test failed: play 02 to 01: MCIERR_HARDWARE mcicda.c:295: Test failed: seek to noflag: MCIERR_HARDWARE mcicda.c:298: Test failed: seek to start+end: MCIERR_HARDWARE mcicda.c:302: Test failed: seek to start: MCIERR_HARDWARE mcicda.c:313: Test failed: status position start (ms): MCIERR_HARDWAR mcicda.c:323: Test failed: status length (ms): MCIERR_HARDWARE mcicda.c:339: Test failed: STATUS type track 1: MCIERR_HARDWARE mcicda.c:340: Test failed: unknown track type feedabad mcicda.c:397: Tests skipped: Found no audio track. mcicda: 53 tests executed (0 marked as todo, 15 failures), 1 skipped. A DVD: C:\Users\jeffz\Desktop>mcicda_test.exe mcicda.c:229: Tests skipped: CD-ROM mode not ready mcicda: 21 tests executed (0 marked as todo, 0 failures), 1 skipped Jeff

Aug. 6, 2010

Re: The WineAPI wiki.

by Francois Gouget

On Thu, 5 Aug 2010, Max TenEyck Woodbury wrote: [...] > > Here's roughly what I have in mind: > > > > 1. Win32 API > > 1. Overview > > 2. acledit API > > 1. Overview > > 2. Functions > > 1. Func1 > > 2. Func2 > > ... > > 3. Interfaces > > 1. Interface 1 > > 1. Method1 > > 2. Method2 > > ... > > 2. Interface 2 > > 1. Method1 > > 2. Method2 > > ... > > 4. Datastructures > > 1. Struct1 > > 2. Struct2 > > 3. Enum1 > > ... > > 3. aclui API > > ... > > 2. Standard Windows tools > > 1. attrib command line options > > 2. cacls command line options > > ... > > 3. General platform-specific notes > > 1. Windows 9x > > Talks about interaction with DOS, etc. > > 2. Windows 95 > > More Win 9x specific general notes > > 3. Windows NT and greater > > Kernel stuff > > 4. Wine > > 1. Wine architecture documentation > > 2. Wine-specific dlls > > 3. Wine-specific tools like winebuild, winemenubuilder, etc) > > 5. Mingw > > Stuff about Mingw, etc. > > 6. ReactOS > > Stuff about ReactOS, etc. > > > Ah! That is where the misunderstanding is. You are thinking of this as > a *document*, a single coherent document. I am not thinking of this as a single document. Each of the above line would be a separate wiki page. [...] > Those names are what the scripts maintain. I'm not sure what there is to maintain. > The pages will also contain sub-pages. Those sub-pages are where the > user-editable content are stored. Do you mean that the documentation for an API like CreateFile() would be a collection of pages? That seems counterproductive to me. > There is also technical content. Such things as the names of the entry > points, the return type, the number of parameters and their types. > That information really should not be subject to debate. It is > determined by the implementation. Well, yes. That's what Func1, Func2 are above. And on their pages you would get the signature, general documentation of the function, description of what each parameter is for, links to the pages describing the types of the parameters if they're complex, what the function returns, finer points about how the function behaves in corner cases if appropriate, and platform-specific details about how it behaves. > That might be something the scripts can maintain, however I will leave > that maintenance until later. However while it would be easy for scripts to create a skeleton page, once the page exists and has been editied they may have a hard time changing stuff like correcting the type of an output parameter. But I guess that's why you want to have sub pages I guess. Though I really would not want to have to go through multiple pages for each of the documentation aspects I mentioned above. > I suspect that the meta-information will in fact have to be duplicated. > It can be different for the different projects. For example Wine is > similar to the Microsoft stuff at the file level. They each have DLLs > with corresponding names. On the other hand, WinGW consists of a single > DLL, if I understand its structure correctly. My mingw-runtime package has a lot of separate 'dlls': libaclui.a, libadvapi32.a, libgdi32.a, etc. Besides, how does that matter? CreateFile() is a kernel32 fnuction, no matter what, and the documentation should reflect that. [...] > There is complication here no matter how it is done. There is simply > too much stuff to keep it really simple. Category markers should be > used extensively. Redirection links will be needed to provide views > from different perspectives without having to actually replicate > articles. That's one of the things I don't like in msdn. Want do know what's the API provided by a given dll? Good luck with that because they seem bent on hiding that kind of information. I think we should really have per-dll documentation and the general articles about 'how to do sound', 'what COM is' should be in a separate section. Otherwise your documentation of CoCreateInstance() is going to keep moving from OLE to COM to DCOM and to whatever today's fashionable marketing term is. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilisé par les informaticiens en lieu et place d'"idiot".

Aug. 6, 2010

Wine users with a CD-ROM drive, please test

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, this is my second call for participation, as only Jeff Zaroyko responded to the first one. I wrote a testsuite for mcicda (play music from CD-ROM using the MCI). Wine's testbot job #4330 at https://testbot.winehq.org/JobDetails.pl?Key=4330 contains both a patch and binary of what I'd initially want to test about mcida.dll, solely lacking compatibility fixes that testing on YOUR machine will show to be necessary. Please download the executable or compile the patch and execute it in MS-Windows: mcicda_test.exe mcicda mcicda.c:270: CD length 69:23:66 mcicda.c:325: track #1 length 989547ms mcicda.c:375: track #1 length: 16m:29s:41frames mcicda.c:410: last track length: 03m:28s:19frames mcicda.c:418: last track position: 65m:57s:47frames mcicda: 112 tests executed (0 marked as todo, 0 failures), 0 skipped. BTW, I wrote patches to make all these tests succeed in Wine. Before submission, I'd appreciate some more test data. Thank you for your participation, Jörg Höhle

Aug. 6, 2010

Re: wiki slightly broken still?

by Damjan Jovanovic

On Tue, Aug 3, 2010 at 4:18 PM, David Gerard <dgerard(a)gmail.com> wrote: > [to list as well] > > On 3 August 2010 15:07, Dimi Paun <dimi(a)lattica.com> wrote: >> On Tue, 2010-08-03 at 14:30 +0200, Alexandru Băluț wrote: > >>> How difficult would it be to use ReCaptcha? >>> http://www.google.com/recaptcha > >> Hm, don't know. We could hack our version to support recaptcha, >> but I'm not familiar with the code base, and I don't have the >> time right now. But I can take patches if someone is willing >> to do it. > > > The MoinMoin developers consider TextCHA inherently superior and so > have no interest in writing a reCaptcha interface: > > http://moinmo.in/FeatureRequests/ReCaptcha > > (Note also the problems people have had with TextCHA: it becomes too > much work to write the questions and to answer the questions.) > > If someone wants reCaptcha in MoinMoin, it appears they will need to > write it all themselves. > > > - d. > > > reCaptcha has essentially been cracked now (http://it.slashdot.org/story/10/08/05/2054247/ReCAPTCHAnet-Now-Vulnerable-t…) so I'm not sure it's worth using it in the wiki. Damjan Jovanovic

Aug. 6, 2010

Re: CD-ROM ioctl support on MacOS?

by Charles Davis

On 8/5/10 9:16 AM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > what's the state of CD-ROM support on the Mac? > ntdll/cdrom.c contains quite a few #ifdef apple. I was the last one to hack on that, so I'll bite. > > I'm asking because the mcicda currently uses these ioctl: > 1. READ_RAW That's implemented. I implemented it myself in 6368dbbd5939bf71b04f3c441dd3af8cd027b7fb. > 2. READ_TOC AJ implemented that in e6ce0da2f99cc8c249a453489b9b199bec1fe435. > 3. READ_Q -> POSITION That might never be implemented. Like I said earlier, the IOCDAudioControl user client was removed in Mac OS X 10.4. I might be able to implement this using a direct SCSI call, though. Come to think of it, I might also be able to extend my experimental BSD client to support this. > > MCICDA could be changed to avoid the third one entirely > -- when using the dsound output. Would that > be enough to use mcicda on MacOS to play music? That might work. > > Thanks for your help, No problem. Chip

Aug. 5, 2010

Re: The WineAPI wiki.

by Max TenEyck Woodbury

On 08/05/2010 03:56 AM, Francois Gouget wrote: > On Wed, 4 Aug 2010, Max TenEyck Woodbury wrote: > [...] >> There several things that have to be coordinated however: >> >> - This is not just the API documentation. It includes a great deal of >> information about the meta-structure of the Wine project. Easy access >> to that meta-information might be one of the more useful aspects of >> this sub-project. > > I suspect some of that information is already present in the Wine > Developer's Guide, in particular the section 'II. Wine Architecture': > > http://www.winehq.org/docs/winedev-guide/index > > So there is the issue of where to put this information: in the developer > guide, in the win32 api wiki or in a separate wiki. Even if it's in the > win32 api wiki I think it could be set slightly apart. > > Here's roughly what I have in mind: > > 1. Win32 API > 1. Overview > 2. acledit API > 1. Overview > 2. Functions > 1. Func1 > 2. Func2 > ... > 3. Interfaces > 1. Interface 1 > 1. Method1 > 2. Method2 > ... > 2. Interface 2 > 1. Method1 > 2. Method2 > ... > 4. Datastructures > 1. Struct1 > 2. Struct2 > 3. Enum1 > ... > 3. aclui API > ... > 2. Standard Windows tools > 1. attrib command line options > 2. cacls command line options > ... > 3. General platform-specific notes > 1. Windows 9x > Talks about interaction with DOS, etc. > 2. Windows 95 > More Win 9x specific general notes > 3. Windows NT and greater > Kernel stuff > 4. Wine > 1. Wine architecture documentation > 2. Wine-specific dlls > 3. Wine-specific tools like winebuild, winemenubuilder, etc) > 5. Mingw > Stuff about Mingw, etc. > 6. ReactOS > Stuff about ReactOS, etc. > Ah! That is where the misunderstanding is. You are thinking of this as a *document*, a single coherent document. That is not quite what this is. It is a collection of *pages*. Each page has a distinct name. Those names are what the scripts maintain. The pages will also contain sub-pages. Those sub-pages are where the user-editable content are stored. Once those sub-pages are created, the scripts will not touch them. (That answers the question in my original post by the way.) There is also technical content. Such things as the names of the entry points, the return type, the number of parameters and their types. That information really should not be subject to debate. It is determined by the implementation. That might be something the scripts can maintain, however I will leave that maintenance until later. >> - The detailed information is, at least initially, coming out of the >> Wine code. It is being generated using scripts. The scripts are very >> likely to be rerun when a file in the Wine repository changes. It may >> take a lot of effort to merge the new information with information >> from other sources. > > No matter what, if such a wiki is meant to be edited directly you won't > be able to merge in data through scripts very long. It will soon have to > stand on its own. > You had better be wrong on this particular point. If you are in fact correct, it will be impossible to keep the technical information and structural information intact. I believe the descriptive and technical information can be put on seperate pages and sub-pages. The project is still in the planning and experimental phase. The details are in the process of being worked out. >> - If the licenses are compatible, it should be possible to copy >> articles between projects. > > Yes, licensing is an important issue and one you must solve before > accepting outside contributions. > > To incorportate data from the Wine source it must be LGPL-compatible > (e.g. GPL). To incorporate data from the Mingw or ReactOS source it must > be compatible with their license (GPL?). > > Even if copying articles from one project to another is technically > legal, I think you cannot count on this as a means to avoid massive > duplication of effort: as soon as you have over a hundred articles (once > fully sutbbed out you should have way over 30000) the work involved for > watching changes on each side and merging duplicate documentation will > be overwhelming (and I suspect finding volunteers for it will be hard > too). > Whether the information comes out of the Wine code or other code, there could be problems. But that is not where most of the value of this project will lie. It will be in the descriptive information that does not come out of the code. It will be the material the individual contributers add. I suspect that the meta-information will in fact have to be duplicated. It can be different for the different projects. For example Wine is similar to the Microsoft stuff at the file level. They each have DLLs with corresponding names. On the other hand, WinGW consists of a single DLL, if I understand its structure correctly. But building up the meta-structure is much less difficult than creating the descriptions. I hope the descriptive information can be shared. >> Also, the page tree structure is based on >> the structure of the Wine repository. > > The wiki should have its own structure, independent from Wine and > anything else. I would also argue that the simpler it is, the less > likely it is to change. > There is complication here no matter how it is done. There is simply too much stuff to keep it really simple. Category markers should be used extensively. Redirection links will be needed to provide views from different perspectives without having to actually replicate articles. The one thing that should not be done is impose a single person's opinion of how it must be done on everybody else. On the other hand, someone has to start this thing. - Max

Aug. 5, 2010

Re: Please report mcicda (CDROM audio) test results

by Robert Kim Wireless Internet Advisor

Guys... I just started looking into developing for the ipad... am i going to have the same issues? I know, i know.. i'm a newbie with objective c. lemme know... On Thu, Aug 5, 2010 at 8:14 AM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Jeff, > >>if I: >>> resume c # yields MCIERR_HARDWARE >>nothing printed > This is not compatible with the test that does not report failure on your system: > + err = mciSendString("resume c", buf, sizeof(buf), hwnd); > + ok(err == MCIERR_HARDWARE, "resume without play: %s\n", dbg_mcierr(err)); /* not NONAPPLICABLE_FUNCTION */ > Does any of the previous commands provoke this difference? > >>> play from <1_or_last_track> notify > Oops > play c from 1 notify > play c from 1 to 2 > play c to 12 > play c from 12 > >>It stopped accepting input, any letters, return were all blocked - >>nothing except ^C. > Works for me. > >>Every track is listed as audio, meanwhile I see the drive with >>included programs etc is mapped in explorer. > This is behaviour unseen on the w95, w2k and wxp machines > that I had access to, with my mixed data+audio CD. > > Your machine's behaviour is mystery to me. Is mcicdda that unreliable??? > > Regards, > Jörg Höhle > > -- Robert Q Kim 2611 S Coast Highway San Diego, CA 92007 310 598 1606 My Latest Blog Post: http://sparkah.com/2010/07/29/experienced-iphone-app-developer-los-angeles-…

Aug. 5, 2010

CD-ROM ioctl support on MacOS?

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, what's the state of CD-ROM support on the Mac? ntdll/cdrom.c contains quite a few #ifdef apple. I'm asking because the mcicda currently uses these ioctl: 1. READ_RAW 2. READ_TOC 3. READ_Q -> POSITION MCICDA could be changed to avoid the third one entirely -- when using the dsound output. Would that be enough to use mcicda on MacOS to play music? Thanks for your help, Jörg Höhle

Aug. 5, 2010

Please report mcicda (CDROM audio) test results

by Joerg-Cyril.Hoehle＠t-systems.com

Jeff, >if I: >> resume c # yields MCIERR_HARDWARE >nothing printed This is not compatible with the test that does not report failure on your system: + err = mciSendString("resume c", buf, sizeof(buf), hwnd); + ok(err == MCIERR_HARDWARE, "resume without play: %s\n", dbg_mcierr(err)); /* not NONAPPLICABLE_FUNCTION */ Does any of the previous commands provoke this difference? >> play from <1_or_last_track> notify Oops play c from 1 notify play c from 1 to 2 play c to 12 play c from 12 >It stopped accepting input, any letters, return were all blocked - >nothing except ^C. Works for me. >Every track is listed as audio, meanwhile I see the drive with >included programs etc is mapped in explorer. This is behaviour unseen on the w95, w2k and wxp machines that I had access to, with my mixed data+audio CD. Your machine's behaviour is mystery to me. Is mcicdda that unreliable??? Regards, Jörg Höhle

Aug. 5, 2010

Re: Please report mcicda (CDROM audio) test results

by Jeff Zaroyko

On Thu, Aug 5, 2010 at 11:51 PM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Hi, > >> Things you can try out using the interactive MCI shell: >> open cdaudio alias c >> status c type track 1 >> set c time format tmsf >> seek c to start >> play c from 1 to 2 wait >>This works - I hear music. > What the test does is not fundamentally different. I'd > appreciate if you could isolate the part that causes havoc. > if I: open cdaudio alias c status c type track 1 # Response: audio (the same for tracks 1-12, 13 is out of range - only 12 tracks on cd) seek c to start > status c position mci.c:188: command: status c position mci.c:193: Response: 00:02:00 > resume c # yields MCIERR_HARDWARE nothing printed > seek c to start notify mci.c:188: command: seek c to start notify mci.c:167: Notification type 0001 > status c type track 1 mci.c:188: command: status c type track 1 mci.c:193: Response: audio > set c time format tmsf no response > play from <1_or_last_track> notify play from 1 notify mci.c:188: command: play from 1 notify mci.c:191: Test failed: mci play from 1 notify error: 300(44 MCIERR_NOTIFY_ON_AUTO_OPEN) > >> waiting a minute, it hasn't returned to accepting input >>here, so I've ^C. > Really? Wait never failed on me. > Did you perhaps get confused because no prompt ever > appears? Just hit return to get MCIERR_MISSING_COMMAND_STRING. It stopped accepting input, any letters, return were all blocked - nothing except ^C. I tested it again, same thing happened. > >>The data+audio cd as previously used: >>mcicda.c:372: Tests skipped: Got no mixed data+audio CD. > The source code led me to believe that data tracks always come > first. Perhaps that's a broken assumption. What's the response to: > status c type track 1 > status c type track 2 > status c type track ... until the last one? > I'd expect > Other [typically 1 single data track] > Audio [for track 2..n] Every track is listed as audio, meanwhile I see the drive with included programs etc is mapped in explorer. > Thank you, > Jörg.

Aug. 5, 2010

Please report mcicda (CDROM audio) test results

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, > Things you can try out using the interactive MCI shell: > open cdaudio alias c > status c type track 1 > set c time format tmsf > seek c to start > play c from 1 to 2 wait >This works - I hear music. What the test does is not fundamentally different. I'd appreciate if you could isolate the part that causes havoc. status c position resume c # yields MCIERR_HARDWARE seek c to start notify status c type track 1 set c time format tmsf play from <1_or_last_track> notify > waiting a minute, it hasn't returned to accepting input >here, so I've ^C. Really? Wait never failed on me. Did you perhaps get confused because no prompt ever appears? Just hit return to get MCIERR_MISSING_COMMAND_STRING. >The data+audio cd as previously used: >mcicda.c:372: Tests skipped: Got no mixed data+audio CD. The source code led me to believe that data tracks always come first. Perhaps that's a broken assumption. What's the response to: status c type track 1 status c type track 2 status c type track ... until the last one? I'd expect Other [typically 1 single data track] Audio [for track 2..n] Thank you, Jörg.

Aug. 5, 2010

Re: [PATCH 5/6] d3dx9_36/tests: Added trigonometric functions test to HLSL test suite

by Octavian Voicu

On Thu, Aug 5, 2010 at 3:58 PM, Joris Huizer <joris_huizer(a)yahoo.com> wrote: > In this patch, you have this code: > > + void *ret = NULL; > //... > + ret = HeapAlloc(GetProcessHeap(), 0, 4 * samples); > + for(i = 0;i < 32;i++) { > //... > + memcpy((void*) (((DWORD) ret) + (4 * i)), lr.pBits, 4); > //... > + } > > I'm not sure, but I think this will cause 64-bit issues (truncating to a 32-bit value?) > Even if it doesn't, it seems simpler (more readable) to use a char pointer instead of a void pointer, like > > + char *ret; > //... > + ret = HeapAlloc(GetProcessHeap(), 0, 4 * samples); > //... > + memcpy(ret + (4 * i), lr.pBits, 4); Or just use a DWORD pointer: + DWORD *ret; //... + ret = HeapAlloc(GetProcessHeap(), 0, 4 * samples); + for(i = 0;i < 32;i++) { //... + ret[i] = lr.pBits; //... + }

Aug. 5, 2010

[PATCH 5/6] d3dx9_36/tests: Added trigonometric functions test to HLSL test suite

by Joris Huizer

Hello Travis Athougies, In this patch, you have this code: + void *ret = NULL; //... + ret = HeapAlloc(GetProcessHeap(), 0, 4 * samples); + for(i = 0;i < 32;i++) { //... + memcpy((void*) (((DWORD) ret) + (4 * i)), lr.pBits, 4); //... + } I'm not sure, but I think this will cause 64-bit issues (truncating to a 32-bit value?) Even if it doesn't, it seems simpler (more readable) to use a char pointer instead of a void pointer, like + char *ret; //... + ret = HeapAlloc(GetProcessHeap(), 0, 4 * samples); //... + memcpy(ret + (4 * i), lr.pBits, 4); HTH, regards, Joris

Aug. 5, 2010

Re: Please report mcicda (CDROM audio) test results

by Jeff Zaroyko

On Thu, Aug 5, 2010 at 6:39 PM, <Joerg-Cyril.Hoehle(a)t-systems.com> > Hi, > > Jeff Zaroyko wrote: >>mcicda.c:355: Test failed: PLAY from 1 notify: MCIERR_HARDWARE >>mcicda: 90 tests executed (0 marked as todo, 14 failures), 0 skipped. > > All failures are explained by your drive's inability to play any piece > of music from the CD in your system. PLAY fails, causing other tests to fail. > Why you'll have to investigate. > Did that machine ever play music from an audio CD? Yes, VLC plays from an audio CD without issue, in addition it also works with Jedi Knight: Dark Forces II demo, which plays cd music (despite there being no audio cd for the demo). > An updated patch with one new bug is at > https://testbot.winehq.org/JobDetails.pl?Key=4314 > mcicda.c:181: Test failed: GETDEVCAPS 4001: MCIERR_UNSUPPORTED_FUNCTION > I've added a skip when PLAY returns an error. > Native MCICDA does not perform a lot of error checking, e.g. > "status c current track" returns 1 when there's no disk in drive. The data+audio cd as previously used: mcicda.c:181: Test failed: GETDEVCAPS 4001: MCIERR_UNSUPPORTED_FUNCTION mcicda.c:243: Test failed: info 2flags: 0=NOERROR mcicda.c:307: track #1 length 76134ms mcicda.c:372: Tests skipped: Got no mixed data+audio CD. mcicda.c:389: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:392: Tests skipped: Cannot manage to play track 1. mcicda: 57 tests executed (0 marked as todo, 3 failures), 2 skipped. The same audio cd as used previously which has audio only: mcicda.c:181: Test failed: GETDEVCAPS 4001: MCIERR_UNSUPPORTED_FUNCTION mcicda.c:243: Test failed: info 2flags: 0=NOERROR mcicda.c:307: track #1 length 252067ms mcicda.c:372: Tests skipped: Got no mixed data+audio CD. mcicda.c:389: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:392: Tests skipped: Cannot manage to play track 1. mcicda: 57 tests executed (0 marked as todo, 3 failures), 2 skipped. Indeed, the tests don't produce any audio. > Things you can try out using the interactive MCI shell: > open cdaudio alias c > status c type track 1 > set c time format tmsf > seek c to start > play c from 1 to 2 wait This works - I hear music. After playing the first track to completion and waiting a minute, it hasn't returned to accepting input here, so I've ^C. > play c from 10 to 11 wait > seek c to 3 > play c > close c > That's not unlike how apps use mcicda. > > Regards, > Jörg.

Aug. 5, 2010

Please report mcicda (CDROM audio) test results

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Jeff Zaroyko wrote: >mcicda.c:355: Test failed: PLAY from 1 notify: MCIERR_HARDWARE >mcicda: 90 tests executed (0 marked as todo, 14 failures), 0 skipped. All failures are explained by your drive's inability to play any piece of music from the CD in your system. PLAY fails, causing other tests to fail. Why you'll have to investigate. Did that machine ever play music from an audio CD? An updated patch with one new bug is at https://testbot.winehq.org/JobDetails.pl?Key=4314 mcicda.c:181: Test failed: GETDEVCAPS 4001: MCIERR_UNSUPPORTED_FUNCTION I've added a skip when PLAY returns an error. Native MCICDA does not perform a lot of error checking, e.g. "status c current track" returns 1 when there's no disk in drive. Things you can try out using the interactive MCI shell: open cdaudio alias c status c type track 1 set c time format tmsf seek c to start play c from 1 to 2 wait play c from 10 to 11 wait seek c to 3 play c close c That's not unlike how apps use mcicda. Regards, Jörg.

Aug. 5, 2010

Re: The WineAPI wiki.

by Francois Gouget

On Wed, 4 Aug 2010, Max TenEyck Woodbury wrote: [...] > There several things that have to be coordinated however: > > - This is not just the API documentation. It includes a great deal of > information about the meta-structure of the Wine project. Easy access > to that meta-information might be one of the more useful aspects of > this sub-project. I suspect some of that information is already present in the Wine Developer's Guide, in particular the section 'II. Wine Architecture': http://www.winehq.org/docs/winedev-guide/index So there the issue of where to put this information: in the developper guide, in the win32 api wiki or in a separate wiki. Even if it's in the win32 api wiki I think it could be set slightly apart. Here's roughly what I have in mind: 1. Win32 API 1. Overview 2. acledit API 1. Overview 2. Functions 1. Func1 2. Func2 ... 3. Interfaces 1. Interface 1 1. Method1 2. Method2 ... 2. Interface 2 1. Method1 2. Method2 ... 4. Datastructures 1. Struct1 2. Struct2 3. Enum1 ... 3. aclui API ... 2. Standard Windows tools 1. attrib command line options 2. cacls command line options ... 3. General platform-specific notes 1. Windows 9x Talks about interaction with DOS, etc. 2. Windows 95 More Win 9x specific general notes 3. Windows NT and greater Kernel stuff 4. Wine 1. Wine architecture documentation 2. Wine-specific dlls 3. Wine-specific tools like winebuild, winemenubuilder, etc) 5. Mingw Stuff about Mingw, etc. 6. ReactOS Stuff about ReactOS, etc. > - The detailed information is, at least initially, coming out of the > Wine code. It is being generated using scripts. The scripts are very > likely to be rerun when a file in the Wine repository changes. It may > take a lot of effort to merge the new information with information > from other sources. No matter what, if such a wiki is meant to be edited directly you won't be able to merge in data through scripts very long. It will soon have to stand on its own. > - If the licenses are compatible, it should be possible to copy > articles between projects. Yes, licensing is an important issue and one you must solve before accepting outside contributions. To incorportate data from the Wine source it must be LGPL-compatible (e.g. GPL). To incorporate data from the Mingw or ReactOS source it must be compatible with their license (GPL?). Even if copying articles from one project to another is technically legal, I think you cannot count on this as a means to avoid massive duplication of effort: as soon as you have over a hundred articles (once fully sutbbed out you should have way over 30000) the work involved for watching changes on each side and merging duplicate documentation will be overwhelming (and I suspect finding volunteers for it will be hard too). > Also, the page tree structure is based on > the structure of the Wine repository. The wiki should have its own structure, independent from Wine and anything else. I would also argue that the simpler it is, the less likely it is to change. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.

Aug. 5, 2010

Re: GDB debugging on ARM

by Dylan Smith

2010/8/4 André Hentschel <nerv(a)dawncrow.de> > Hi, > what is the best/easiest/fastest way to hack Wine so it does not start > winedbg and i can debug it with gdb? > my problem is that my WineARM works so far that it tries to run winedbg and > uses its own handlers. but i want that not to happen > of course it crashes somewhere and then tries to start winedbg... but > winedbg is not really implemented yet on arm and its not yet time for it. i > just want to debug on assembler level with gdb... > "winedbg --gdb" is also not what i want. > > So my understanding is that Wine somewhere register its exception handlers, > but i cant find that code to disable it. Anyone? > > > winedbg is set as the debugger in the registry: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug Auto=1 Debugger="winedbg --auto %ld %ld" You should be able to disable it by setting the value Auto=0, or you could change the Debugger to use gdb.

Aug. 4, 2010

Re: [PATCH 07/10] ddraw: Allow creating back buffer for DirectX 1 interfaces. (try 3)

by Oldřich Jedlička

On Wednesday 04 August 2010 10:10:17 Stefan Dösinger wrote: > Am 03.08.2010 um 21:26 schrieb Oldřich Jedlička: > > DirectX 1 interface allowed creation of explicit back buffers, so move > > the restrictive checks to DirectX 2+ implementations. Don't permit > > creating of primary surface back buffer. > > The patch(as well as 9 and 10) look OK to me. Patch 6 is OK too. > > Patch 8 is missing a call to wined3d to tell it about the new backbuffer. > (Apps will likely still work with the GDI renderer, but not the opengl > ddraw renderer) That is not so easy as it looks. I've tried to play with that, but there are some difficulties and I don't have time to investigate them deeper: 1. To be able to call IWineD3DDevice_SetFrontBackBuffers, the backbuffer has to be created with Usage |= WINED3DUSAGE_RENDERTARGET (ddraw.c, method ddraw_create_surface). No problem here (if I ignore the fact that I don't know what the rendertarget really means). 2. The IWineD3DDevice_SetFrontBackBuffers call in surface.c, method ddraw_surface_attach_surface, has to use the right ordering of arguments. Afterwards I had problems with freeing some surface (page fault). 3. The method GetAttachedSurface needs fixing for flipping too - it doesn't return the right surface sometimes. When I modified the method, I got other failures/crashes with d3d tests. >From my point of view it would be better to have the flipping for backbuffers unsupported for now - until somebody with more understanding of internals has a better look. I'm not the right person now. The flipping tests are the right ones to start. The changes from the patch doesn't add the full support, but it doesn't add more failures and it doesn't crash (which is much better than results from my playing this evening). Thanks. Oldřich.

Aug. 4, 2010

Re: The WineAPI wiki.

by Max TenEyck Woodbury

On 08/04/2010 03:15 PM, Francois Gouget wrote: > On Mon, 2 Aug 2010, Max TenEyck Woodbury wrote: > [...] >> This has been discussed elsewhere on this mailing list. >> >> There is a lot of information specific to Wine, particularly its >> internal structure, that is not shared with Microsoft's product. >> Further, there is a little confusing and incorrect information in the >> Microsoft documentation. Bluntly, the Microsoft documentation is what >> they want it to be. We need to document what it really is. > > I think such documentation should be open to all projects involved in > the Win32 space such as Mingw, React OS, as well as Windows software > developpers whenever they are irritated by an MSDN deficiency. > > Sure there will be differences between how each project implements a > given API, just like there are differences between the Windows 98, 2000 > or Vista implementations. But I expect most of the documentation to be > common to all so that the best approach would be to describe the > reference behavior and then have notes describing the platform-specific > differences. > > However calling the Wiki 'WineAPI' is not very welcoming to other > contributors and it would be a shame if each project ended up > duplicating this huge effort just because of a naming issue. > That is a very good point! There several things that have to be coordinated however: - This is not just the API documentation. It includes a great deal of information about the meta-structure of the Wine project. Easy access to that meta-information might be one of the more useful aspects of this sub-project. - The detailed information is, at least initially, coming out of the Wine code. It is being generated using scripts. The scripts are very likely to be rerun when a file in the Wine repository changes. It may take a lot of effort to merge the new information with information from other sources. - If the licenses are compatible, it should be possible to copy articles between projects. Also, the page tree structure is based on the structure of the Wine repository. Since the Wine repository structure is fairly stable, (new parts are added fairly often, but once a piece is in place for a while, it usually stays where it is. I could definitely be wrong about this!) links into the WineAPI wiki should also be stable. - Max

Aug. 4, 2010

Re: The WineAPI wiki.

by Francois Gouget

On Mon, 2 Aug 2010, Max TenEyck Woodbury wrote: [...] > > You have chosen not very good name. There is no such a thing as Wine API, > > Wine implements Win32 API, and doesn't specify/add anything custom to it. > > The name "WineAPI" implies that Wine defines its own API which is not true, > > and is confusing. > > > This has been discussed elsewhere on this mailing list. > > There is a lot of information specific to Wine, particularly its > internal structure, that is not shared with Microsoft's product. > Further, there is a little confusing and incorrect information in the > Microsoft documentation. Bluntly, the Microsoft documentation is what > they want it to be. We need to document what it really is. I think such documentation should be open to all projects involved in the Win32 space such as Mingw, React OS, as well as Windows software developpers whenever they are irritated by an MSDN deficiency. Sure there will be differences between how each project implements a given API, just like there are differences between the Windows 98, 2000 or Vista implementations. But I expect most of the documentation to be common to all so that the best approach would be to describe the reference behavior and then have notes describing the platform-specific differences. However calling the Wiki 'WineAPI' is not very welcoming to other contributors and it would be a shame if each project ended up duplicating this huge effort just because of a naming issue. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.

Aug. 4, 2010

Re: [PATCH 2/5] gameux: Add stub of IGameStatisticsMgr implementation (try 2)

by Jerome Leclanche

Just resend this one, it's easier that way. J. Leclanche / Adys 2010/8/3 Mariusz Pluciński <vshader(a)gmail.com>: > W dniu 03.08.2010 13:28, Nikolay Sivov pisze: >> >> On 8/3/2010 13:58, Mariusz Pluciński wrote: >>> >>> --- >>> dlls/gameux/Makefile.in | 1 + >>> dlls/gameux/factory.c | 5 ++ >>> dlls/gameux/gamestatistics.c | 153 >>> ++++++++++++++++++++++++++++++++++++++++++ >>> dlls/gameux/gameux_private.h | 1 + >>> dlls/gameux/regsvr.c | 9 +++ >>> 5 files changed, 169 insertions(+), 0 deletions(-) >>> create mode 100644 dlls/gameux/gamestatistics.c >>> + TRACE("(%p, %s, 0x%x, %p, %p)\n", iface, debugstr_w(GDFBinaryPath), >>> openType, pOpenResult, ppiStats); >>> + FIXME("stub\n"); >>> + return E_NOTIMPL; >> >> No need for duplicated traces, add one FIXME with full parameter output >> in it. >> > I hope my patches are acceptable despite of this. But in the future I'll > avoid it, thanks. > > >

Aug. 4, 2010

Vacation

by Alexandre Julliard

Folks, I'll be on vacation until the end of next week, so there won't be any commits for a while. That shouldn't prevent anybody from making progress, as we have seen during the recent code freeze ;-) The next release will be on Friday 20th. -- Alexandre Julliard julliard(a)winehq.org

Aug. 4, 2010

Re: [PATCH 03/10] ddraw/tests: Add test for NULL/bad size of surface caps in CreateSurface. (try 3)

by GOUJON Alexandre

On 08/04/2010 12:29 PM, Alexandre Julliard wrote: > You can't use Wine exception macros in tests. > I guess my patch [1] was rejected for the same reason but then how to handle it ? The test only crashes on NT4 but is needed because some programs use a NULL descriptor [2] I'm not allowed to check the windows version the test is currently running on. And I can't use __TRY on tests. Any idea how I could handle that case ? --- [1] : http://source.winehq.org/patches/data/64667 [2] : relevant +relay log 001f:Call advapi32.GetNamedSecurityInfoA(0064e3bc "C:\\Program Files\\Typing Pal 5\\Games",00000001,00000004,00000000,00000000,0064e3a4,00000000,00000000) ret=1 00013c8 001f:Ret advapi32.GetNamedSecurityInfoA() retval=00000057 ret=100013c8 001f:Call KERNEL32.GetLastError() ret=100013d2 001f:Ret KERNEL32.GetLastError() retval=00000578 ret=100013d2 001f:Call shlwapi.wvnsprintfA(0064df54,00000400,100023e8 "Cannot read access control list.\r\nError code: %d",0064e36c) ret=100010dc 001f:Ret shlwapi.wvnsprintfA() retval=00000032 ret=100010dc 001f:Call user32.MessageBoxA(00010064,0064df54 "Cannot read access control list.\r\nError code: 1400",00000000,00040010) ret=100010f6

Aug. 4, 2010

Re: shdocvw: Add the Polish translation

by Jacek Caban

On 8/4/10 5:45 PM, Łukasz Wojniłowicz wrote: > From: Lukasz Wojnilowicz<Wojnilowicz(a)localhost.localdomain> > > --- > dlls/shdocvw/Makefile.in | 1 + > dlls/shdocvw/Pl.rc | 57 ++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 58 insertions(+), 0 deletions(-) > create mode 100644 dlls/shdocvw/Pl.rc > > diff --git a/dlls/shdocvw/Makefile.in b/dlls/shdocvw/Makefile.in > index 9e2d8e1..f43e02e 100644 > --- a/dlls/shdocvw/Makefile.in > +++ b/dlls/shdocvw/Makefile.in > @@ -35,6 +35,7 @@ RC_SRCS = \ > Ko.rc \ > Lt.rc \ > Nl.rc \ > + Pl.rc \ > Ro.rc \ > Sv.rc \ > Uk.rc \ > diff --git a/dlls/shdocvw/Pl.rc b/dlls/shdocvw/Pl.rc > new file mode 100644 > index 0000000..1dd735b > --- /dev/null > +++ b/dlls/shdocvw/Pl.rc > @@ -0,0 +1,57 @@ > +/* > + * Copyright 2010 �ukasz Wojni�owicz > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +#include "resource.h" > + > +LANGUAGE LANG_POLISH, SUBLANG_DEFAULT > + > +IDD_BROWSE_OPEN DIALOG 10, 10, 200, 70 > +STYLE DS_MODALFRAME | WS_CAPTION > +CAPTION "Otw�rz URL" > +FONT 8, "MS Shell Dlg" > +{ > + LTEXT "Podaj adres URL, kt�ry chcesz otworzy� w Internet Explorer",-1,25, 5, 150,15 It should be "(...) Internet Explorerze". > + LTEXT "Otw�rz:", -1, 2, 32, 20, 15 > + EDITTEXT IDC_BROWSE_OPEN_URL, 25, 30, 160, 13 > + DEFPUSHBUTTON "&OK", IDOK, 25, 50, 50, 15 > + PUSHBUTTON "&Anuluj", IDCANCEL, 85, 50, 50, 15 > +} > + > +IDR_BROWSE_MAIN_MENU MENU > +{ > + POPUP "&Plik" > + { > + POPUP "&Nowe" > + { > + MENUITEM "&Okno" ID_BROWSE_NEW_WINDOW > + } > + MENUITEM "&Otw�rz...", ID_BROWSE_OPEN > + MENUITEM "&Zapisz", ID_BROWSE_SAVE > + MENUITEM "Zapisz&jako...", ID_BROWSE_SAVE_AS > + MENUITEM SEPARATOR > + MENUITEM "Wydrukuj&format...", ID_BROWSE_PRINT_FORMAT It should be "Format wydruku". > + MENUITEM "&Drukuj...", ID_BROWSE_PRINT > + MENUITEM "Wydrukuj&podgl�d...", ID_BROWSE_PRINT_PREVIEW It should be "Podglad wydruku". Please be more careful about translations. ID_BROWSE_PRINT_FORMAT and ID_BROWSE_PRINT_PREVIEW are fairly obvious mistakes. Jacek

Aug. 4, 2010

Re: shdocvw: Add the Polish translation

by Paul Vriens

Hi Łukasz, On 08/04/2010 05:45 PM, Łukasz Wojniłowicz wrote: > +CAPTION "Otw�rz URL" This file needs the UTF-8 pragma. -- Cheers, Paul.

Aug. 4, 2010

RE: WineTestBot and D3D

by Greg Geldorp

> From: Stefan Doesinger > > Greg's testbot looks pretty useful by now, but for me it has one major > problem: It cannot run D3D tests because it is stuck in a virtual machine. > > I understand that the core of Winetestbot will stay in VMs, but is there a > way we can extend it with extra machines? I have a few spare boxes with > different GPUs here that could be used to run the tests. What I need is > basically: > > *) Some magic patchwatcher software I can install on these boxes > *) A Server this software talks to to get patch jobs and report the results > back. > *) Depending on the load, configure my machines to run d3d-related tests only > and leave others to the VMs. > > Now I guess it is important that if one of those extra test boxes dies(e.g. I > turn off my computers when I am away for a while) that this doesn't break the > testbot as a whole because it is waiting for test results. For starters I think > security is not that much of an issue, as long as I can firewall the machine > (via my router) and prevent it from connecting to anything but the testbot > master. > > Does the Testbot infrastructure allow this? Currently, no, it doesn't. But it certainly seems something that can be added. I'll investigate a bit what it will take. Ge.

Aug. 4, 2010

GDB debugging on ARM

by André Hentschel

Hi, what is the best/easiest/fastest way to hack Wine so it does not start winedbg and i can debug it with gdb? my problem is that my WineARM works so far that it tries to run winedbg and uses its own handlers. but i want that not to happen of course it crashes somewhere and then tries to start winedbg... but winedbg is not really implemented yet on arm and its not yet time for it. i just want to debug on assembler level with gdb... "winedbg --gdb" is also not what i want. So my understanding is that Wine somewhere register its exception handlers, but i cant find that code to disable it. Anyone? -- Best Regards, André Hentschel

Aug. 4, 2010

Please report mcicda (CDROM audio) test results

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Jeff Zaroyko wrote: >> mcicda: 98 tests executed (0 marked as todo, 2 failures), 0 skipped. >With a dual mode cd which has a data and audio tracks: >mcicda: 90 tests executed (0 marked as todo, 14 failures), 0 skipped. >Tried a different cd with audio tracks only: >mcicda: 90 tests executed (0 marked as todo, 15 failures), 0 skipped. Strange, a mixed CD should have executed more tests, like my sample result. I'll add a skip when only audio tracks are found. The only way to have 0 skips flagged would then to use a mixed data + audio CD like you initially did. However those are rare. Thank you for your feedback. That gives me food to digest later. At a first glance, it looks like nothing was ever played. Octavian Voicu wrote: >> I noticed the midi notes playing, didn't think much of it. >That's nothing, some tests record whatever comes via the microphone >then play it back. Might be scary if you forget about the tests :) That comment really had me ROTFL. It's also me who wrote those tests - recording, midi, mcicda :-) I don't have a microphone. Regards, Jörg Höhle

Aug. 4, 2010

Re: [PATCH 1/2] ntdll: Implement RtlIpv4AddressToString / RtlIpv4AddressToStringEx

by Alexandre Julliard

Detlef Riekenberg <wine.dev(a)web.de> writes: > @@ -37,8 +37,12 @@ > #include "winternl.h" > #include "wine/debug.h" > #include "wine/exception.h" > +#include "wine/unicode.h" > #include "ntdll_misc.h" > > +#include "winsock2.h" You don't want to include winsock2.h here. -- Alexandre Julliard julliard(a)winehq.org

Aug. 4, 2010

WineTestBot and D3D

by Stefan Dösinger

Hi, Greg's testbot looks pretty useful by now, but for me it has one major problem: It cannot run D3D tests because it is stuck in a virtual machine. I understand that the core of Winetestbot will stay in VMs, but is there a way we can extend it with extra machines? I have a few spare boxes with different GPUs here that could be used to run the tests. What I need is basically: *) Some magic patchwatcher software I can install on these boxes *) A Server this software talks to to get patch jobs and report the results back. *) Depending on the load, configure my machines to run d3d-related tests only and leave others to the VMs. Now I guess it is important that if one of those extra test boxes dies(e.g. I turn off my computers when I am away for a while) that this doesn't break the testbot as a whole because it is waiting for test results. For starters I think security is not that much of an issue, as long as I can firewall the machine(via my router) and prevent it from connecting to anything but the testbot master. Does the Testbot infrastructure allow this? Cheers, Stefan

Aug. 4, 2010

Re: [PATCH 2/2 (resend)] shell32: Also compare UNIX realpaths in SHChangeNotify

by Andrew Eikum

On 08/04/2010 08:50 AM, Alexandre Julliard wrote: > Andrew Eikum<aeikum(a)codeweavers.com> writes: > >> User calls SHChangeNotifyRegister with a PIDL like "[Desktop][C:]". >> The shell (or whatever) calls SHChangeNotify with a PIDL in the UNIX >> filesystem, like "[Desktop][/][home][user][.wine][drive_c]". These >> should result in a match and the window being notified, but instead >> the comparison fails. > > Is this the way it works on Windows? If you access the same file > through two different drives, do they both get notified? > Nope I guess it doesn't. Back to the drawing board. I think the tests from [1/2] should still be good, though. Andrew

Aug. 4, 2010

Re: [PATCH 2/2 (resend)] shell32: Also compare UNIX realpaths in SHChangeNotify

by Alexandre Julliard

Andrew Eikum <aeikum(a)codeweavers.com> writes: > User calls SHChangeNotifyRegister with a PIDL like "[Desktop][C:]". > The shell (or whatever) calls SHChangeNotify with a PIDL in the UNIX > filesystem, like "[Desktop][/][home][user][.wine][drive_c]". These > should result in a match and the window being notified, but instead > the comparison fails. Is this the way it works on Windows? If you access the same file through two different drives, do they both get notified? -- Alexandre Julliard julliard(a)winehq.org

Aug. 4, 2010

Re: Please report mcicda (CDROM audio) test results

by Octavian Voicu

On Wed, Aug 4, 2010 at 4:27 PM, Jeff Zaroyko <jeffzaroyko(a)gmail.com> wrote: > I noticed the midi notes playing, didn't think much of it. That's nothing, some tests record whatever comes via the microphone then play it back. Might be scary if you forget about the tests :) Octavian

Aug. 4, 2010

Re: [PATCH 3/4] jscript: Fixed Error.toString implementation for non-Error this.

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=4288 Your paranoid android. === W98SE (32 bit) === No test summary line found === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found

Aug. 4, 2010

Re: Please report mcicda (CDROM audio) test results

by Jeff Zaroyko

On Wed, Aug 4, 2010 at 10:36 PM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Hi, > > Wine's testbt job #4280 > http://testbot.winehq.org/JobDetails.pl?Key=4280 > contains both a patch and a binary for new MCICDA=MCI CD-audio tests. > > It already contains most of what I want in the initial release but > would benefit from testing on a broad range of native MS systems. > Please invoke it as: mcicda_test.exe mcicda > (it generates many failures on Wine but I already wrote several > patches to fix them.) > > Some failures are still possible as there are a few rough edges, e.g. > mcicda.c:222: Test failed: info upc: 0=NOERROR > mcicda.c:322: Test failed: PLAY data to 00291d10: MCIERR_OUTOFRANGE > mcicda: 98 tests executed (0 marked as todo, 2 failures), 0 skipped. > > It skips tests if > - there's no disk in drive; > - there are no audio tracks; > Untested: blank RW disk > > Questions: > - Is this patch right in mcicda/tests/ or should it be part of winmm/tests/? > - Which kind of tests should I restrict to WINETEST_INTERACTIVE mode only? > People may start to complain in the near future that running the Wine > testsuite starts spinning their CD-ROM and even play music. > (like somebody observed that the MIDI testsuite plays a few notes). > I noticed the midi notes playing, didn't think much of it. Vista 32bit SP2: With a dual mode cd which has a data and audio tracks: C:\Users\jeffz\Desktop>mcicda_test.exe mcicda.c:288: track #1 length 76134ms mcicda.c:355: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:361: Test failed: status mode during play is stopped mcicda.c:367: Waiting for delayed notification from pause should abort notification mcicda.c:367: Test failed: Expect message 0004 from pause should abort notification mcicda.c:381: Test failed: PLAY without parms: MCIERR_HARDWARE mcicda.c:390: Test failed: status mode after play is stopped mcicda.c:400: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:406: Test failed: SEEK to 1 notify: MCIERR_HARDWARE mcicda.c:413: Waiting for delayed notification from SEEK aborts mcicda.c:413: Test failed: Expect message 0004 from SEEK aborts mcicda.c:419: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:434: Test failed: got 0001 instead of MCI_NOTIFY_xyz 0002 from command dangling from PLAY mcicda.c:435: Waiting for delayed notification from status mode mcicda.c:435: Test failed: Expect message 0001 from status mode mcicda.c:447: last track length: 04m37s029f mcicda.c:455: Test failed: PLAY (TMSF) from 0000000c to 0925040c: MCIERR_HARDWARE mcicda.c:461: Test failed: status current track gave 1, expected 12 mcicda.c:466: Waiting for delayed notification from STOP notify mcicda.c:466: Test failed: Expect message 0004 from STOP notify mcicda: 90 tests executed (0 marked as todo, 14 failures), 0 skipped. (Ran it twice, 14 failures each time). Tried a different cd with audio tracks only: C:\Users\jeffz\Desktop>mcicda_test.exe mcicda.c:222: Test failed: info upc: 0=NOERROR mcicda.c:288: track #1 length 252067ms mcicda.c:355: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:361: Test failed: status mode during play is stopped mcicda.c:367: Waiting for delayed notification from pause should abort notification mcicda.c:367: Test failed: Expect message 0004 from pause should abort notification mcicda.c:381: Test failed: PLAY without parms: MCIERR_HARDWARE mcicda.c:390: Test failed: status mode after play is stopped mcicda.c:400: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:406: Test failed: SEEK to 1 notify: MCIERR_HARDWARE mcicda.c:413: Waiting for delayed notification from SEEK aborts mcicda.c:413: Test failed: Expect message 0004 from SEEK aborts mcicda.c:419: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:434: Test failed: got 0001 instead of MCI_NOTIFY_xyz 0002 from command dangling from PLAY mcicda.c:435: Waiting for delayed notification from status mode mcicda.c:435: Test failed: Expect message 0001 from status mode mcicda.c:447: last track length: 04m54s0252f mcicda.c:455: Test failed: PLAY (TMSF) from 00000005 to 34360405: MCIERR_HARDWARE mcicda.c:461: Test failed: status current track gave 1, expected 5 mcicda.c:466: Waiting for delayed notification from STOP notify mcicda.c:466: Test failed: Expect message 0004 from STOP notify mcicda: 90 tests executed (0 marked as todo, 15 failures), 0 skipped. (again, 15 failures with a repeated run).

Aug. 4, 2010

Re: [PATCH 2/2 (resend)] shell32: Also compare UNIX realpaths in SHChangeNotify

by Andrew Eikum

On 08/04/2010 05:24 AM, Alexandre Julliard wrote: > Andrew Eikum<aeikum(a)codeweavers.com> writes: > >> This fixes bug 18606. >> >> It's possible to refer to the same file in two different ways with PIDLs >> in Wine. This can cause notifications via SHChangeNotify to fail to >> trigger. To ensure an apples-to-apples comparison, we convert the >> incoming PIDLs and the filters to UNIX paths and compare those if the >> PIDLs fail to match. > > You should never compare Unix paths. If you want to compare file > identity you should use stat and compare device+inode. Makes sense. > But it's not > clear to me that this is the right thing to do here, what is the exact > case that is failing? User calls SHChangeNotifyRegister with a PIDL like "[Desktop][C:]". The shell (or whatever) calls SHChangeNotify with a PIDL in the UNIX filesystem, like "[Desktop][/][home][user][.wine][drive_c]". These should result in a match and the window being notified, but instead the comparison fails. Andrew

Aug. 4, 2010

Please report mcicda (CDROM audio) test results

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Wine's testbt job #4280 http://testbot.winehq.org/JobDetails.pl?Key=4280 contains both a patch and a binary for new MCICDA=MCI CD-audio tests. It already contains most of what I want in the initial release but would benefit from testing on a broad range of native MS systems. Please invoke it as: mcicda_test.exe mcicda (it generates many failures on Wine but I already wrote several patches to fix them.) Some failures are still possible as there are a few rough edges, e.g. mcicda.c:222: Test failed: info upc: 0=NOERROR mcicda.c:322: Test failed: PLAY data to 00291d10: MCIERR_OUTOFRANGE mcicda: 98 tests executed (0 marked as todo, 2 failures), 0 skipped. It skips tests if - there's no disk in drive; - there are no audio tracks; Untested: blank RW disk Questions: - Is this patch right in mcicda/tests/ or should it be part of winmm/tests/? - Which kind of tests should I restrict to WINETEST_INTERACTIVE mode only? People may start to complain in the near future that running the Wine testsuite starts spinning their CD-ROM and even play music. (like somebody observed that the MIDI testsuite plays a few notes). Thank you for your contributions, Jörg Höhle

Aug. 4, 2010

Re: user32: Protect from setting as a window owner one of window's succesors.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > <testbot(a)testbot.winehq.org> (Marvin) wrote: > >> === W98SE (32 bit win) === >> win.c:110: Test failed: Wrong result for GWL_HWNDPARENT 0000076C expected 00000000 >> win.c:114: Test failed: Wrong result for GW_OWNER 0000076C expected 00000000 >> win.c:388: Test failed: GWL_HWNDPARENT return value 0000076C expected 0 > > This test existed before my patch, probably it was failing before as well. I don't think so. -- Alexandre Julliard julliard(a)winehq.org

Aug. 4, 2010

Re: Re: [PATCH 03/10] ddraw/tests: Add test for NULL/bad size of surface caps in CreateSurface. (try 3)

by Oldrich Jedlicka

Hi Stefan, 4.8.2010 13:04:43, Stefan Dösinger <stefandoesinger(a)gmx.at>: > > Am 04.08.2010 um 12:29 schrieb Alexandre Julliard: > > > Oldřich Jedlička <oldium.pro(a)seznam.cz> writes: > > > >> + __TRY > >> + { > >> + hr = IDirectDraw_CreateSurface(lpDD, NULL, &surf, NULL); > >> + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface > didn't return 0x%08x, but 0x%08x\n", > >> + DDERR_INVALIDPARAMS, hr); > >> + } > >> + __EXCEPT_PAGE_FAULT > >> + { > >> + todo_wine ok(FALSE, "IDirectDraw_CreateSurface dereferenced NULL > pointer\n"); > >> + } > >> + __ENDTRY > > > > You can't use Wine exception macros in tests. > In this case it is better not to include the NULL pointer tests in this patch > and add them in the patch that adds the NULL pointer checks in ddraw. Ok, otherwise there would be a page fault in the test, which is not good. I will send updated patchset in the evening. Oldřich. > @Alexandre: I didn't know about that either, otherwise I'd have caught it when > looking at the patch.

Aug. 4, 2010

Re: user32: Protect from setting as a window owner one of window's succesors.

by Dmitry Timoshkov

<testbot(a)testbot.winehq.org> (Marvin) wrote: > === W98SE (32 bit win) === > win.c:110: Test failed: Wrong result for GWL_HWNDPARENT 0000076C expected 00000000 > win.c:114: Test failed: Wrong result for GW_OWNER 0000076C expected 00000000 > win.c:388: Test failed: GWL_HWNDPARENT return value 0000076C expected 0 This test existed before my patch, probably it was failing before as well. > === W7PRO (32 bit win) === > win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 006E01AE fg 00030050 in hook HCBT_SETFOCUS > win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 007001AE fg 00030050 in hook HCBT_SETFOCUS > win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000501A0 fg 00030050 in hook HCBT_SETFOCUS > win.c:2668: Test failed: GetActiveWindow() = 00000000 > win.c:2668: Test failed: GetFocus() = 00000000 > win.c:2694: Test failed: GetActiveWindow() = 00000000 > win.c:2694: Test failed: GetFocus() = 00000000 ... These are unrelated to the new test, and look like a usual set of intermittent win.c failures. -- Dmitry.

Aug. 4, 2010

Re: user32: Protect from setting as a window owner one of window's succesors.

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=4287 Your paranoid android. === W98SE (32 bit win) === win.c:110: Test failed: Wrong result for GWL_HWNDPARENT 0000076C expected 00000000 win.c:114: Test failed: Wrong result for GW_OWNER 0000076C expected 00000000 win.c:388: Test failed: GWL_HWNDPARENT return value 0000076C expected 0 === W7PRO (32 bit win) === win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 006E01AE fg 00030050 in hook HCBT_SETFOCUS win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 007001AE fg 00030050 in hook HCBT_SETFOCUS win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000501A0 fg 00030050 in hook HCBT_SETFOCUS win.c:2668: Test failed: GetActiveWindow() = 00000000 win.c:2668: Test failed: GetFocus() = 00000000 win.c:2694: Test failed: GetActiveWindow() = 00000000 win.c:2694: Test failed: GetFocus() = 00000000 win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000601A0 fg 00030050 in hook HCBT_SETFOCUS win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000501A2 fg 00030050 in hook HCBT_SETFOCUS win.c:2753: Test failed: GetActiveWindow() = 00000000 win.c:2753: Test failed: GetFocus() = 00000000 win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000C016C fg 00030050 in hook HCBT_SETFOCUS win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 002E01A2 fg 00030050 in hook HCBT_SETFOCUS win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 002F01A2 fg 00030050 in hook HCBT_SETFOCUS win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000401A4 fg 00030050 in hook HCBT_SETFOCUS win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000801A4 fg 00030050 in hook HCBT_SETFOCUS win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000901A4 fg 00030050 in hook HCBT_SETFOCUS win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 001801A0 fg 00030050 in hook HCBT_SETFOCUS win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000401A8 fg 00030050 in hook HCBT_SETFOCUS win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000C016C fg 00030050 in hook HCBT_SETFOCUS

Aug. 4, 2010

Re: [PATCH 03/10] ddraw/tests: Add test for NULL/bad size of surface caps in CreateSurface. (try 3)

by Stefan Dösinger

Am 04.08.2010 um 12:29 schrieb Alexandre Julliard: > Oldřich Jedlička <oldium.pro(a)seznam.cz> writes: > >> + __TRY >> + { >> + hr = IDirectDraw_CreateSurface(lpDD, NULL, &surf, NULL); >> + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface didn't return 0x%08x, but 0x%08x\n", >> + DDERR_INVALIDPARAMS, hr); >> + } >> + __EXCEPT_PAGE_FAULT >> + { >> + todo_wine ok(FALSE, "IDirectDraw_CreateSurface dereferenced NULL pointer\n"); >> + } >> + __ENDTRY > > You can't use Wine exception macros in tests. In this case it is better not to include the NULL pointer tests in this patch and add them in the patch that adds the NULL pointer checks in ddraw. @Alexandre: I didn't know about that either, otherwise I'd have caught it when looking at the patch.

Aug. 4, 2010

Re: [PATCH] kernel32/tests: Try harder to crash in the debugger test.

by Octavian Voicu

Please ignore this patch. It seems that it does crash all the time, just that sometimes the debugger won't kick in on win64. There is a bug but it's somewhere else. Octavian

Aug. 4, 2010

Re: [PATCH 03/10] ddraw/tests: Add test for NULL/bad size of surface caps in CreateSurface. (try 3)

by Alexandre Julliard

Oldřich Jedlička <oldium.pro(a)seznam.cz> writes: > + __TRY > + { > + hr = IDirectDraw_CreateSurface(lpDD, NULL, &surf, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface didn't return 0x%08x, but 0x%08x\n", > + DDERR_INVALIDPARAMS, hr); > + } > + __EXCEPT_PAGE_FAULT > + { > + todo_wine ok(FALSE, "IDirectDraw_CreateSurface dereferenced NULL pointer\n"); > + } > + __ENDTRY You can't use Wine exception macros in tests. -- Alexandre Julliard julliard(a)winehq.org

Aug. 4, 2010

Re: [PATCH 2/2 (resend)] shell32: Also compare UNIX realpaths in SHChangeNotify

by Alexandre Julliard

Andrew Eikum <aeikum(a)codeweavers.com> writes: > This fixes bug 18606. > > It's possible to refer to the same file in two different ways with PIDLs > in Wine. This can cause notifications via SHChangeNotify to fail to > trigger. To ensure an apples-to-apples comparison, we convert the > incoming PIDLs and the filters to UNIX paths and compare those if the > PIDLs fail to match. You should never compare Unix paths. If you want to compare file identity you should use stat and compare device+inode. But it's not clear to me that this is the right thing to do here, what is the exact case that is failing? -- Alexandre Julliard julliard(a)winehq.org

Aug. 4, 2010

Re: shdocvw: Update Italian translation

by Austin English

On Wed, Aug 4, 2010 at 3:17 PM, Luca Bennati <lucak3(a)gmail.com> wrote: Please send patches to wine-patches(a)winehq.org, they are not picked up here. Thanks! -- -Austin

Aug. 4, 2010

Re: d3dx9_36/tests: Added HLSL test suite. (try 3)

by Henri Verbeet

On 3 August 2010 21:07, Travis Athougies <iammisc(a)gmail.com> wrote: > dlls/d3dx9_36/tests/Makefile.in | 1 + > dlls/d3dx9_36/tests/hlsl.c | 666 +++++++++++++++++++++++++++++++++++++++ > include/d3dx9shader.h | 11 + > 3 files changed, 678 insertions(+), 0 deletions(-) > create mode 100644 dlls/d3dx9_36/tests/hlsl.c > Needs splitting.

Aug. 4, 2010

Re: [PATCH 07/10] ddraw: Allow creating back buffer for DirectX 1 interfaces. (try 3)

by Stefan Dösinger

Am 03.08.2010 um 21:26 schrieb Oldřich Jedlička: > DirectX 1 interface allowed creation of explicit back buffers, so move the > restrictive checks to DirectX 2+ implementations. Don't permit creating of > primary surface back buffer. The patch(as well as 9 and 10) look OK to me. Patch 6 is OK too. Patch 8 is missing a call to wined3d to tell it about the new backbuffer. (Apps will likely still work with the GDI renderer, but not the opengl ddraw renderer)

Aug. 4, 2010

Re: [PATCH 04/10] ddraw/tests: New visual back buffer flipping tests. (try 3)

by Stefan Dösinger

Am 03.08.2010 um 21:26 schrieb Oldřich Jedlička: > + whiteBrush = CreateSolidBrush(white); > + ok(whiteBrush != NULL, "CreateBrush returned: %p\n", whiteBrush); > + redBrush = CreateSolidBrush(red); > + ok(redBrush != NULL, "CreateBrush returned: %p\n", redBrush); > + > + hr = IDirectDrawSurface_GetDC(Backbuffer, &dc); > + ok(hr == DD_OK, "IDirectDrawSurface_GetDC returned: %x\n", hr); > + ret = FillRect(dc, &rect, redBrush); > + ok(ret != 0, "FillRect failed\n"); > + hr = IDirectDrawSurface_ReleaseDC(Backbuffer, dc); > + ok(hr == DD_OK, "IDirectDrawSurface_ReleaseDC returned: %x\n", hr); It would be more directdraw-ish to use a colorfill blit instead of getDC + gdi drawing. Tests 1-3 and 5 look OK though.

Aug. 4, 2010

shdocvw: Update Italian translation

by Luca Bennati

Aug. 4, 2010

Re: [PATCH 09/10] ddraw: Add checking of SURFACEDESC type into CreateSurface methods. (try 3)

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=4262 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found

Aug. 4, 2010

Re: [PATCH 08/10] ddraw: Allow attaching backbuffers and primaries. (try 3)

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=4261 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found

Aug. 4, 2010

Re: [PATCH 07/10] ddraw: Allow creating back buffer for DirectX 1 interfaces. (try 3)

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=4260 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found

Aug. 4, 2010

Re: tools/winebuild: add missing separators

by Andrew Nguyen

On Tue, Aug 3, 2010 at 9:57 PM, Austin English <austinenglish(a)gmail.com> wrote: > -- > -Austin > > > > The colons aren't decorative separators, but rather determine which short arguments expect a parameter as per the requirements of getopt/getopt_long. With your patch applied: $ tools/winebuild/winebuild -h tools/winebuild/winebuild: option requires an argument -- 'h'

Aug. 4, 2010

Re: [PATCH 04/10] ddraw/tests: New visual back buffer flipping tests. (try 3)

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=4251 Your paranoid android. === W2KPROSP4 (32 bit visual) === visual.c:1497: Test failed: Got color 000a246a, expected 000000ff or near visual.c:1503: Test failed: Got color 006b8bbd, expected 000000ff or near visual.c:1509: Test failed: Got color 00ffffff, expected 00000080 or near visual.c:1515: Test failed: Got color 00ffffff, expected 00000080 or near

Aug. 4, 2010

Re: [PATCH 03/10] ddraw/tests: Add test for NULL/bad size of surface caps in CreateSurface. (try 3)

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=4250 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found

Aug. 4, 2010

Re: [PATCH] kernel32/tests: Try harder to crash in the debugger test.

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=4248 Your paranoid android. === W7PROX64 (64 bit debugger) === debugger.c:309: Test failed: Timed out waiting for the child to crash debugger.c:323: Test failed: wrong exit code : 00000103 debugger.c:334: Test failed: Timed out waiting for the debugger debugger.c:149: Test failed: wrong size for 'C:\Users\winetest\AppData\Local\Temp\wtD67.tmp': read=0 debugger.c:339: Test failed: wrong debugger argument count: -32297584 debugger.c:340: Test failed: the child and debugged pids don't match: 2284 != 2046 debugger.c:309: Test failed: Timed out waiting for the child to crash debugger.c:316: Test failed: wrong exit code : 00000103 debugger.c:334: Test failed: Timed out waiting for the debugger debugger.c:149: Test failed: wrong size for 'C:\Users\winetest\AppData\Local\Temp\wtE239.tmp': read=0 debugger.c:339: Test failed: wrong debugger argument count: -32297584 debugger.c:340: Test failed: the child and debugged pids don't match: 2384 != 2046 Timeout

Aug. 4, 2010

Re: [PATCH 02/10] ddraw/tests: New attachment/flipping tests for back buffers. (try 3)

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=4246 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found

Aug. 4, 2010

Re: [PATCH 01/10] ddraw/tests: New CreateSurface for DDSCAPS_BACKBUFFER tests. (try 3)

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=4245 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found

Aug. 4, 2010

Re: regedit: Added Hebrew translation

by Charles Davis

On 8/3/10 4:58 AM, Yaron Shahrabani wrote: > How can I compile a single RC file? After configuring Wine, go to the directory containing the RC file and type in a Terminal: make <basename>.res where <basename> is the part of the filename before the '.rc' extension. So if you wanted to compile only He.rc for regedit, you'd first 'cd' to <wine-src>/programs/regedit and then type 'make He.res'. Chip

Aug. 3, 2010

Re: Should we expect Liberation fonts to be installed?

by Scott Ritchie

On 08/03/2010 03:09 PM, David Gerard wrote: > On 3 August 2010 21:57, Scott Ritchie <scott(a)open-vote.org> wrote: > >> This bug, for instance, prevents Photoshop from working unless there is >> an Arial font installed: http://bugs.winehq.org/show_bug.cgi?id=9623 >> Wine doesn't seem to respect system-level fontconfig aliases, so even >> though Liberation Sans is installed on the system Photoshop won't try to >> use it in place of Arial. > > > This is an excellent idea, except that the Liberation fonts are really > horrible. I've *tried* using them for general text use and they make > me want to gouge my eyes out. > > Is there really no reasonable way to detect the system font settings > in GNOME or KDE? And where detection fails, a Wine control panel > perhaps? > > > - d. Well, if we did use the fontconfig aliases, you'd be seeing the Liberation fonts unless you had the real Arial installed ;) Thanks, Scott Ritchie

Aug. 3, 2010

Re: Should we expect Liberation fonts to be installed?

by David Gerard

On 3 August 2010 21:57, Scott Ritchie <scott(a)open-vote.org> wrote: > This bug, for instance, prevents Photoshop from working unless there is > an Arial font installed: http://bugs.winehq.org/show_bug.cgi?id=9623 > Wine doesn't seem to respect system-level fontconfig aliases, so even > though Liberation Sans is installed on the system Photoshop won't try to > use it in place of Arial. This is an excellent idea, except that the Liberation fonts are really horrible. I've *tried* using them for general text use and they make me want to gouge my eyes out. Is there really no reasonable way to detect the system font settings in GNOME or KDE? And where detection fails, a Wine control panel perhaps? - d.

Aug. 3, 2010

Should we expect Liberation fonts to be installed?

by Scott Ritchie

I was looking through our fairly large collection of open font bugs and realized that things might be a lot simpler if we took some opinionated positions and just declared certain fonts to be dependencies and expected all packagers to provide them. This is similar to bundling our own Tahoma, except much less work. This bug, for instance, prevents Photoshop from working unless there is an Arial font installed: http://bugs.winehq.org/show_bug.cgi?id=9623 Wine doesn't seem to respect system-level fontconfig aliases, so even though Liberation Sans is installed on the system Photoshop won't try to use it in place of Arial. But if however we assumed that Liberation Sans was installed, we could make things much better: a link/substitution for Arial->Liberation Sans could be provided in our own registry (and similarly for Times New Roman and Courier). An alternative is to simply symlink to the Liberation Fonts in /usr/share/wine/fonts as though they were our own shipped fonts (like Tahoma). This would make Photoshop think Arial was present and keep it functional. Ideally the real Arial would be displayed if it was installed (eg through winetricks corefonts or by installing the distro-provided corefonts package). A related question is whether to show "Arial" in the list of fonts (eg notepad) when we're actually just providing a substituted Arial. My inclination says no, however I'm not sure how it works internally and what an application would expect. Thanks, Scott Ritchie

Aug. 3, 2010

Re: [PATCH 2/4] include/shlobj.h: SHILCreateFromPath takes both CSTR and WSTR

by Alexandre Julliard

Andrew Eikum <aeikum(a)codeweavers.com> writes: > This is different from the latest PSDK, but Wine's SHILCreateFromPath > accepts both types, so we shouldn't make compiler warnings about it. If there are warnings with the Windows headers there should be warnings with the Wine ones too. -- Alexandre Julliard julliard(a)winehq.org

Aug. 3, 2010

Re: wiki slightly broken still?

by David Gerard

[to list as well] On 3 August 2010 15:07, Dimi Paun <dimi(a)lattica.com> wrote: > On Tue, 2010-08-03 at 14:30 +0200, Alexandru Băluț wrote: >> How difficult would it be to use ReCaptcha? >> http://www.google.com/recaptcha > Hm, don't know. We could hack our version to support recaptcha, > but I'm not familiar with the code base, and I don't have the > time right now. But I can take patches if someone is willing > to do it. The MoinMoin developers consider TextCHA inherently superior and so have no interest in writing a reCaptcha interface: http://moinmo.in/FeatureRequests/ReCaptcha (Note also the problems people have had with TextCHA: it becomes too much work to write the questions and to answer the questions.) If someone wants reCaptcha in MoinMoin, it appears they will need to write it all themselves. - d.

Aug. 3, 2010