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

Error handling in RpcBindingVectorFree (dlls/rpcrt4/rpc_binding.c)
by Gerald Pfeifer Nov. 22, 2020

Nov. 22, 2020

Looking at RPC_STATUS WINAPI RpcBindingVectorFree( RPC_BINDING_VECTOR** BindingVector ) { RPC_STATUS status; ULONG c; TRACE("(%p)\n", BindingVector); for (c=0; c<(*BindingVector)->Count; c++) { status = RpcBindingFree(&(*BindingVector)->BindingH[c]); } HeapFree(GetProcessHeap(), 0, *BindingVector); *BindingVector = NULL; return RPC_S_OK; } we currently always ignore the outcome of RpcBindingFree and return RPC_S_OK. However, there is one case where RpcBindingFree returns something different (which is if *Binding is null when RPC_S_INVALID_BINDING is returned). What is the proper way of handling this? Just keeping the code as is and removing the unused status variable? Breaking the loop once RpcBindingFree returns something different from RPC_S_OK? Continuing and returning the first / the last status different from RPC_S_OK? Gerald

1 1

ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces
by Qian Hong Sept. 28, 2018

Sept. 28, 2018

Dear all, While test another online bank with wine ActiveX, I got an unimplemented fuction of ntoskrnl: IoGetDeviceInterfaces, I found it listed in http://source.winehq.org/WineAPI/ntoskrnl.html as a stup, so I can't understand this log: wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called at address 0x7b839552 (thread 0022), starting debugger... Grateful for any explain! env: wine1.3.12 on Ubuntu 10.04 Here are the steps: 1. install an ActiveX from https://e.bank.ecitic.com/perbank5/plugs/CNCBSecPkg_EN.exe $ rm -rf ~/.wine $ winetricks -q mfc42 $ wine CNCBSecPkg_EN.exe fixme:ole:DllRegisterServer stub fixme:win:DisableProcessWindowsGhosting : stub fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:ole:CoCreateInstance no instance created for interface {ea1afb91-9e28-4b86-90e9-9e9f8a5eefaf} of class {56fdf344-fd6d-11d0-958a-006097c9a090}, hres is 0x80004002 fixme:sfc:SfcIsFileProtected ((nil), L"C:\\Program Files\\\4e2d\4fe1\94f6\884c\7f51\94f6\5b89\5168\63a7\4ef6\\unins000.exe") stub fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub! fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 -1: stub! fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub! wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called at address 0x7b839552 (thread 002b), starting debugger... wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting 2. open the online bank entry with wine builtin IE, then IE will crash: $ wine iexplore https://e.bank.ecitic.com/perbank5/signIn.do Please checkout the full log here: http://pastebin.com/rbAg7gwj Should I file a singel bug in ntoskrnl component , or separate bugs, one for ntoskrnl and one for the IE crashing? Generalliy what component should I switch while file a bug about IE crashing? Many thanks! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

5 6

ODBC Databases: Jet/Access success
by Barry Bird June 14, 2018

June 14, 2018

Good Afternoon. In section 3.3.6.2 of your User Guide you ask readers to report successes with databases other than MS SQL. Well here's one (I know Access 2000 can work with Wine, but this doesn't require Access): How to set up Wine to enable Windows programs that read and write to Jet (Access) databases using ODBC. I write such programs in C and use the API defined in ODBC API Reference http://msdn.microsoft.com/en-us/library/ms714562%28VS.85%29.aspx They work fine on Windows and only require Mingw to be installed to compile and link them, both for console programs and those using Windows SDK. You then can write interactive programs in C which use a full-featured SQL database which comes bundled with Windows. No need to purchase Access. With the set-up below they will also run on Linux (Kubuntu 9.04) and Wine 1.1.26. You need to update the registry to install the Access drivers. Under Windows, export from the Registry to *.reg files the registry entries - HKLM\Software\ODBC - HKLM\Software\Microsoft\Jet all subsidiary keys and values come with them. You can carefully edit these files to remove drivers and DSNs you don't need. Import these files using the registry editor in wine: wine regedit.exe. You need to bring across from Windows to Windows\System32 under wine: clbcatq.dll comres.dll expsrv.dll msjet40.dll mswstr10.dll msjter40.dll msjint40.dll msjtes40.dll msrd3x40.dll odbc32.dll odbccp32.dll odbcji32.dll odbcjt32.dll odbcad32.exe odbcint.dll odbctrac.dll vbajet32.dll Register this server in wine: wine regsvr32.exe msjtes40.dll No need to install MDAC. To use Windows ODBC drivers, you have to override Wine's odbccp32.dll and odbc32.dll with the native versions because the Wine versions are currently wired directly to Linux's unixodbc. This can be done by setting up the ODBC Data Source Administrator odbcad32.exe using winecfg: - Add the program to the Applications tab - then in the libraries tab, pick from 'New override for library' drop-down odbc32.dll and odbccp32.dll add them and edit them to be Native for Windows. Then if you do wine odbcad32.exe this brings up the ODBC Data Source Administrator window as in the Windows Control Panel If needed, set up (System) DSNs using this program. Bring across the programs and *.mdb database files from Windows. Using winecfg, you need to set up each program you want to run with overrides for odbc32.dll and odbccp32.dll (Applications and Libraries tabs) as above. The programs should then run as they did in Windows but perhaps a bit slower with: wine Odbc-prog.exe This has been tested twice on a clean .wine install. I cannot vouch for support of all API and SQL facilities however. I hope someone finds this useful. Barry Bird

5 4

IMM / IME work
by Aric Stewart June 16, 2016

June 16, 2016

Hello all, I know this will only interest a small portion of you but thought i would give a quick update on the state of IMM32 since I have brought it to a major milestone. All the main patches are in which now separate IMM32 and IMEs. There is still more work to do but the major framework is in place. X11 XIM processing should be unchanged. However wine can now begin to load native windows IMEs as well. I have tested with windows ATOK20 (a popular Japanese IME) and successfully had text processing in a fully IME aware application. There are still clear issues to resolve in many aspects of this processing but we have forward progress. ImmInstallIME does not work yet, nor does switching keyboards. So to get the native IME to work you need to add this registry key. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\<keyboard layout>] "Ime File"=<IME filename> so for example for ATOK20 in Japanese i used. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\e0010411] "Ime File"="ATOK20W.IME" I would love to hear how well things work. I am sure using native IMEs will quickly show us many places where IMM32 needs to be improved. One issues I am going to investigate next is that sometimes non x11drv ime initialization, if occurring too early, causes x11drv to fail to create windows. I have not investigated with the latest changes to xim.c (which may already correct this problem) but if you see this problem this patch may help and i believe the IME_UpdateAssociation(NULL) is already unneeded. diff --git a/dlls/winex11.drv/xim.c b/dlls/winex11.drv/xim.c index d4df9f7..0c98136 100644 --- a/dlls/winex11.drv/xim.c +++ b/dlls/winex11.drv/xim.c @@ -475,7 +475,6 @@ static void X11DRV_OpenIM(Display *display, XPointer ptr, XP XUnregisterIMInstantiateCallback(display, NULL, NULL, NULL, X11DRV_OpenIM, wine_tsx11_unlock(); IME_XIMPresent(TRUE); - IME_UpdateAssociation(NULL); } thanks, -aric

5 7

[PATCH] Use asserts for mmap failure modes
by Michael Gilbert July 26, 2015

July 26, 2015

Hi, Using exit in shared libraries is a discouraged practice, and wine's mmap implementation currently does that. I attach a proposed change using asserts instead. Let me know if you have any feedback. Best wishes, Mike (btw I'm the debian wine maintainer)

2 2

Re: XInput [1/4]: Implement XInputGetState
by Stefan Dösinger July 5, 2015

July 5, 2015

Am 09.07.2009 um 02:58 schrieb Michael Gruber: > This patch series implements parts of the XInput library. You can use > this to play games that support Xbox 360 Controllers. To be able to > use this you will need to have your Controller working on Linux via > the xpad kernel driver and the event interface. It will not work on > any OS other than Linux. It supports gamepads, should work with > guitars and wheels, but will not work with dance-mats. > <1-XInputGetState.patch> Is it possible to implement XInput on top of DirectInput? DirectInput already has some internal abstraction layers for differnet joystick APIs, and has basic support for OSX joysticks. Does DInput have enough capabilities to access all the Xbox controller's features? My gut says no, otherwise MS wouldn't have created a new lib. I guess its worth checking though.

5 6

Wine 64 bit
by Kevin Davies June 5, 2015

June 5, 2015

Hello, Where would you find information on wine64 status for running 64 bit windows software under OSX. These days a lot of Windows programs are going 64bit to make use of the available memory. Its becoming necessary to have this capability. Many thanks Kevin

13 31

Re: [PATCH] user32/tests: Test SetUserObjectInformation for invisible winstation.
by Alexandre Julliard April 23, 2015

April 23, 2015

Qian Hong <qhong(a)codeweavers.com> writes: > --- > dlls/user32/tests/winstation.c | 57 > ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 57 insertions(+) Can you please fix the test failures introduced by your previous changes first? cf. https://test.winehq.org/data/tests/user32:winstation.html -- Alexandre Julliard julliard(a)winehq.org

3 8

Re: [PATCH 8/9] wined3d: Filter messages generated by focus handling.
by Henri Verbeet Jan. 19, 2015

Jan. 19, 2015

On 4 December 2014 at 21:51, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > We may want to consider moving mode changes, window setup and focus loss > handling into the client libs. With this patch and the next one we have > 3 wined3d flags just for focus loss handling. Furthermore, dxgi yet > again has different behavior - it doesn't hook the window procedure and Yeah, possibly, although I'd also like to keep the amount of Win32 specific stuff in the public wined3d API to a minimum, so I'd rather not have the client libs e.g. handle window messages directly. > diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c > index ae6600e..89ec00a 100644 > --- a/dlls/wined3d/device.c > +++ b/dlls/wined3d/device.c > @@ -4961,7 +4961,7 @@ void device_invalidate_state(const struct wined3d_device *device, DWORD state) > LRESULT device_process_message(struct wined3d_device *device, HWND window, BOOL unicode, > UINT message, WPARAM wparam, LPARAM lparam, WNDPROC proc) > { > - if (device->filter_messages) > + if (device->filter_messages && message != WM_DISPLAYCHANGE) That seems pretty specific. I'd be curious how other broadcast messages are handled.

2 2

Re: [PATCH 9/9] wined3d: Pass WM_SYSCOMMAND(SC_RESTORE) to DefWindowProc.
by Henri Verbeet Jan. 19, 2015

Jan. 19, 2015

On 4 December 2014 at 21:51, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c > index 89ec00a..51dabd4 100644 > --- a/dlls/wined3d/device.c > +++ b/dlls/wined3d/device.c > @@ -4992,6 +4992,16 @@ LRESULT device_process_message(struct wined3d_device *device, HWND window, BOOL > > device->device_parent->ops->activate(device->device_parent, wparam); > } > + else if (message == WM_SYSCOMMAND) > + { > + if (wparam == SC_RESTORE && !(device->wined3d->flags & WINED3D_NO_SYSCOMMAND_HANDLING)) I'm not really a fan of this kind of double negative. The way the flag is used, it also seems to be about restores in particular instead of syscommands in general. > + { > + if (unicode) > + DefWindowProcW(window, message, wparam, lparam); > + else > + DefWindowProcA(window, message, wparam, lparam); > + } > + } > > if (unicode) > return CallWindowProcW(proc, window, message, wparam, lparam); Is this really how it's supposed to work? In particular, should DefWindowProc really always get the message before the application does, or should we give the application a chance first, and only pass to DefWindowProc if it doesn't handle the message?

2 2

Re: kernel32: Implement Get{Time,Date}FormatEx
by Nikolay Sivov Jan. 4, 2015

Jan. 4, 2015

On 30.12.2014 2:06, Sean Burke wrote: > Provides an implementation of time and date format functions added in > Vista sufficient to allow some basic applications requiring them to run. > Includes necessary tests and header defs. > > > Sean Burke > > > Hi, Sean. As you can see tests are failing on win2000 and winxp because these calls are not available on these platforms. You should use GetProcAddress() to fix that. > +@ stdcall GetDateFormatEx(ptr long ptr wstr ptr long ptr) First argument should be 'wstr' as well. > +@ stdcall GetTimeFormatEx(ptr long ptr wstr ptr long) Same. > +INT WINAPI GetDateFormatEx(LPCWSTR lpLocaleName, DWORD dwFlags, > + const SYSTEMTIME* lpDate, LPCWSTR lpFormat, > + LPWSTR lpDateStr, INT cchDate, LPCWSTR lpCalendar) Please use cleaner argument names, like 'localename', 'flags', 'date', 'format', etc. So lowercase, no prefix. > + lcid = LocaleNameToLCID(lpLocaleName, 0); > + > + return NLS_GetDateTimeFormatW(lcid, dwFlags | DATE_DATEVARSONLY, lpDate, > + lpFormat, lpDateStr, cchDate); No real need for temporary 'lcid' variable.

2 2

Re: secur32: Add support for ECDHE algorithms using gnutls
by Jacek Caban Jan. 4, 2015

Jan. 4, 2015

Hi Sean, On 12/30/14 00:08, Sean Burke wrote: > diff --git a/dlls/secur32/schannel_gnutls.c b/dlls/secur32/schannel_gnutls.c > index 638b3c5..810c598 100644 > --- a/dlls/secur32/schannel_gnutls.c > +++ b/dlls/secur32/schannel_gnutls.c > @@ -328,6 +328,8 @@ static ALG_ID schannel_get_kx_algid(gnutls_kx_algorithm_t kx) > switch (kx) > { > case GNUTLS_KX_RSA: return CALG_RSA_KEYX; > + case GNUTLS_KX_ECDHE_ECDSA: Shouldn't this case use CALG_ECDSA? > + case GNUTLS_KX_ECDHE_RSA: return CALG_ECDH; > case GNUTLS_KX_DHE_DSS: > case GNUTLS_KX_DHE_RSA: return CALG_DH_EPHEM; > default: Cheers, Jacek

2 1

Re: [PATCH] winealsa: support up to 6 channels
by Chris Robinson Jan. 2, 2015

Jan. 2, 2015

On 12/31/2014 01:34 PM, Mark Harmstone wrote: > Needed for surround sound. ALSA uses a different channel mapping for 5.1 than Windows. Windows wants: front-left, front-right, front-center, lfe, back-left*, back-right* while ALSA wants: front-left, front-right, back-left*, back-right*, front-center, lfe So you can't just pass the samples through without swapping them. * This is complicated by the fact that some 5.1 setups use the side channels instead of the back channels, and with the side channels the mappings are the same for both: front-left, front-right, front-center, lfe, side-left, side-right Technically 5.1 is supposed to use the side channels according to Dolby, but until recently Windows has used back and many speakers are color-coded to match the surround speakers to the back speaker jacks. The newer enumerant DSSPEAKER_5POINT1_SURROUND indicates it's using side channels, while the older DSSPEAKER_5POINT1 (aka DSSPEAKER_5POINT1_BACK) indicates the back channels.

2 1

Re: po: Update Portuguese translation
by Bruno Jesus Dec. 31, 2014

Dec. 31, 2014

On Wed, Mar 5, 2014 at 9:48 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > Sorry, the subtitle is wrong. Please prefer the update version.

1 1

Unicode Support in wine-devel
by 中川祥 Dec. 31, 2014

Dec. 31, 2014

This mailing list does not support any chinise and japanese character, so we cannot help feeling discriminated.

2 1

FOSDEM 2015
by Stefan Dösinger Dec. 31, 2014

Dec. 31, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've been asked by the gallium nine devs and a developer of one of the proprietary drivers if any one of us will be at FOSDEM in a month. Since we won't have a full-blown Wine room I'm wondering if the Wine Party Fund has enough resources to send myself (and/or Henri and Matteo if they're interested) to FOSDEM. My main agenda is to sit in the Xorg room for smalltalk. If there's interest on part of the Xorg developers I can give an updated performance talk like the last two years. If anyone is planning a Wine table I can help out with it, or talk to other upstream projects if anyone else here has any errands to take care of. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUoQCDAAoJEN0/YqbEcdMwiT0QAIGfxFvIiTwt3QeRaMiIc/07 AMnQ7/xCIj63hYUzAcR8Z0wzfGG1JH/nQmhu+tkNhCU4XMj8nZt0nD6YC/GGOytU 6mOFpbF902sbW4mtT18w0ZTIsZhU9rl6sufsPQiNnNRZGP61bo432NwYYlO29EKh n/rUO8WESxSzQjN73bF14J1r5d0GGB8q9cakkqi5zfQhOgBJHT3wijfumR/6wJI/ Xkccdzn4on0yaDLmnWQgpwu+kwDaZ5a48J48BlwFXi6zGoUmY/wIJPcdB9mwXm42 +k6lBmPyv5iPCbiMje6lvZajKdayKSc4MNyuURwrl3nBdtuXIFpQwrtJsjjILm3B CwL660h8yTbuFaGJQTY7fKyy8YxDGDnKKscrWzTyyFGe75I6eo4w1iMIsAy9dF9Q VP9J4+j2NYMozzxxB8nhrjvN7Cf67hKtvhJepeGDG6/JIMLR+ryksFhvMRNlDpjq 5gJOdWBqJJO/ODdzlhaUuqKfTyDGciwO6mljzyuWcnOA4eEd6fMVLkOpkvBvzQCc fGiV7nMjUi0aSkoctjgh7UNHFfqSbAnNfVum5h+iEYP/wdch2HBiZX5jbbjn3XzX ktkzcGN+Av+yfkB1AfNAWcSyaEGthzeEONtxduvoEgKH640tU2PhLOWLoyKNNaS2 xkRhiL5U4QV0cF7pFhSm =//r+ -----END PGP SIGNATURE-----

4 4

Re: [PATCH] msvcr120: Fixed a race condition in Concurrency::critical_section.
by Piotr Caban Dec. 31, 2014

Dec. 31, 2014

On 12/31/14 00:45, Yifu Wang wrote: > @@ -380,11 +393,18 @@ void __thiscall critical_section_lock(critical_section *this) > memset(&q, 0, sizeof(q)); > last = InterlockedExchangePointer(&this->tail, &q); > if(last) { > + /* If last == &this->unk_active, the current thread might be racing setting > + * unk_active.next with another thread calling cs_set_head(). If the current > + * thread sets unk_active.next first, the data structure would be left in an > + * inconsistent state and causes hang. Spin waiting until unk_active.next > + * becomes NULL solves the race condition. > + */ > + if(last == &this->unk_active) > + spin_wait_for_next_null(&this->unk_active); > last->next = &q; > NtWaitForKeyedEvent(keyed_event, &q, 0, NULL); > } > > - this->unk_active.next = NULL; > if(InterlockedCompareExchangePointer(&this->tail, &this->unk_active, &q) != &q) > spin_wait_for_next_cs(&q); > cs_set_head(this, &q); There's still a race with your patch. There's no guarantee that this->unk_active.next != NULL before cs_set_head(this, &q) is called. Changing the place where cs_set_head is called should fix the issue in cleaner way: diff --git a/dlls/msvcrt/lock.c b/dlls/msvcrt/lock.c index 328b5b5..e2ebef3 100644 --- a/dlls/msvcrt/lock.c +++ b/dlls/msvcrt/lock.c @@ -384,10 +397,11 @@ void __thiscall critical_section_lock(critical_section *this) NtWaitForKeyedEvent(keyed_event, &q, 0, NULL); } - this->unk_active.next = NULL; - if(InterlockedCompareExchangePointer(&this->tail, &this->unk_active, &q) != &q) - spin_wait_for_next_cs(&q); cs_set_head(this, &q); + if(InterlockedCompareExchangePointer(&this->tail, &this->unk_active, &q) != &q) { + spin_wait_for_next_cs(&q); + this->unk_active.next = q.next; + } } /* ?try_lock(a)critical_section@Concurrency@@QAE_NXZ */ There's also similar race in critical_section_try_lock and critical_section_try_lock_for function. Could you please also fix it there? Thank you, Piotr

