December 2013 - Wine-Devel - list.winehq.org

Re:Re: kernel32/tests: add test for RemoveDirectory

by 刘涛

I think that if you want GetLastError(), "SetLastError( 0xdeadbeef );" should be added before every function which could SetLastError(). -- Thanks， Tao, Liu At 2013-12-25 22:23:44,"Zhenbo Li" <litimetal(a)gmail.com> wrote: >2013/12/25 Dmitry Timoshkov <dmitry(a)baikal.ru>: >> Zhenbo Li <litimetal(a)gmail.com> wrote: >> >>> + /* remove a nonexist directory */ >>> + rc = RemoveDirectoryA(directory); >>> + todo_wine >>> + ok(!rc && GetLastError() == ERROR_FILE_NOT_FOUND, >>> + "Expected ERROR_FILE_NOT_FOUND, got ret=%d, gle=%d\n", rc, GetLastError() ); >> >> This kind of test for several values simultaneously is really very awkward >> as a starting point for any person who is going to work on this, or just is >> looking for a simple bug to fix and greps for todo_wine in the tests. First >> of all it's not clear where the failure is: is it the API failing to return >> correct return value, or is it just last error which is set differently? >> I admit that the error message mentions both values, but it's often more >> useful to spot areas with todo_wine statements and clearly see the reason >> of a failure without actually running the test. >> >> -- >> Dmitry. > >You are right, I'll send another patch. > >-- >Have a nice day! >Zhenbo Li > >

Dec. 26, 2013

Re: kernel32/tests: add test for RemoveDirectory

by Zhenbo Li

2013/12/25 Dmitry Timoshkov <dmitry(a)baikal.ru>: > Zhenbo Li <litimetal(a)gmail.com> wrote: > >> + /* remove a nonexist directory */ >> + rc = RemoveDirectoryA(directory); >> + todo_wine >> + ok(!rc && GetLastError() == ERROR_FILE_NOT_FOUND, >> + "Expected ERROR_FILE_NOT_FOUND, got ret=%d, gle=%d\n", rc, GetLastError() ); > > This kind of test for several values simultaneously is really very awkward > as a starting point for any person who is going to work on this, or just is > looking for a simple bug to fix and greps for todo_wine in the tests. First > of all it's not clear where the failure is: is it the API failing to return > correct return value, or is it just last error which is set differently? > I admit that the error message mentions both values, but it's often more > useful to spot areas with todo_wine statements and clearly see the reason > of a failure without actually running the test. > > -- > Dmitry. You are right, I'll send another patch. -- Have a nice day! Zhenbo Li

Dec. 25, 2013

Re: Implementing support for MFPlat.dll and MFReadWrite.dll

by André Hentschel

Am 25.12.2013 01:48, schrieb Alexandre Bique: > > I'm trying to make Ableton Live works better with wine, and as stated > in this bug: https://bugs.winehq.org/show_bug.cgi?id=35105 setting > wine version to win8 will make Ableton Live crash. > > I first though that it was an issue with the OpenFileDialog being > replaced by IFileDialog because it was something that changed and it > was visible, but after second thought, I'm thinking about something > else. > > I noticed that ableton tries to load these libraries: > > err:module:import_dll Library MFReadWrite.dll (which is needed by > L"C:\\users\\Public\\Application Data\\Ableton\\Live 9 > Suite\\Program\\VideoExportMMF.dll") not found > err:module:import_dll Library MFPlat.DLL (which is needed by > L"C:\\users\\Public\\Application Data\\Ableton\\Live 9 > Suite\\Program\\VideoExportMMF.dll") not found > > and they're part of Microsoft Media Foundation ... > > And just after IFileDialog returns with valid data, the application > crash and we can see on the output: > How do you guess by that output that it's about some MF*.dll? is e07010ec-bc17-44c0-97b0-46c7c95b9edc related? I don't know how things behave with missing interfaces, but i guess the app get's a NULL pointer back and tries to call a function from that object. (so an easy test hack would be to stub an interface like that somewhere else and see what happens) > > So what do you think? Is MFPlat.dll and MFReadWrite.dll a good > candidate? If so, how to implement the library? What are the > guidelines? Guidelines can be found in the documentation. You can also use git to see how new dlls are built up. e.g. b03d07dff4d710d9176602a7d939c94bf7dd89ff

Dec. 25, 2013

Re: kernel32/tests: add test for RemoveDirectory

by Dmitry Timoshkov

