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

Problem about declarations of strcoll functions

by Jactry Zeng

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

March 31, 2013

Re: Float printf precision

by Henri Verbeet

On 31 March 2013 11:58, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > 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? > It's been a while since I actually did the calculation, but IIRC you also need to take the implicit extra bit in the significand into account, so you'd end up with log(2^24) = ~7.2, which would give %.7e. But I just rounded up to the next "round" number.

March 31, 2013

Float printf precision

by Stefan Dösinger

-----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-----

March 31, 2013

Re: wined3d: Properly handle WS_VISIBLE and WS_EX_TOPMOST style flags on fullscreen windows.

by Henri Verbeet

On 30 March 2013 23:50, Sam Edwards <cfsworks(a)gmail.com> wrote: > I'm a bit confused, then: Without this change, the exstyle test breaks, and the guidelines request that every patch be atomic. They also request that all tests be included in the same patch. I'm not sure there really is such a rule. > Off the top of my head, I would guess it's one of these: > 1. The "all tests in the same patch" rule is only appropriate for single-patch submissions, so in multipatch patchsets, it's acceptable to include a final patch with nothing but tests. > 2. Only introduce the tests in the last patch of the patchset. (That is, add them all at once, but only when all of the necessary changes have been made to allow the tests to work first.) > 3. Include each test in the first patch that will allow the test to pass. (That is, add them incrementally.) > 4. Add the tests as todo_wine in the first patch, then remove the todo_wine in later patches as each test becomes functional. (That is, add them all at once as todo_wine, and mark them as non-todo incrementally.) I think either or those is fine in principle, it depends a bit on the kind of test what's most practical. I guess that for this one you'll probably want 3.

March 31, 2013

[website try2] Simplified Chinese translation for release 1.5.27

by Jactry Zeng

March 31, 2013

Re: wined3d: Properly handle WS_VISIBLE and WS_EX_TOPMOST style flags on fullscreen windows.

by Sam Edwards

On 03/29/2013 06:16 AM, Henri Verbeet wrote: > 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. Ack, you're right! I saw the test_window_style() but second-guessed myself and put it into test_reset() instead... That was foolish of me. Thanks. >> - 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. I'm a bit confused, then: Without this change, the exstyle test breaks, and the guidelines request that every patch be atomic. They also request that all tests be included in the same patch.What is the proper procedure for this when it comes to multipatch patchsets? Off the top of my head, I would guess it's one of these: 1. The "all tests in the same patch" rule is only appropriate for single-patch submissions, so in multipatch patchsets, it's acceptable to include a final patch with nothing but tests. 2. Only introduce the tests in the last patch of the patchset. (That is, add them all at once, but only when all of the necessary changes have been made to allow the tests to work first.) 3. Include each test in the first patch that will allow the test to pass. (That is, add them incrementally.) 4. Add the tests as todo_wine in the first patch, then remove the todo_wine in later patches as each test becomes functional. (That is, add them all at once as todo_wine, and mark them as non-todo incrementally.) >> + device->style ^= (device->style^style) & WS_VISIBLE; > Spaces around the (second) ^, please. Done. :) Thank you, Sam

March 30, 2013

Fresh WineWiki Theme, Straight from the Farm

by Kyle Auble

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

March 30, 2013

Re: secur32: Take schannel backend capabilities into account when configuring enabled protocols.

by Juan Lang

Hi Jacek, On Sat, Mar 30, 2013 at 8:36 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: > Most of the argument could be used against enabling TLS 1.1 and TLS 1.2, > because it's not present on older Macs (nor enabled by default on Windows), > so we'll have different behaviour. That's sadly something we have to live > with. Anyway, I'm all for trying to avoid using SSL2, but I'd like to be a > bit less extreme. How about this patch: > > http://source.winehq.org/patches/data/95298 > > With this patch, SSL2 will be completely disabled in default Wine config, > but it will be still possible to enable by registries, if someone really > needs it. > Thanks, this approach looks good to me. --Juan

March 30, 2013

Re: Windows API on Linux

by Vincent Povirk

Mono on non-Windows platforms ships with a static library called io-layer that implements a small subset of the Windows API for compatibility reasons, without any server processes or a registry. It does not (normally) attempt to do any path translation, so I think that's as close as possible to what you want to achieve for those low-level api's. Of course, there's a limit to the level of compatibility (even if you're only looking for source compatibility) you can achieve without the sort of architecture Wine has to simulate services that are available on a real Windows system. Combine this with the fact that the Windows API just isn't very nice to program against, and it leads to little interest in a project like this. But maybe it would be possible for one person to pull this off for a large enough win32 subset to run a GUI application, using the code already available in Mono and Wine.

March 30, 2013

Re: secur32: Take schannel backend capabilities into account when configuring enabled protocols.

by Jacek Caban

Hi Juan, On 03/29/13 18:19, Juan Lang wrote: > Hi Jacek, > > thanks for the detailed reply. > > On Fri, Mar 29, 2013 at 3:02 AM, Jacek Caban <jacek(a)codeweavers.com > <mailto:jacek(a)codeweavers.com>> wrote: > > Each protocol has two kinds of enable/disable flags: "enabled" and > "disabled by default". Those have different default values for > each protocol and there are registry setting allowing to change > each of them. Only "enabled" protocols are used at all. This patch > limits "enabled" protocols to those that we can really support. If > an application asks schannel to use default set of protocols > (which I'd expect them to do unless they have a good reason), > schannel will use all "enabled" protocols that are not "disabled > by default". An alternative to default set of protocols is listing > each allowed separately. > > This means that if protocol is "enabled" and "disabled by default" > it won't be used unless application explicitly asks for it. SSL2 > is such a protocol by default. Do you think we should do this > differently? > > > Yes, my suggestion here is to explicitly disable SSL2 support > altogether. GnuTLS doesn't support it, and having behavior that > differs between Linux and Mac can be kind of maddening. I can imagine > something like, "embedded browser doesn't work for game X", with lots > of "works for me" reports and the occasional "fails here too", only to > discover that it works on Mac but not Linux. The additional cost of a > difference in behavior doesn't seem worth it, especially when the > protocol itself really should have died long ago. Most of the argument could be used against enabling TLS 1.1 and TLS 1.2, because it's not present on older Macs (nor enabled by default on Windows), so we'll have different behaviour. That's sadly something we have to live with. Anyway, I'm all for trying to avoid using SSL2, but I'd like to be a bit less extreme. How about this patch: http://source.winehq.org/patches/data/95298 With this patch, SSL2 will be completely disabled in default Wine config, but it will be still possible to enable by registries, if someone really needs it. Jacek

March 30, 2013