July 2015 - Wine-Devel - list.winehq.org

Re: ieframe: implement clicking on Properties

by Jacek Caban

Hi Jared, On 06/30/15 16:00, Jared Smudde wrote: > When the user clicks on the properties menu in ieframe, launch inetcpl.cpl. > > dlls/ieframe/iexplore.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/dlls/ieframe/iexplore.c b/dlls/ieframe/iexplore.c > index 08bb167..c1d0d74 100644 > --- a/dlls/ieframe/iexplore.c > +++ b/dlls/ieframe/iexplore.c > @@ -402,6 +402,11 @@ static void ie_dialog_about(HWND hwnd) > DestroyIcon(icon); > } > > +static void ie_dialog_properties(HWND hwnd) > +{ > + ShellExecuteW(hwnd, NULL, L"inetcpl.cpl", NULL, NULL, 0); > +} I think that we should call inetcpl.cpl functions directly here (probably LaunchInternetControlPanel). Also, you can't use L"" for strings due to compatibility problems, see how other strings are declared. > + > static void add_tb_separator(HWND hwnd) > { > TBBUTTON btn; > @@ -629,6 +634,10 @@ static LRESULT iewnd_OnCommand(InternetExplorer *This, HWND hwnd, UINT msg, WPAR > case ID_BROWSE_QUIT: > ShowWindow(hwnd, SW_HIDE); > break; > + > + case ID_BROWSE_PROPERTIES: > + ie_dialog_properties(hwnd); > + break; Broken indention. Thanks, Jacek

July 1, 2015

Re: [PATCH 1/2] d3drm: Add stubs for IDirect3DRMDevice methods.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-07-01 um 01:03 schrieb Aaryaman Vasishta: > +static ULONG WINAPI d3drm_device1_AddRef(IDirect3DRMDevice *iface) > +{ > + struct d3drm_device *device = impl_from_IDirect3DRMDevice(iface); > + ULONG refcount = InterlockedIncrement(&device->ref); > + > + TRACE("%p increasing refcount to %u.\n", iface, refcount); > + > + return refcount; > +} > + > +static ULONG WINAPI d3drm_device1_Release(IDirect3DRMDevice *iface) > +{ > + struct d3drm_device *device = impl_from_IDirect3DRMDevice(iface); > + > + return IDirect3DRMDevice2_Release(&device->IDirect3DRMDevice2_iface); > +} Why are you forwarding Release to d3drmdevice2 but not Addref? I think we should look again at moving the IUnknown methods to Device3, so we don't thunk to the middle child and stay consistent with the other methods. Please send an extra patch before this one that migrates the code to device3. I remember we already looked at this. If this failed in some spectacular way please remind me :-) . Is there a logic behind which method forwards to device3 and which just returns E_NOTIMPL? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVk+jzAAoJEN0/YqbEcdMwL/MP/jmYjvhWcVOosMP2FyKVaezA c4SqCONBE+xPvhmC97IfPXZ8wJQUjH0tt5CjZN2JZTY0yw50bEM4JHDfC1pPjF3O IX4qKllp0UeAeNCNKu64a8rxYT2kLRwLp7zs+GO7YygwimKy9DAMxUCW5+IP4DiB bsO1wTcSWlCHQ8c4ikUou6aIY/npJ+UqVS8DNGl5m1cLw6oUdzZMvcurSooH2LUv 1oq4XC1DQe/wx3Ob826xY8w/2v6CM0JDAgAT1dGqxIWDS5DNzsKj9P8oKEso/C8c thpZdsIvgQLEkfmKgN6wRh9h03aAMVHbXoSmGVihaapSspF7299DYrDyoiQvYxEq k+SgAMqHAtAzfXkQto9n0f8FjiLEJzbFu9WMoKLJmjdk7hpH8CXPsoioA/o8xNDA 8dB9LxITlJuK5oEUczGhdrnN144Ml8AkZbs+DBcvTdHvaOaY7urL2sZ6/QuvGtAY IGGeUnPW2VBMGpg1YlSn9OmziBibrjKOVtXHVmbwYQhZhXOcfzgMT+QBBV2eQ/pQ 0tmDnUk93+ungNnc4slfLZo+uZ8/8kvPRMv8fYPcQjkcXOIRCobup4bqx3vrQVWT zOx05HKBDQihZAxZuHynFaNqA5E1QbhbPac0BsOSLk8r4zSKx58BgNLBYWz51oe6 NN959TJY84womG8/lfFc =jkwG -----END PGP SIGNATURE-----