Zhenbo Li <litimetal(a)gmail.com> wrote: > + /* remove a nonexist directory */ > + rc = RemoveDirectoryA(directory); > + todo_wine > + ok(!rc && GetLastError() == ERROR_FILE_NOT_FOUND, > + "Expected ERROR_FILE_NOT_FOUND, got ret=%d, gle=%d\n", rc, GetLastError() ); This kind of test for several values simultaneously is really very awkward as a starting point for any person who is going to work on this, or just is looking for a simple bug to fix and greps for todo_wine in the tests. First of all it's not clear where the failure is: is it the API failing to return correct return value, or is it just last error which is set differently? I admit that the error message mentions both values, but it's often more useful to spot areas with todo_wine statements and clearly see the reason of a failure without actually running the test. -- Dmitry.

Dec. 25, 2013

Re: [PATCH] ddraw: add dsurface dimension tests, try 5

by Francois Gouget

On Sat, 14 Dec 2013, Patrick Rudolph wrote: > How much physical memory does each test VM have ? more than 2 GByte ? > On 64bit Windows I should be able to allocate 2GByte of virtual memory using > the pagefile, shouldn't I ? Currently the WineTestBot VMs all have 1GB of memory allocated to them, except the Windows 8.1 32-bit VM which has 1.5GB (when I redo the 64-bit Windows 8 VM I'll probably give it 1.5GB too). -- Francois Gouget <fgouget(a)codeweavers.com>

Dec. 25, 2013

Implementing support for MFPlat.dll and MFReadWrite.dll

by Alexandre Bique

Hi, I'm trying to make Ableton Live works better with wine, and as stated in this bug: https://bugs.winehq.org/show_bug.cgi?id=35105 setting wine version to win8 will make Ableton Live crash. I first though that it was an issue with the OpenFileDialog being replaced by IFileDialog because it was something that changed and it was visible, but after second thought, I'm thinking about something else. I noticed that ableton tries to load these libraries: err:module:import_dll Library MFReadWrite.dll (which is needed by L"C:\\users\\Public\\Application Data\\Ableton\\Live 9 Suite\\Program\\VideoExportMMF.dll") not found err:module:import_dll Library MFPlat.DLL (which is needed by L"C:\\users\\Public\\Application Data\\Ableton\\Live 9 Suite\\Program\\VideoExportMMF.dll") not found and they're part of Microsoft Media Foundation ... And just after IFileDialog returns with valid data, the application crash and we can see on the output: fixme:commdlg:IServiceProvider_fnQueryService Interface {e07010ec-bc17-44c0-97b0-46c7c95b9edc} requested from unknown service {e07010ec-bc17-44c0-97b0-46c7c95b9edc} fixme:shell:ViewModeToListStyle ViewMode 0 not implemented fixme:shell:IShellBrowser_fnSendControlMsg stub, 0xea510 (2, 1026, a003, 0, 0x23d5b8) fixme:shell:IShellBrowser_fnSendControlMsg stub, 0xea510 (2, 1026, a004, 0, 0x23d5b8) fixme:shell:IShellBrowser_fnSendControlMsg stub, 0xea510 (2, 1025, a003, 1, 0x23d5b8) fixme:shell:IShellBrowser_fnSendControlMsg stub, 0xea510 (2, 1025, a004, 1, 0x23d5b8) fixme:nstc:NSTC2_fnSetControlStyle2 mask & style (0x00000004) contains unsupported style(s): 0x00000004 fixme:commdlg:IServiceProvider_fnQueryService Interface {e07010ec-bc17-44c0-97b0-46c7c95b9edc} requested from unknown service {e07010ec-bc17-44c0-97b0-46c7c95b9edc} fixme:shell:ViewModeToListStyle ViewMode 0 not implemented fixme:shell:IShellBrowser_fnSendControlMsg stub, 0xea510 (2, 1026, a003, 0, 0x23d248) fixme:shell:IShellBrowser_fnSendControlMsg stub, 0xea510 (2, 1026, a004, 0, 0x23d248) fixme:shell:IShellBrowser_fnSendControlMsg stub, 0xea510 (2, 1025, a003, 1, 0x23d248) fixme:shell:IShellBrowser_fnSendControlMsg stub, 0xea510 (2, 1025, a004, 1, 0x23d248) fixme:shell:IShellBrowser_fnOnViewWindowActive stub, 0xea510 (0x1574fa60) fixme:commdlg:IServiceProvider_fnQueryService Interface {e07010ec-bc17-44c0-97b0-46c7c95b9edc} requested from unknown service {e07010ec-bc17-44c0-97b0-46c7c95b9edc} fixme:shell:ViewModeToListStyle ViewMode 0 not implemented fixme:shell:IShellBrowser_fnSendControlMsg stub, 0xea510 (2, 1026, a003, 0, 0x23d3a8) fixme:shell:IShellBrowser_fnSendControlMsg stub, 0xea510 (2, 1026, a004, 0, 0x23d3a8) fixme:shell:IShellBrowser_fnSendControlMsg stub, 0xea510 (2, 1025, a003, 1, 0x23d3a8) fixme:shell:IShellBrowser_fnSendControlMsg stub, 0xea510 (2, 1025, a004, 1, 0x23d3a8) fixme:shell:IShellBrowser_fnOnViewWindowActive stub, 0xea510 (0xef860) fixme:commdlg:IServiceProvider_fnQueryService Interface {e07010ec-bc17-44c0-97b0-46c7c95b9edc} requested from unknown service {e07010ec-bc17-44c0-97b0-46c7c95b9edc} fixme:shell:ViewModeToListStyle ViewMode 0 not implemented fixme:shell:IShellBrowser_fnSendControlMsg stub, 0xea510 (2, 1026, a003, 0, 0x23d3a8) fixme:shell:IShellBrowser_fnSendControlMsg stub, 0xea510 (2, 1026, a004, 0, 0x23d3a8) fixme:shell:IShellBrowser_fnSendControlMsg stub, 0xea510 (2, 1025, a003, 1, 0x23d3a8) fixme:shell:IShellBrowser_fnSendControlMsg stub, 0xea510 (2, 1025, a004, 1, 0x23d3a8) fixme:shell:IShellBrowser_fnOnViewWindowActive stub, 0xea510 (0xeb240) fixme:dbghelp:elf_search_auxv can't find symbol in module So what do you think? Is MFPlat.dll and MFReadWrite.dll a good candidate? If so, how to implement the library? What are the guidelines? Thanks and happy Christmas, -- Alexandre Bique

