March 2013 - Wine-devel - list.winehq.org

Fresh WineWiki Theme, Straight from the Farm
by Kyle Auble 11 Apr '13

11 Apr '13

So as usual, my estimate of how long it would take was way off, but I'm finally done adapting the WineHQ theme to Moinmoin. It's not perfect, but I feel it's ready to submit for switching over. I've tested it in Firefox, Chromium, Midori, and Opera (briefly in IE8 & IE9 too). I did do everything through Moinmoin's stand-alone server, but while I know there always seem to be ghosts in the machine, I'm guessing that Apache shouldn't interfere with layout issues. I mostly followed the WineHQ & current WineWiki theme for large things, just tweaking the CSS to make it fit what Moinmoin spits out. I did make more design choices of my own on the smaller stuff though. After wrestling with Moinmoin's theme system, I was surprised how many things are still hard-coded (at least as of v1.5). For example, Moinmoin wraps some things in divs without providing a CSS class for the div, just the child element. The fortune cookie on the RecentChanges page & the edit page are two cases of that. The dummy content in the search bar is another tricky one. It's set in the javascript for the search bar (don't remember where it was in the source tree) so I left that one alone. One other tricky issue was handling overflows & RTL support. They both seem to work ok in isolation, but go crazy when you mix them. I haven't checked RTL in IE, but if you force an RTL page to overflow in Webkit, it positions things based on what's actually in the window (so the sidebar winds up floating in the middle of the page). Firefox simply doesn't try to apply any of the overflow rules in RTL (which I guess is nice in a Hippocratic sense). Opera alone handled things exactly like I hoped. As for the tables, I think they should display ok now, although I don't know if everyone wants my exact values for paddings & such. The old theme had some table-based layout that may have had conflicting CSS rules, but I've div-vied everything up so the only table tags now should be when Moinmoin itself chooses them over a div and well... tables. I've pushed all of the changes to my Bitbucket repo at: https://bitbucket.org/kauble/wine-wiki-migration The "refined" branch is the one you want although I expect that once the code is hosted at WineHQ's git repo, it would become the new master branch. At that point, I can just reset my repo to point to the WineHQ one as the origin. - Kyle

3 4

Re: secur32: Take schannel backend capabilities into account when configuring enabled protocols.
by Ken Thomases 11 Apr '13

11 Apr '13

On Mar 28, 2013, at 6:05 AM, Jacek Caban wrote: > --- a/dlls/secur32/schannel_macosx.c > +++ b/dlls/secur32/schannel_macosx.c > @@ -630,6 +630,11 @@ static OSStatus schan_push_adapter(SSLConnectionRef transport, const void *buff, > return ret; > } > > +DWORD schan_imp_enabled_protocols(void) > +{ > + /* NOTE: No support for TLS 1.1 and TLS 1.2 */ > + return SP_PROT_SSL2_CLIENT | SP_PROT_SSL3_CLIENT | SP_PROT_TLS1_0_CLIENT; > +} Mac OS X 10.8 introduced support for TLS 1.1 and 1.2. You can test at build time with: #if MAC_OS_X_VERSION_MAX_ALLOWED >= 1080 ... #else ... #endif If we want to support building on 10.8 for deployment to earlier versions, we'd do something like: #if MAC_OS_X_VERSION_MAX_ALLOWED >= 1080 SSLProtocol maxProtocol; if (SSLGetProtocolVersionMax != NULL && SSLGetProtocolVersionMax(context, &maxProtocol) == noErr) { ... compare maxProtocol against kTLSProtocol11 and kTLSProtocol12 ... } ... #else ... #endif The idea is that SSLGetProtocolVersionMax() would be weak linked, so we'd check if it was actually available before calling it. Of course, the other complication is that that function requires a context parameter, but we can create one just for the query if we're interested in the framework capabilities (as opposed to what's been configured for a particular context). -Ken

3 10

[PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
by Pavel Shilovsky 04 Apr '13

04 Apr '13

This patchset adds support of O_DENY* flags for Linux fs layer. These flags can be used by any application that needs share reservations to organize a file access. VFS already has some sort of this capability - now it's done through flock/LOCK_MAND mechanis, but that approach is non-atomic. This patchset build new capabilities on top of the existing one but doesn't bring any changes into the flock call semantic. These flags can be used by NFS (built-in-kernel) and CIFS (Samba) servers and Wine applications through VFS (for local filesystems) or CIFS/NFS modules. This will help when e.g. Samba and NFS server share the same directory for Windows and Linux users or Wine applications use Samba/NFS share to access the same data from different clients. According to the previous discussions the most problematic question is how to prevent situations like DoS attacks where e.g /lib/liba.so file can be open with DENYREAD, or smth like this. That's why one extra flag O_DENYMAND is added. It indicates to underlying layer that an application want to use O_DENY* flags semantic. It allows us not affect native Linux applications (that don't use O_DENYMAND flag) - so, these flags (and the semantic of open syscall that they bring) are used only for those applications that really want it proccessed that way. So, we have four new flags: O_DENYREAD - to prevent other opens with read access, O_DENYWRITE - to prevent other opens with write access, O_DENYDELETE - to prevent delete operations (this flag is not implemented in VFS and NFS part and only suitable for CIFS module), O_DENYMAND - to switch on/off three flags above. Also, this version of the patchset fixes the problem of data races on newely created files: open with O_CREAT can return the -ETXTBSY error for a successfully created file if this files was locked with a deny lock by another task. The #1 patch adds flags to fcntl, the #2 patch implements VFS part. The patches #3, #4, #5 are related to CIFS-specific changes, #6 and #7 describe NFS and NFSD parts. The preliminary patch for Samba that replaces the existing use of flock/LOCK_MAND mechanism with O_DENY* flags: http://git.etersoft.ru/people/piastry/packages/?p=samba.git;a=commitdiff;h=… The future part of open man page patch: ----- O_DENYMAND - used to inforce a mandatory share reservation scheme of the file access. If this flag is passed, the open fails with -ETXTBSY in following cases: 1) if O_DENYREAD flag is specified and there is another open with O_DENYMAND flag and READ access to the file; 2) if O_DENYWRITE flag is specified and there is another open with O_DENYMAND flag and WRITE access to the file; 3) if READ access is requested and there is another open with O_DENYMAND and O_DENYREAD flags; 4) if WRITE access is requested and there is another open with O_DENYMAND and O_DENYWRITE flags. If O_DENYDELETE flag is specified and the open succeded, any further unlink operation will fail with -ETXTBSY untill this open is closed. Now this flag is processed by CIFS filesystems only. This mechanism is done through flocks. If O_DENYMAND is specified and flock syscall is processed after the open. The share modes are translated into flock according the following rules: 1) O_DENYMAND -> LOCK_MAND 2) !O_DENYREAD -> LOCK_READ 3) !O_DENYWRITE -> LOCK_WRITE ----- Pavel Shilovsky (7): fcntl: Introduce new O_DENY* open flags vfs: Add O_DENYREAD/WRITE flags support for open syscall CIFS: Add O_DENY* open flags support CIFS: Use NT_CREATE_ANDX command for forcemand mounts CIFS: Translate SHARING_VIOLATION to -ETXTBSY error code for SMB2 NFSv4: Add O_DENY* open flags support NFSD: Pass share reservations flags to VFS fs/cifs/cifsacl.c | 6 +- fs/cifs/cifsglob.h | 12 +++- fs/cifs/cifsproto.h | 9 +-- fs/cifs/cifssmb.c | 47 ++++++++-------- fs/cifs/dir.c | 14 +++-- fs/cifs/file.c | 18 ++++-- fs/cifs/inode.c | 11 ++-- fs/cifs/link.c | 10 ++-- fs/cifs/readdir.c | 2 +- fs/cifs/smb1ops.c | 15 ++--- fs/cifs/smb2file.c | 10 ++-- fs/cifs/smb2inode.c | 4 +- fs/cifs/smb2maperror.c | 2 +- fs/cifs/smb2ops.c | 10 ++-- fs/cifs/smb2pdu.c | 6 +- fs/cifs/smb2proto.h | 14 +++-- fs/fcntl.c | 5 +- fs/locks.c | 117 +++++++++++++++++++++++++++++++++++---- fs/namei.c | 44 ++++++++++++++- fs/nfs/nfs4xdr.c | 24 ++++++-- fs/nfsd/nfs4state.c | 46 ++++++++++++++- include/linux/fs.h | 6 ++ include/uapi/asm-generic/fcntl.h | 14 +++++ 23 files changed, 345 insertions(+), 101 deletions(-) -- 1.8.1.2

