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

Re: [website] Simplified Chinese translation for release 1.5.27

by Hin-Tak Leung

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

March 30, 2013

Re: [website] Simplified Chinese translation for release 1.5.27

by Hin-Tak Leung

This one I do without google translate, "high resolution" would be 高解像 . --- 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: "Qian Hong" <fracting(a)gmail.com> Cc: "Wine Devel" <wine-devel(a)winehq.org> Date: Saturday, 30 March, 2013, 10:23 2013/3/30 Qian Hong <fracting(a)gmail.com> > 2013/3/30 Jactry Zeng <jactry92(a)gmail.com>: > > + <li>一些 C 运行时的改进。</li> > > I think it is better to translate "C runtime" to “C 运行时库“ rather than > just ”C 运行时“。 > > + <li>为内建程序提供更高质量的图标。</li> > > Large icon means 大图标，not 高质量图标。You can verify this by the git commits。In fact, I have verified it before I commit this patch. I translated it as "高质量" meaning a picture have hight resolution. For a example, programs/wordpad/wordpad.ico, had a 48x48 resolution before, and now it is 256x256. > Thanks for the work. Thanks for your review. I will commit a newer patch. :-) -- Regards, Jactry Zeng -----Inline Attachment Follows-----

March 30, 2013

Re: Windows API on Linux

by Joris Huizer

On 03/29/2013 01:27 PM, Abhinav Jangda wrote: > 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. Reminds me of Winelib Joris

March 30, 2013

Re: [website] Simplified Chinese translation for release 1.5.27

by Jactry Zeng

2013/3/30 Qian Hong <fracting(a)gmail.com> > 2013/3/30 Jactry Zeng <jactry92(a)gmail.com>: > > + <li>一些 C 运行时的改进。</li> > > I think it is better to translate "C runtime" to “C 运行时库“ rather than > just ”C 运行时“。 > > + <li>为内建程序提供更高质量的图标。</li> > > Large icon means 大图标，not 高质量图标。You can verify this by the git commits。 In fact, I have verified it before I commit this patch. I translated it as "高质量" meaning a picture have hight resolution. For a example, programs/wordpad/wordpad.ico, had a 48x48 resolution before, and now it is 256x256. > Thanks for the work. Thanks for your review. I will commit a newer patch. :-) -- Regards, Jactry Zeng

March 30, 2013

Re: [website] Simplified Chinese translation for release 1.5.27

by Hin-Tak Leung

I was not very happy with "大型 ..." for "large icon", so I expanded the meaning a bit and did 'large size icon'. I think it should be 大規格 or 大尺寸 or 大碼 . All of them are more precise about "size", whereas "大型" is less precise and more generic as in 'large format'/'large style'. So I would opt for "大碼圖標" . --- On Sat, 30/3/13, Hin-Tak Leung <htl10(a)users.sourceforge.net> wrote: > From: Hin-Tak Leung <htl10(a)users.sourceforge.net> > Subject: Re: [website] Simplified Chinese translation for release 1.5.27 > To: "Wine Devel" <wine-devel(a)winehq.org>, fracting(a)gmail.com, "Jactry Zeng" <jactry92(a)gmail.com> > Date: Saturday, 30 March, 2013, 10:02 > --- On Sat, 30/3/13, Qian Hong <fracting(a)gmail.com> > wrote: > > > Hi Jactry, > > > > 2013/3/30 Jactry Zeng <jactry92(a)gmail.com>: > > > + <li>一些 C > 运行时的改进。</li> > > > > I think it is better to translate "C runtime" to “C > > 运行时库“ rather than > > just ”C 运行时“。 > > 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!? > > I think google translate is quite useful for technical terms > like these, as long as one is vigilant about not accepting > 'not quite correct' and go through the alternatives. One can > also help it a bit by giving a more verbose version of the > concept ('runtime library' instead of just 'runtime'), and > even occasionally some context (e.g. a full > sentence with '...loading in a runtime library...'). > > > + > > > <li>为内建程序提供更高质量的图标。</li> > > > > Large icon means 大图标，not 高质量图标。You > can > > verify this by the git commits。 > > 大型圖示 or 大型圖標 ? > > > Thanks for the work. > > > > -- > > Regards, > > Qian Hong > > > > - > > http://www.winehq.org > >

March 30, 2013

Re: [website] Simplified Chinese translation for release 1.5.27

by Hin-Tak Leung

--- On Sat, 30/3/13, Qian Hong <fracting(a)gmail.com> wrote: > Hi Jactry, > > 2013/3/30 Jactry Zeng <jactry92(a)gmail.com>: > > + <li>一些 C 运行时的改进。</li> > > I think it is better to translate "C runtime" to “C > 运行时库“ rather than > just ”C 运行时“。 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!? I think google translate is quite useful for technical terms like these, as long as one is vigilant about not accepting 'not quite correct' and go through the alternatives. One can also help it a bit by giving a more verbose version of the concept ('runtime library' instead of just 'runtime'), and even occasionally some context (e.g. a full sentence with '...loading in a runtime library...'). > + > <li>为内建程序提供更高质量的图标。</li> > > Large icon means 大图标，not 高质量图标。You can > verify this by the git commits。大型圖示 or 大型圖標 ? > Thanks for the work. > > -- > Regards, > Qian Hong > > - > http://www.winehq.org