1 0

Re: wininet: Handle CERT_TRUST_IS_NOT_SIGNATURE_VALID in netconn_verify_cert()
by 中川祥 Dec. 31, 2014

Dec. 31, 2014

Yes.it will fix, but the function is not implemented yet,too. On 2014年12月31日(水) PM2:47 Bruno Jesus <00cpxxx(a)gmail.com> wrote: > The application hits a CERT_TRUST_IS_NOT_SIGNATURE_VALID, and only > passes the flag SECURITY_FLAG_IGNORE_UNKNOWN_CA. Currently wine is not > able to ignore this error and aborts. > > This is an extension to the work added by commit > http://source.winehq.org/git/wine.git/commitdiff/ > e2a9511b30e5b68eb328c08ffecf56dcc91bce0b > > Fixes https://bugs.winehq.org/show_bug.cgi?id=36785 > >

1 0

Re: 答复: zh_CN Translation Submittion
by Jactry Zeng Dec. 30, 2014

Dec. 30, 2014

Hi Jeff, Thanks for your work! Most of them look good to me. I would like to discuss these cases with you guys :) : 1. #: crypt32.rc:30 msgid "Authority Key Identifier" -msgstr "" +msgstr "权限键值辨识" #: crypt32.rc:31 msgid "Key Attributes" -msgstr "" +msgstr "键值属性" #: crypt32.rc:32 msgid "Key Usage Restriction" -msgstr "" +msgstr "键值使用限制" #: crypt32.rc:36 msgid "Key Usage" -msgstr "" +msgstr "键值使用" #: crypt32.rc:38 msgid "Subject Key Identifier" -msgstr "" +msgstr "对象键值辨识" #: crypt32.rc:41 msgid "Enhanced Key Usage" -msgstr "" +msgstr "高级键值使用" I'm not sure is 'key' here same as 'key'(秘钥) in 'Public Key', or 'key value'(键) in Registry. 2. #: crypt32.rc:52 msgid "Challenge Password" -msgstr "" +msgstr "Challenge Password" Don't modify it if you didn't translate it. 3. #: crypt32.rc:54 msgid "S/MIME Capabilities" -msgstr "" +msgstr "S/MIME 能力" Maybe '功能' is better than '能力' ? 4. #: crypt32.rc:57 cryptdlg.rc:35 msgid "User Notice" -msgstr "" +msgstr "用户告示" I'll prefer '用户通知' here. ;) 5. #: crypt32.rc:72 msgid "Organization" -msgstr "" +msgstr "阻止" Typo. 6. #: crypt32.rc:74 msgid "Common Name" -msgstr "" +msgstr "统称" Do you think '常用名' will be more proper? 7. #: crypt32.rc:91 msgid "Enrollment CSP" -msgstr "" +msgstr "招入 CSP" I prefer '注册' which you did in line 381. 8. #: crypt32.rc:93 msgid "Delta CRL Indicator" -msgstr "" +msgstr "增量 CRL 指示器" '指示器' or '指示符', which will be better? I'm not sure, but you can find some documents with 'CRL 指示符' with Google. 9. #: crypt32.rc:104 msgid "CMC Response" -msgstr "" +msgstr "CMC 回应" I'll prefer 'CMC 响应'. 10. #: crypt32.rc:193 msgid "Unknown Key Usage" -msgstr "" +msgstr "未知密钥使用" What about '未知密钥用法'? 11. #: cryptui.rc:192 msgid "Issuer &Statement" -msgstr "" +msgstr "颁发者陈述 (&S)" One more unnecessary space after '述'? 12. #: cryptui.rc:408 msgid "&DER-encoded X.509 (*.cer)" -msgstr "" +msgstr "&DER 编码的 X.509 (*.cer) (&D)" #: cryptui.rc:410 msgid "Ba&se64-encoded X.509 (*.cer):" -msgstr "" +msgstr "Ba&se64 编码的 X.509 (*.cer): (&S)" #: cryptui.rc:412 msgid "&Cryptographic Message Syntax Standard/PKCS #7 Message (*.p7b)" -msgstr "" +msgstr "加密消息语法标准/PKCS #7 消息 (*.p7b) (&C)" #: cryptui.rc:414 msgid "&Include all certificates in the certification path if possible" -msgstr "" +msgstr "如果可能，将所有证书包含在证书目录 (&I)" #: cryptui.rc:416 msgid "&Personal Information Exchange/PKCS #12 (*.pfx)" -msgstr "" +msgstr "个人信息交换/PKCS #12 (*.pfx) (&P)" Should we use brackets in SBC case here? It'll be "+msgstr "个人信息交换/PKCS #12（*.pfx） (&P)" . 13. #: cryptui.rc:61 msgid "%1 (%2!d! bits)" -msgstr "" +msgstr "%1 (%2!d! 位)" Ditto. 14. #: cryptui.rc:67 msgid "Please enter an OID in the form 1.2.3.4" -msgstr "" +msgstr "请在表单 1.2.3.4 输入对象 ID (OID)" #: cryptui.rc:68 msgid "The OID you entered already exists." -msgstr "" +msgstr "你输入的对象 ID (OID) 已经存在" Ditto. 15. #: cryptui.rc:77 msgid "X.509 Certificate (*.cer; *.crt)" -msgstr "" +msgstr "X.509 证书 (*.cer; *.crt)" #: cryptui.rc:78 msgid "Personal Information Exchange (*.pfx; *.p12)" -msgstr "" +msgstr "个人信息交换 (*.pfx; *.p12)" #: cryptui.rc:79 cryptui.rc:158 msgid "Certificate Revocation List (*.crl)" -msgstr "" +msgstr "证书吊销列表 (*.crl)" #: cryptui.rc:80 cryptui.rc:159 msgid "Certificate Trust List (*.stl)" -msgstr "" +msgstr "证书信任列表 (*.stl)" #: cryptui.rc:82 msgid "CMS/PKCS #7 Messages (*.spc; *.p7b)" -msgstr "" +msgstr "CMS/PKCS #7 消息 (*.spc; *.p7b)" Ditto. 16. #: cryptui.rc:114 msgid "" @@ -2678,6 +2693,8 @@ "trusted.\n" "Are you sure you want to remove this certificate?" msgstr "" +"用此证书颁发机构颁发的证书将不会被继续信任。\n" +"你确定要移除此证书吗？" #: cryptui.rc:115 msgid "" @@ -2685,6 +2702,8 @@ "trusted.\n" "Are you sure you want to remove these certificates?" msgstr "" +"用这些证书颁发机构颁发的证书将不会被继续信任。\n" +"你确定要移除这些证书吗？" #: cryptui.rc:116 msgid "" @@ -2692,6 +2711,8 @@ "certification authorities it issued, will no longer be trusted.\n" "Are you sure you want to remove this trusted root certificate?" msgstr "" +"用此根证书颁发机构颁发的或任何受颁发的证书颁发机构的证书将不会被继续信任。\n" +"你确定要移除这个受信任的根证书吗？" #: cryptui.rc:117 msgid "" @@ -2699,6 +2720,8 @@ "certification authorities they issued, will no longer be trusted.\n" "Are you sure you want to remove these trusted root certificates?" msgstr "" +"用这些根证书颁发机构颁发的或任何受颁发的证书颁发机构的证书将不会被继续信任。\n" +"你确定要移除这些受信任的根证书吗？" Is '用' a typo of '由' here? 17. #: cryptui.rc:156 msgid "DER-Encoded Binary X.509 (*.cer)" -msgstr "" +msgstr "DER 编码的二进制 X.509 (*.cer)" #: cryptui.rc:157 msgid "Base64-Encoded X.509 (*.cer)" -msgstr "" +msgstr "Ba&se64 编码的 X.509 (*.cer)" #: cryptui.rc:160 msgid "CMS/PKCS #7 Messages (*.p7b)" -msgstr "" +msgstr "CMS/PKCS #7 消息 (*.p7b)" #: cryptui.rc:161 msgid "Personal Information Exchange (*.pfx)" -msgstr "" +msgstr "个人信息交换 (*.pfx)" Same as 12. 18. #: gdi32.rc:42 msgid "Hangul(Johab)" -msgstr "" +msgstr "韩文（裘哈）" Is '裘哈' typo of '朝鲜语'? 19. #: inetcpl.rc:32 msgid "Configure Wine Internet Browser and related settings" -msgstr "" +msgstr "配置 Wine Internet Explorer 以及相关设置" Here is 'Wine Internet Browser', I think 'Wine Internet 浏览器' will be better. What about you? 20. #: inetcpl.rc:35 msgid "Very Low" -msgstr "" +msgstr "非常低" What about '极低' ? When 'Medium' is '中等' and 'Increased' is '较高'. 21. #: winecfg.rc:227 msgid "" @@ -12790,8 +12734,7 @@ msgstr "" "你确定要删除 C 盘吗？\n" "\n" -"大部分 Windows 程序都假定 C 盘存在，在没有它时会死得很难看。如果要继续，请记" -"得重新建立一个！" +"大部分 Windows 程序都假定 C 盘存在，在没有它时会死得很难看。如果要继续，请记得重新建立一个！" Translation here is facetious but I don't think it's appropriate. :-p Can we translate '死得很难看' to "严重出错" ? Finally, you should resend the patch to wine-patches, not provide a link of the patch. The wiki page provided by Nikolay may help. Thanks again! 2014-12-16 8:24 GMT+08:00 Jeff Bai <jeffbaichina(a)gmail.com>: > > ---------- Forwarded message ---------- > From: Jeff Bai <jeffbaichina(a)gmail.com> > Date: Mon, Dec 15, 2014 at 5:02 PM > Subject: Re: 答复: zh_CN Translation Submittion > To: Nikolay Sivov <bunglehead(a)gmail.com> > > Okay, got the part fixed. Sorry about that. More translation will be > coming and I will be editing them with a text editor instead. > > https://pastebin.anthonos.org/view/30fbda6b > > Regards, > Jeff Bai > > On Mon, Dec 15, 2014 at 2:42 PM, Nikolay Sivov <bunglehead(a)gmail.com> > wrote: >> >> On 16.12.2014 0:01, Jeff Bai wrote: >> >>> The problem is I'm not sure how to fix them. >>> >> >> How to fix what? Just open a file in a text editor and make changes there. >> >> ------------------------------------------------------------------------ >>> 发件人: Nikolay Sivov <mailto:bunglehead(a)gmail.com> >>> 发送时间: ‎2014/‎12/‎15 13:08 >>> 收件人: Jeff Bai <mailto:jeffbaichina(a)gmail.com> >>> 抄送: wine-devel(a)winehq.org <mailto:wine-devel(a)winehq.org> >>> >>> 主题: Re: zh_CN Translation Submittion >>> >>> >>> On 15.12.2014 17:39, Jeff Bai wrote: >>> > Umm... I think POEdit is the one who made these changes... Not sure >>> if it's my settings or what. >>> >>> Yes, it's mostly likely it. But you don't have to use it, your favorite >>> text editor will work just fine. >>> >>> > >>> > >>> >> 在 2014年12月15日，上午12:01，Nikolay Sivov <bunglehead(a)gmail.com> >>> 写道： >>> >> >>> >>> On 15.12.2014 7:53, Jeff Bai wrote: >>> >>> Hello, fellow developers. >>> >>> >>> >>> I've got several hundred strings translated to zh_CN, and according >>> to >>> >>> you guys' wiki I am supposed to submit a patch of what I've changed. >>> >>> >>> >>> So here it is (too long, used PasteBin) >>> >>> >>> >>> https://pastebin.anthonos.org/view/bb82ca07 >>> >>> >>> >>> Also, I am not sure if I would be fast enough to get them all done >>> by >>> >>> 1.7.34 (nearly two weeks apart?), so is it Okay for me to submit >>> them >>> >>> bit by bit, like this time, several hundred? There's still about 950 >>> >>> left as I can see on POEdit - and I think I can push this to 100% >>> after >>> >>> my high school final four days later. >>> >>> >>> >>> Thanks everyone, Wine is AWESOME. >>> >>> >>> >>> Regards, >>> >>> >>> >>> Jeff Bai (白铭骢) >>> >> >>> >> Hi, Jeff. >>> >> >>> >> I think it's okay to submit full diff at once. But please avoid >>> changing original messages like you do here (or maybe not you directly >>> but poedit): >>> >> >>> >>> #: oleview.rc:121 >>> >>> -msgid "" >>> >>> -"Toggle the display of component categories that are not meant to >>> be visible" >>> >>> +msgid "Toggle the display of component categories that are not >>> meant to be visible" >>> >>> msgstr "切换隐藏组件类显示" >>> >> >>> >> So keep msgid part as it is and touch only msgstr part, this will >>> also help reducing resulting diff. >>> >> >>> >> And once you fixed that you should send a patch to >>> wine-patches(a)winehq.org as it says here >>> http://wiki.winehq.org/SubmittingPatches. >>> >>> >> > > > -- Regards, Jactry Zeng

2 1

Re: kernel32: Implement Get{Time,Date}FormatEx
by Marvin Dec. 29, 2014

Dec. 29, 2014

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=10947 Your paranoid android. === w2000pro (32 bit locale) === The test timed out === wxppro (32 bit locale) === The test timed out

1 0

Any last UTF-7 comments?
by Alex Henrie Dec. 29, 2014

Dec. 29, 2014

Now that Alexandre has merged a complete set of UTF-7 tests, are there any more comments on the two implementation patches before I submit those as well? https://github.com/alexhenrie/wine/commits/master -Alex

1 0

Re: [PATCH] dsound: allow LOCHARDWARE flag
by Alexandre Julliard Dec. 29, 2014

Dec. 29, 2014