8 36

Wine Gecko 2.20-beta1
by Jacek Caban 04 Apr '13

04 Apr '13

Hi all, I've uploaded a new Gecko builds to SourceForge [1]. This one is based on Firefox 20 beta and, other than usual update of Gecko, it should fix some crashes like bug b*ug 32753* <http://bugs.winehq.org/show_bug.cgi?id=32753>. To test them, you need recent Wine Git version with the attached patch. As usually, grab the build from SourceForge, put it in the right place [2] and run patched Wine. All help with testing is appreciated! Thanks, Jacek [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/2.20-beta1/ [2] http://wiki.winehq.org/Gecko

1 1

Problem about declarations of strcoll functions
by Jactry Zeng 01 Apr '13

01 Apr '13

Hi folks, I tried to implement a lot of strcoll function these days, and I meet some trouble when I added the declaration into include/msvcrt/*.h. With "grep coll *.spec" in dlls/msvcrt/ we can find there was a lot of strcoll function. Some of them was implemented and some of them not: @ cdecl ___lc_collate_cp_func() @ stub __lc_collate @ extern __lc_collate_cp MSVCRT___lc_collate_cp @ cdecl _mbscoll(str str) @ cdecl _mbscoll_l(str str ptr) @ cdecl _mbsicoll(str str) @ cdecl _mbsicoll_l(str str ptr) @ cdecl _mbsnbcoll(str str long) @ cdecl _mbsnbcoll_l(str str long ptr) @ cdecl _mbsnbicoll(str str long) @ cdecl _mbsnbicoll_l(str str long ptr) @ stub _mbsncoll(str str long) # stub _mbsncoll_l(str str long ptr) @ stub _mbsnicoll(str str long) # stub _mbsnicoll_l(str str long ptr) @ cdecl _strcoll_l(str str ptr) MSVCRT_strcoll_l @ cdecl _stricoll(str str) MSVCRT__stricoll @ cdecl _stricoll_l(str str ptr) MSVCRT__stricoll_l @ cdecl _strncoll(str str long) MSVCRT_strncoll_l @ cdecl _strncoll_l(str str long ptr) MSVCRT_strncoll @ cdecl _strnicoll(str str long) MSVCRT__strnicoll @ cdecl _strnicoll_l(str str long ptr) MSVCRT__strnicoll_l # stub _wcscoll_l(wstr wstr ptr) @ cdecl _wcsicoll(wstr wstr) MSVCRT__wcsicoll # stub _wcsicoll_l(wstr wstr ptr) @ cdecl _wcsncoll(wstr wstr long) MSVCRT__wcsncoll @ cdecl _wcsncoll_l(wstr wstr long ptr) MSVCRT__wcsncoll_l @ cdecl _wcsnicoll(wstr wstr long) MSVCRT__wcsnicoll # stub _wcsnicoll_l(wstr wstr long ptr) @ cdecl strcoll(str str) MSVCRT_strcoll @ cdecl wcscoll(wstr wstr) MSVCRT_wcscoll With "grep coll *.h" in include/msvcrt/ we can find some declarations of some strcoll function: crtdefs.h: unsigned int lc_collate_cp; mbstring.h:int __cdecl _mbscoll(const unsigned char*,const unsigned char*); mbstring.h:int __cdecl _mbsicoll(const unsigned char*,const unsigned char*); mbstring.h:int __cdecl _mbsnbcoll(const unsigned char*,const unsigned char*,size_t); mbstring.h:int __cdecl _mbsnbicoll(const unsigned char*,const unsigned char*,size_t); mbstring.h:int __cdecl _mbsncoll(const unsigned char*,const unsigned char*,size_t); mbstring.h:int __cdecl _mbsnicoll(const unsigned char*,const unsigned char*,size_t); string.h:int __cdecl _stricoll(const char*,const char*); string.h:int __cdecl strcoll(const char*,const char*); string.h:int __cdecl _wcsicoll(const wchar_t*,const wchar_t*); string.h:int __cdecl _wcsnicoll(const wchar_t*,const wchar_t*,size_t); string.h:int __cdecl wcscoll(const wchar_t*,const wchar_t*); string.h:static inline int stricoll(const char* s1, const char* s2) { return _stricoll(s1, s2); } string.h:static inline int wcsicoll(const wchar_t* str1, const wchar_t* str2) { return _wcsicoll(str1, str2); } wchar.h:int __cdecl _wcsicoll(const wchar_t*,const wchar_t*); wchar.h:int __cdecl _wcsnicoll(const wchar_t*,const wchar_t*,size_t); wchar.h:int __cdecl wcscoll(const wchar_t*,const wchar_t*); As we can see, _strcoll_l and _mbsnbcoll_l were implemented but they were not declared. Should we declare all of them? And whether the sequence was important? Thank you. -- Regards, Jactry Zeng

2 2

Float printf precision
by Stefan Dösinger 31 Mar '13

31 Mar '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Henri, While overhauling the patch to hardcode local constants in the shader code I came across the TRACEs in wined3d_device_set_{vs,ps}_consts_f, which print the floats with %.8e. You changed this from %f in 979e3744f7721bef9e88fd671dfd7591c9f85392. I was curious how you ended up with 8 digits. My thinking was that 32 bit floats have a 23 bit mantissa, and one digit in the printout encodes lb(10) bits - so you need ~6,9 digits to encode the mantissa, which rounds up to 7. Thinking further, %.6e should do the job as well, as there's one additional digit leading the decimal. Is my thinking correct, or am I missing something? Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRWAiyAAoJEN0/YqbEcdMw+4AQAIW57gxqJJcPEKzS35K4R++Q aMy1rma7JV4/cUmRIqkmOROc6Y3T2bz7x3e12mNpLVvI9YUBdaZKsofuBJk9QCtL R6nWL266dLc3aRdIFazwjxK6GmohqjxoLidpCAPSXGkekjw48DqhA+5fdXO2YYm/ 2g1Fhyy/cpi6BN2AUh760YNy3ojk/x9eH25oTmifFxCUbWlhYNGsIVt8OTTW9YBE RnQyyoO2lPjNi5mlNIqoSkkYriG5m97nS8bSMXvu9BjKW8rSmmErLGPf2zDL7Big wdibKxbXaSSx74upJaOTLjoOx04sqoi4SuPnX/55ftFKj7s2SeoFJaOUwgdNJoN+ UxKcd0HzfaXBi/VikYvtfMd0+SLA8wFIVjrJsWeBwgNU9cEAA3OiRFPWyizZCPqu 4UQOSnxuK6LZ7Ke58ikcG6JqMVTye8iTeEmr6r3NhkRdmCKrFbVGmJ1POb8Q26Hu q2yQBHq2L5CZ0Vx7fruvqq9Ap8auI/l5B6tneDM/RUdvpWxQTJneVRpSqIE50ZmW U3XH2cx4eLaEGJnSnHBgxnqgSAmcVTJEkFHtd8tCiqsPcnkw2g3Ng3gQZhjkDJ45 ZxvXNxVUl3B899Y1CwFd3FVJhKQq2jFS0NQvNQYZXhx0djZ2ok8rvtmoJzTaNN1s SMfTtZDHxHFtluASd6zJ =7CAL -----END PGP SIGNATURE-----

2 1

Re: wined3d: Properly handle WS_VISIBLE and WS_EX_TOPMOST style flags on fullscreen windows.
by Henri Verbeet 31 Mar '13

31 Mar '13

On 29 March 2013 03:31, Sam Edwards <cfsworks(a)gmail.com> wrote: > Note that the tests are NOT (primarily) intended to make sure that > WS_VISIBLE and WS_EX_TOPMOST are still set. The main purpose of this patch > is to fix a slightly more serious bug: > > - Create a window without WS_VISIBLE. > - Create a fullscreen Direct3D device. > - wined3d applies its own flags (including WS_VISIBLE) to the window, to > make it fullscreen. > - Reset the device back to windowed mode. > - Because wined3d_device_setup_fullscreen_window didn't see the window had > WS_VISIBLE, wined3d_device_restore_fullscreen_window won't restore the > style. > > This patch corrects that behavior, and the window restores back to its > original style as on Windows. > I think the idea is basically ok, but I do have some comments: I think test_window_style() is a more appropriate place for the tests, and you should add them to the variants in ddraw as well. Ddraw applications in particular are very fragile in this regard. Note that the test_window_style() tests are fairly similar to what your tests do, except that they don't test restoring the window as such. That test also shows that we're actually not supposed to touch the styles at all, but that's hard to make work without calling into winex11. > - SetWindowPos(window, HWND_TOP, 0, 0, w, h, SWP_FRAMECHANGED | SWP_SHOWWINDOW | SWP_NOACTIVATE); > + SetWindowPos(window, HWND_TOPMOST, 0, 0, w, h, SWP_FRAMECHANGED | SWP_SHOWWINDOW | SWP_NOACTIVATE); This is really a separate change. > + device->style ^= (device->style^style) & WS_VISIBLE; Spaces around the (second) ^, please.

2 2

[website try2] Simplified Chinese translation for release 1.5.27
by Jactry Zeng 30 Mar '13

30 Mar '13

1 0

Windows API on Linux
by Abhinav Jangda 30 Mar '13

30 Mar '13

Hello everyone, I'm working on a project which aims to develop a port of Windows API on Linux, so that programs written using Windows API could directly be compiled and executed on Linux with its native look and feel. Anyone, interested in working on this project. I think some Wine developers will be as they would be having a good knowledge of Windows API. If anyone interested then please let me know. Thank You :)

4 3

Re: [website] Simplified Chinese translation for release 1.5.27
by Hin-Tak Leung 30 Mar '13

30 Mar '13

--- On Sat, 30/3/13, Jactry Zeng <jactry92(a)gmail.com> wrote: From: Jactry Zeng <jactry92(a)gmail.com> Subject: Re: [website] Simplified Chinese translation for release 1.5.27 To: htl10(a)users.sourceforge.net Cc: "Wine Devel" <wine-devel(a)winehq.org>, "Qian Hong" <fracting(a)gmail.com> Date: Saturday, 30 March, 2013, 10:41 2013/3/30 Hin-Tak Leung <htl10(a)users.sourceforge.net> > > > I think both are terrible translations but could not think of a better alternative off my head, so I went to consult google translate. It defaults to 運行時庫 for "runtime library" but allow me to choose a few other alternatives, among which is > > "執行階段程式庫" > > Don't you think that's much better!? Hi Hin-Tak, Thanks for your review. I also think both "运行时" or "运行时库" was not best translation. But I have seen a lot of documents in Simplified Chinese translated it in this way. Maybe it was not too accurate... And in my opinion, "运行时" meaning some function, "运行时库" meaning a runtime library. To be honest, I think a lot of Chinese translations of technical topics (or even not-technical topics) are quite poor, and little beyond a word-for-word substitution. run -> 运行 ("to convey/process", the more common use of "run", of 'using your legs faster than walking' is obviously wrong) time -> 时 ("hour", "during") library -> 库 ("storage container", the more common use of "library" to mean "collection of books" obviously wrong). Whereas "執行階段程式庫" meaning "the program/routine library of/in the execute stage" is quite a lot more fitting to what 'runtime library' actually means. As I was saying, one needs to be vigilant about automated translations being 'not quite correct'. I suspect it is a much abused practice in China, so you see the same (mis-)usage over and over. There are entire web sites devoted to poorly translated public signs in China and making fun of them. It is quite educational - one gets lazy and and accepts the occasional poor translation, but seeing similar but slightly different mistakes collected in a large quantity really makes one think. 2013/3/30 Jactry Zeng <jactry92(a)gmail.com> > > I translated it as "高质量" meaning a picture have hight resolution. Here has a typo, hight -> higher .... -- Regards, Jactry Zeng

1 0