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

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