Dec. 25, 2013

Re: infosoft/tests: Constify a character string

by Marvin

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3827 Your paranoid android. === wvista (32 bit infosoft) === infosoft.c:183: Test failed: failed infosoft.c:197: Test failed: failed === w2008s64 (32 bit infosoft) === infosoft.c:183: Test failed: failed infosoft.c:197: Test failed: failed === w7pro64 (32 bit infosoft) === infosoft.c:183: Test failed: failed infosoft.c:197: Test failed: failed === w2008s64 (64 bit infosoft) === infosoft.c:183: Test failed: failed infosoft.c:197: Test failed: failed === w7pro64 (64 bit infosoft) === infosoft.c:183: Test failed: failed infosoft.c:197: Test failed: failed

Dec. 24, 2013

Re: COMDLG32: native color picker on mac os x

by Ken Thomases

Hi Žiga, On Dec 23, 2013, at 11:00 AM, Žiga Željko wrote: > I have made a patch for comdlg32 on Mac OS X that replaces Wine's own color > picker dialog with the native one. > Bellow are the sources for colordlg.c, cocoa_colordlg.m and Makefile.in > (without comments). Thanks for your interest in improving Wine, but I'm afraid this is pretty far from any possible inclusion in Wine. Replacement source file are not a "patch". A patch should be in unified diff format (including those generated by git) showing the differences between the existing sources and your proposed versions. Any proposed changes have to maintain functionality on all platforms that Wine supports, so they can't remove the existing implementation. Any Mac-specific code would have to be conditionally compiled. If Wine is going to use the Mac-native color picker, it should only do so when the Mac driver is being used. If the X11 driver is used, then the Mac-native dialog would belong to the wrong process and may even show up on the wrong display (if X11 is displaying remotely). So, really, this should be in the user driver as an optional entry point. Also, even if the user driver provides the entry point, it should be possible for it to decline to present a driver-specific dialog (by returning FALSE, for example), so the code should fall back to the normal built-in dialog. The code would have to consider _all_ of the options that the calling code can specify via the ChooseColor() function and the CHOOSECOLOR structure. For example, if the caller specified a hook procedure, then it expects to exercise control over the behavior of the dialog. If you don't support that, then the caller will get unexpected behavior. Since it's basically impossible to support such a hook procedure when using the Mac-native dialog, you would have to decline to use the Mac-native dialog when a hook procedure is specified. Same with a dialog template. Similarly, if the caller specifies CC_PREVENTFULLOPEN then it's only prepared to handle certain colors being returned. You would have to implement that or, if you can't, fall back to the built-in dialog. Etc. This means that some Windows programs would get the Mac-native dialog and others would get the built-in dialog. In fact, both might be used by the same Windows program at different times, depending on context. Since this is undesirable, it's an open question as to whether this feature is a good idea at all. At the very least, there should be a registry setting to turn off the Mac-native dialog in case the user doesn't want it or it interferes with compatibility of some Windows program. Built-in dialogs disable the owning window if one is specified. An implementation of the Mac-native dialog would have to do the same thing in order to prevent weird interaction bugs. Obviously, it would have to reenable the owner after it completes. The GetColor() function is Carbon, which should be avoided if possible. In fact, even for Carbon, the GetColor() function was marked as obsolete. The PickColor() function was preferred when Carbon was still in active development. The Cocoa equivalent (NSColorPanel) should be preferred. Regards, Ken

