December 2014 - wine-devel

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

22 Nov '20

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 28 Sep '18

28 Sep '18

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 14 Jun '18

14 Jun '18

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 16 Jun '16

16 Jun '16

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 26 Jul '15

26 Jul '15

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 05 Jul '15

05 Jul '15

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 05 Jun '15

05 Jun '15

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 23 Apr '15

23 Apr '15

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 19 Jan '15

19 Jan '15

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 19 Jan '15

19 Jan '15

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 04 Jan '15

04 Jan '15

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 04 Jan '15

04 Jan '15

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 02 Jan '15

02 Jan '15

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 31 Dec '14

31 Dec '14

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 中川祥 31 Dec '14

31 Dec '14

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 31 Dec '14

31 Dec '14

-----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 31 Dec '14

31 Dec '14

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@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 中川祥 31 Dec '14

31 Dec '14

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 30 Dec '14

30 Dec '14

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@gmail.com> >>> 发送时间: ‎2014/‎12/‎15 13:08 >>> 收件人: Jeff Bai <mailto:jeffbaichina@gmail.com> >>> 抄送: wine-devel(a)winehq.org <mailto:wine-devel@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 30 Dec '14

30 Dec '14

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 29 Dec '14

29 Dec '14

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 29 Dec '14

29 Dec '14

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 29 Dec '14

29 Dec '14

-----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 29 Dec '14

29 Dec '14

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 29 Dec '14

29 Dec '14

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 29 Dec '14

29 Dec '14

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 29 Dec '14

29 Dec '14

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 28 Dec '14

28 Dec '14

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 28 Dec '14

28 Dec '14

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

1 0

CSMT patch
by Emanuele Oriani 28 Dec '14

28 Dec '14

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 27 Dec '14

27 Dec '14

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 27 Dec '14

27 Dec '14

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 24 Dec '14

24 Dec '14

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 24 Dec '14

24 Dec '14

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 24 Dec '14

24 Dec '14

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 24 Dec '14

24 Dec '14

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 24 Dec '14

24 Dec '14

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 23 Dec '14

23 Dec '14

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 23 Dec '14

23 Dec '14

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 23 Dec '14

23 Dec '14

"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 23 Dec '14

23 Dec '14

"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 23 Dec '14

23 Dec '14

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 22 Dec '14

22 Dec '14

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 21 Dec '14

21 Dec '14

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 20 Dec '14

20 Dec '14

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 20 Dec '14

20 Dec '14

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 19 Dec '14

19 Dec '14

- 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 19 Dec '14

19 Dec '14

"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 19 Dec '14

19 Dec '14

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 19 Dec '14

19 Dec '14

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel December 2014