Mark Harmstone <hellas(a)burntcomma.com> writes: > @@ -975,12 +975,6 @@ HRESULT DirectSoundDevice_CreateSoundBuffer( > TRACE("(lpwfxFormat=%p)\n",dsbd->lpwfxFormat); > } > > - if (dsbd->dwFlags & DSBCAPS_LOCHARDWARE && > - !(dsbd->dwFlags & DSBCAPS_PRIMARYBUFFER)) { > - TRACE("LOCHARDWARE is not supported, returning E_NOTIMPL\n"); > - return E_NOTIMPL; > - } > - It breaks the tests: ../../../tools/runtest -q -P wine -T ../../.. -M dsound.dll -p dsound_test.exe.so dsound && touch dsound.ok dsound.c:1705: Test failed: CreateSoundBuffer(1) gave wrong error: 00000000 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ntdll: fix read_directory_getdirentries() under FreeBSD.
by André Hentschel Dec. 29, 2014

Dec. 29, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 28.12.2014 um 21:09 schrieb David Naylor: > > Change the handling of getdirentries(2) by: - tracking the data pointer instead of subtracting 'res' - simplify rewind by skipping re-appending entries onto the list - try make the logic easier to follow --- dlls/ntdll/directory.c | 73 +++++++++++++++++++------------------------------- 1 file changed, 28 insertions(+), 45 deletions(-) Hi and welcome to Wine development, maybe it's just me, but the patch is not easy to review. Is it possible to split the patch into multiple atomic patches (maybe three, as in the change list you provided)? Also, how does the patch fix Wine on FreeBSD? A quick look at the patch itself: You missed a whitespace at the last lseek call. You're adding a FIXME comment, but you should rather clarify your question, use wine-devel and/or IRC and/or "git blame" for that. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQGcBAEBAgAGBQJUoVfbAAoJEGm5GZTakYssGkoMAIfOM3ulOIh28PKA3RS0IByC sEk8AerEkKyN2nS4d2hNRU/kHIFlW+wHfi8Ah7FhBGepZ0HIHrWqZhuMmZsYx1W/ MeYyW+bROa+uCGWYvz7w9aaXW+xOIKDaJ7mIQrJKnkMgOQ3FFI8yKa6tRSSAm6iA Xg2porB96Ov+lLcl6zq0UATuVgqENhzSRrMxHh/YhVwK3xO7hSQ4ysgMJj2cBg7A XX7cEdxys1X5kSAO10I/gucmtKe3GrQi++DWx6VUd1O4WIEtm86c1gO2UtbUxYNf p9q5feajTJLscWOKpaC032fLrfFcnkhSS1ZwyIl7TfICaWW6u+8zfrcrVG8xfPkR MfbCRrJpkCFXsa5bYJLTPdD+0LETPlJ48zkyRyny56XYwgkBlgPirVlCeYnSZs9t CCOaHYYrMePAyB1DLZeJIdCCmyy8gLlY9cu28SgbN/oaHuYtwfrPbXKt30fwhZyM cOcTZnZZuYSeb5oVt72O+j0GbkSW2x+juFuVhyBvlw== =RACU -----END PGP SIGNATURE-----

2 3

Re: secur32: Always tell the user that libgnutls could not be loaded
by Henri Verbeet Dec. 29, 2014

Dec. 29, 2014

On 28 December 2014 at 13:00, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > Ensures a message is printed in the standard output to make the > problem obvious. Will solve problems like the one in > https://bugs.winehq.org/show_bug.cgi?id=35180#c4: > You'd probably want that to go to the winediag channel then.

1 0

Re: [PATCH] dsound: allow LOCHARDWARE flag
by Andrew Eikum Dec. 29, 2014

Dec. 29, 2014

Mark's dsound and alsa patches look OK to me. Andrew On Sun, Dec 28, 2014 at 01:54:27PM +0000, Mark Harmstone wrote: > Patch to allow DSound buffers to be created with the DSBCAPS_LOCHARDWARE > flag. There's been no audio hardware acceleration on Windows since XP, so > this flag is meaningless nowadays anyway - but X3DAudio will refuse to > create a buffer of more than two channels if it's not accepted. > > --- > dlls/dsound/dsound.c | 6 ------ > 1 file changed, 6 deletions(-) > > > diff --git a/dlls/dsound/dsound.c b/dlls/dsound/dsound.c > index 8df778a..eaa4247 100644 > --- a/dlls/dsound/dsound.c > +++ b/dlls/dsound/dsound.c > @@ -975,12 +975,6 @@ HRESULT DirectSoundDevice_CreateSoundBuffer( > TRACE("(lpwfxFormat=%p)\n",dsbd->lpwfxFormat); > } > > - if (dsbd->dwFlags & DSBCAPS_LOCHARDWARE && > - !(dsbd->dwFlags & DSBCAPS_PRIMARYBUFFER)) { > - TRACE("LOCHARDWARE is not supported, returning E_NOTIMPL\n"); > - return E_NOTIMPL; > - } > - > if (dsbd->dwFlags & DSBCAPS_PRIMARYBUFFER) { > if (dsbd->lpwfxFormat != NULL) { > WARN("invalid parameter: dsbd->lpwfxFormat must be NULL for " > >

1 0

Re: [PATCH] dsound: convert freqAdjust and freqAcc to integers
by Andrew Eikum Dec. 29, 2014

Dec. 29, 2014

On Sat, Dec 27, 2014 at 11:41:07PM +0100, Marton Balint wrote: > Fixes resamping errors caused by truncating floating point numbers. These > errors were responsible for clicking noises when resampling from 44100 to 48000 > Hz, as mentioned in bug 35971. > I was able to reproduce this, and this patch fixes it. Looks good to me. Andrew

1 0

Re: [PATCH] msvcr120: Implemented Concurrency::details::_Condition_variable. (try 2)
by Piotr Caban Dec. 29, 2014

Dec. 29, 2014

On 12/26/14 20:20, Yifu Wang wrote: > --- > dlls/msvcp90/msvcp90.h | 23 ++++ > dlls/msvcr120/msvcr120.spec | 36 +++--- > dlls/msvcr120/tests/msvcr120.c | 267 ++++++++++++++++++++++++++++++++++++++-- > dlls/msvcrt/lock.c | 172 ++++++++++++++++++++++++++ > 4 files changed, 471 insertions(+), 27 deletions(-) The tests are sometimes failing for me (on windows): msvcr120: 74522 tests executed (0 marked as todo, 0 failures), 0 skipped. msvcr120.c:381: Test failed: produced != consumed msvcr120: 108919 tests executed (0 marked as todo, 1 failure), 0 skipped. Thanks, Piotr

1 0

Re: iphlpapi: add FreeMibTable implementation (try 2)
by Nikolay Sivov Dec. 28, 2014

Dec. 28, 2014

On 27.12.2014 7:04, Austin English wrote: > > +/****************************************************************** > + * FreeMibTable (IPHLPAPI.@) > + * > + * Free buffer allocated by network functions > + * > + * PARAMS > + * ptr [In] pointer to the buffer to free > + * > + * RETURNS > + * Success: TRUE > + * Failure: FALSE As Thomas pointed out, this is wrong. > + */ > +void WINAPI FreeMibTable (PVOID *ptr) > +{ > + TRACE("(ptr %p): stub\n", ptr); > + HeapFree(GetProcessHeap(), 0, ptr); > +} Argument type should be 'void *'. Trace message could be just '(%p)\n'.

1 0

Re: iphlpapi: add FreeMibTable implementation (try 2)
by Thomas Faber Dec. 28, 2014

Dec. 28, 2014

> Try 2: fixed specfile, comment Actually the fixed comment still seems wrong since the function returns void ;)

1 0

CSMT patch
by Emanuele Oriani Dec. 28, 2014

Dec. 28, 2014

Hi Wine Devs/Stefan, Can you please give us an update in regards to the CSMT patch? Do you plan to integrate it in mainline? If not "officially", would be possible to have it in as an experimental code-path (default off)? What are the obstacles of making this happen? What is your view? Again, I believe this patch is superior to just NVIDIA Threaded Optimizations; on applications such as Starcraft II I get +150% FPS and performance is comparable to windows (if not better). I believe many other games would benefit from this great improvement. Cheers, Emanuele

5 6

Re: iphlpapi: add FreeMibTable implementation
by Dmitry Timoshkov Dec. 26, 2014

Dec. 26, 2014

Austin English <austinenglish(a)gmail.com> wrote: > -#@ stub FreeMibTable > +@ stub FreeMibTable( ptr ) This won't work as expected. -- Dmitry.

2 1

Re: gdi32: add FreeMibtable implementation
by Bruno Jesus Dec. 26, 2014

Dec. 26, 2014

On Sat, Dec 27, 2014 at 12:51 AM, Austin English <austinenglish(a)gmail.com> wrote: > https://bugs.winehq.org/show_bug.cgi?id=36092 Wrong patch subject? Shouldn't it be: iphlpapi: Add FreeMibTable implementation > -- > -Austin > > >

2 1

Re: [PATCH (resend)] kernel32/tests: Add tabular UTF-7 encoding tests.
by Alex Henrie Dec. 24, 2014

Dec. 24, 2014

Alexandre, I need to know why you are ignoring this patch so that I can improve it to meet your standards. -Alex

1 1

Holidays
by Alexandre Julliard Dec. 24, 2014

Dec. 24, 2014

Folks, Like probably most of you, I will be out for a few days for the holidays, so I'm going to skip this week's release. I expect things to be fairly slow next week too. I'll still commit patches when I'm around, but the next release will be on January 9. Enjoy your holidays! -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] dsound: do not allow adding a NULL ptr as buffer in DirectSoundDevice_AddBuffer()
by Nikolay Sivov Dec. 24, 2014

Dec. 24, 2014

On 12/24/2014 04:55 PM, Pierre Schweitzer wrote: > Dear all, > > Please find attach a patch which prevents DirectSoundDevice_AddBuffer() > from accepting NULL pointers. > It results from a bugfix & testing here. While trying to start Steam > Lego Star Wars, I was experiencing an invalid address dereference in > DSOUND_ChangeListener() (line 312). > > Adding this check makes the game work properly (with sound). I tested it. > > Cheers, > Please add a test for that.

2 2

Re: mshtml: Allow '#' to be the first char of resource name in res protocol.
by Marvin Dec. 24, 2014

Dec. 24, 2014

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=10902 Your paranoid android. === w2000pro (32 bit protocol) === protocol.c:259: Test failed: expected ReportProgress protocol.c:259: Test failed: expected ReportProgress

1 0

Re: [PATCH 4/4] mshtml: Added script element readyState and onreadystatechange tests.
by Marvin Dec. 24, 2014

Dec. 24, 2014

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=10901 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [PATCH] msvcp120: Implemented xtime functions.
by Piotr Caban Dec. 23, 2014

Dec. 23, 2014

Hi, the tests are failing on windows (and sometimes on wine). Please also test return value of xtime_get and check if values returned by it are similar to what native does. Thanks, Piotr

1 0

Re: [PATCH] msvcr120: Implemented Concurrency::details::_Condition_variable.
by Piotr Caban Dec. 23, 2014

Dec. 23, 2014

Hi, I was not really looking on this patches yet but I've seen few issues: - you forgot to call init_thiscall_thunk function - there are some compilation warnings - the tests are not passing on windows Thanks, Piotr

1 0

Re: [PATCH 2/3] gdiplus: fix get_clip_hrgn when window origin point changed
by Dmitry Timoshkov Dec. 22, 2014

Dec. 22, 2014