Dec. 23, 2013

COMDLG32: native color picker on mac os x

by Žiga Željko

Hello, I have made a patch for comdlg32 on Mac OS X that replaces Wine's own color picker dialog with the native one. Bellow are the sources for colordlg.c, cocoa_colordlg.m and Makefile.in (without comments). -------------------- colordlg.c -------------------- static BOOL ChooseColor_CocoaCommon(COLORREF *color, BOOL init); BOOL WINAPI ChooseColorW( CHOOSECOLORW *lpChCol ) { if (!lpChCol) return FALSE; return ChooseColor_CocoaCommon(&lpChCol->rgbResult, lpChCol->Flags & CC_RGBINIT); } BOOL WINAPI ChooseColorA( LPCHOOSECOLORA lpChCol ) { if (!lpChCol) return FALSE; return ChooseColor_CocoaCommon(&lpChCol->rgbResult, lpChCol->Flags & CC_RGBINIT); } struct RGBColor { unsigned short red; unsigned short green; unsigned short blue; }; int cocoa_run_color_dialog_modal(struct RGBColor *color); static BOOL ChooseColor_CocoaCommon(COLORREF *color, BOOL init) { struct RGBColor rgb = { 0, 0, 0 }; if (init) { rgb.red = GetRValue(*color) * 257; rgb.green = GetGValue(*color) * 257; rgb.blue = GetBValue(*color) * 257; } BOOL ret = cocoa_run_color_dialog_modal(&rgb); if (ret) *color = RGB(rgb.red / 257, rgb.green / 257, rgb.blue / 257); return ret; } -------------------- cocoa_colordlg.m -------------------- #import <AppKit/AppKit.h> #import <Carbon/Carbon.h> int cocoa_run_color_dialog_modal(RGBColor *color) { __block int ret = 0; void (^block)(void) = ^{ ret = GetColor((Point){ 0, 0 }, (const unsigned char *)"Color", color, color); }; if ([NSThread isMainThread]) block(); else dispatch_sync(dispatch_get_main_queue(), block); return ret; } -------------------- Makefile.in -------------------- MODULE = comdlg32.dll IMPORTLIB = comdlg32 IMPORTS = uuid shell32 shlwapi comctl32 winspool user32 gdi32 advapi32 DELAYIMPORTS = ole32 EXTRALIBS = -framework AppKit -framework Carbon C_SRCS = \ cdlg32.c \ colordlg.c \ filedlg.c \ filedlg31.c \ filedlgbrowser.c \ finddlg.c \ fontdlg.c \ itemdlg.c \ printdlg.c RC_SRCS = comdlg32.rc SVG_SRCS = \ pd32_collate.svg \ pd32_landscape.svg \ pd32_nocollate.svg \ pd32_portrait.svg OBJC_SRCS = \ cocoa_colordlg.m IDL_R_SRCS = comdlg32_classes.idl @MAKE_DLL_RULES@ ------------------------------------------------------------ Any comments are welcome.

Dec. 23, 2013

Re: D3D command stream abandoned?

by Stefan Dösinger

Hi, Am 21.12.2013 um 19:26 schrieb Forest <winehq(a)tibit.com>: > I haven't seen any news of the command stream lately. The last thing I read > was the mention of "more preparation work" in the 1.7.4 release > announcement. Has the project been abandoned? It’s not been abandoned. I’m working on getting it merged, but I was delayed by other, partially related work. I’m on vacation right now, but I plan to send a new patchset to wine-devel early in January, probably for 1.7.10. I was hoping to do so for 1.7.9 before the Chrismas vacation, but the patches I have in my tree are somewhat broken at the moment and only produce a segfault. I didn’t finish cleaning them up in time. Getting the command stream merged will take a while. My current goal at the moment is merging surface and resource location management and moving it into the resource class. Buffers will have to be migrated as well before the command stream itself can proceed. And for the CS itself we have a few more design decisions to work out to make sure the code is maintainable in the long term. > I maintain a wine build for gamers, and currently have it frozen at version > 1.7.1 with Stefan's September 2 command stream patches, because they seem to > boost performance quite a bit for some folks. I'd love to get something > more mature into my users' hands if it's available. If you are looking for an intermediate version of the code with a few bugs from my original wine-devel submission fixed then you can find that in the CrossOver 13 Wine sources. It’d be a bit of effort to isolate those changes and put them in the upstream wine code though.

Dec. 23, 2013