March 30, 2013

Re: [website] Simplified Chinese translation for release 1.5.27

by Qian Hong

Hi Jactry, 2013/3/30 Jactry Zeng <jactry92(a)gmail.com>: > + <li>一些 C 运行时的改进。</li> I think it is better to translate "C runtime" to “C 运行时库“ rather than just ”C 运行时“。 + <li>为内建程序提供更高质量的图标。</li> Large icon means 大图标，not 高质量图标。You can verify this by the git commits。 Thanks for the work. -- Regards, Qian Hong - http://www.winehq.org

March 30, 2013

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

by Juan Lang

Hi Jacek, thanks for the detailed reply. On Fri, Mar 29, 2013 at 3:02 AM, Jacek Caban <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. --Juan

March 29, 2013

Re: [PATCH 1/3] jscript: Use helpers to access string buffers in jsregexp.c.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/jscript/jsregexp.c | 114 > +++++++++++++++++++++++++++++++----------------- > 1 file changed, 73 insertions(+), 41 deletions(-) It breaks the tests: ../../../tools/runtest -q -P wine -M jscript.dll -T ../../.. -p jscript_test.exe.so run.c && touch run.ok run.c:1804: Test failed: expected global_success_d run.c:1805: Test failed: expected global_success_i run.c:1807: Test failed: parse_script failed: 80004005 run.c:1804: Test failed: expected global_success_d run.c:1805: Test failed: expected global_success_i run.c:1807: Test failed: parse_script failed: 80004005 run.c:1804: Test failed: expected global_success_d run.c:1805: Test failed: expected global_success_i run.c:1807: Test failed: parse_script failed: 80004005 run.c:1804: Test failed: expected global_success_d run.c:1805: Test failed: expected global_success_i run.c:1807: Test failed: parse_script failed: 80004005 run.c:1804: Test failed: expected global_success_d run.c:1805: Test failed: expected global_success_i run.c:1807: Test failed: parse_script failed: 80004005 run.c:1804: Test failed: expected global_success_d run.c:1805: Test failed: expected global_success_i run.c:1807: Test failed: parse_script failed: 80004005 make: *** [run.ok] Error 18 -- Alexandre Julliard julliard(a)winehq.org

March 29, 2013

Re: d3dx9 [patch 1/2, try 4]: Implement D3DXSHEvalSphericalLight

by Alexandre Julliard

Nozomi Kodama <nozomi.kodama(a)yahoo.com> writes: > From bb40ba80a24a954d21c44cbe55b4b9c79e2087c5 Mon Sep 17 00:00:00 2001 > From: "nozomi.kodama" <nozomi.kodama(a)yahoo.com> > Date: Wed, 27 Mar 2013 22:38:51 -1000 > Subject: d3dx9: Implement D3DXSHEvalSphericalLight It still fails the same way... -- Alexandre Julliard julliard(a)winehq.org

March 29, 2013

Re: msvcp110: Add VS2012 C/C++ runtime

by Piotr Caban

On 03/28/13 23:22, Stefan Leichter wrote: > --- > configure.ac | 1 + > dlls/msvcp110/Makefile.in | 5 + > dlls/msvcp110/msvcp110.c | 37 + > dlls/msvcp110/msvcp110.spec | 3900 > +++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 3943 insertions(+), 0 deletions(-) > create mode 100644 dlls/msvcp110/Makefile.in > create mode 100644 dlls/msvcp110/msvcp110.c > create mode 100644 dlls/msvcp110/msvcp110.spec You can use tools/make_specfiles script to generate forwards to other msvcpXX dlls. The script will generate big parts of the spec file differently (because it prefers to forward to msvcp90, not to msvcp100).

March 29, 2013

Re: Windows API on Linux

by Henri Verbeet

On 29 March 2013 13:27, Abhinav Jangda <abhijangda(a)hotmail.com> wrote: > 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. Is that really any different from what Wine does?

March 29, 2013

Windows API on Linux

by Abhinav Jangda

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

March 29, 2013

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

by Henri Verbeet

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.

March 29, 2013

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

by Jacek Caban

Hi Juan, On 03/28/13 21:55, Juan Lang wrote: > On Thu, Mar 28, 2013 at 12:31 PM, Ken Thomases <ken(a)codeweavers.com > <mailto:ken(a)codeweavers.com>> wrote: > > 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; > > > Do we really want to continue supporting SSL2? It's got a number of > vulnerabilities, and is disabled pretty much everywhere by now: > http://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_2.0 I implemented it the way it's done in Windows. It's a bit under-documented and contains usual MSDN mistakes, so let me explain what I found when testing Windows (most of it is implemented by http://source.winehq.org/git/wine.git/commitdiff/0f2e0365ea1f5c6baba4cfd9c0…) 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? Thanks, Jacek

March 29, 2013