July 1, 2015

Re: [PATCH 8/8] comctl32: Implement the legacy notifications during restore.

by Huw Davies

On 1 Jul 2015, at 13:36, Marvin wrote: > > === wvistau64 (64 bit toolbar) === > No test summary line found > > === w2008s64 (64 bit toolbar) === > No test summary line found This patch should probably be dropped. The earlier ones should still be good. Huw.

July 1, 2015

Re: [PATCH 8/8] comctl32: Implement the legacy notifications during restore.

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://testbot.winehq.org/JobDetails.pl?Key=14894 Your paranoid android. === wvistau64 (64 bit toolbar) === No test summary line found === w2008s64 (64 bit toolbar) === No test summary line found

July 1, 2015

Re: kernel32: K32EnumProcessModules: Handle NULL pointer gracefully.

by Olivier F. R. Dierick

Le mardi 30 juin 2015 à 16:04 -0600, Alex Henrie a écrit : > > diff --git a/dlls/kernel32/module.c b/dlls/kernel32/module.c > > index f495e81..5461881 100644 > > --- a/dlls/kernel32/module.c > > +++ b/dlls/kernel32/module.c > > @@ -1226,6 +1226,12 @@ BOOL WINAPI K32EnumProcessModules(HANDLE process, HMODULE *lphModule, > > if (!init_module_iterator(&iter, process)) > > return FALSE; > > > > + if (!lphModule) > > + { > > + SetLastError(ERROR_NOACCESS); > > + return FALSE; > > + } > > + > > if (!needed) > > { > > SetLastError(ERROR_NOACCESS); > > Wouldn't it be easier to write "if (!lphModule || !needed)"? Adding a > test or two would also be nice. > > -Alex That would be fine for me. I'll check the behavior of actual Windows and write appropriate conformance tests. I'll send a new patch accordingly. -- Olivier F. R. Dierick o.dierick(a)piezo-forte.be

July 1, 2015

odbccp32: Implement SQLGetPrivateProfileString (try 6 - resend)

by Hugh McMaster

>+ LONG ret = 0; >+ HKEY hkey; >+ DWORD size = 0; >+ BOOL usedefault = TRUE; >+ /* snip */ >+ clear_errors(); >+ >+ if(!cbRetBuffer) >+ return 0; >+ >+ if(RetBuffer) >+ RetBuffer[0] = 0; >+ >+ if(!lpszSection || !lpszEntry || !lpszDefault || !RetBuffer || !cbRetBuffer) >+ return ret; You are checking "if (!cbRetBuffer)" twice. Same in the next function. You don't need to clear RetBuffer. RegGetValue adds a null terminating character if it doesn't already exist. You also "return 0" and "return ret". They are the same at the moment, so be consistent. >+size = cbRetBuffer; >+if(RegGetValueW(hkeysect, NULL, lpszEntry, RRF_RT_REG_SZ, &type, RetBuffer, &size) == ERROR_SUCCESS) cbRetBuffer is the size in characters of the buffer pointed to by RetBuffer.[1] size needs to be in bytes, so unless RetBuffer uses char, this is wrong. >+ ret = SQLGetPrivateProfileStringW(sect, entry, string, retval, cbRetBuffer, file); >+ if(ret) >+ { >+ WideCharToMultiByte(CP_ACP, 0, retval, -1, RetBuffer, ret+1, NULL, NULL); >+ } This doesn't look right to me. "ret+1" should be the size, in bytes, of RetBuffer. [2] [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms724868%28v=vs.85… [2] https://msdn.microsoft.com/en-us/library/windows/desktop/dd374130%28v=vs.85…

July 1, 2015

Re: [PATCH 1/6]: msvcp110: Add tr2_sys__Copy_file implementation and test.

by Piotr Caban

Hi, On 07/01/15 07:08, YongHaoHu wrote: > On 15/6/30 下午8:25, Piotr Caban wrote: >>>> Currently your implementation sometimes returns error even so it >>>> succeeds. >>>> >>> Which one do you mean ? As you know, last_error hadling is not correct >>> in wine's CopyFile, was this happened in Wine platform? >> { "f1", "tr2_test_dir\\f1_copy", TRUE } >> Your implementation returns error if f1_copy file already exists. It >> only makes sense to use GetLastError if function have failed. >> > I had tested the ret and the last_error before in testbot. The result > shows that the function's return value is exactly the same as > GetLastError(). > ret = p_tr2_sys__Copy_file(tests[i].source, tests[i].dest, > tests[i].fail_if_exists); > printf("ret is %d\n", ret); > printf("GetLastError is %d\n\n", GetLastError()); > > Here is the test result: > https://testbot.winehq.org/JobDetails.pl?Key=14885&log_101=1#k101 > And { "f1", "tr2_test_dir\\f1_copy", TRUE } returns 80( ERROR_FILE_EXSITS). > Sorry, I thought about this test: { "f1", "tr2_test_dir\\f1_copy", FALSE }, your implementation returns error while on windows it returns 0. Thanks, Piotr

July 1, 2015

Re: Proposal: to make binfmt-misc with wine workable and make Wine compadiblity modes more like Windows compadiblity mode.

by Peter Dolding

On 7/1/15, Vincent Povirk <madewokherd(a)gmail.com> wrote: >>> We shouldn't condone assigning security permissions to specific win32 >>> exe files beyond what the user naturally has. Currently, we cannot >>> protect the exe process from anything else the user does, so it's >>> effectively the same as giving that permission to any user that can >>> execute the file. >> >> Please note setcap on a file can also block permissions. So you can >> make a program run with Less permissions than your current user. The >> fact this currently cannot work its both ways. > > Then I should note that the limitation works both ways as well: we > cannot currently protect other wine processes from one that has fewer > permissions than the current user. Cannot currently is mostly that those cases have not had to be considered because they were not possibilities. > >>> Of course, giving special permissions to wineloader is ALSO the same >>> as doing that, but the solution is to give the permissions to the >>> target program in some way that actually works, rather than switch to >>> a different way that doesn't. >>> >>> I would suggest running these programs in a dedicated account. >> >> Even switching away you have to know when the application has or has >> not got the permission. Using binfmt-misc the wine loader program >> still will be run first and it can still drop the flags. This is one >> of the advantages of capabilities. Even switching to another method >> you really do need to tag what applications are using raised >> capabilities. > > I don't see why this is. Can't the appropriate permissions just be > assigned to the user that will run this software? > Running software in a different user is not a normal Linux solution. Like ping you don't run that as a different user. Ping works because it been granted permissions. The fact that wine does not check capabilities. http://www.dsm.fordham.edu/cgi-bin/man-cgi.pl?topic=capsh Run as a user with a capabilities binding set. The reality here is using setcap that does not require root privilage or using capsh as root to start executable as a particular user with a reduced capset. This is basically normal Linux that a user will be running applications of different capabilities. Binfmt-misc remove root user requirement change capabilities. Basically presuming that users and capabilities under Linux align is wrong. Please note starting wine by a bash script can also have giving wine more capabilities than it normally would have if the bash script had setcap applied to it. >>>> Really the MINE type usage by .desktop to run wine should disappear >>>> for Linux other than to tell the system >>>> to directly execute the exe. >>> >>> The use of wine.desktop to run executable files is intentional and >>> necessary. This is because Windows runs executables differently >>> depending on whether they are invoked from the command-line or from >>> the GUI (windows explorer). There are several differences, but the >>> most important is that running from the GUI sets the working directory >>> to the parent directory of the executable. Many applications rely on >>> this behavior and won't be able to find their own files if they are >>> executed from a different directory. Use of wine.desktop runs >>> executables the way explorer does, which is appropriate when a user >>> double-clicks the file. >> >> Yes but the reality here is it broken. Anyone using multi prefixes >> there is nothing to tell wine.desktop what prefix it should be. > > It's intentional that we don't expose multiple prefixes in the UI of > plain Wine. The idea is that it should just work "like Windows", and > Windows doesn't have any concept of prefixes. You just run your > installer and then run your program from shortcuts. Except it never going to. At least inside the next 5 years. Works just like Windows is so wrong. Remember Windows 7 pro had Windows XP virtual machine. How did you declare that a executable should be in the virtual machine the exe.manifest file/compatibility mode. So the XP virtual machine is example of dual prefix under Microsoft. We wish to run a broader selection of application so multi prefixes should be expected. > > If you've set up multiple prefixes, you've already used the command > line (or an external UI) to start a program in a different prefix, so > you can certainly do it again. > You have dropped to command line because you have been forced to so application work. Wine does not have a super complex shim system with Application Compatibility Database. Without a shim system usage of custom patched versions of wine will be required at times. Microsoft Application Compatibility Database has a limited size because once it gets past a particular size it starts slowing down running any application under windows. So the Microsoft method here is busted. That this solution is busted we cannot copy how windows does it or will will copy the exact same problem. Basically goes like this under Windows. 1 you request to run an application 2 it looks up the application compatibility database and lines up to apply all shim alterations. 3 it reads all the .manifest files to find out what library the application should see and. 4 At long last Windows decides to start running the executable. All the settings in the application compatibility database to avoid the expand to hell issue is place them in a file next to the executable. Yes stacking them in the registry per executable name has the same problem or worse. Why worse what happens when you have two programs that have installed a exe file with exactly the same name requiring different tweeks. Currently wine registry method of applying per application settings is broken. Microsoft Method is half broken. Why half broken the .manifest stuff of Microsofts works. >>> We don't want to change the working directory when running an exe via >>> the command line because windows doesn't do that, and because it can >>> be important. >> >> Also running command line program by gui there is nothing to tell >> wine.desktop at the moment it has it wrong. So this is another thing >> that is broken. There needs to be somewhere to record this. Is the >> program commandline or is it gui. The fact it not recorded causes >> failures. > > If you started a program from a command line via wine.desktop, you've > probably used xdg-open which doesn't allow command-line arguments. > There is no good reason to do this (except if you know you want to > start the program in the gui mode, and don't know about 'wine start > /unix'). > > If you started a console application (which is NOT what I mean by a > command-line program) via wine.desktop, Wine will create a console > window for it, just like Windows. When I say "command-line program", I > mean one designed to be invoked from cmd.exe, rather than > explorer.exe. Note what you said here will create a console window instead of using the already open console. Yes there is a bug here. > > This is a case where being "like Windows" is the least surprising > thing we can do. Normal people don't know that cmd and explorer start > executables differently. However, they DO know how their software is > intended to be used and will naturally use it in that way. > > Being better than Windows in some weird corner cases, and then only > with user configuration, doesn't seem worth the complexity here. > >> This is the point of having a manifest file. Yes a user may not be >> able to alter the binfmt-misc settings themselves. But the >> exe.manifest file is the users file. > > This is only worth it if we want to encourage use of binfmt with Wine, > which I don't think we should do, given that the only known use case > for binfmt+wine is one we can't functionally support. > >>> For users that need to use something other than wine for only some >>> .exe files, the sensible thing to do is create a shortcut (.desktop >>> file, shell script, or whatever is most convenient) that does it in >>> the right way. That has the advantages of being a generally useful >>> skill that users are likely to already know or at least use again, and >>> of not relying on the user to have binfmt configured in a specific >>> way. >>> >> Ok so we expect users to be interactive. Great. >>>> Even .desktop files to run programs under Linux should become super >>>> simple. >>>> Path to executable as enough. All the extra complexity in the >>>> .desktop files for Linux is a bug. >>> >>> Generally .desktop files correspond to .lnk files, not .exe files. >>> Links to executables are just one specific case. And more importantly, >>> putting some configuration file next to a .exe would require user >>> intervention, while we can create .desktop files automatically. >>> >> >> What there is now a problem with users being interactive and doing >> things. Sorry you cannot have this both ways. > > Your solution requires manual intervention all of the time, while Wine > currently only requires that in some cases. > Until win64 works manual intervention to prevent users install applications that will work in win32 prefix in a win64 prefix that fail. Some cases by number of applications in the appdb its over 60 percent of cases are going to need manual intervention. This is not going to change any time soon. >> Also most exe that users would be wanting to straight on click on will >> most likely be the ones that have lnk files. So when the .desktop >> file was generated so could have been the .manifest file next to the >> .exe. Even if .desktop generation was disabled by user the manifest >> could have been generated. Currently with lnk files to desktopl or >> nothing. Generating a file next to the exe would give us 3 options. >> lnk file to ,desktop and .manifest or lnk file to just .manifest or >> nothing. > > We can't automatically put random files in application directories > next to executables. That's likely to break applications. > The file I am talking about creating never before caused a issue under Windows. Windows compatibility mode does .exe.manifest files. If application provided one it does exe.1.manifest and so on. Of course it marks them hidden and these files have never caused a Windows application to miss read them. Why the Windows application never reads them. So creating .manifest file for compatibility reasons is obeying how Windows does things. Only time what I am suggest could cause a issue is a portable app on a USB key being taken back to windows. Adding a .manifest file contain extra stuff that wine understands will never cause a issue for the application itself being run under wine. It SXS and Windows compatibility under windows/wine that processes the exe.manifest file. Yes putting extra data in the .config file of a .net application could be problematic as some applications open and edit this themselves. No application edits it own exe.manifest file under Windows. Peter Dolding

July 1, 2015

Re: [PATCH 2/2] msvcp90: Implement time_get<char> ctors and dtors (try 2)

by Alexandre Julliard

Daniel Lehman <dlehman(a)esri.com> writes: > Try2: > - remove cast for Locinfo > - handle failed new() > - change 'unsigned int refs' to 'MSVCP_size_t refs' to match the rest of the file It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M msvcp60.dll -p msvcp60_test.exe.so ios && touch ios.ok wine: Unhandled page fault on write access to 0xd8003304 at address 0x7bc4e659 (thread 0009), starting debugger... Unhandled exception: page fault on write access to 0xd8003304 in 32-bit code (0x7bc4e659). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7bc4e659 ESP:0032f4e4 EBP:0032f688 EFLAGS:00010216( R- -- I -A-P- ) EAX:d8003300 EBX:7bcc3540 ECX:00010000 EDX:75003300 ESI:00331c40 EDI:00000018 Stack dump: 0x0032f4e4: 00000000 0032f688 7bc4e4ab 00000000 0x0032f4f4: 00330000 00000000 00000000 00330000 0x0032f504: 00000000 00000002 00000014 00000000 0x0032f514: 7bc6b946 0032f540 00330014 00000000 0x0032f524: 7b8c57ac 0032f558 7bc6ad4a f7532361 0x0032f534: f75324a1 7ed54740 7bc6ad4a 7b810000 Backtrace: =>0 0x7bc4e659 RtlAllocateHeap+0x1e9(heap=<couldn't compute location>, flags=<couldn't compute location>, size=<couldn't compute location>) [/home/julliard/wine/wine/dlls/ntdll/../../include/wine/list.h:100] in ntdll (0x0032f688) 1 0x7eceb358 msvcrt_heap_alloc+0x57() in msvcrt (0x0032f6b8) 2 0x7eceb51c MSVCRT_operator_new+0x4b() in msvcrt (0x0032f6d8) 3 0x7eba526d locale__Locimp__Makexloc+0x49c(locinfo=0x32f780, cat=0x3f, locimp=0x3316d8, loc=(nil)) [/home/julliard/wine/wine/dlls/msvcp60/../msvcp90/locale.c:10584] in msvcp60 (0x0032f72c) 4 0x7eba5707 locale__Locimp__Makeloc+0x56(locinfo=0x32f780, cat=0x3f, locimp=0x3316d8, loc=(nil)) [/home/julliard/wine/wine/dlls/msvcp60/../msvcp90/locale.c:10617] in msvcp60 (0x0032f75c) 5 0x7eba5aba locale_ctor_cstr+0xb9(this=0x32f840, locname="German", cat=0x3f) [/home/julliard/wine/wine/dlls/msvcp60/../msvcp90/locale.c:10791] in msvcp60 (0x0032f7dc) 6 0x7eff37a4 test_num_get_get_double+0x353() [/home/julliard/wine/wine/dlls/msvcp60/tests/ios.c:910] in msvcp60_test (0x0032fc78) 7 0x7eff7212 func_ios+0xd91() [/home/julliard/wine/wine/dlls/msvcp60/tests/ios.c:1645] in msvcp60_test (0x0032fd58) 8 0x7eff3063 main+0x352(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/dlls/msvcp60/tests/../../../include/wine/test.h:584] in msvcp60_test (0x0032fe08) 9 0x7effac1f __wine_spec_exe_entry+0x6e(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in msvcp60_test (0x0032fe58) 10 0x7b85b55c call_process_entry+0xb() in kernel32 (0x0032fe78) 11 0x7b85c4ea start_process+0x59(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/kernel32/process.c:1104] in kernel32 (0x0032fea8) 12 0x7bc7a0b0 call_thread_func_wrapper+0xb() in ntdll (0x0032fec8) 13 0x7bc7cdc1 call_thread_func+0xb0(entry=0x7b85c490, arg=0x7ffdf000, frame=0x32ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2732] in ntdll (0x0032ffa8) 14 0x7bc7a08e call_thread_entry_point+0x11() in ntdll (0x0032ffc8) 15 0x7bc51b87 start_process+0x16(kernel_start=0x7b85c490) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2868] in ntdll (0x0032ffe8) 16 0xf75fd21d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 17 0xf75fd380 wine_switch_to_stack+0x1f(func=0x7bc51b70, arg=0x7b85c490, stack=0x330000) [/home/julliard/wine/wine/libs/wine/port.c:59] in libwine.so.1 (0xffb94238) 18 0x7bc56ef1 LdrInitializeThunk+0x1f0(kernel_start=<couldn't compute location>, unknown2=<couldn't compute location>, unknown3=<couldn't compute location>, unknown4=<couldn't compute location>) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2922] in ntdll (0xffb94278) 19 0x7b862213 __wine_kernel_init+0x9b2() [/home/julliard/wine/wine/dlls/kernel32/process.c:1276] in kernel32 (0xffb95168) 20 0x7bc57cb3 __wine_process_init+0x152() [/home/julliard/wine/wine/dlls/ntdll/loader.c:3131] in ntdll (0xffb951e8) 21 0xf75fae83 wine_init+0x2c2(argc=0x3, argv=0xffb95724, error="", error_size=0x400) [/home/julliard/wine/wine/libs/wine/loader.c:958] in libwine.so.1 (0xffb95238) 22 0x7bf00d6a main+0x79(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/loader/main.c:247] in <wine-loader> (0xffb95678) 23 0xf741ca63 __libc_start_main+0xf2() in libc.so.6 (0x00000000) 0x7bc4e659 RtlAllocateHeap+0x1e9 [/home/julliard/wine/wine/dlls/ntdll/../../include/wine/list.h:100] in ntdll: movl %edx,0x4(%eax) 100 elem->next->prev = elem->prev; -- Alexandre Julliard julliard(a)winehq.org

July 1, 2015

Re: [PATCH 1/6]: msvcp110: Add tr2_sys__Copy_file implementation and test.

by YongHaoHu

Hi, Piotr. On 15/6/30 下午8:25, Piotr Caban wrote: >>> Currently your implementation sometimes returns error even so it >>> succeeds. >>> >> Which one do you mean ? As you know, last_error hadling is not correct >> in wine's CopyFile, was this happened in Wine platform? > { "f1", "tr2_test_dir\\f1_copy", TRUE } > Your implementation returns error if f1_copy file already exists. It > only makes sense to use GetLastError if function have failed. > I had tested the ret and the last_error before in testbot. The result shows that the function's return value is exactly the same as GetLastError(). ret = p_tr2_sys__Copy_file(tests[i].source, tests[i].dest, tests[i].fail_if_exists); printf("ret is %d\n", ret); printf("GetLastError is %d\n\n", GetLastError()); Here is the test result: https://testbot.winehq.org/JobDetails.pl?Key=14885&log_101=1#k101 And { "f1", "tr2_test_dir\\f1_copy", TRUE } returns 80( ERROR_FILE_EXSITS).

July 1, 2015