"Changhui Liu" <liuchanghui(a)linuxdeepin.com> wrote: > --- a/dlls/gdiplus/graphics.c > +++ b/dlls/gdiplus/graphics.c > @@ -350,7 +350,18 @@ static void gdi_alpha_blend(GpGraphics *graphics, INT dst_x, INT dst_y, INT dst_ > static GpStatus get_clip_hrgn(GpGraphics *graphics, HRGN *hrgn) > { > /* clipping region is in device coords */ > - return GdipGetRegionHRgn(graphics->clip, NULL, hrgn); > + GpStatus state = GdipGetRegionHRgn(graphics->clip, NULL, hrgn); Please use 'status' instead of 'state'. > + if (graphics->hdc) > + { This should be if (status == Ok && graphics->hdc) > --- a/dlls/gdiplus/tests/graphics.c > +++ b/dlls/gdiplus/tests/graphics.c > @@ -5603,6 +5603,95 @@ static void test_GdipGetVisibleClipBounds_memoryDC(void) > ReleaseDC(hwnd, dc); > } > > +#define BLUE_COLOR (0xff0000ff) > +#define IsBlue(color) ( ((color) & 0x00ffffff) == 0xff ) > +#define GetBitmapPixel(x,y) pixel[(y)*(width) + (x)] Inline helpers without Win32 API resembling names would be better. Something like is_blue_color, get_bitmap_pixel. Same applies for remaining code. -- Dmitry.

1 0

Re: [PATCH 1/3] gdiplus: fix get_graphics_bounds when window origin point changed
by Dmitry Timoshkov Dec. 22, 2014

Dec. 22, 2014

"Changhui Liu" <liuchanghui(a)linuxdeepin.com> wrote: > @@ -5619,7 +5674,7 @@ START_TEST(graphics) > test_alpha_hdc(); > test_bitmapfromgraphics(); > test_GdipFillRectangles(); > - > + test_GdipGetVisibleClipBounds_memoryDC(); > GdiplusShutdown(gdiplusToken); > DestroyWindow( hwnd ); > } An empty line before GdiplusShutdown is intentional and makes it clearer to separate tests from the clean up. Please keep it that way. -- Dmitry.

1 0

Re: gdiplus: fix GdipFillRectangleI no effect on memoryDCwhosewindoworiginpoint has changed
by Changhui Liu Dec. 22, 2014

Dec. 22, 2014

Hi, > I would prefer that you use the expect() macro when comparing integers in tests. > >If you don't expect a function (in this case GetDIBits, in patch 2) to >fail when running a test, use ok() to check that it succeeded. It's OK >if the test will crash when the ok() check fails. > >If GetDIBits really does fail sometimes, we need to understand why >that happens and document it in the test. > >When writing comments about this, make sure you specify that you are >talking about gdi32 device coordinates, which are different from >gdiplus device coordinates. I have modified, please see the new patch file. >+ status = GdipSetClipRectI(graphics, rect.left+width/2, rect.top+height/2, >+ rect.right, rect.bottom, CombineModeReplace); > >This looks wrong to me. GdipSetClipRectI takes a width and height, not >right and bottom. The above statement is setting a clip range: (rect.left+width/2, rect.top+height/2) - (rect.left+rect.right+width/2, rect.top+rect.bottom+height/2). Because the rect is {100, 100, 180, 180}, so the clip range is: (140,140) - (320,320). In fact GdipSetClipRectI can take any int value to specify a clip region. But according to your advice, I have changed to take a width and height . For helping review, I attached a BMP file which is the output of each test_GdipFillRectangle drawing on Memory DC. Thank you. ------------------ Regards.

3 4

Re: [PATCH 2/3] urlmon: Skip query and hash part in find_mime_from_url.
by Marvin Dec. 22, 2014

Dec. 22, 2014

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=10873 Your paranoid android. === w2000pro (32 bit misc) === misc.c:723: Test failed: [5] wrong mime: L"text/plain" === wxppro (32 bit misc) === misc.c:723: Test failed: [5] wrong mime: L"text/plain"

1 0

Re: mshtml: Added IHTMLDOMTextNode::splitText implementation.
by Marvin Dec. 21, 2014

Dec. 21, 2014

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=10849 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: shell32: Added stub IPropertyStore for a shell link object
by Marvin Dec. 20, 2014

Dec. 20, 2014

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=10846 Your paranoid android. === wxppro (32 bit shelllink) === shelllink.c:1170: Test failed: got 0x80004002 shelllink: unhandled exception c0000005 at 0041529E

1 0

Re: [PATCH] libs/wine/string.c: Duplicate Windows behaviour in vsnprintfW
by Hugh McMaster Dec. 20, 2014

Dec. 20, 2014

Sorry, I didn't see your message as it was sent to wine-patches. On Thursday, 18 Dec 2014 18:09:01 +0100, Jonathan Vollebregt wrote: >> If buffer or format is NULL, or if count is less than or equal to zero, these functions invoke the invalid parameter handler, as described in Parameter Validation. If execution is allowed to continue, these functions return -1 and set errno to EINVAL. >This doc says that vsnprintf *should* always return -1 given your example. Yes, MSDN does say that. >Is there a test that shows the MSDN docs are wrong? I'm not sure if Wine has one, but I'll check. Running multiple tests with Visual Studio 2013 on Windows 7 64-bit returns the number of chars that would be written for vsnprintf(NULL, 0, fmt, args). -1 is returned in cases when "the number of characters to write is greater than count". So some examples would be vsnprintf(valid buffer, 0, fmt, args) or vsnprintf(very small buffer, 8, fmt, args). >On 12/18/2014 11:57 AM, Hugh McMaster wrote: >> Recent discussions on the wine-devel mailing list conclude that Wine's vsnprintfW must duplicate Windows' vsnprintf behaviourW[1]. >> >> Currently, there are two issues. >> >> 1. vsnprintfW(NULL, 0, fmt, args). Both Windows and GCC allow these arguments. Both return the number of chars that would be written in this instance. Wine returns -1, which is incorrect. >> >> 2. vsnprintfW(some buffer, 0, fmt, args). Both Windows and Wine return -1, but in this case, Wine does this by default. We need to maintain this behaviour. >> >> To fix these inconsistencies, we need to add an 'else' block to the check for len (i.e. checking for a non-zero value). Then we check for a NULL pointer. If true, we return (int)written, like Windows and GCC do, because vsnprintfW(NULL, 0, fmt, args) was called. >> >> This patch fixes these issues. >> >> [1] https://www.winehq.org/pipermail/wine-devel/2014-December/106066.html

3 3

Re: gdiplus: fix GdipFillRectangleI no effect on memory DC whose windoworigin point has changed
by Vincent Povirk Dec. 19, 2014

Dec. 19, 2014

- rect->X = 0; - rect->Y = 0; + /*The user maybe has called SetWindowOrgEx to change origin point*/ + POINT pt = {0, 0}; + GetWindowOrgEx(graphics->hdc, &pt); + rect->X = pt.x; + rect->Y = pt.y; I don't think we should use GetWindowOrgEx in gdiplus. There are too many ways to change the mapping of co-ordinates for an HDC, and it doesn't make sense to specifically account for them all. In get_graphics_bounds, we already have code that accounts for the HDC transform using DPtoLP. Maybe we should do that even when GetMapMode == MM_TEXT. Transforming the region in alpha_blend_pixels_hrgn looks wrong to me, because we can't do that in the general case. Logical coordinates on the HDC may not be pixels. Your test is very unclear. A good test for this should make it obvious how the HDC's transform affects GDI+ world coordinates. If I fill a rectangle at (0,0) using GDI+, on an HDC with window origin (5,5), what is the origin of that rectangle on the screen?

3 7

Re: [PATCH 1/4] ntdll: Implement retrieving DOS attributes in NtQueryInformationFile (try 2).
by Alexandre Julliard Dec. 19, 2014

Dec. 19, 2014

"Erich E. Hoover" <erich.e.hoover(a)gmail.com> writes: > Currently only Linux extended attributes are supported, when they are > not available at compile time the ports implementation will fall back > to a "not-supported" return and any such attributes will be ignored. > It is necessary to place this feature in ports so that Mac and FreeBSD > can be supported separately, as the semantics of these APIs are quite > different on such systems (patches to come after this initial > implementation). That doesn't mean they should go into ports, especially not as such non-standard functions. Unless you really have to use them all over the place, they should remain in ntdll. -- Alexandre Julliard julliard(a)winehq.org

2 6

Re: [3/3] advapi32: Fix HKLM\Software handling when opening with KEY_WOW64_32KEY.
by Nikolay Sivov Dec. 19, 2014

Dec. 19, 2014

On 12/18/2014 06:21 PM, Akihiro Sagawa wrote: > --- > dlls/advapi32/registry.c | 99 ++++++++++++++++++++++++++++++++++++------ > dlls/advapi32/tests/registry.c | 6 +-- > 2 files changed, 88 insertions(+), 17 deletions(-) > Just curious, why HKLM\Software needs special handling in this case? In other words is there a solution that covers all paths?

2 1

Patch 108275 superseded incorrectly?
by Dmitry Kozliuk Dec. 19, 2014

Dec. 19, 2014

Hello, Patch status page shows patch http://source.winehq.org/patches/data/108275 as "Superseded", and patch http://source.winehq.org/patches/data/108285 as "New". However, the former is supposed to supersede the latter: it has "(try 2)" mark an was submitted later with an explanation. Please consider patch status correction. -- Dmitry Kozliuk

1 0

Re: [PATCH 3/4] ntdll: Implement storing DOS attributes in NtSetInformationFile (try 2).
by Marvin Dec. 18, 2014

Dec. 18, 2014

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=10823 Your paranoid android. === w8 (32 bit file) === file.c:397: Test failed: mismatched file size for L"WindowsUpdate.log"

1 0

Re: [PATCH 3/4] ntdll: Implement storing DOS attributes in NtSetInformationFile.
by cdavis5x＠gmail.com Dec. 18, 2014

Dec. 18, 2014

> On Dec 18, 2014, at 10:16 AM, Erich E. Hoover <erich.e.hoover(a)gmail.com> wrote: > This patch implements storing DOS attributes in the Samba format > "user.DOSATTRIB" extended attribute using fsetxattr and fremovexattr. > FILE_ATTRIBUTE_NORMAL is masked out since that attribute is > unnecessary, and leaving it out avoids having to store an attribute > for every file on the system. Only NORMAL? There are quite a few DOS attributes. Here’s a list from <winnt.h>: #define FILE_ATTRIBUTE_READONLY 0x00000001 #define FILE_ATTRIBUTE_HIDDEN 0x00000002 #define FILE_ATTRIBUTE_SYSTEM 0x00000004 #define FILE_ATTRIBUTE_DIRECTORY 0x00000010 #define FILE_ATTRIBUTE_ARCHIVE 0x00000020 #define FILE_ATTRIBUTE_DEVICE 0x00000040 #define FILE_ATTRIBUTE_NORMAL 0x00000080 #define FILE_ATTRIBUTE_TEMPORARY 0x00000100 #define FILE_ATTRIBUTE_SPARSE_FILE 0x00000200 #define FILE_ATTRIBUTE_REPARSE_POINT 0x00000400 #define FILE_ATTRIBUTE_COMPRESSED 0x00000800 #define FILE_ATTRIBUTE_OFFLINE 0x00001000 #define FILE_ATTRIBUTE_NOT_CONTENT_INDEXED 0x00002000 #define FILE_ATTRIBUTE_ENCRYPTED 0x00004000 (Yes, all of those are in Microsoft’s public headers. I checked.) Of those, these are the ones that Samba lets clients set: FILE_ATTRIBUTE_READONLY FILE_ATTRIBUTE_HIDDEN FILE_ATTRIBUTE_SYSTEM FILE_ATTRIBUTE_ARCHIVE FILE_ATTRIBUTE_OFFLINE and these are the ones that Samba returns: FILE_ATTRIBUTE_READONLY FILE_ATTRIBUTE_HIDDEN FILE_ATTRIBUTE_SYSTEM FILE_ATTRIBUTE_DIRECTORY FILE_ATTRIBUTE_ARCHIVE FILE_ATTRIBUTE_SPARSE_FILE (Weird. They let people set OFFLINE, but never return it…) These are the ones that MSDN says Windows lets programs set with SetFileAttributes() (but I can’t vouch for MSDN’s accuracy, so this really needs to be demonstrated with a test): FILE_ATTRIBUTE_READONLY FILE_ATTRIBUTE_HIDDEN FILE_ATTRIBUTE_SYSTEM FILE_ATTRIBUTE_NORMAL FILE_ATTRIBUTE_ARCHIVE FILE_ATTRIBUTE_TEMPORARY FILE_ATTRIBUTE_OFFLINE FILE_ATTRIBUTE_NOT_CONTENT_INDEXED and these are the ones that CreateFile() is supposed to let programs set: FILE_ATTRIBUTE_READONLY FILE_ATTRIBUTE_HIDDEN FILE_ATTRIBUTE_SYSTEM FILE_ATTRIBUTE_NORMAL FILE_ATTRIBUTE_ARCHIVE FILE_ATTRIBUTE_TEMPORARY FILE_ATTRIBUTE_OFFLINE FILE_ATTRIBUTE_ENCRYPTED I definitely think we shouldn’t be letting people set the DEVICE attribute (this is, I suspect, the attribute you get from a device handle), or the REPARSE_POINT attribute (this is what Windows returns for e.g. symlinks and junctions); MSDN says that the SET_REPARSE_POINT FSCTL is supposed to be able to set this attribute, though. Samba also forcibly sets the DIRECTORY attribute according to whether the file is or is not actually a directory; we should do this, too. MSDN also says the COMPRESSED attribute is supposed to be set by the SET_COMPRESSION FSCTL, the ENCRYPTED attribute is supposed to be set by advapi32.EncryptFile() (which I suspect just makes a SET_ENCRYPTION FSCTL) or when the file is created, and the SPARSE_FILE attribute is supposed to be set by the SET_SPARSE FSCTL, so we should mask all those out too. (Or error out, depending on what native does; as always, the tests are your friends here.) Also, NORMAL is only supposed to be valid by itself, so if any attributes are set along with NORMAL, we may need to error out. We REALLY need tests for all this. ;) (We have some tests for setting file attributes, but not enough IMO.) Chip

2 1

Re: [PATCH 4/4] ntdll: Implement storing DOS attributes in NtCreateFile.
by Marvin Dec. 18, 2014

Dec. 18, 2014

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=10817 Your paranoid android. === build (build) === Make in include dir failed

1 0

Re: [PATCH 3/4] ntdll: Implement storing DOS attributes in NtSetInformationFile.
by Marvin Dec. 18, 2014

Dec. 18, 2014

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=10816 Your paranoid android. === build (build) === Make in include dir failed

1 0

Re: winex11.drv: don't drop raw input events after mouse warp
by Patrick Rudolph Dec. 18, 2014

Dec. 18, 2014

Am 2014-12-17 20:56, schrieb Alexandre Julliard: > Patrick Rudolph <siro(a)das-labor.org> writes: > >> This patch fixes bug https://bugs.winehq.org/show_bug.cgi?id=32913 >> After each mouse move the cursor is warped back to the center of the >> screen. This is OK for XInput, but not for XInput2 as XInput2 reports >> raw events that doesn't care about absolute screen coordinates and >> doesn't need to be dropped. There're frequent cursor warps resulting >> in lot's of dropped raw motion events (up to all). These dropped >> motion events cause mouse jitter, which is notable in FPS games, but >> not while using any GUI that only needs pixel coordinates. > > The problem is that warping the mouse also generates events, and you > have to ignore those. I've attached a log file, here: https://bugs.winehq.org/attachment.cgi?id=50258 As you can see XWarpCursor inserts MotionNotify events, that are correctly ignored using the serial, but there're no inserted RawMotion events. So there's no need to drop them, correct me if I'm wrong. Sadly I couldn't find any documentation for XWarpCursor and RawMotion events. Kind Regards, Patrick

2 1

Re: winex11.drv: don't drop raw input events after mouse warp
by Alexandre Julliard Dec. 17, 2014

Dec. 17, 2014

Patrick Rudolph <siro(a)das-labor.org> writes: > This patch fixes bug https://bugs.winehq.org/show_bug.cgi?id=32913 > After each mouse move the cursor is warped back to the center of the > screen. This is OK for XInput, but not for XInput2 as XInput2 reports > raw events that doesn't care about absolute screen coordinates and > doesn't need to be dropped. There're frequent cursor warps resulting > in lot's of dropped raw motion events (up to all). These dropped > motion events cause mouse jitter, which is notable in FPS games, but > not while using any GUI that only needs pixel coordinates. The problem is that warping the mouse also generates events, and you have to ignore those. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/2] mmdevapi: More accurately track device position
by Marvin Dec. 17, 2014

Dec. 17, 2014

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=10797 Your paranoid android. === w7u (32 bit render) === render.c:1976: Test failed: Got wrong volume: 0.501088 render.c:2005: Test failed: Got wrong volume: 0.501088 === w8 (32 bit render) === render.c:1976: Test failed: Got wrong volume: 0.671337 render.c:2005: Test failed: Got wrong volume: 0.671337

1 0

RE: [PATCH] libs/wine/string.c: Always return (int)written
by Hugh McMaster Dec. 17, 2014

Dec. 17, 2014

On Wednesday, Dec 17 05:54:42 CST 2014, Jonathan Vollebregt wrote: >No: http://msdn.microsoft.com/en-us/library/1kt27hek.aspx#returnValueToggle >> vsnprintf ,_vsnprintf, and _vsnwprintf return the number of characters written if the number of characters to write is less than or equal to count; if the number of characters to write is greater than count, these functions return -1 indicating that output has been truncated. The return value does not include the terminating null, if one is written. >> >> If buffer or format is NULL, or if count is less than or equal to zero, these functions invoke the invalid parameter handler, as described in Parameter Validation. If execution is allowed to continue, these functions return -1 and set errno to EINVAL. I disagree. vsnprintfW is not a Windows function. We should be following the Linux form here, which returns the number of chars that would be written.

2 1

Re: [PATCH] libs/wine/string.c: Always return (int)written
by Jonathan Vollebregt Dec. 17, 2014

Dec. 17, 2014

No: http://msdn.microsoft.com/en-us/library/1kt27hek.aspx#returnValueToggle > vsnprintf ,_vsnprintf, and _vsnwprintf return the number of characters written if the number of characters to write is less than or equal to count; if the number of characters to write is greater than count, these functions return -1 indicating that output has been truncated. The return value does not include the terminating null, if one is written. > > If buffer or format is NULL, or if count is less than or equal to zero, these functions invoke the invalid parameter handler, as described in Parameter Validation. If execution is allowed to continue, these functions return -1 and set errno to EINVAL. On 12/17/2014 12:47 PM, Hugh McMaster wrote: > Both GCC and Windows versions of vsnprintf return the number of chars that would be written to a given buffer when vsnprintf(NULL, 0, fmt, va_args) is called. > > Wine currently returns -1, which is incorrect. > > Also, if there is a short buffer, that is, buffer <= len, not only is any output truncated, but the return value is the number of chars that would be written if the buffer had sufficient space. > > Here, Wine returns -1, which is, again, incorrect. > > In all cases, the return value should be the number of chars written or the number of chars that would be written if the buffer has sufficient space.

1 0

RE: (resend) regedit: Improve error message when recasing a key.
by Hugh McMaster Dec. 17, 2014

Dec. 17, 2014

On Wednesday, 17 Dec 2014 01:31:53 +0300, Dmitry Kozliuk wrote: >+ IDS_ERROR_RENAMING_VALUE "Error Renaming Value" >+ IDS_KEY_ALREADY_EXISTS "The Registry Editor cannot rename %s. > The specified key name already exists. Type another name and try again." You cannot use those strings. The first is a verbatim copy from native regedit.exe. The second is almost verbatim, with the exception of "key name". Native regedit.exe uses "value name". Please craft different text with the same meaning.

1 0

Re: shell32: Implement IApplicationAssociationRegistration, QueryCurrentDefault (try 4)
by Nikolay Sivov Dec. 16, 2014

Dec. 16, 2014

On 12/17/2014 08:11 AM, Alistair Leslie-Hughes wrote: > - test_IApplicationAssociationRegistration_QueryInterface(); > + /* this works since Vista */ > + hr = CoCreateInstance(&CLSID_ApplicationAssociationRegistration, NULL, CLSCTX_INPROC_SERVER, > + &IID_IApplicationAssociationRegistration, (LPVOID*)&appreg); > + if (hr == S_OK) > + { > + test_IApplicationAssociationRegistration_QueryInterface(appreg); > + test_IApplicationAssociationRegistration_QueryCurrentDefault(appreg); > + > + IApplicationAssociationRegistration_Release(appreg); > + } > + else > + skip("IApplicationAssociationRegistration not supported: 0x%x\n", hr); This should be win_skip().

1 0

Re: dpnet: Implement IDirectPlay8Address GetComponentByName (try 3)
by Marvin Dec. 16, 2014

Dec. 16, 2014

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=10793 Your paranoid android. === w8 (32 bit address) === The test timed out

2 1

Re: [1/2] server: Never attempt to wake up the current thread.
by Sebastian Lackner Dec. 16, 2014

Dec. 16, 2014

On 16.12.2014 06:23, Sebastian Lackner wrote: > Alternative approach for patch #107840 "server: Avoid sending unexpected wakeup with uninitialized cookie value." (which should also still be fine, but this solution is probably a bit easier). > > We never want to send any wakeup cookies to our currently active thread, so just fake success in this case. > To demonstrate what happens without this patch (and to avoid any regressions) I've also added a test in patch 2/2. > > The unexpected cookies itself are not visible without debug messages of course, but because of the buffer size limitation the whole wineserver freezes. > When forcefully killing the test, the wineserver also crashes with: > > ==14785== Invalid read of size 4 > ==14785== at 0x807CE1B: select_on (thread.c:830) > ==14785== by 0x807E604: req_select (thread.c:1462) > ==14785== by 0x8076003: call_req_handler (request.c:247) > ==14785== by 0x807620A: read_request (request.c:302) > ==14785== by 0x807B8C1: thread_poll_event (thread.c:267) > ==14785== by 0x805679F: fd_poll_event (fd.c:446) > ==14785== by 0x8056A43: main_loop_epoll (fd.c:541) > ==14785== by 0x8056E2F: main_loop (fd.c:886) > ==14785== by 0x805F4B6: main (main.c:148) > ==14785== Address 0x50 is not stack'd, malloc'd or (recently) free'd > ==14785== > ==14785== Process terminating with default action of signal 11 (SIGSEGV): dumping core > > Reason for the crash is that the wakeup write() syscall fails -> the thread is terminated with kill_thread() -> this sets current = NULL - the code later assumes that 'current' is still a valid pointer. By not sending wakeup cookies we avoid this whole code path, and the test runs well. > > --- > server/thread.c | 4 ++++ > 1 file changed, 4 insertions(+) > Please ignore this patch for now, there are some situations (not covered by existing tests) where this idea would not work correctly.

1 0

Re: include/ddk: add csq.h
by Austin English Dec. 15, 2014

Dec. 15, 2014

On Thu, Nov 13, 2014 at 3:30 PM, Austin English <austinenglish(a)gmail.com> wrote: > > > -- > -Austin > Patch dropped off the tracker without comment, could I get some feedback please? -- -Austin

1 0

Re: zh_CN Translation Submittion
by Nikolay Sivov Dec. 15, 2014

Dec. 15, 2014

On 15.12.2014 17:39, Jeff Bai wrote: > Umm... I think POEdit is the one who made these changes... Not sure if it's my settings or what. Yes, it's mostly likely it. But you don't have to use it, your favorite text editor will work just fine. > > >> 在 2014年12月15日，上午12:01，Nikolay Sivov <bunglehead(a)gmail.com> 写道： >> >>> On 15.12.2014 7:53, Jeff Bai wrote: >>> Hello, fellow developers. >>> >>> I've got several hundred strings translated to zh_CN, and according to >>> you guys' wiki I am supposed to submit a patch of what I've changed. >>> >>> So here it is (too long, used PasteBin) >>> >>> https://pastebin.anthonos.org/view/bb82ca07 >>> >>> Also, I am not sure if I would be fast enough to get them all done by >>> 1.7.34 (nearly two weeks apart?), so is it Okay for me to submit them >>> bit by bit, like this time, several hundred? There's still about 950 >>> left as I can see on POEdit - and I think I can push this to 100% after >>> my high school final four days later. >>> >>> Thanks everyone, Wine is AWESOME. >>> >>> Regards, >>> >>> Jeff Bai (白铭骢) >> >> Hi, Jeff. >> >> I think it's okay to submit full diff at once. But please avoid changing original messages like you do here (or maybe not you directly but poedit): >> >>> #: oleview.rc:121 >>> -msgid "" >>> -"Toggle the display of component categories that are not meant to be visible" >>> +msgid "Toggle the display of component categories that are not meant to be visible" >>> msgstr "切换隐藏组件类显示" >> >> So keep msgid part as it is and touch only msgstr part, this will also help reducing resulting diff. >> >> And once you fixed that you should send a patch to wine-patches(a)winehq.org as it says here http://wiki.winehq.org/SubmittingPatches.

1 0

setting break point in 16 bit Windows app
by Marius Cirsta Dec. 15, 2014

Dec. 15, 2014

I'd like to use winedbg to set a break point in a 16 bit Windows app, to stop execution on some function call. From what I've read this is broken as of 2005 ( https://www.winehq.org/pipermail/wine-devel/2006-June/048343.html ). Has anything happened since ? I'm interested in getting this to work but it all depends on the effort involved. Can anyone provide an estimate as to how much work is needed ? Thanks.

1 0

Re: d3d9: Don't assert when apps pass in the wrong shader iface.
by Sebastian Lackner Dec. 15, 2014

Dec. 15, 2014

On 15.12.2014 15:29, Michael Stefaniuc wrote: > Fixes a regression reported in > https://bugs.winehq.org/show_bug.cgi?id=37723 > --- > dlls/d3d9/shader.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/dlls/d3d9/shader.c b/dlls/d3d9/shader.c > index 0c2c881..9541028 100644 > --- a/dlls/d3d9/shader.c > +++ b/dlls/d3d9/shader.c > @@ -165,9 +165,8 @@ HRESULT vertexshader_init(struct d3d9_vertexshader *shader, struct d3d9_device * > > struct d3d9_vertexshader *unsafe_impl_from_IDirect3DVertexShader9(IDirect3DVertexShader9 *iface) > { > - if (!iface) > + if (!iface && iface->lpVtbl != &d3d9_vertexshader_vtbl) ^^^^ Shouldn't it be !iface || iface->lpVtbl != &d3d9_vertexshader_vtbl ? > return NULL; > - assert(iface->lpVtbl == &d3d9_vertexshader_vtbl); > > return impl_from_IDirect3DVertexShader9(iface); > } > @@ -315,9 +314,8 @@ HRESULT pixelshader_init(struct d3d9_pixelshader *shader, struct d3d9_device *de > > struct d3d9_pixelshader *unsafe_impl_from_IDirect3DPixelShader9(IDirect3DPixelShader9 *iface) > { > - if (!iface) > + if (!iface && iface->lpVtbl != &d3d9_pixelshader_vtbl) > return NULL; > - assert(iface->lpVtbl == &d3d9_pixelshader_vtbl); > > return impl_from_IDirect3DPixelShader9(iface); > } >

1 0

Re: zh_CN Translation Submittion
by Nikolay Sivov Dec. 15, 2014

Dec. 15, 2014

On 15.12.2014 7:53, Jeff Bai wrote: > Hello, fellow developers. > > I've got several hundred strings translated to zh_CN, and according to > you guys' wiki I am supposed to submit a patch of what I've changed. > > So here it is (too long, used PasteBin) > > https://pastebin.anthonos.org/view/bb82ca07 > > Also, I am not sure if I would be fast enough to get them all done by > 1.7.34 (nearly two weeks apart?), so is it Okay for me to submit them > bit by bit, like this time, several hundred? There's still about 950 > left as I can see on POEdit - and I think I can push this to 100% after > my high school final four days later. > > Thanks everyone, Wine is AWESOME. > > Regards, > > Jeff Bai (白铭骢) > > > Hi, Jeff. I think it's okay to submit full diff at once. But please avoid changing original messages like you do here (or maybe not you directly but poedit): > #: oleview.rc:121 > -msgid "" > -"Toggle the display of component categories that are not meant to be visible" > +msgid "Toggle the display of component categories that are not meant to be visible" > msgstr "切换隐藏组件类显示" So keep msgid part as it is and touch only msgstr part, this will also help reducing resulting diff. And once you fixed that you should send a patch to wine-patches(a)winehq.org as it says here http://wiki.winehq.org/SubmittingPatches.

1 0

Re: ole32:fix CoWaitForMultipleHandles cause RPC hang
by Changhui Liu Dec. 15, 2014

Dec. 15, 2014

Hi, I got it. The CoWaitForMultipleHandles of Microsoft implement is this: The message loop continue although has received WM_QUIT, but just dispatch message who sent to the OleMainThreadWndClass Window. I attached a latest patch and a verify function. Run the test_CoWaitForMultipleHandlesDispatchMsg, We will only get the message who send to cowait_test_class window . It also pass your PeekMessage test at: https://github.com/wine-compholio/wine-staging/blob/master/patches/ole32-Co… Please help me review it again when you are free. Thank you. ------------------ Regards. ------------------ Original ------------------ From: "Sebastian Lackner"<sebastian(a)fds-team.de>; Date: Sat, Dec 13, 2014 11:32 PM To: "Changhui Liu"<liuchanghui(a)linuxdeepin.com>; Cc: "wine-devel"<wine-devel(a)winehq.org>; Subject: Re: ole32:fix CoWaitForMultipleHandles cause RPC hang Hi, On 13.12.2014 16:15, Changhui Liu wrote: > Hi Sebastian, > > > I tested your current work-in-progress patch: > https://github.com/wine-compholio/wine-staging/blob/master/patches/ole32-Co… > > I have two puzzles about these code: >> index = 0xdeadbeef; >> PostMessageA(hWnd, WM_DDE_FIRST, 0, 0); >> PostQuitMessage(44); >> thread = CreateThread(NULL, 0, post_message_thread, hWnd, 0, &tid); >> ok(thread != NULL, "CreateThread failed, error %u\n", GetLastError()); >> hr = CoWaitForMultipleHandles(0, 100, 2, handles, &index); >> ok(hr == RPC_S_CALLPENDING, "expected RPC_S_CALLPENDING, got 0x%08x\n", hr); >> ok(index == 0 || broken(index == 0xdeadbeef) /* Win 8 */, "expected index 0, got %u\n", index); >> success = PeekMessageA(&msg, hWnd, WM_DDE_FIRST, WM_DDE_FIRST, PM_REMOVE); >> ok(success, "PeekMessageA failed, error %u\n", GetLastError()); > > > The first, why use the PeekMessage to check if received a WM_DDE_FIRST message? > Is there an real application do like that way? Of course there are multiple ways to test for window messages in the message queue, I just picked PeekMessageA because it doesn't require setting up a Wndproc. > > > In fact CoWaitForMultipleHandles has a message loop, the WM_DDE_FIRST message has been > dispatched to the window's WNDPROC. So the PeekMessageA certainly failed. No, it doesn't. Feel free to run the tests yourself on a Windows machine, I have tested them with the Wine testbot and all tests pass on 2000/XP/Vista/8/2008/... - which means that Windows does not process all WM_DDE_FIRST messages. This is also why I am unsure about how to fix it. When changing the behaviour in order to fix one of the tests which fails in Wine (marked with todo_wine), it breaks other tests which were working well before. > > > I think the correct test should be this: > 1, Define a custom WNDPROC function named cowait_test_wnd_proc . > 2, Define a global int variable named g_count_of_wm_dde_first. > 3, Set the value of g_count_of_wm_dde_first to zero before call CoWaitForMultipleHandles. > 4, Increase the value of g_count_of_wm_dde_first by one, once received a WM_DDE_FIRST message in cowait_test_wnd_proc. > 5, Check if the value of g_count_of_wm_dde_first is equal to 2 after CoWaitForMultipleHandles returned. > This testing method would also be fine, but you would get 1 instead of 2. My patch doesn't show any test failures on Windows, which means that one of the WM_DDE_FIRST messages is still in the queue. > > The second is why use todo_wine ? > todo_wine > ok(!success, "PeekMessageA succeeded\n"); > why not just write? > ok(!success, "PeekMessageA succeeded\n"); > The Wine coding guideline does not allow to add new test failures, instead all tests which do not pass yet have to be marked with "todo_wine". This makes easily visible which tests need further work just by looking at the source code, moreover it avoids introducing regressions (breaking tests which were working well before). Take a look at some of the other Wine tests, this is not the only place where its used. > > > > Thank you. Regards, Sebastian

1 1

Re: [1/2] jscript: Support PROPERTYGET in Date Value
by Jacek Caban Dec. 14, 2014

Dec. 14, 2014

On 12/14/14 00:18, Alistair Leslie-Hughes wrote: > case INVOKE_PROPERTYGET: > + { > + DateInstance *date; > + > + if(!(date = date_this(jsthis))) > + return throw_type_error(ctx, JS_E_DATE_EXPECTED, NULL); It's guaranteed that jsthis is of DataInstance type in case of *_value functions, so there is no need to check that in runtime. You may simply cast it here. Jacek

1 0

Re: ole32:fix CoWaitForMultipleHandles cause RPC hang
by Sebastian Lackner Dec. 13, 2014

Dec. 13, 2014

On 11.12.2014 15:07, Changhui Liu wrote: > Because there's a RPC request need to be handled by OLE apartment window proc apartment_wndproc. > So, after received a WM_QUIT, > if the GUI thread in calling CoWaitForMultipleHandles don't handle message loop any more , > the RPC will never be handled, the RPC dispatch thread will be hang. > > > > There are several issues with this patch. You wrote in your last mail: > so this patch can't pass test on testbot.winehq.org, it only pass test on wine. > The test result is here, https://testbot.winehq.org/JobDetails.pl?Key=10727. It is not clear what you mean. The test should of course also pass on testbot.winehq.org, if it doesn't, this means that Wine doesn't properly reproduce the expected behaviour. You need to create a test so that it passes on both wine and the testbot, otherwise nothing is tested at all. Other issues in your patch: * It seems very unlikely that this is how quit messages are processed. Immediately calling PostQuitMessage(...) but continuing to process messages means that effectively WM_QUIT is lost. * Always add a "\n" at the end of ok(...) messages. * Try to avoid huge sleeps like Sleep(5000). This will probably cause the tests time out. Unfortunately I didn't have much time to look into this issue myself so far, but I guess I'll have more time at the weekend. Regards, Sebastian

2 4

Re: [PATCH v3 03/10] reg: Add system error printing function
by Indrek Altpere Dec. 13, 2014

Dec. 13, 2014

Seems that the patches have reached the magical "1 month" limit where they disappear from the list silently. Last I saw, your patchset contained about 8 or 10 patches? Not sure if the best suggestion by official rules/guidelines, but perhaps it would be possible to add the new stuff in multiple, smaller patchsets, instead of one mega-patchset? It would mean that reviewers don't have to dig around in hundreds of lines of code changes that change a lot of functionality, makes it hard to keep track of all of it and review it thoroughly. Many big patchsets have gotten stalled like that: reviewer notices a few things, notifies developer, developer makes the changes, sends the changed full patchset again, reviewer checks full patchset again, finds more stuff in next files (or even the same files), notifies developer and so on and so on. Sometimes multiple reviewers also cause havoc, because due to many coding rules not being written down (http://wiki.winehq.org/SubmittingPatches contains general and vague guidelines, but essentially 0 hard examples) and each reviewer having a bit different viewpoint about what styling issues are could-be or should-be, so sending a huge set will end up with responses "here's about ~10 things wrong with your code" and like that after each submit. As I understand, someone correct me if I'm wrong, there is currently also no active reg component maintainer, who would be able to review things quickly, so smaller patchset would probably help things move along much faster? About https://source.winehq.org/patches/data/107580 getting stalled, I have no clue/opinion, does not seem to be overly complex? Regards, Indrek Altpere

3 2

Re: jscript: Added test of Date object default value.
by Marvin Dec. 12, 2014

Dec. 12, 2014

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=10746 Your paranoid android. === w2000pro (32 bit run) === run.c:1962: Test failed: Invoke failed: 8000ffff run.c:1963: Test failed: V_VT(v) = 0

1 0

Re: [PATCH v4 2/4] combase: Implement creation and deletion of HSTRING objects.
by Martin Storsjö Dec. 12, 2014

Dec. 12, 2014

On Wed, 10 Dec 2014, Martin Storsjo wrote: > --- > configure.ac | 1 + > .../api-ms-win-core-winrt-string-l1-1-0.spec | 8 +- > dlls/combase/Makefile.in | 3 +- > dlls/combase/combase.spec | 8 +- > dlls/combase/string.c | 143 +++++++++++++++++++++ > dlls/combase/tests/Makefile.in | 4 + > dlls/combase/tests/string.c | 128 ++++++++++++++++++ > tools/make_specfiles | 1 + > 8 files changed, 287 insertions(+), 9 deletions(-) > create mode 100644 dlls/combase/string.c > create mode 100644 dlls/combase/tests/Makefile.in > create mode 100644 dlls/combase/tests/string.c Any further comments on these ones (2-4), or should I resubmit them for a new look? // Martin

1 0

Drawbridge -- WinAPI/NT API sandbox in Windows
by Saulius Krasuckas Dec. 11, 2014

Dec. 11, 2014

Hello, I just have heard about MS project called Drawbridge. [*] They use NT kernel (ntoskrnl + win32k) implementation in user-mode (NTUM) to load native DLLs and services from different versions of Windows, IIUC. Set of downcalls from NTUM (to native kernel) is reduced to 45 items. This way a process-based isolation is achieved. Some sort of sandbox/container. It sounds like Wine on Windows. Just FYI. S. [*] http://research.microsoft.com/en-us/projects/drawbridge/

1 0

Re: ole32:fix CoWaitForMultipleHandles cause RPC hang
by Marvin Dec. 11, 2014

Dec. 11, 2014

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=10727 Your paranoid android. === w2000pro (32 bit compobj) === compobj.c:2325: compobj.c:2299: Test failed: sleep 5 second === wxppro (32 bit compobj) === compobj.c:2325: compobj.c:2299: Test failed: sleep 5 second === wvistau64 (32 bit compobj) === compobj.c:2299: Test failed: Expected OLE apartment window is valid!compobj.c:2334: The RPC request is processed OK! === w2008s64 (32 bit compobj) === compobj.c:2299: Test failed: Expected OLE apartment window is valid!compobj.c:2334: The RPC request is processed OK! === w7u (32 bit compobj) === compobj.c:2299: Test failed: Expected OLE apartment window is valid!compobj.c:2334: The RPC request is processed OK! === w8 (32 bit compobj) === compobj.c:2299: Test failed: Expected OLE apartment window is valid!compobj.c:2334: The RPC request is processed OK! === wvistau64 (64 bit compobj) === compobj.c:2299: Test failed: Expected OLE apartment window is valid!compobj.c:2334: The RPC request is processed OK! === w2008s64 (64 bit compobj) === compobj.c:2299: Test failed: Expected OLE apartment window is valid!compobj.c:2334: The RPC request is processed OK!

1 0

Re: ole32:fix CoWaitForMultipleHandles cause RPC hang
by Marvin Dec. 11, 2014

Dec. 11, 2014

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=10726 Your paranoid android. === w2000pro (32 bit compobj) === compobj.c:2296: Test failed: Expected OLE apartment window is valid!compobj.c:2325: sleep 1 second === wxppro (32 bit compobj) === compobj.c:2296: Test failed: Expected OLE apartment window is valid!compobj.c:2325: sleep 1 second === wvistau64 (32 bit compobj) === compobj.c:2296: Test failed: Expected OLE apartment window is valid!compobj.c:2325: sleep 1 second === w2008s64 (32 bit compobj) === compobj.c:2296: Test failed: Expected OLE apartment window is valid!compobj.c:2325: sleep 1 second === w7u (32 bit compobj) === compobj.c:2296: Test failed: Expected OLE apartment window is valid!compobj.c:2325: sleep 1 second === w8 (32 bit compobj) === compobj.c:2296: Test failed: Expected OLE apartment window is valid!compobj.c:2325: sleep 1 second === wvistau64 (64 bit compobj) === compobj.c:2296: Test failed: Expected OLE apartment window is valid!compobj.c:2325: sleep 1 second === w2008s64 (64 bit compobj) === compobj.c:2296: Test failed: Expected OLE apartment window is valid!compobj.c:2325: sleep 1 second

1 0

Re: d3dx9: ID3DXFont PreloadCharacters return S_OK
by Bruno Jesus Dec. 10, 2014

Dec. 10, 2014

On Thu, Dec 11, 2014 at 1:27 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Hi, > If any program uses the SharpDX library, it throws an exception when > PreloadCharacters > returns E_NOTIMPL. > > Changelog: > d3dx9: ID3DXFont PreloadCharacters return S_OK Missing patch. > > Best Regards > Alistair Leslie-Hughes Regards, Bruno

1 0

Re: dwrite: Block creation of unsupported face types
by Marvin Dec. 10, 2014

Dec. 10, 2014

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=10716 Your paranoid android. === wvistau64 (32 bit font) === font.c:1056: Test failed: got 0x80070057 === w2008s64 (32 bit font) === font.c:1056: Test failed: got 0x80070057 === wvistau64 (64 bit font) === font.c:1056: Test failed: got 0x80070057 === w2008s64 (64 bit font) === font.c:1056: Test failed: got 0x80070057

1 0

Re: [8/9] winhttp: Don't try to read data when the server response is HTTP_STATUS_NO_CONTENT or HTTP_STATUS_NOT_MODIFIED.
by Bruno Jesus Dec. 10, 2014

Dec. 10, 2014

On Tue, Dec 9, 2014 at 9:50 AM, Hans Leidekker <hans(a)codeweavers.com> wrote: > Tests based on a patch by Bruno Jesus. > --- > dlls/winhttp/request.c | 15 ++++++----- > dlls/winhttp/tests/winhttp.c | 62 +++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 69 insertions(+), 8 deletions(-) > Hans, I can no longer find the bug that this was about. Can you please give the bug URL? Do you think your current patch set fixed it? Best regards, Bruno

2 1

Re: [PATCH v3 4/7] include: Add hstring.h and winstring.h.
by Alexandre Julliard Dec. 10, 2014

Dec. 10, 2014

Martin Storsjo <martin(a)martin.st> writes: > --- > No changes since v2. > --- > include/Makefile.in | 2 ++ > include/hstring.h | 39 +++++++++++++++++++++++++++++++++++++++ > include/winstring.h | 46 ++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 87 insertions(+) > create mode 100644 include/hstring.h > create mode 100644 include/winstring.h hstring.h should be generated from idl. -- Alexandre Julliard julliard(a)winehq.org

2 1

RE: [PATCH v3 03/10] reg: Add system error printing function
by Hugh McMaster Dec. 9, 2014

Dec. 9, 2014

On Saturday, 8 Nov 2014 11:26:44 +0100, Jonathan Vollebregt wrote: +static void reg_print_error(LSTATUS error_code) +{ + switch (error_code) + { + case ERROR_SUCCESS: + return; + case ERROR_BAD_COMMAND: + reg_message(STRING_INVALID_CMDLINE); + return; + default: + { + static const WCHAR error_string[] = {'%','0','5','d',':',' ','%','s',0}; + WCHAR *message = NULL; + FormatMessageW(FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_ALLOCATE_BUFFER, NULL, + error_code, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), (WCHAR *)&message, 0, NULL); + + reg_message(STRING_ERROR); + reg_printfW(error_string, error_code, message); + LocalFree(message); + return; + } + } +}This seems like a step backwards to me. It would be much better to add the required functionality -- e.g. FormatMessage() -- and fix reg.exe printf-style functions in one go. See http://source.winehq.org/patches/data/107578 for what I mean. Also, mixing reg_message() and reg_printfW() just seems wrong. A clear resource string incorporating your formatting above would suffice, I expect. -- Hugh McMaster

2 3

Re: [8/9] winhttp: Don't try to read data when the server response is HTTP_STATUS_NO_CONTENT or HTTP_STATUS_NOT_MODIFIED.
by Marvin Dec. 9, 2014

Dec. 9, 2014

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=10702 Your paranoid android. === w7u (32 bit winhttp) === winhttp.c:2035: Test failed: failed to receive response 12030 winhttp.c:2039: Test failed: failed to query status code 12019 winhttp.c:2040: Test failed: request failed unexpectedly 589826 winhttp.c:2044: Test failed: failed to query authentication schemes 4317 winhttp.c:2045: Test failed: got deadbeef winhttp.c:2046: Test failed: got deadbeef winhttp.c:2047: Test failed: got deadbeef === w8 (32 bit winhttp) === winhttp.c:2035: Test failed: failed to receive response 12030 winhttp.c:2039: Test failed: failed to query status code 12019 winhttp.c:2040: Test failed: request failed unexpectedly 589826 winhttp.c:2044: Test failed: failed to query authentication schemes 4317 winhttp.c:2045: Test failed: got deadbeef winhttp.c:2046: Test failed: got deadbeef winhttp.c:2047: Test failed: got deadbeef

2 1

Re: [9/9] winhttp/tests: Close the connection immediately after authentication.
by Marvin Dec. 9, 2014

Dec. 9, 2014

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=10703 Your paranoid android. === w2008s64 (32 bit winhttp) === winhttp.c:2250: Test failed: WinHttpReceiveResponse failed: 12152 winhttp.c:2255: Test failed: WinHttpQueryHeaders failed: 12019 winhttp.c:2256: Test failed: got 0 winhttp.c:2260: Test failed: WinHttpQueryDataAvailable failed: 12019 === w7u (32 bit winhttp) === winhttp.c:2041: Test failed: failed to receive response 12030 winhttp.c:2045: Test failed: failed to query status code 12019 winhttp.c:2046: Test failed: request failed unexpectedly 589826 winhttp.c:2050: Test failed: failed to query authentication schemes 4317 winhttp.c:2051: Test failed: got deadbeef winhttp.c:2052: Test failed: got deadbeef winhttp.c:2053: Test failed: got deadbeef === w8 (32 bit winhttp) === winhttp.c:2041: Test failed: failed to receive response 12030 winhttp.c:2045: Test failed: failed to query status code 12019 winhttp.c:2046: Test failed: request failed unexpectedly 589826 winhttp.c:2050: Test failed: failed to query authentication schemes 4317 winhttp.c:2051: Test failed: got deadbeef winhttp.c:2052: Test failed: got deadbeef winhttp.c:2053: Test failed: got deadbeef

1 0

Re: gdiplus: fix GdipFillRectangleI no effect on memory DC whose windoworigin point has changed
by Marvin Dec. 9, 2014

Dec. 9, 2014

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=10699 Your paranoid android. === w7u (32 bit graphics) === graphics.c:5575: Test failed: Expected the color of memory bitmap is blue!graphics: 4644 tests executed (0 marked as todo, 1 failure), 0 skipped.

1 0

Re: [PATCH v2 08/10] combase: Implement creation and deletion of HSTRING objects.
by Sebastian Lackner Dec. 9, 2014

Dec. 9, 2014

On 08.12.2014 10:26, Martin Storsjo wrote: > + return E_INVALIDARG; > + if (str == NULL) > + { > + *out = NULL; <--- > + return S_OK; <--- > + } > + if (priv->reference) > + return WindowsCreateString(priv->buffer, priv->length, out); Wrong indentation. Moreover I noticed a mistake in patch 10. I had the guess that preallocating an empty string should also return a NULL string-buffer. + /* Test creation of an empty buffer */ + ok(pWindowsPreallocateStringBuffer(0, &ptr, &buf) == S_OK, "Failed to preallocate string buffer\n"); + ok(buf != NULL, "Empty string buffer is a null string\n"); + ok(ptr != NULL, "Empty string didn't return a buffer pointer\n"); + ok(pWindowsDeleteStringBuffer(buf) == S_OK, "Failed to delete string buffer\n"); + The testbot seems to confirm that: https://newtestbot.winehq.org/JobDetails.pl?Key=10687 ( I would suggest to wait with resending till after the daily commits, everything from patch 1-7 should be fine, and it probably doesn't make sense to resend the whole series several times. ;) ) Regards, Sebastian

2 2

Re: gdiplus: fix GdipFillRectangleI no effect on memory DC whose window origin point has changed
by Marvin Dec. 9, 2014

Dec. 9, 2014

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=10695 Your paranoid android. === w7u (32 bit graphics) === graphics.c:5575: Test failed: Expected the color of memory bitmap is blue!graphics: 4645 tests executed (0 marked as todo, 1 failure), 0 skipped.

1 0

Puzzle about ExtSelectClipRgn?
by Changhui Liu Dec. 8, 2014

Dec. 8, 2014

Dear all, I test this code : void test (HDC hdc, HRGN hregion) { RECT srcbox; RECT dstbox; GetClipBox(hdc, &dstbox); GetRgnBox(hregion, &srcbox); TRACE("Before ExtSelectClipRgn:%s,%s\n", wine_dbgstr_rect(&srcbox), wine_dbgstr_rect(&dstbox) ); ExtSelectClipRgn(hdc, hregion, RGN_AND ); GetClipBox(graphics->hdc,&dstbox); TRACE("After ExtSelectClipRgn:%s,%s\n", wine_dbgstr_rect(&dstbox) ); } It output in wine is : Before ExtSelectClipRgn:(693,5)-(763,28),(693,5)-(763,28) After ExtSelectClipRgn:(693,5)-(693,5) But I think it should be output: Before ExtSelectClipRgn:(693,5)-(763,28),(693,5)-(763,28) After ExtSelectClipRgn:(693,5)-(763,28) Where is my understanding mistake, or is it a bug in ExtSelectClipRgn? Thank you!

3 3

Re: [PATCH 4/4] dwrite: Implement GetDesignGlyphAdvances()
by Marvin Dec. 8, 2014

Dec. 8, 2014

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=10681 Your paranoid android. === wvistau64 (32 bit font) === font: unhandled exception c0000005 at 00409EDC === w2008s64 (32 bit font) === font: unhandled exception c0000005 at 00409EDC === wvistau64 (64 bit font) === font: unhandled exception c0000005 at 0000000000409275 === w2008s64 (64 bit font) === font: unhandled exception c0000005 at 0000000000409275

1 0

Re: [PATCH 3/4] dwrite: Implement IsMonospacedFont()
by Marvin Dec. 8, 2014

Dec. 8, 2014

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=10680 Your paranoid android. === wvistau64 (32 bit font) === font: unhandled exception c0000005 at 00409EDC === w2008s64 (32 bit font) === font: unhandled exception c0000005 at 00409EDC === wvistau64 (64 bit font) === font: unhandled exception c0000005 at 0000000000409275 === w2008s64 (64 bit font) === font: unhandled exception c0000005 at 0000000000409275

1 0

Re: [PATCH] msvcr120: Implement more C99 math functions.
by Piotr Caban Dec. 8, 2014

Dec. 8, 2014

On 12/06/14 17:07, Martin Storsjo wrote: > +/********************************************************************* > + * cbrt (MSVCR120.@) > + */ > +double CDECL MSVCR120_cbrt(double x) > +{ > +#ifdef HAVE_CBRT > + return cbrt(x); > +#else > + return x < 0 ? -powf(-x, 1.0 / 3.0) : powf(x, 1.0 / 3.0); > +#endif Please use pow instead of powf here. Thanks, Piotr

2 1

Re: [PATCH 05/10] combase: Add stub dll.
by Sebastian Lackner Dec. 8, 2014

Dec. 8, 2014

Hi Martin, a few things where I am not sure about: [PATCH 05/10] [...] > +@ stub COMBASE_63 > +@ stub COMBASE_64 > +@ stub COMBASE_65 > +@ stub COMBASE_66 > +@ stub COMBASE_67 > +@ stub COMBASE_68 [...] Are these really named exports, or exports by ordinal? If they are by ordinal and have no name assigned they are probably internal, and its not worth exporting them in Wine. I also noticed that combase.dll exports a lot of functions (Co*), which in Wine are implemented in ole32. It probably makes sense to sync that, but that can also be added in a later patch in my opinion. I don't think make_specfiles already supports such a situation. [PATCH 06/10 and also following patches] > +/*********************************************************************** > + * RoInitialize (api-ms-win-core-winrt-l1-1-0.@) > + */ Those comments should probably be changed. [PATCH 07/10] Does creating an empty string really return a HSTRING or just NULL (which seems to behave identical)? It probably makes sense to add a test for that. Does WindowsCreateString or WindowsCreateStringReference strip terminating NULL chars? (Embedded NULL chars are allowed obviously, but it might be possible that trailing NULL chars are handled differently). nsivov on #winehackers also suggested that it might be worth trying to find out what the structure is on Windows, but not sure if its worth the effort. If we're not trying at all to be compatible, we could get rid of one of the two memory allocations by allocating (sizeof(hstring_private) + length) as a single chunk, and setting ->buffer according. [PATCH 09/10] I would also suggest adding tests for the content of the buffer. You can use for example memcmp(...) to verify that the content is correct. [PATCH 10/10] Is the buffer initialized? Are terminating NULLs stripped from the buffer? Regards, Sebastian

2 2

Re: [PATCH 3/4] api-ms-win-core-winrt-string: Implement a few HSTRING functions.
by Sebastian Lackner Dec. 7, 2014

Dec. 7, 2014

Hi Martin, most of the patch looks okay, but I think there are a few things you should (or could) change. For patch 3/4: * I would split it up in several patches, and after adding the minimally necessary functions always combine the implementation with the corresponding tests. The huge number of functions in a single patch makes it difficult to review. * Include files should also be added as a separate patch. At the moment the formatting looks a bit ugly (random number of linebreaks?). I would also suggest to rename the function arguments to make sure they don't look exactly like MSDN. * Rename function arguments in the implementation itself, to avoid that they look identical to MSDN. * Internal helper functions (like alloc_string) do not necessarily need to return a HRESULT return value, when there are only two possible results. I would suggest using BOOL instead. * In the specfile use 'wstr' for arguments which are widechar strings. This allows to print them with the +relay debug channel. * Not sure how strict Wine is about the coding style, but generally a slighly different style is preferred for new code. Instead of --- snip --- if (...) { .... } --- snip --- the preferred version is --- snip --- if (...) { ... } --- snip --- The same applies also for for and do-while loops. Moreover cast operations like "(HSTRING)string" should usually have no space inbetween of the type and variable name. For patch 4/4: * C++-Style comments like "// ..." are not allowed in Wine source, instead use "/* ... */" for single-line comments or --- snip --- /* ... * ... */ --- snip --- for multi-line comments. * To avoid crashes on machines where this library is not available, it is recommended to skip the tests in such a case. For example: --- snip --- hmod = LoadLibraryA(...); if (!hmod) { win_skip("Failed to load api-ms-win-core-winrt-string-l1-1-0, skipping tests\n"); return; } --- snip --- * It is okay to use define macros for loading function pointers, but they should be defined directly before, and undefined immediately afterwards, to avoid collision with other definitions. I also don't think that checking for != NULL is really necessary, these api-* dlls have a well-defined set of export functions, so it is basically guaranteed that all functions are available. * check_string should also show the line number because it is used very often. The general way to do that is: --- snip --- #define check_string(str, length, has_null) _check_string(__LINE__, str, length, has_null) static void check_string(int line, HSTRING str, UINT32 length, BOOL has_null) { ... ok_(__FILE__, line)(condition, ...); ... } --- snip --- This allows to determine much easier where something goes wrong. * I would also suggest to split the tests. There is no need to put everything in a single function, especially because api-*-string only implements string functions. ;) I would prefer something like: --- snip --- START_TEST(...) { if (!init_functions()) return; test_CreateString(); test_DuplicateString(); ... } --- snip --- (Of course this doesn't mean that WindowsCreateString can only be used in one function.) Regards, Sebastian

2 4

Re: [PATCH 4/4] api-ms-win-core-winrt-string-l1-1-0: Add tests.
by Marvin Dec. 7, 2014

Dec. 7, 2014

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=10659 Your paranoid android. === build (build) === Can't determine base name

1 0

Re: [PATCH 15/15] api-ms-win-core-winrt-string: Implement a few HSTRING functions.
by Sebastian Lackner Dec. 6, 2014

Dec. 6, 2014

On 01.12.2014 11:27, Martin Storsjo wrote: > + > + buf = malloc(sizeof(*buf)); > + if (!buf) > + return E_OUTOFMEMORY; > + buf->buffer = malloc((length + 1) * sizeof(*buf->buffer)); > + if (!buf->buffer) { > + free(buf); > + return E_OUTOFMEMORY; > + } Some of your previous patches also contain changes to ./configure which is an autogenerated file. Afaik its not allowed to include that when submitting patches. Feedback for this part: * HSTRING and HSTRING_HEADER should probably be defined in some include fine. To ensure that the size of private structure matches you could also use C_ASSERT(...), and maybe even disable align of the structure fields. * You should avoid using malloc(...) in Wine source * http://msdn.microsoft.com/en-us/library/br224632(v=vs.85).aspx mentions: """Calling WindowsDeleteString decrements the reference count of the backing buffer, and if the reference count reaches 0, the Windows Runtime de-allocates the buffer.""" I don't see the concept of refcounted backing buffers anywhere in your code, which is most likely wrong. Its difficult to fix that later. * I would suggest starting with some stub functions, and then add tests before sending the actual implementation. BTW: Michael Müller was also working on some api-ms-win-core-* stubs, but I think he is also fine when your patches get upstream instead: https://github.com/wine-compholio/wine-staging/tree/master/patches/api-ms-w… Regards, Sebastian

3 9

Please help spread the word about the Software Freedom Conservancy
by Jeremy White Dec. 5, 2014

Dec. 5, 2014

Folks, Tony at the Conservancy reached out to us to ask our help in spreading the word about Conservancy. The Conservancy is our sponsoring organization, and they have been a great friend to Wine through the years. As they requested, I'm sending an email blast to our mailing list to spread the word. I'd ask you to scan their email and if you can help them in any of the ways they ask, please help them. They're good people, and good for Wine. Thanks, Jeremy -------- Forwarded Message -------- Subject: Conservancy projects: help us launch the Official Conservancy Supporter program! Date: Wed, 03 Dec 2014 17:17:47 -0500 From: Tony Sebro Hi, all: We at Conservancy are committed to doing whatever we can to support our member projects, and to help you produce great, freely-licensed software for the public's benefit. At this time, we could use the support of you, our member projects, as well. Today, Conservancy launched the official Conservancy Supporter program (http://sfconservancy.org/supporter/) This is our first campaign to build awareness about Conservancy, and our first attempt to really engage the public in a fundraising campaign. While we're glad to help you organize project-specific revenue-generating activities (e.g., project fundraisers, conferences, etc.), we've kept the percentage of revenue we receive from member projects under our FSA so low that it doesn't even pay for a single Conservancy staff member. So, we need our member projects' help to get the word out about who we are, what we do, and how friends of free and open source software can become Conservancy Supporters. Conservancy Supporters will receive: - an "Official Conservancy Supporter" badge for display on their personal websites; - a printable "Official Conservancy Supporter" card; and - a snazzy Conservancy T-Shirt. _ Ways__you can help spread the word_: - Follow @Conservancy on Twitter and/or Identi.ca - Tweet/Dent/Microblog about the Conservancy Supporter program on your social media platform of choice, with a link to the campaign page (please use the #ConservancySupporter hashtag) - If your project has an official social media account, please use that to microblog as well - Send email blasts to your project's mailing lists - Write a blog post or a testimonial about Conservancy (we'd really appreciate it) We thank you in advance for your support -- especially during this giving time of the year! Best, -Tony

1 0

Re: ws2_32/tests: Add SO_BSP_STATE tests
by Marvin Dec. 5, 2014

Dec. 5, 2014

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=10633 Your paranoid android. === wxppro (32 bit sock) === sock.c:610: Test failed: oob_server (190): unexpectedly at the OOB mark: 0

1 0

Re: [PATCH 9/9] wined3d: Pass WM_SYSCOMMAND(SC_RESTORE) to DefWindowProc.
by Marvin Dec. 5, 2014

Dec. 5, 2014

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=10625 Your paranoid android. === w8 (32 bit device) === device.c:1222: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1267: Test failed: Reset failed, hr 0x88760868. device.c:1269: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1273: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1280: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1281: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1282: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1283: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1284: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1285: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1290: Test failed: Screen width is 640, expected 800. device.c:1291: Test failed: Screen height is 480, expected 600. device.c:1297: Test failed: Back buffer width is 640, expected 800. device.c:1299: Test failed: Back buffer height is 480, expected 600. device.c:1329: Test failed: Screen width is 640, expected 1024. device.c:1330: Test failed: Screen height is 480, expected 768. device.c:2550: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2555: Test failed: The focus window is active. device.c:2563: Test failed: Got unexpected hr 0x88760869. device.c:2569: Test failed: Got unexpect screen size 800x600. device.c:2584: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2593: Test failed: Got unexpect screen size 800x600. device.c:2606: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2614: Test failed: Got unexpect width 640. device.c:2615: Test failed: Got unexpect height 480.

1 0

Re: [PATCH 8/9] wined3d: Filter messages generated by focus handling.
by Marvin Dec. 4, 2014

Dec. 4, 2014

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=10623 Your paranoid android. === w8 (32 bit device) === device.c:1222: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1267: Test failed: Reset failed, hr 0x88760868. device.c:1269: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1273: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1280: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1281: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1282: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1283: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1284: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1285: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1290: Test failed: Screen width is 640, expected 800. device.c:1291: Test failed: Screen height is 480, expected 600. device.c:1297: Test failed: Back buffer width is 640, expected 800. device.c:1299: Test failed: Back buffer height is 480, expected 600. device.c:1329: Test failed: Screen width is 640, expected 1024. device.c:1330: Test failed: Screen height is 480, expected 768. device.c:2550: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2555: Test failed: The focus window is active. device.c:2563: Test failed: Got unexpected hr 0x88760869. device.c:2569: Test failed: Got unexpect screen size 800x600. device.c:2584: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2593: Test failed: Got unexpect screen size 800x600. device.c:2606: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2614: Test failed: Got unexpect width 640. device.c:2615: Test failed: Got unexpect height 480.

1 0

Re: [PATCH 5/9] d3d8/tests: Test WM_SYSCOMMAND handling.
by Marvin Dec. 4, 2014

Dec. 4, 2014

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=10620 Your paranoid android. === w8 (32 bit device) === device.c:1222: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1267: Test failed: Reset failed, hr 0x88760868. device.c:1269: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1273: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1280: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1281: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1282: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1283: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1284: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1285: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1290: Test failed: Screen width is 640, expected 800. device.c:1291: Test failed: Screen height is 480, expected 600. device.c:1297: Test failed: Back buffer width is 640, expected 800. device.c:1299: Test failed: Back buffer height is 480, expected 600. device.c:1329: Test failed: Screen width is 640, expected 1024. device.c:1330: Test failed: Screen height is 480, expected 768. device.c:2550: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2555: Test failed: The focus window is active. device.c:2563: Test failed: Got unexpected hr 0x88760869. device.c:2569: Test failed: Got unexpect screen size 800x600. device.c:2584: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2593: Test failed: Got unexpect screen size 800x600. device.c:2606: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2614: Test failed: Got unexpect width 640. device.c:2615: Test failed: Got unexpect height 480.

1 0

Re: [PATCH 3/9] d3d8/tests: Test focus loss message filtering.
by Marvin Dec. 4, 2014

Dec. 4, 2014

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=10618 Your paranoid android. === w8 (32 bit device) === device.c:1222: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1267: Test failed: Reset failed, hr 0x88760868. device.c:1269: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1273: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1280: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1281: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1282: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1283: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1284: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1285: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1290: Test failed: Screen width is 640, expected 800. device.c:1291: Test failed: Screen height is 480, expected 600. device.c:1297: Test failed: Back buffer width is 640, expected 800. device.c:1299: Test failed: Back buffer height is 480, expected 600. device.c:1329: Test failed: Screen width is 640, expected 1024. device.c:1330: Test failed: Screen height is 480, expected 768. device.c:2524: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2529: Test failed: The focus window is active. device.c:2537: Test failed: Got unexpected hr 0x88760869. device.c:2543: Test failed: Got unexpect screen size 800x600. device.c:2558: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2567: Test failed: Got unexpect screen size 800x600. device.c:2580: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2587: Test failed: Got unexpect width 640. device.c:2588: Test failed: Got unexpect height 480.

1 0

Re: ntdll: Adds support for custom serial port baudrates on Mac
by Nikolay Sivov Dec. 4, 2014

Dec. 4, 2014

On 11/29/2014 07:53 PM, Nathan Fearnley wrote: > Mac OS X supports a special function call for custom baud rates. I have > implemented this feature to allow non-standard baud rates. > Unfortunately, setting any other parameters using tcsetattr will fail, > because it does not support the higher baud rates. In order to work > around this, when setting other parameters, the baud rate is temporarily > set to 9600, then reset back to custom rate after the changes are complete. > > I can't comment on functional part, but regarding code structure this should be better separated imho. Maybe it's even better to duplicate whole functions and ifdef them all in case when __APPLE__ is not defined. Also don't use C++ 'bool', use BOOL with TRUE/FALSE defines.

2 1

Re: [PATCH] winealsa: do not destroy remapping info on IsFormatSupported
by Andrew Eikum Dec. 4, 2014

Dec. 4, 2014

Good catch. I don't like the copying, though. What about making: struct alsa_channel_map { int alsa_channels; int map[32]; }; and passing that into map_channels()? need_remapping can be indicated by a S_FALSE vs S_OK return from map_channels(), or maybe set outside the call in _Initialize(). What do you think? Andrew On Thu, Dec 04, 2014 at 02:26:05PM +0000, Mark Harmstone wrote: > At present, AudioClient_IsFormatSupported nukes the remapping information > if called after AudioClient_Initialize. > > --- > dlls/winealsa.drv/mmdevdrv.c | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > > diff --git a/dlls/winealsa.drv/mmdevdrv.c b/dlls/winealsa.drv/mmdevdrv.c > index 007f351..3d14a53 100644 > --- a/dlls/winealsa.drv/mmdevdrv.c > +++ b/dlls/winealsa.drv/mmdevdrv.c > @@ -1598,6 +1598,8 @@ static HRESULT WINAPI AudioClient_IsFormatSupported(IAudioClient *iface, > WAVEFORMATEX *closest = NULL; > unsigned int max = 0, min = 0; > int err; > + int alsa_channels_orig, alsa_channel_map_orig[32]; > + BOOL need_remapping_orig; > > TRACE("(%p)->(%x, %p, %p)\n", This, mode, fmt, out); > > @@ -1692,9 +1694,18 @@ static HRESULT WINAPI AudioClient_IsFormatSupported(IAudioClient *iface, > closest->nChannels = min; > } > > + need_remapping_orig = This->need_remapping; > + alsa_channels_orig = This->alsa_channels; > + memcpy(alsa_channel_map_orig, This->alsa_channel_map, sizeof(This->alsa_channel_map)); > + > if(FAILED(map_channels(This, fmt))){ > hr = AUDCLNT_E_DEVICE_INVALIDATED; > WARN("map_channels failed\n"); > + > + This->need_remapping = need_remapping_orig; > + This->alsa_channels = alsa_channels_orig; > + memcpy(This->alsa_channel_map, alsa_channel_map_orig, sizeof(This->alsa_channel_map)); > + > goto exit; > } > if(This->alsa_channels > max){ > @@ -1702,6 +1713,10 @@ static HRESULT WINAPI AudioClient_IsFormatSupported(IAudioClient *iface, > closest->nChannels = max; > } > > + This->need_remapping = need_remapping_orig; > + This->alsa_channels = alsa_channels_orig; > + memcpy(This->alsa_channel_map, alsa_channel_map_orig, sizeof(This->alsa_channel_map)); > + > if(closest->wFormatTag == WAVE_FORMAT_EXTENSIBLE) > ((WAVEFORMATEXTENSIBLE*)closest)->dwChannelMask = get_channel_mask(closest->nChannels); > > >

1 0

Re: [PATCH 6/8] ddraw/tests: Test WM_SYSCOMMAND handling.
by Marvin Dec. 4, 2014

Dec. 4, 2014

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=10606 Your paranoid android. === w8 (32 bit ddraw2) === ddraw2.c:3814: Test failed: Expected WM_ACTIVATEAPP, but did not receive it. === w8 (32 bit ddraw4) === ddraw4.c:4169: Test failed: Expected WM_ACTIVATEAPP, but did not receive it.

2 1

Re: [PATCH 8/8] wined3d: Pass WM_SYSCOMMAND(SC_RESTORE) to DefWindowProc.
by Marvin Dec. 4, 2014

Dec. 4, 2014

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=10609 Your paranoid android. === w8 (32 bit device) === device.c:1222: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1267: Test failed: Reset failed, hr 0x88760868. device.c:1269: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1273: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1280: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1281: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1282: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1283: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1284: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1285: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1290: Test failed: Screen width is 640, expected 800. device.c:1291: Test failed: Screen height is 480, expected 600. device.c:1297: Test failed: Back buffer width is 640, expected 800. device.c:1299: Test failed: Back buffer height is 480, expected 600. device.c:1329: Test failed: Screen width is 640, expected 1024. device.c:1330: Test failed: Screen height is 480, expected 768. device.c:2550: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2555: Test failed: The focus window is active. device.c:2563: Test failed: Got unexpected hr 0x88760869. device.c:2569: Test failed: Got unexpect screen size 800x600. device.c:2584: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2593: Test failed: Got unexpect screen size 800x600. device.c:2606: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2614: Test failed: Got unexpect width 640. device.c:2615: Test failed: Got unexpect height 480.

1 0

Re: [PATCH 7/8] wined3d: Filter messages generated by focus handling.
by Marvin Dec. 4, 2014

Dec. 4, 2014

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=10607 Your paranoid android. === w8 (32 bit device) === device.c:1222: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1267: Test failed: Reset failed, hr 0x88760868. device.c:1269: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1273: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1280: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1281: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1282: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1283: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1284: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1285: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1290: Test failed: Screen width is 640, expected 800. device.c:1291: Test failed: Screen height is 480, expected 600. device.c:1297: Test failed: Back buffer width is 640, expected 800. device.c:1299: Test failed: Back buffer height is 480, expected 600. device.c:1329: Test failed: Screen width is 640, expected 1024. device.c:1330: Test failed: Screen height is 480, expected 768. device.c:2550: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2555: Test failed: The focus window is active. device.c:2563: Test failed: Got unexpected hr 0x88760869. device.c:2569: Test failed: Got unexpect screen size 800x600. device.c:2584: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2593: Test failed: Got unexpect screen size 800x600. device.c:2606: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2614: Test failed: Got unexpect width 640. device.c:2615: Test failed: Got unexpect height 480.

1 0

Re: ole32: fixed CoWaitForMultipleHandles cause app hang
by Changhui Liu Dec. 4, 2014

Dec. 4, 2014

Hi, it's not your recent fix cause. The app is named QQ, a very popular IM client in China. When it runs, it create two process named QQ.exe and TXPlatform.exe. The TXPlatform.exe is an out-of-process COM server, The QQ.exe is the GUI process. When the user click the exit button of the QQ.exe, the QQ.exe and TXPlatform.exe both hang. The backtrace of the GUI thread of QQ.exe is like this: =>0 0xf779d42e __kernel_vsyscall+0xe() in [vdso].so (0x0033e938) 1 0xf7598e1b __libc_read+0x4a() in libpthread.so.0 (0x0033e938) 2 0x7ef8ec9a wait_select_reply+0x30(cookie=0x33e968) 3 0x7ef8fac6 server_select+0x20c(select_op=0x33ea8c, size=0x8, flags=0x2, timeout=(nil)) 4 0x7ef998e7 NtWaitForMultipleObjects+0xbc(count=0x1, handles=0x33ebe0, wait_any=1, alertable=0, timeout=(nil)) 5 0x7ecbcd31 WaitForMultipleObjectsEx+0x191 in kernel32 (0x0033ecf8) 6 0x7e13c224 CoWaitForMultipleHandles+0x4e2 in ole32 (0x0033edf8) 7 0x7e1775b8 ClientRpcChannelBuffer_SendReceive+0x598 in ole32 (0x0033eef8) ... And the backtrace of another thread of QQ.exe is like this: Backtracing for thread 0080 in process 003c (C:\Program Files\Tencent\QQ\Bin\QQ.exe): Backtrace: =>0 0xf779d42e __kernel_vsyscall+0xe() in [vdso].so (0x020ce2a8) 1 0xf7598e1b __libc_read+0x4a() in libpthread.so.0 (0x020ce2a8) 2 0x7ef8ec9a wait_select_reply+0x30(cookie=0x20ce2d8) 3 0x7ef8fac6 server_select+0x20c(select_op=0x20ce3fc, size=0x8, flags=0x2, timeout=(nil)) 4 0x7ef998e7 NtWaitForMultipleObjects+0xbc(count=0x1, handles=0x20ce550, wait_any=1, alertable=0, timeout=(nil)) 5 0x7ecbcd31 WaitForMultipleObjectsEx+0x191 6 0x7ecbcae7 WaitForSingleObject+0x45 7 0x7e179258 dispatch_rpc+0x350(msg=0x3f24668) in ole32 (0x020ce788) 8 0x7e0c10fa process_request_packet+0x3b8(conn=0x158370, hdr=0x55a12e8, msg=0x3f24668) in rpcrt4 (0x020ce8c8) 9 0x7e0c15c6 RPCRT4_process_packet+0x114(conn=0x158370, hdr=0x55a12e8, msg=0x3f24668, auth_data=0x0(nil), auth_length=0) in rpcrt4 (0x020ce928) 10 0x7e0c1759 RPCRT4_worker_thread+0x4e( in rpcrt4 (0x020ce978) ... The dispatch_rpc thread has post a 0x400 RPC message to the GUI thread and is waiting for GUI thread to process the RPC request. But the GUI thread has received WM_QUIT message, the message_loop variable set to FALSE and it only wait for event signal, so the 0x400 RPC message can't be handled. The TXPlatform.exe hang because it is waiting for dispatch_rpc thread send RPC result to a named pipe. Because the hang is too complex , I don't know how to add a test for it. ------------------ Original ------------------ From: "Sebastian Lackner"<sebastian(a)fds-team.de>; Date: Wed, Dec 3, 2014 06:42 PM To: "liuchanghui"<liuchanghui(a)linuxdeepin.com>; Cc: "wine-devel"<wine-devel(a)winehq.org>; Subject: Re: ole32: fixed CoWaitForMultipleHandles cause app hang On 03.12.2014 08:15, Changhui Liu wrote: > > > Do I understand you correctly that this is caused by my recent fix of CoWaitForMultipleHandles? Which app is it? Your change might be correct, but to ensure that this is the case please add a test for it: http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ole32/tests/compobj.c… Moreover you should completely remove old code then, not just comment it out. Regards, Sebastian

1 0

Re: [PATCH 5/8] d3d8/tests: Test WM_SYSCOMMAND handling.
by Marvin Dec. 4, 2014

Dec. 4, 2014

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=10605 Your paranoid android. === w8 (32 bit device) === device.c:1222: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1267: Test failed: Reset failed, hr 0x88760868. device.c:1269: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1273: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1280: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1281: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1282: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1283: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1284: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1285: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1290: Test failed: Screen width is 640, expected 800. device.c:1291: Test failed: Screen height is 480, expected 600. device.c:1297: Test failed: Back buffer width is 640, expected 800. device.c:1299: Test failed: Back buffer height is 480, expected 600. device.c:1329: Test failed: Screen width is 640, expected 1024. device.c:1330: Test failed: Screen height is 480, expected 768. device.c:2550: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2555: Test failed: The focus window is active. device.c:2563: Test failed: Got unexpected hr 0x88760869. device.c:2569: Test failed: Got unexpect screen size 800x600. device.c:2584: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2593: Test failed: Got unexpect screen size 800x600. device.c:2606: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2614: Test failed: Got unexpect width 640. device.c:2615: Test failed: Got unexpect height 480.

1 0

Re: [PATCH 3/8] d3d8/tests: Test focus loss message filtering.
by Marvin Dec. 4, 2014

Dec. 4, 2014

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=10603 Your paranoid android. === w8 (32 bit device) === device.c:1222: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1267: Test failed: Reset failed, hr 0x88760868. device.c:1269: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1273: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1280: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1281: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1282: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1283: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1284: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1285: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1290: Test failed: Screen width is 640, expected 800. device.c:1291: Test failed: Screen height is 480, expected 600. device.c:1297: Test failed: Back buffer width is 640, expected 800. device.c:1299: Test failed: Back buffer height is 480, expected 600. device.c:1329: Test failed: Screen width is 640, expected 1024. device.c:1330: Test failed: Screen height is 480, expected 768. device.c:2524: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2529: Test failed: The focus window is active. device.c:2537: Test failed: Got unexpected hr 0x88760869. device.c:2543: Test failed: Got unexpect screen size 800x600. device.c:2558: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2567: Test failed: Got unexpect screen size 800x600. device.c:2580: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2587: Test failed: Got unexpect width 640. device.c:2588: Test failed: Got unexpect height 480.

1 0

Re: urlmon/tests: Remove unused strings (Clang)
by Marvin Dec. 3, 2014

Dec. 3, 2014

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=10595 Your paranoid android. === w2008s64 (32 bit url) === url.c:1478: Test failed: progress 2: hres = 1, expected 0 url.c:1668: Test failed: unexpected call OnProgress_FINDINGRESOURCE url.c:1478: Test failed: progress 1: hres = 1, expected 0 url.c:1680: Test failed: unexpected call OnProgress_CONNECTING url.c:1478: Test failed: progress 2: hres = 1, expected 0 url.c:1701: Test failed: unexpected call OnProgress_SENDINGREQUEST

1 0

Re: user32/tests: Remove unused variables (Clang)
by Marvin Dec. 3, 2014

Dec. 3, 2014

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=10592 Your paranoid android. === w7u (32 bit msg) === msg.c:12105: Test failed: unexpected hwnd 0012013C msg.c:12127: Test failed: bad time 310a2/310b2

1 0

Re: user32/tests: Remove unused variables (Clang)
by André Hentschel Dec. 3, 2014

Dec. 3, 2014

Am 03.12.2014 um 23:53 schrieb André Hentschel: > --- > dlls/user32/tests/msg.c | 112 ------------------------------------------------ > 1 file changed, 112 deletions(-) Just want to note, that this code was added in 2003 and most likely has never been used, just in case someone wonders why i dare to remove so much code ;)

1 0

Re: [PATCH 08/15] msvcr120: Remove stray parameter specs for stub functions.
by Alexandre Julliard Dec. 3, 2014

Dec. 3, 2014

Martin Storsjo <martin(a)martin.st> writes: > This avoids adding stray functions when using make_specfiles. There shouldn't be any reason to do that. The parameters are here on purpose. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [PATCH] wine.inf: Add quotes to webbrowser command key for mailto protocol.
by Qian Hong Dec. 3, 2014

Dec. 3, 2014

Hi Indrek, On Mon, Dec 1, 2014 at 3:46 PM, Indrek Altpere <efbiaiinzinz(a)hotmail.com> wrote: > Hello > > I even saw your patch in my inbox but it does not appear at > https://source.winehq.org/patches/data/107949 for some reason, so I don't > remember what lines you changed exactly so apologies if I seem to be > re-stating things tou fixed already. > > > When checking > http://source.winehq.org/git/wine.git/blob_plain/HEAD:/loader/wine.inf.in > there is also tons of other discrepancies (if you didn't already). > > > Parameters are escaped with ""%1"" but not command: > HKCR,Msi.Package\shell\Open\command,,2,"%11%\msiexec.exe /i ""%1""" > HKCR,Msi.Package\shell\Repair\command,,2,"%11%\msiexec.exe /f ""%1""" > HKCR,Msi.Package\shell\Uninstall\command,,2,"%11%\msiexec.exe /x ""%1""" > > > Command itself is escaped: > HKCR,htmlfile\shell\open\command,,2,"""%11%\winebrowser.exe"" -nohome" > > > Neither command nor parameter is escaped: > HKCR,txtfile\shell\open\command,,2,"%11%\notepad.exe %1" > HKCR,txtfile\shell\print\command,,2,"%11%\notepad.exe /p %1" > HKCR,wrifile\shell\open\command,,2,"%11%\wordpad.exe %1" > HKCR,wrifile\shell\print\command,,2,"%11%\wordpad.exe /p %1" > > HKCR,rtffile\shell\open\command,,2,"%11%\wordpad.exe %1" > HKCR,rtffile\shell\print\command,,2,"%11%\wordpad.exe /p %1" > > HKCR,inffile\shell\install\command,,2,"%11%\rundll32.exe > setupapi,InstallHinfSection DefaultInstall 132 %1" > > HKCR,hlpfile\shell\open\command,,2,"%11%\winhlp32.exe %1" > > > If winebrowser needs escaping because %11 contains a space then all other > places also use %11 need that escaping. And if msiexec need to escape %1 > then all other places need it too don't they? > Thanks a lot for your comment, I'm investigating a bit more... Will update later :) -- Regards, Qian Hong - http://www.codeweavers.com

1 0

Re: [PATCH 01/15] msvcr120: Implement the _vacopy function.
by Martin Storsjö Dec. 3, 2014

Dec. 3, 2014

Hi, On Mon, 1 Dec 2014, Martin Storsjo wrote: > --- > dlls/msvcr120/msvcr120.spec | 2 +- > dlls/msvcrt/misc.c | 8 ++++++++ > include/msvcrt/crtdefs.h | 2 ++ > 3 files changed, 11 insertions(+), 1 deletion(-) I saw on http://source.winehq.org/patches/ that this one was rejected - any comment on why and what needs to be fixed? // Martin

2 1

Re: [PATCH 02/15] msvcr120: Implement more C99 math functions.
by Alexandre Julliard Dec. 3, 2014

Dec. 3, 2014

Martin Storsjo <martin(a)martin.st> writes: > Implement the *rint, trunc, *round, log2, exp2 and cbrt > function families. > > These are directly passed on to the corresponding host > libc functions. You can't do that, there's no guarantee that the host has these functions. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: ole32: fixed CoWaitForMultipleHandles cause app hang
by Sebastian Lackner Dec. 3, 2014

Dec. 3, 2014

On 03.12.2014 08:15, Changhui Liu wrote: > > > Do I understand you correctly that this is caused by my recent fix of CoWaitForMultipleHandles? Which app is it? Your change might be correct, but to ensure that this is the case please add a test for it: http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ole32/tests/compobj.c… Moreover you should completely remove old code then, not just comment it out. Regards, Sebastian

1 0

Re: msi: Properly handle service control events in Start/StopService.
by Marvin Dec. 2, 2014

Dec. 2, 2014

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=10574 Your paranoid android. === wxppro (32 bit action) === The test timed out === w7u (32 bit action) === The test timed out === w8 (32 bit action) === The test timed out === wvistau64 (64 bit action) === The test timed out

1 0

Re: ole32/tests: Remove unused variable (Clang)
by Marvin Dec. 1, 2014

Dec. 1, 2014

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=10569 Your paranoid android. === wvistau64 (32 bit moniker) === moniker: unhandled exception c0000005 at 00427679 === w2008s64 (32 bit moniker) === moniker: unhandled exception c0000005 at 00427679 === w7u (32 bit moniker) === moniker: unhandled exception c0000005 at 00427679 === w8 (32 bit moniker) === moniker: unhandled exception c0000005 at 00427679 === wvistau64 (64 bit moniker) === moniker: unhandled exception c0000005 at 0000000000421BDA === w2008s64 (64 bit moniker) === moniker: unhandled exception c0000005 at 0000000000421BDA

1 0

Re: msi/tests: Remove unused variables (Clang)
by Marvin Dec. 1, 2014

Dec. 1, 2014

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=10567 Your paranoid android. === wxppro (32 bit install) === The test timed out === w7u (32 bit install) === The test timed out === w8 (32 bit install) === The test timed out

1 0

Re: mshtml/tests: Remove unused variable (Clang)
by Marvin Dec. 1, 2014

Dec. 1, 2014

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=10565 Your paranoid android. === w2000pro (32 bit events) === The test timed out

1 0

Re: kernel32/tests: Remove unused strings (Clang)
by Marvin Dec. 1, 2014

Dec. 1, 2014

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=10564 Your paranoid android. === wvistau64 (32 bit file) === file.c:365: Test failed: attributes of file "testfile.xxx" are 0x0820 === wvistau64 (64 bit file) === file.c:365: Test failed: attributes of file "testfile.xxx" are 0x0820

1 0

Re: [PATCH 2/3] d3d8: Refuse to reset a lost device (v2).
by Marvin Dec. 1, 2014

Dec. 1, 2014

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=10563 Your paranoid android. === w8 (32 bit device) === device.c:1222: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1267: Test failed: Reset failed, hr 0x88760868. device.c:1269: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1273: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1280: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1281: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1282: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1283: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1284: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1285: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1290: Test failed: Screen width is 640, expected 800. device.c:1291: Test failed: Screen height is 480, expected 600. device.c:1297: Test failed: Back buffer width is 640, expected 800. device.c:1299: Test failed: Back buffer height is 480, expected 600. device.c:1329: Test failed: Screen width is 640, expected 1024. device.c:1330: Test failed: Screen height is 480, expected 768. device.c:2517: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2522: Test failed: The focus window is active. device.c:2530: Test failed: Got unexpected hr 0x88760869. device.c:2536: Test failed: Got unexpect screen size 800x600. device.c:2551: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2560: Test failed: Got unexpect screen size 800x600. device.c:2573: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2580: Test failed: Got unexpect width 640. device.c:2581: Test failed: Got unexpect height 480.

1 0

Re: [PATCH 1/5] d3d9: Refuse to reset a lost device.
by Henri Verbeet Dec. 1, 2014

Dec. 1, 2014

On 28 November 2014 at 11:16, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if (!device->d3d_parent->extended && InterlockedCompareExchange(&device->device_state, > + D3D9_DEVICE_STATE_LOST, D3D9_DEVICE_STATE_LOST) == D3D9_DEVICE_STATE_LOST) Do you need the InterlockedCompareExchange()?

2 3

Re: mshtml: Added support for flag 2 in getAttribute.
by Marvin Dec. 1, 2014

Dec. 1, 2014

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=10556 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [PATCH] wine.inf: Add quotes to webbrowser command key for mailto protocol.
by Qian Hong Dec. 1, 2014

Dec. 1, 2014

Hi, `git grep command | grep HKCR | grep -v '"""'` exposed more places which seems missing quotes in command key, anyone know if we should update every place? Any advice is great appreciated! loader/wine.inf.in:HKCR,chm.file\shell\open\command,,2,"%10%\hh.exe %1" loader/wine.inf.in:HKCR,cplfile\shell\cplopen\command,,2,"rundll32.exe shell32.dll,Control_RunDLL ""%1"",%*" loader/wine.inf.in:HKCR,hlpfile\shell\open\command,,2,"%11%\winhlp32.exe %1" loader/wine.inf.in:HKCR,inffile\shell\install\command,,2,"%11%\rundll32.exe setupapi,InstallHinfSection DefaultInstall 132 %1" loader/wine.inf.in:HKCR,inifile\shell\open\command,,2,"%11%\notepad.exe %1" loader/wine.inf.in:HKCR,inifile\shell\print\command,,2,"%11%\notepad.exe /p %1" loader/wine.inf.in:HKCR,rtffile\shell\open\command,,2,"%11%\wordpad.exe %1" loader/wine.inf.in:HKCR,rtffile\shell\print\command,,2,"%11%\wordpad.exe /p %1" loader/wine.inf.in:HKCR,txtfile\shell\open\command,,2,"%11%\notepad.exe %1" loader/wine.inf.in:HKCR,txtfile\shell\print\command,,2,"%11%\notepad.exe /p %1" loader/wine.inf.in:HKCR,wrifile\shell\open\command,,2,"%11%\wordpad.exe %1" loader/wine.inf.in:HKCR,wrifile\shell\print\command,,2,"%11%\wordpad.exe /p %1" On Mon, Dec 1, 2014 at 1:38 PM, Qian Hong <qhong(a)codeweavers.com> wrote: > Hi Piotr, > > This is a follow up of the below commit: > > commit 54833c9b7cf5f8f5e37b43038e1fa4c1c369deb0 > Author: Piotr Caban <piotr(a)codeweavers.com> > Date: Wed May 4 13:20:41 2011 +0200 > > wine.inf: Add quotes to webbrowser command keys. > > To make sure i'm not breaking anything which is intended, would you mind > have a look? > > Thanks! > > --- > loader/wine.inf.in | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > -- Regards, Qian Hong - http://www.codeweavers.com

1 0