August 2012 - Wine-Devel - list.winehq.org

Re: [1/16] po: Update Russian translation

by Francois Gouget

On Sat, 25 Aug 2012, Oleg Yarigin wrote: > >> I translated so because, I hope, "floppy disc" term is obsolete > >> nowadays (nobody has it). > >> > > This is not up to translator to alter a meaning of original text just > > cause some words in it are not > > used frequently enough these days than they used to. Note however that if a translator finds something wrong in the English string he is welcome to either send a patch to fix it (in the RC file and if pretty sure of the change), or raise the issue on wine-devel (if the change is more questionable). By doing so you not only improve your translation, but also the English version and all the other translations. And really, only the translators, by force, make a complete and thorough review of Wine's messages. So if they don't contribute fixes to the English version, nobody will. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ There are 10 types of people in the world... those who understand binary and those who don't.

Aug. 31, 2012

Re: kernel32: Return correct drive type for empty drives

by Erich E. Hoover

On Fri, Aug 31, 2012 at 9:59 AM, Francois Gouget <fgouget(a)codeweavers.com> wrote: > ... > I'm pretty sure others have things they'd like to see in the new > WineTestBot. Where can we keep track of those? If you're collecting a wish list then multiple network interfaces would be awesome, though I recognize that there is only a small number of tests that would be affected by it. Erich Hoover ehoover(a)mines.edu

Aug. 31, 2012

Re: kernel32: Return correct drive type for empty drives

by Francois Gouget

On Fri, 31 Aug 2012, GOUJON Alexandre wrote: [...] > Except the fact that I wasn't testing my patch the right way (I'm not very > proud of it), this also proved the TestBot is not very efficient regarding > volume tests. > So, I am proposing to add several virtual drives to some virtual machines. Is > it possible ? I can work on it if needed. > With genisomage and mkudffs, it's very easy to generate ISO files of different > kinds. > It won't be the same as with real discs and real drives but at least, it would > prevent some regressions.. > Any comment on this ? The existing WineTestBot infrastructure is going to be replaced soonish... hopefully. So it's unlikely that we'll change the VMs now. However we can certainly add some drives or even ISOs as we build the VMs of the new WineTestBot. You'd need to detail which configurations you're interested in. One thing to keep in mind is we should strive to test as much as possible in as few configurations as possible, especially for the base VMs (those that run every single test patch). But at the same time it should be possible to isolate the effect of one configuration change. I'm pretty sure others have things they'd like to see in the new WineTestBot. Where can we keep track of those? Should we add a WineTestBot product to Bugzilla? Should the WineHQ.org product be coopted? -- Francois Gouget <fgouget(a)codeweavers.com>

Aug. 31, 2012

Wine Gecko 1.8-beta1

by Jacek Caban

Hi all, It's time for another Gecko update. I've uploaded to SourceForge [1] new Gecko builds. These are based on Firefox 16 beta. Other than tons of changes inherited from Firefox and usual fixes to keep it working well for us, it brings a few visible fixes: - Proper <noscript> tag handling - Synchronous ActiveX loading - Possibility to properly call APIs requiring JSContext - Possibility to implement HTMLStyleElement::styleSheet property As usually, to test it you need the attached patch and Gecko build placed in the right place [2]. Any help with testing is appreciated! On related note, I seriously consider dropping debug builds and replace them by unstripped release build or even just a separated package containing only debug symbols for the release build. Here are my thoughts about reasoning (in random order): - People use debug build mostly to retrieve better backtraces. Unstripped builds also give that ability. - If someone really needs debug build, it's easy enough to build it himself (and that's usually a good idea anyway) - Debug builds are seriously different than release build, so it occasionally exposes different set of problems, leading to invalid assumptions. This is really something for developers rather than users. - It costs my time spent builds and tests. And I consider it a serious matter. Amount of work needed to keep Gecko relevant is constantly growing. I try to mitigate it by doing long-term improvements upstream, automating the process and improving my hardware, but that has its limits. And the time spent on Gecko maintenance (as in pure maintenance, not real improvements) costs Wine in terms of improvements I could make in this time. If someone has a reason to keep debug builds, let me know. Any comments are welcomed. Thanks, Jacek [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.8-beta1/ [2] http://wiki.winehq.org/Gecko

Aug. 31, 2012

Re: kernel32: Return correct drive type for empty drives

by GOUJON Alexandre

On 08/29/2012 09:35 PM, Alexandre Julliard wrote: > Alexandre Goujon <ale.goujon(a)gmail.com> writes: > >> Should fix bug #17037 >> I followed your advice and now, I only ask the mountmgr when needed. >> --- >> dlls/kernel32/volume.c | 10 +++++++++- >> 1 file changed, 9 insertions(+), 1 deletion(-) > This is failing here when the drive is empty: > > ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so volume.c && touch volume.ok > volume.c:132: Tests skipped: can't test removing fake drive > volume.c:785: Test failed: IOCTL_DVD_READ_STRUCTURE (DvdPhysicalDescriptor) failed, last error = 87 > make: *** [volume.ok] Error 1 > > If I put a DVD in I get: > > volume.c:813: Test failed: IOCTL_DVD_READ_STRUCTURE should have failed > > Probably the tests need some fixing. > I worked on these issues and found that : + "make volume.ok" is different than "wine kernel32_test.exe.so volume" (WINETEST_PLATFORM=wine is set in the first command) + the error "volume.c:813: Test failed: IOCTL_DVD_READ_STRUCTURE should have failed" comes from a missing check. I fixed it with http://source.winehq.org/patches/data/89457. + the error "volume.c:785: Test failed: IOCTL_DVD_READ_STRUCTURE (DvdPhysicalDescriptor) failed, last error = 87" comes from ioctl() failing (errno = ENOMEDIUM), returning STATUS_INVALID_PARAMETER hence last error = 87 (ERROR_INVALID_PARAMETER). I fixed that with http://source.winehq.org/patches/data/89458. Except the fact that I wasn't testing my patch the right way (I'm not very proud of it), this also proved the TestBot is not very efficient regarding volume tests. So, I am proposing to add several virtual drives to some virtual machines. Is it possible ? I can work on it if needed. With genisomage and mkudffs, it's very easy to generate ISO files of different kinds. It won't be the same as with real discs and real drives but at least, it would prevent some regressions.. Any comment on this ?

Aug. 31, 2012

Wine Gecko 1.8-beta1

by Jacek Caban

Hi all, It's time for another Gecko update. I've uploaded to SourceForge [1] new Gecko builds. These are based on Firefox 16 beta. Other than tons of changes inherited from Firefox and usual fixes to keep it working well for us, it brings a few visible fixes: - Proper <noscript> tag handling - Synchronous ActiveX loading - Possibility to properly call APIs requiring JSContext - Possibility to implement HTMLStyleElement::styleSheet property As usually, to test it you need the attached patch and Gecko build placed in the right place [2]. Any help with testing is appreciated! On related note, I seriously consider dropping debug builds and replace them by unstripped release build or even just a separated package containing only debug symbols for the release build. Here are my thoughts about reasoning (in random order): - People use debug build mostly to retrieve better backtraces. Unstripped builds also give that ability. - If someone really needs debug build, it's easy enough to build it himself (and that's usually a good idea anyway) - Debug builds are seriously different than release build, so it occasionally exposes different set of problems, leading to invalid assumptions. This is really something for developers rather than users. - It costs my time spent builds and tests. And I consider it a serious matter. Amount of work needed to keep Gecko relevant is constantly growing. I try to mitigate it by doing long-term improvements upstream, automating the process and improving my hardware, but that has its limits. And the time spent on Gecko maintenance (as in pure maintenance, not real improvements) costs Wine in terms of improvements I could make in this time. If someone has a reason to keep debug builds, let me know. Any comments are welcomed. Thanks, Jacek [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.8-beta1/ [2] http://wiki.winehq.org/Gecko

Aug. 31, 2012

Re: kernel32: Add UTF-7 support. (try 5)

by Alexandre Julliard

Alex Henrie <alexhenrie24(a)gmail.com> writes: > Try 5 adds two tests for the case where srclen < -1 and passes them both. You are still overflowing the source. You need to spend more time on this. You also need to split the patch, and write some sort of table-driven tests so you can test a lot more cases, the ones you have are clearly not sufficient. -- Alexandre Julliard julliard(a)winehq.org

Aug. 31, 2012

Re: Moving pages to/from wiki

by Alexandre Julliard

Michael Stefaniuc <mstefani(a)redhat.com> writes: > On 08/30/2012 06:05 PM, Jeremy Newman wrote: >> On 08/29/2012 09:32 PM, Kyle Auble wrote: >>> just checked http://cvs.winehq.org and sure enough, there is still a >>> very outdated CVS repository there, but I can't find a template or a PHP >>> applet for it, just the same links you found (most in WWN issues). I've >>> CCed Jeremy Newman because I'm guessing the site admin would have to >>> remove it. >> >> I am not opposed to removing it. We had left it up as a historical >> archive, or for people that were not ready to switch to GIT yet. If >> there is consensus then I can certainly take it down. > According to Alexandre it is used by http://source.winehq.org/ for the > "Wine Cross Reference". Actually that doesn't use CVS, it's using a static copy. It should really use git instead, but that's a different issue. -- Alexandre Julliard julliard(a)winehq.org

Aug. 31, 2012

Re: Moving pages to/from wiki

by Kyle Auble

Thu, Aug 30, 2012 12:23, Michael Stefaniuc wrote: > On 08/30/2012 06:05 PM, Jeremy Newman wrote: >> On 08/29/2012 09:32 PM, Kyle Auble wrote: >>> just checked http://cvs.winehq.org and sure enough, there is still a >>> very outdated CVS repository there, but I can't find a template or a PHP >>> applet for it, just the same links you found (most in WWN issues). I've >>> CCed Jeremy Newman because I'm guessing the site admin would have to >>> remove it. >> >> I am not opposed to removing it. We had left it up as a historical >> archive, or for people that were not ready to switch to GIT yet. If >> there is consensus then I can certainly take it down. > According to Alexandre it is used by http://source.winehq.org/ for the > "Wine Cross Reference". Ahhh, that certainly changes things. Does the server have to run a CVS instance to generate the web interface? If so, and if it's possible to somehow store the CVS data somewhere else, it might not hurt to consolidate it someday. That's really distant, low-priority stuff though. I'll remove the line from the WineHQ Todo list and make a note on the wiki SourceCode page so no one gets confused. - Kyle

Aug. 30, 2012

Re: Moving pages to/from wiki

by Kyle Auble

Thu, Aug 30, 2012 11:55, André Hentschel wrote: > Am 30.08.2012 04:32, schrieb Kyle Auble: >> As for redirecting to http://www.winehq.org/cvs, since that was designed >> as a notice page for people trying to browse the source code, I was >> picturing just redirecting the links to http://source.winehq.org/git and >> deleting http://www.winehq.org/cvs as only WWN issues and news would >> still have dangling links. I don't want to remove it if there's another >> reason for keeping it though. > please don't remove it. there's still much linking to it on the web, or hiding links, like in sourcecodes somewhere OK, sounds good. I'll leave the CVS notice pages but update the links. - Kyle

Aug. 30, 2012

Re: [PATCH 2/5] hhctrl.ocx: Implement HH_SET_WIN_TYPE (try 7).

by Alexandre Julliard

"Erich E. Hoover" <ehoover(a)mymail.mines.edu> writes: > @@ -1784,11 +1785,25 @@ void ReleaseHelpViewer(HHInfo *info) > OleUninitialize(); > } > > -HHInfo *CreateHelpViewer(LPCWSTR filename, HWND caller) > +static BOOL info_in_list(HHInfo *info) > +{ > + HHInfo *i; > + > + LIST_FOR_EACH_ENTRY(i, &window_list, HHInfo, entry) > + { > + if(i == info) > + return TRUE; > + } > + return FALSE; > +} You should never need that sort of thing. -- Alexandre Julliard julliard(a)winehq.org

Aug. 30, 2012

Re: kernel32: Add UTF-7 support. (try 4)

by Alexandre Julliard

Alex Henrie <alexhenrie24(a)gmail.com> writes: > + do > + { > + if (src[source_index] == 0 && srclen == -1) > + { > + if (dry_run) dest_index++; else if (write_to_w_string(dst, dstlen, &dest_index, 0)) return -1; > + /* when srclen=-1, terminate at the first null character found */ > + break; > + } > + else if (src[source_index] == '+') > + { > + WCHAR byte_pair = 0; > + short offset = 0; > + > + source_index++; /* skip the + sign */ > + > + if (src[source_index] == '-') > + { > + /* just a plus sign escaped as +- */ > + if (dry_run) dest_index++; else if (write_to_w_string(dst, dstlen, &dest_index, '+')) return -1; > + source_index++; > + continue; > + } You are not checking properly for the source string length. Also please add tests for such cases. -- Alexandre Julliard julliard(a)winehq.org

Aug. 30, 2012

Re: Moving pages to/from wiki

by Michael Stefaniuc

On 08/30/2012 06:05 PM, Jeremy Newman wrote: > On 08/29/2012 09:32 PM, Kyle Auble wrote: >> just checked http://cvs.winehq.org and sure enough, there is still a >> very outdated CVS repository there, but I can't find a template or a PHP >> applet for it, just the same links you found (most in WWN issues). I've >> CCed Jeremy Newman because I'm guessing the site admin would have to >> remove it. > > I am not opposed to removing it. We had left it up as a historical > archive, or for people that were not ready to switch to GIT yet. If > there is consensus then I can certainly take it down. According to Alexandre it is used by http://source.winehq.org/ for the "Wine Cross Reference". bye michael

Aug. 30, 2012

Re: Moving pages to/from wiki

by André Hentschel

Am 30.08.2012 04:32, schrieb Kyle Auble: > As for redirecting to http://www.winehq.org/cvs, since that was designed > as a notice page for people trying to browse the source code, I was > picturing just redirecting the links to http://source.winehq.org/git and > deleting http://www.winehq.org/cvs as only WWN issues and news would > still have dangling links. I don't want to remove it if there's another > reason for keeping it though. please don't remove it. there's still much linking to it on the web, or hiding links, like in sourcecodes somewhere -- Best Regards, André Hentschel

Aug. 30, 2012

Re: Moving pages to/from wiki

by Jeremy Newman

On 08/29/2012 09:32 PM, Kyle Auble wrote: > just checked http://cvs.winehq.org and sure enough, there is still a > very outdated CVS repository there, but I can't find a template or a PHP > applet for it, just the same links you found (most in WWN issues). I've > CCed Jeremy Newman because I'm guessing the site admin would have to > remove it. I am not opposed to removing it. We had left it up as a historical archive, or for people that were not ready to switch to GIT yet. If there is consensus then I can certainly take it down.

Aug. 30, 2012

Re: Moving pages to/from wiki

by Kyle Auble

Wed, Aug 29, 2012 16:09, André Hentschel wrote: > get the website source and do "grep -Ri cvs *" > then ignore wwn/ and news/ ... > all that should somehow bring you to http://www.winehq.org/cvs or be deleted grep -r "...." * is rapidly becoming a very good friend of mine ;) I just checked http://cvs.winehq.org and sure enough, there is still a very outdated CVS repository there, but I can't find a template or a PHP applet for it, just the same links you found (most in WWN issues). I've CCed Jeremy Newman because I'm guessing the site admin would have to remove it. As for redirecting to http://www.winehq.org/cvs, since that was designed as a notice page for people trying to browse the source code, I was picturing just redirecting the links to http://source.winehq.org/git and deleting http://www.winehq.org/cvs as only WWN issues and news would still have dangling links. I don't want to remove it if there's another reason for keeping it though. - Kyle

Aug. 30, 2012

Re: Moving pages to/from wiki

by André Hentschel

Am 29.08.2012 21:13, schrieb Kyle Auble: > I'm starting to work on moving static pages to and from the wiki, but I > wanted to ask for opinions on a few changes first: ... > 3. Do we still need the static "cvs" page, or should I just redirect any > links to it, then delete? On a related note, the WineHQ ToDo on the > wiki still claims that a browser for the old CVS source tree is > lurking on the site somewhere. Is that true, or do I need to cut that > line from the ToDo list? get the website source and do "grep -Ri cvs *" then ignore wwn/ and news/ the first lines already look like they need love: > include/htaccess.sample:RedirectPermanent /dev.shtml http://www.winehq.org/cvs > include/htaccess.sample:RedirectPermanent /dev.html http://www.winehq.org/cvs > include/htaccess.sample:RedirectPermanent /devstart.shtml http://www.winehq.org/cvs > include/htaccess.sample:RedirectMatch ^/cvsweb(.*)$ http://cvs.winehq.org/cvsweb$1 > include/htaccess.sample:RedirectMatch ^/patch.py(.*)$ http://cvs.winehq.org/patch.py$1 > include/wwn.php: if ($file == "." or $file == ".." or $file == "CVS" or $file == "interviews") and some things in templates all that should somehow bring you to http://www.winehq.org/cvs or be deleted -- Best Regards, André Hentschel

Aug. 29, 2012

Re: kernel32: Return correct drive type for empty drives

by Alexandre Julliard

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > Should fix bug #17037 > I followed your advice and now, I only ask the mountmgr when needed. > --- > dlls/kernel32/volume.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) This is failing here when the drive is empty: ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so volume.c && touch volume.ok volume.c:132: Tests skipped: can't test removing fake drive volume.c:785: Test failed: IOCTL_DVD_READ_STRUCTURE (DvdPhysicalDescriptor) failed, last error = 87 make: *** [volume.ok] Error 1 If I put a DVD in I get: volume.c:813: Test failed: IOCTL_DVD_READ_STRUCTURE should have failed Probably the tests need some fixing. -- Alexandre Julliard julliard(a)winehq.org

Aug. 29, 2012

Moving pages to/from wiki

by Kyle Auble

I'm starting to work on moving static pages to and from the wiki, but I wanted to ask for opinions on a few changes first: 1. Move all static IRC pages to the wiki or add info from the wiki to the static templates? The static pages only mention #winehq and don't describe guidelines, but IRC details shouldn't change much right? 2. For the static About page, some languages also have wiki versions. Do we want to keep the sparser versions currently in use, or add the more detailed information from the wiki version? Both versions seem well-written, and exist for English, Hebrew, & Spanish (I deleted the Polish wiki version; it was a duplicate). 3. Do we still need the static "cvs" page, or should I just redirect any links to it, then delete? On a related note, the WineHQ ToDo on the wiki still claims that a browser for the old CVS source tree is lurking on the site somewhere. Is that true, or do I need to cut that line from the ToDo list? 4. Since licensing tends to be really static could we just redirect the WikiLicense page to the static license page, or should they be kept separate? While I'd think it wouldn't be too hard to reword the static page's intro to include other projects, I'm leery of editing any legal-ese without asking first. By the way, the WikiLicense page says it's LGPL v2.1 in the intro text, but the included license actually looks like v2.0 of the GPL with a modification for libraries. If the wiki version of the page should stay, I'll put in a copy of v2.1 - Kyle

Aug. 29, 2012

Re: [Tools] testbot: Add LICENSE and COPYING.LIB files.

by Francois Gouget

On Wed, 29 Aug 2012, Henri Verbeet wrote: > On 29 August 2012 16:35, Francois Gouget <fgouget(a)codeweavers.com> wrote: > > --- > > > > I think this made total sense when th WineTestBot was in its own > > repository. Now maybe the COPYING.LIB and LICENSE files can be > > considered to apply to all of the Wine tools and should go to the > > top-level directory? > > > Not all of the code in tools.git is under LGPL 2.1. (And personally > I'd argue that GPL 3 is probably more appropriate for most of the > things in there anyway.) Ok. So these files are in the right place then. As for LGPL 2.1 vs. GPL 3 I'm just documentin Ge's choices. -- Francois Gouget <fgouget(a)codeweavers.com>

Aug. 29, 2012

Re: [Tools] testbot: Add LICENSE and COPYING.LIB files.

by Henri Verbeet

On 29 August 2012 16:35, Francois Gouget <fgouget(a)codeweavers.com> wrote: > --- > > I think this made total sense when th WineTestBot was in its own > repository. Now maybe the COPYING.LIB and LICENSE files can be > considered to apply to all of the Wine tools and should go to the > top-level directory? > Not all of the code in tools.git is under LGPL 2.1. (And personally I'd argue that GPL 3 is probably more appropriate for most of the things in there anyway.)

Aug. 29, 2012

Re: Wine bot results

by Alistair Leslie-Hughes

Hi Jacek, -------------------------------------------------- From: "Jacek Caban" <jacek(a)codeweavers.com> Sent: Wednesday, August 29, 2012 1:16 AM To: "Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com> Cc: <wine-devel(a)winehq.org> Subject: Re: Wine bot results > > This VariantClear call attempts to free uninitialized VARIANT instance. > You probably meant VariantInit(). Thanks, it works on all systems now. Best Regards Alistair Leslie-Hughes

Aug. 29, 2012

Re: d3dx9: ID3DXConstantTable

by Rico Schüller

On 28.08.2012 10:50, Henri Verbeet wrote: > On 28 August 2012 09:12, Rico Schüller <kgbricola(a)web.de> wrote: >> 3. The wine_todo should be fixed in the test. Is there a way to disable them >> to show up, when running e.g. "wine d3dx9_36_test.exe.so shader"? It's a bit >> annoying when you search for your own failing tests. Well I could comment >> out the tests, but that's also not a very fine solution. >> > You can set WINETEST_PLATFORM=wine, but the easiest is probably to > just do "make shader.ok" instead of trying to run the test manually. > Well, I found an other way, fixing the test seems also a solution :-) . But I stumble over a problem: How could I create shader variables which uses D3DXRS_INT4 or D3DXRS_BOOL as register set? My goal is to check different combinations of the RegisterSet and the Type (e.g. D3DXRS_FLOAT4 and D3DXPT_FLOAT, D3DXRS_INT4 and D3DXPT_FLOAT, D3DXRS_BOOL and D3DXPT_FLOAT, D3DXRS_INT4 and D3DXPT_INT, D3DXRS_BOOL and D3DXPT_INT, ...). I have an improved version of set_float_matrix but I've no glue how to check if the assumption is correct, it fixes one todo but I'd like to test the rest if possible. Creating variables with D3DXRS_FLOAT4 or D3DXRS_SAMPLER is no problem. Anyone an idea? Attached is a patch. I changed some more stuff (not only the set_float_matrix function), but the main goal is a test for that one. I'd also be happy if someone has some criticism or suggestions to the rest in the patch. Cheers Rico

Aug. 29, 2012

Re: gdiplus: Make GdipMeasureCharacterRanges/GdipMeasureString/GdipDrawString add extra space around the text. Take 2.

by Vincent Povirk

This looks correct to me. Lack of shared logic and GenericTypographic still makes me sad, but not too sad because the added logic is simple.

Aug. 28, 2012

Re: About WineHQ Wiki

by Oleg Yarigin

28.08.2012 19:50, Kyle Auble пишет > If you're mainly noticing problems with the wiki, that may also be > that we're using an outdated version of moinmoin. Cheer Xiao was saying > that Moinmoin 2.0 will allow Mediawiki syntax so I'd recommend > upgrading Moinmoin, then converting the pages to Mediawiki syntax. Well, let`s try. > However, I believe all the content on WineHQ & the wiki are under the > LGPL so if you really wanted to, I'd think you could try testing a > mirror of the site as a proof of concept, running Cherokee on your own > computer. Well, that`t a good idea to run Wikimedia version at my computer. In addition, I will be able make all configuration properly. I will write there, when I buy a static address at my provider and get a domain name, OK? > Rather than switching out the http server, I think there is some > interest in moving WineHQ over to a web-framework/CMS. Thank you!I got an idea to create CMS-based WineHQ site mirror on my computer too. --- Oleg

Aug. 28, 2012

Re: Wine bot results

by Saulius Krasuckas

* On Tue, 28 Aug 2012, Saulius Krasuckas wrote: > * On Tue, 28 Aug 2012, Alistair Leslie-Hughes wrote: > > > > > Target: i686-w64-mingw32 > ... > > Target: i586-mingw32msvc > > There was the same topic brought up two years ago: > http://www.winehq.org/pipermail/wine-devel/2010-September/086643.html > > IIRC, MSVC and i586-mingw32msvc compilers initialize every declared > variable while *-mingw32* one does not. I mean *-mingw32-gcc (the one not using MSVCRT.DLL) with the latter;) S.

Aug. 28, 2012

Re: Wine bot results

by Saulius Krasuckas

* On Tue, 28 Aug 2012, Alistair Leslie-Hughes wrote: > > > Target: i686-w64-mingw32 ... > Target: i586-mingw32msvc There was the same topic brought up two years ago: http://www.winehq.org/pipermail/wine-devel/2010-September/086643.html IIRC, MSVC and i586-mingw32msvc compilers initialize every declared variable while *-mingw32* one does not. S.

Aug. 28, 2012

Re: About WineHQ Wiki

by Kyle Auble

Tues, Aug 28, 2012 4:47 AM, Oleg Yarigin wrote: > Now I wait an answer from Dimi Paun. > > > Well, in addition, how do you think, is any necessarity there to move > wine site and wiki from Apache to Cherokee? While I think it's good to keep alternatives in mind as new technology comes out, I wouldn't want to switch the actual http server out until it starts having noticeable problems, or in the distant future once higher priorities have been taken care of. For me, WineHQ itself seems to be really fast, and as we were discussing earlier in the thread, the wiki is hosted at Lattica, which may not have the same hardware resources or bandwidth of WineHQ. If you're mainly noticing problems with the wiki, that may also be that we're using an outdated version of moinmoin. Cheer Xiao was saying that Moinmoin 2.0 will allow Mediawiki syntax so I'd recommend upgrading Moinmoin, then converting the pages to Mediawiki syntax. I've never run a real Apache server myself (just played with it on my computer), but while it can be a pain to set up, it is battle-tested. Since the site admins would have to do all the dirty work, I feel like this should be their call in the end. However, I believe all the content on WineHQ & the wiki are under the LGPL so if you really wanted to, I'd think you could try testing a mirror of the site as a proof of concept, running Cherokee on your own computer. If you can show the advantages outweigh the trouble of switching over, the site admins would probably be more willing to consider it. Rather than switching out the http server, I think there is some interest in moving WineHQ over to a web-framework/CMS. I wanted to handle the wiki first, but afterwards if there's still demand for it, I'd like to try helping make the jump to a CMS. -Kyle

Aug. 28, 2012

Re: Wine bot results

by Jacek Caban

On 08/28/12 12:04, Alistair Leslie-Hughes wrote: > Hi, > > I have a patch that when run on on the testbot, it fails on all but > two machines. > However when I build the exe myself and run it, it pass on all but two > machines. > > http://testbot.winehq.org/JobDetails.pl?Key=21257 > http://testbot.winehq.org/JobDetails.pl?Key=21256 > > Ubuntu 12.04. > > Any Ideas on the different results? + VariantClear(&d); + V_VT(&v) = VT_BSTR; + V_BSTR(&v) = SysAllocStringLen(NULL, 0); This VariantClear call attempts to free uninitialized VARIANT instance. You probably meant VariantInit(). Jacek

Aug. 28, 2012

Re: About WineHQ Wiki

by Jeremy Newman

On 08/28/2012 04:47 AM, Oleg Yarigin wrote: > Well, in addition, how do you think, is any necessarity there to move > wine site and wiki from Apache to Cherokee? Not going to happen anytime in the near future. I won't say never however. -N

Aug. 28, 2012

Re: [PATCH 1/5] d3dx9: Add some traces to D3DXLoadSurfaceFromMemory().

by Henri Verbeet

2012/8/28 Rico Schüller <kgbricola(a)web.de>: > + FIXME("Format conversation missing %#x -> %#x\n", src_format, surfdesc.Format); I don't think that's really what we want it to say.

Aug. 28, 2012

Re: shell32: Make ShellExecute use native file association databases as fallback path (resend)

by Alexandre Julliard

Erik van Pienbroek <erik(a)vanpienbroek.nl> writes: > +#if defined(HAVE_FORK) && defined(HAVE_WAITPID) > +static UINT_PTR SHELL_try_native_execute ( const char *openCmd, const char *unixName ) > +{ > + UINT_PTR retval = SE_ERR_NOASSOC; > + pid_t cpid; > + struct stat st; > + > + if (stat(openCmd, &st) == -1) > + { > + TRACE("stat() %s failed: %s\n", openCmd, strerror(errno)); > + return retval; > + } > + > + cpid = fork(); > + if (!cpid) > + { > + /* Prevent the situation where the native file association database > + * tries to run wine to execute a program and we trigger this fallback > + * path again and end up in a recursive loop */ > + if (getenv("WINE_INSIDE_SHELLEXECUTE")) > + { > + TRACE("recursive loop detected, not continuing with ShellExecute call\n"); > + exit(EXIT_SUCCESS); > + } > + setenv("WINE_INSIDE_SHELLEXECUTE", "1", 0); > + > + TRACE("running %s %s\n", openCmd, unixName); > + execlp(openCmd, openCmd, unixName, (char*) NULL); > + /* execlp replaces the current process image with a new process image, > + * so no code below here should get executed by the forked child */ > + } else { > + int status; > + waitpid(cpid, &status, 0); > + TRACE("status %x\n", status); > + if(!WEXITSTATUS(status)) > + retval = 33; > + } > + > + return retval; > +} You want spawnvp(), but that sort of thing should probably go in winebrowser or something like that, and be configurable. -- Alexandre Julliard julliard(a)winehq.org

Aug. 28, 2012

Re: kernel32: Try to get the drive type from the mountmgr first [resend]

by Alexandre Julliard

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > Should fix bug #17037 > Now that my patch disappeared from source.winehq.org/patches, I'm resending it. > Before commenting, please read the e-mail I sent in July (winehq.org/pipermail/wine-devel/2012-July/096587.html) The goal here is to avoid a mountmgr round-trip for the common case, calling mountmgr first defeats this. -- Alexandre Julliard julliard(a)winehq.org

Aug. 28, 2012

Re: d3dx9: ID3DXConstantTable

by Rico Schüller

On 28.08.2012 10:50, Henri Verbeet wrote: > On 28 August 2012 09:12, Rico Schüller <kgbricola(a)web.de> wrote: >> 3. The wine_todo should be fixed in the test. Is there a way to disable them >> to show up, when running e.g. "wine d3dx9_36_test.exe.so shader"? It's a bit >> annoying when you search for your own failing tests. Well I could comment >> out the tests, but that's also not a very fine solution. >> > You can set WINETEST_PLATFORM=wine, but the easiest is probably to > just do "make shader.ok" instead of trying to run the test manually. > Thanks, that's exactly what I need. Cheers Rico

Aug. 28, 2012

Re: Wine bot results

by Alistair Leslie-Hughes

Hi Qian, > > $ i686-w64-mingw32-gcc -v > Using built-in specs. > COLLECT_GCC=i686-w64-mingw32-gcc > COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-w64-mingw32/4.6.1/lto-wrapper > Target: i686-w64-mingw32 > Configured with: ../../src/configure --build=i686-linux-gnu > --prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' > --infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var > --libexecdir='/usr/lib/gcc-mingw-w64' --disable-maintainer-mode > --disable-dependency-tracking --prefix=/usr --disable-shared > --disable-multilib --enable-linker-build-id --with-system-zlib > --libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib > --enable-libstdcxx-time=yes --with-tune=generic > --enable-version-specific-runtime-libs > --enable-languages=c,c++,fortran --enable-lto --with-plugin-ld > --enable-fully-dynamic-string --target=i686-w64-mingw32 > --with-gxx-include-dir=/usr/include/c++/4.6 > --with-as=/usr/bin/i686-w64-mingw32-as > --with-ld=/usr/bin/i686-w64-mingw32-ld > Thread model: win32 > gcc version 4.6.1 (GCC) > $ i586-mingw32msvc-gcc -v Using built-in specs. Target: i586-mingw32msvc Configured with: /build/buildd/mingw32-4.2.1.dfsg/build_dir/src/gcc-4.2.1-2-dfsg/configure -v --prefix=/usr --target=i586-mingw32msvc --enable-languages=c,c++ --enable-threads --enable-sjlj-exceptions --disable-multilib --enable-version-specific-runtime-libs Thread model: win32 gcc version 4.2.1-sjlj (mingw32-2) Here is what install on my system, Ill try to update it to a later version. Best Regards Alistair Leslie-Hughes

Aug. 28, 2012

Re: Wine bot results

by Qian Hong

Hello Alistair, On Tue, Aug 28, 2012 at 6:04 PM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > http://testbot.winehq.org/JobDetails.pl?Key=21257 > http://testbot.winehq.org/JobDetails.pl?Key=21256 I downloaded your patch from http://testbot.winehq.org/GetFile.pl?JobKey=21257&StepKey=1 , compiled with i686-w64-mingw32-gcc on Ubuntu 10.10, then resubmit it to wine testbot, my result is the same as the one built by testbot: https://testbot.winehq.org/JobDetails.pl?Key=21288 Maybe it is interesting to know what compiler you use and which one is used by testbot. Though we should make sure we are always test on the same patch first =) $ i686-w64-mingw32-gcc -v Using built-in specs. COLLECT_GCC=i686-w64-mingw32-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-w64-mingw32/4.6.1/lto-wrapper Target: i686-w64-mingw32 Configured with: ../../src/configure --build=i686-linux-gnu --prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' --infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var --libexecdir='/usr/lib/gcc-mingw-w64' --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr --disable-shared --disable-multilib --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib --enable-libstdcxx-time=yes --with-tune=generic --enable-version-specific-runtime-libs --enable-languages=c,c++,fortran --enable-lto --with-plugin-ld --enable-fully-dynamic-string --target=i686-w64-mingw32 --with-gxx-include-dir=/usr/include/c++/4.6 --with-as=/usr/bin/i686-w64-mingw32-as --with-ld=/usr/bin/i686-w64-mingw32-ld Thread model: win32 gcc version 4.6.1 (GCC) -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

Aug. 28, 2012

Re: [PATCH 6/6] Always define WIDL_C_INLINE_WRAPPERS

by Marvin

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 http://testbot.winehq.org/JobDetails.pl?Key=21287 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

Aug. 28, 2012

Re: Wine bot results

by Dmitry Timoshkov

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > I have a patch that when run on on the testbot, it fails on all but two > machines. > However when I build the exe myself and run it, it pass on all but two > machines. > > http://testbot.winehq.org/JobDetails.pl?Key=21257 > http://testbot.winehq.org/JobDetails.pl?Key=21256 > > Ubuntu 12.04. > > Any Ideas on the different results? This probably means that behaviour is undefined and depends on memory contents. -- Dmitry.

Aug. 28, 2012

Re: [PATCH 6/6] Always define WIDL_C_INLINE_WRAPPERS

by Marvin

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 http://testbot.winehq.org/JobDetails.pl?Key=21286 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

Aug. 28, 2012

Re: [PATCH 6/6] Always define WIDL_C_INLINE_WRAPPERS

by Marvin

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 http://testbot.winehq.org/JobDetails.pl?Key=21285 Your paranoid android. === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

Aug. 28, 2012

Wine bot results

by Alistair Leslie-Hughes

Hi, I have a patch that when run on on the testbot, it fails on all but two machines. However when I build the exe myself and run it, it pass on all but two machines. http://testbot.winehq.org/JobDetails.pl?Key=21257 http://testbot.winehq.org/JobDetails.pl?Key=21256 Ubuntu 12.04. Any Ideas on the different results? Best Regards Alistair Leslie-Hughes

Aug. 28, 2012

Re: About WineHQ Wiki

by Oleg Yarigin

Finally I got an answer from Jeremy White, wine site admin: >Hi Oleg, > >On 08/26/2012 08:21 AM, Oleg Yarigin wrote: >> Good time of a day, Jeremy. >> >> I write to you as to a WEB-administrator of WineHQ server about some >> ideas of site functionality improvement: >> >> 1. How is about moving WineHQ Wiki onto Wikimedia engine and break >> it into multiple language trurd-level domains (like interwiki in >> Wikipedia)? I am ready to move the Wiki`s material from old one >> (wiki.winehq.org) to new one. A discussion of this idea is in August >> wine-devel pipemail, "About WineHQ Wiki" thread. > >I'm afraid that this is something best discussed on the wine-devel list. > And the person you really need to persuade is Dimi Paun - he runs the >Wiki. > >> 2. How is about moving a whole site from Apache web server to >> Cherokee web server? I heared, it is much faster. > >Are we having a problem with Apache being too slow? I think you'll find >us very reluctant to make change for no driving reason. Again, if you >are finding a problem with the current web site, please share that on >the wine-devel mailing list. > >Cheers, > >Jeremy Now I wait an answer from Dimi Paun. Well, in addition, how do you think, is any necessarity there to move wine site and wiki from Apache to Cherokee? --- Oleg

Aug. 28, 2012

Re: gdiplus: When copying an image do not round pixel positions up.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > >> I just did, and the behavior, though it looks wrong, is the same > >> between builtin and native - the image is shifted by 1/2 pixel so that > >> it's cut off at the upper-left and we have extra transparent space at > >> the lower-right. > > > > With native gdiplus scenario described earlier works just fine for me, > > while with built-in there are black borders on bottom/right. > > You should be getting transparent borders on the bottom/right. > > This probably means you're using a surface that's not capable of alpha > blending, and in that situation gdi_alpha_blend currently draws fully > transparent pixels as black when it shouldn't. I'm pretty sure I > mentioned that as a problem earlier, around the time you introduced > gdi_alpha_blend. The problem is not related to a device not supporting alpha blending, I even replaced a TRACE there by ERR just in case, but it never triggers. > If you compare the size of the image drawn between native/builtin (not > counting the border, which native draws as transparent, as does > builtin under normal circumstances), I think you'll find that it > currently matches and your patch changes it. If you didn't notice, > you're probably not enlarging the image enough. I don't see a difference in the image size regardless how much I enlarge the image. > Since GdipDrawImage doesn't accept a source rectangle, and those extra > pixels are supposed to be transparent, you could probably have > GdipDrawImage subtract 0.5 from your image width and height. That > should solve your problem in this limited case without fixing > gdi_alpha_blend or introducing a bug. Subtracting 0.5 from width and height hides the problem, but that's just a compensation to rounding up that my patch is removing. -- Dmitry.

Aug. 28, 2012

Re: d3dx9: ID3DXConstantTable

by Henri Verbeet

On 28 August 2012 09:12, Rico Schüller <kgbricola(a)web.de> wrote: > 3. The wine_todo should be fixed in the test. Is there a way to disable them > to show up, when running e.g. "wine d3dx9_36_test.exe.so shader"? It's a bit > annoying when you search for your own failing tests. Well I could comment > out the tests, but that's also not a very fine solution. > You can set WINETEST_PLATFORM=wine, but the easiest is probably to just do "make shader.ok" instead of trying to run the test manually.

Aug. 28, 2012

Re: xmllite: Store DTD processing mode in reader

by Alexandre Julliard

Dan Kegel <dank(a)kegel.com> writes: > Alexandre Julliard wrote: >> Explicit ok() calls are better than hiding them inside a macro. > > Uh-oh. Want me to get rid of this macro > > +#define CHECK_RET_ERRNO(ret, ex) \ > + do { \ > + ok(ret == ex, "ret is %d, expected %d\n", ret, ex); \ > + ok(errno == ex, "errno is %d, expected %d\n", errno, ex); \ > + } while (0) > > in http://source.winehq.org/patches/data/89349 ? Obviously, yes. -- Alexandre Julliard julliard(a)winehq.org

Aug. 28, 2012

Re: d3dx9: ID3DXConstantTable

by Rico Schüller

On 23.08.2012 22:58, Rico Schüller wrote: > On 23.08.2012 15:43, Józef Kucia wrote: >> I would prefer you to clean it up submit it. I hope it gets committed >> this time. > > Ok, I'll try to clean them and send them. I will do it the safe way and > compare each handle with all handles we have. If it is slow, we could > easily move by using the highest bit for comparison against the > D3DXHANDLE. We just have to take care that an easy switch is possible. > > Thanks for the input. > Rico > Patches are in git now. The normal way should work fine. The following things should be considered (but I have no patches for these): 1. The cross calling (table1, variable_from_table2). 2. We may avoid the desc copy, because the variables may be set often and so the copy time will make some speed difference in set_*_array and GetSamplerIndex. Example for GetSamplerIndex: res = ID3DXConstantTable_GetConstantDesc(iface,constant,&desc,&count); if (FAILED(res)) return (UINT)-1; if (desc.RegisterSet != D3DXRS_SAMPLER) to something like: struct ctab_constant *c = get_valid_constant(This, constant); if (c->desc.RegisterSet != D3DXRS_SAMPLER) 3. The wine_todo should be fixed in the test. Is there a way to disable them to show up, when running e.g. "wine d3dx9_36_test.exe.so shader"? It's a bit annoying when you search for your own failing tests. Well I could comment out the tests, but that's also not a very fine solution. Cheers Rico

Aug. 28, 2012

Re: [3/3] gdiplus: Make GdipMeasureCharacterRanges/GdipMeasureString/GdipDrawString add extra space around the text.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > > If there are only cosmetic objections, I'd like to see this patch accepted, > > and work of further improvements after that. > > I asked Alexandre to wait until I had more time to understand/test this patch. > > It seems you've introduced a problem with scaling (see attached test > program and screenshot). I think that MeasureString is working > correctly in this case, and DrawString/MeasureCharacterRanges are > wrong. Thanks for the test program, it's pretty illustrative. I sent another version of the patch that should take scaling and world transform into account. > This sort of problem would be less likely if the logic were in > gdip_format_string. I still think that it's more important to make these APIs behave correctly first, and only then try to optimize/merge/redesign the logic behind them. -- Dmitry.

Aug. 28, 2012

Re: gdiplus: When copying an image do not round pixel positions up.

by Vincent Povirk

>> I just did, and the behavior, though it looks wrong, is the same >> between builtin and native - the image is shifted by 1/2 pixel so that >> it's cut off at the upper-left and we have extra transparent space at >> the lower-right. > > With native gdiplus scenario described earlier works just fine for me, > while with built-in there are black borders on bottom/right. You should be getting transparent borders on the bottom/right. This probably means you're using a surface that's not capable of alpha blending, and in that situation gdi_alpha_blend currently draws fully transparent pixels as black when it shouldn't. I'm pretty sure I mentioned that as a problem earlier, around the time you introduced gdi_alpha_blend. If you compare the size of the image drawn between native/builtin (not counting the border, which native draws as transparent, as does builtin under normal circumstances), I think you'll find that it currently matches and your patch changes it. If you didn't notice, you're probably not enlarging the image enough. Since GdipDrawImage doesn't accept a source rectangle, and those extra pixels are supposed to be transparent, you could probably have GdipDrawImage subtract 0.5 from your image width and height. That should solve your problem in this limited case without fixing gdi_alpha_blend or introducing a bug.

Aug. 28, 2012

Re: gdiplus: When copying an image do not round pixel positions up.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > > Just write a test with GdipDrawImageI and scenario described above and > > you will see the problem. In my case it's even more visible because of > > indirect magnifaction: image with resolution 100 dpi is being copied to > > device with 300 dpi. > > I just did, and the behavior, though it looks wrong, is the same > between builtin and native - the image is shifted by 1/2 pixel so that > it's cut off at the upper-left and we have extra transparent space at > the lower-right. With native gdiplus scenario described earlier works just fine for me, while with built-in there are black borders on bottom/right. -- Dmitry.

Aug. 28, 2012

Re: gdiplus: When copying an image do not round pixel positions up.

by Vincent Povirk

> Just write a test with GdipDrawImageI and scenario described above and > you will see the problem. In my case it's even more visible because of > indirect magnifaction: image with resolution 100 dpi is being copied to > device with 300 dpi. I just did, and the behavior, though it looks wrong, is the same between builtin and native - the image is shifted by 1/2 pixel so that it's cut off at the upper-left and we have extra transparent space at the lower-right.

Aug. 28, 2012

Re: gdiplus: When copying an image do not round pixel positions up.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > > In my tests (which replicate the behaviour of a target application) if > > an image of say 10x10 pixels is being copied with a magnification world > > transform then the destination image has right/bottom border completely > > wrong, and my patch fixes this. Besides, bilinear interpolation does > > exactly that already - doesn't round pixel positions up, which contradicts > > your explanation. > > The same rule about pixel centers applies with bilinear interpolation. > That means that at the lower-right corner of a stretched image you end > up with places where the lower-right pixel was blended with a pixel > from outside the image. Just write a test with GdipDrawImageI and scenario described above and you will see the problem. In my case it's even more visible because of indirect magnifaction: image with resolution 100 dpi is being copied to device with 300 dpi. -- Dmitry.

Aug. 28, 2012

Re: gdiplus: When copying an image do not round pixel positions up.

by Vincent Povirk

> In my tests (which replicate the behaviour of a target application) if > an image of say 10x10 pixels is being copied with a magnification world > transform then the destination image has right/bottom border completely > wrong, and my patch fixes this. Besides, bilinear interpolation does > exactly that already - doesn't round pixel positions up, which contradicts > your explanation. The same rule about pixel centers applies with bilinear interpolation. That means that at the lower-right corner of a stretched image you end up with places where the lower-right pixel was blended with a pixel from outside the image.

Aug. 28, 2012

Re: gdiplus: When copying an image do not round pixel positions up.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > I know this looks wrong, but it's there for a reason, and it matches > the behavior of the other interpolations. In my tests, the center of a > bitmap pixel is at an integral value, meaning that the pixel at (0,0) > is a rectangle extending from (-0.5, -0.5) to (0.5, 0.5), and if you > enlarge an image you do get out-of-bounds bits on the lower right. > > I'm pretty sure I also tested GdipDrawImageRect separately and got the > same result. In my tests (which replicate the behaviour of a target application) if an image of say 10x10 pixels is being copied with a magnification world transform then the destination image has right/bottom border completely wrong, and my patch fixes this. Besides, bilinear interpolation does exactly that already - doesn't round pixel positions up, which contradicts your explanation. -- Dmitry.

Aug. 28, 2012

Re: gdiplus: Use outside color from image attributes for an out of bounds pixel.

by Vincent Povirk

> if (src_pointf.X >= srcx && src_pointf.X < srcx + srcwidth && src_pointf.Y >= srcy && src_pointf.Y < srcy+srcheight) > *dst_color = resample_bitmap_pixel(&src_area, src_data, bitmap->width, bitmap->height, &src_pointf, imageAttributes, interpolation); > else > - *dst_color = 0; > + *dst_color = imageAttributes->outside_color; It's like this for a reason. This isn't out of the bounds of the source image, which is when imageAttributes would apply. This is out of the bounds of the parallelogram we're drawing, and we should be leaving that pixel alone.

Aug. 28, 2012

Re: gdiplus: When copying an image do not round pixel positions up.

by Vincent Povirk

I know this looks wrong, but it's there for a reason, and it matches the behavior of the other interpolations. In my tests, the center of a bitmap pixel is at an integral value, meaning that the pixel at (0,0) is a rectangle extending from (-0.5, -0.5) to (0.5, 0.5), and if you enlarge an image you do get out-of-bounds bits on the lower right. I'm pretty sure I also tested GdipDrawImageRect separately and got the same result.

Aug. 28, 2012

re: xmllite: Store DTD processing mode in reader

by Dan Kegel

Alexandre Julliard wrote: > Explicit ok() calls are better than hiding them inside a macro. Uh-oh. Want me to get rid of this macro +#define CHECK_RET_ERRNO(ret, ex) \ + do { \ + ok(ret == ex, "ret is %d, expected %d\n", ret, ex); \ + ok(errno == ex, "errno is %d, expected %d\n", errno, ex); \ + } while (0) in http://source.winehq.org/patches/data/89349 ?

Aug. 27, 2012

Re: [PATCH 1/2] msvcrt: Detect UTF-8 mode

by Alexandre Julliard

Detlef Riekenberg <wine.dev(a)web.de> writes: > @@ -1286,6 +1288,17 @@ static int msvcrt_get_flags(const MSVCRT_wchar_t* mode, int *open_flags, int* st > case '+': > case ' ': > break; > + case ',': > + if (!memcmp(mode, encoding_utf8, sizeof(encoding_utf8)) ) > + { > + *open_flags |= MSVCRT__O_U8TEXT; > + *open_flags &= ~(MSVCRT__O_TEXT | MSVCRT__O_BINARY | MSVCRT__O_WTEXT | MSVCRT__O_U16TEXT); > + mode += (sizeof(encoding_utf8)/sizeof(MSVCRT_wchar_t)); > + } > + else > + FIXME("mode %s not supported\n", debugstr_w(mode -1)); Your string parsing needs more work. -- Alexandre Julliard julliard(a)winehq.org

Aug. 27, 2012

Re: xmllite: Store DTD processing mode in reader

by Alexandre Julliard

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > @@ -350,34 +353,47 @@ static void test_reader_create(void) > HRESULT hr; > IXmlReader *reader; > IUnknown *input; > + DtdProcessing dtd; > > /* crashes native */ > if (0) > { > pCreateXmlReader(&IID_IXmlReader, NULL, NULL); > - pCreateXmlReader(NULL, (LPVOID*)&reader, NULL); > + pCreateXmlReader(NULL, (void**)&reader, NULL); > } > > - hr = pCreateXmlReader(&IID_IXmlReader, (LPVOID*)&reader, NULL); > - ok(hr == S_OK, "Expected S_OK, got %08x\n", hr); > + hr = pCreateXmlReader(&IID_IXmlReader, (void**)&reader, NULL); > + EXPECT_HR(hr, S_OK); > > test_read_state(reader, XmlReadState_Closed, -1, FALSE); > > + dtd = 2; > + hr = IXmlReader_GetProperty(reader, XmlReaderProperty_DtdProcessing, (LONG_PTR*)&dtd); > + EXPECT_HR(hr, S_OK); > + ok(dtd == DtdProcessing_Prohibit, "got %d\n", dtd); > + > + dtd = 2; > + hr = IXmlReader_SetProperty(reader, XmlReaderProperty_DtdProcessing, dtd); > + EXPECT_HR(hr, E_INVALIDARG); > + > + hr = IXmlReader_SetProperty(reader, XmlReaderProperty_DtdProcessing, -1); > + EXPECT_HR(hr, E_INVALIDARG); > + > /* Null input pointer, releases previous input */ > hr = IXmlReader_SetInput(reader, NULL); > - ok(hr == S_OK, "Expected S_OK, got %08x\n", hr); > + EXPECT_HR(hr, S_OK); Explicit ok() calls are better than hiding them inside a macro. -- Alexandre Julliard julliard(a)winehq.org

Aug. 27, 2012

Re: [3/3] gdiplus: Make GdipMeasureCharacterRanges/GdipMeasureString/GdipDrawString add extra space around the text.

by Vincent Povirk

> If there are only cosmetic objections, I'd like to see this patch accepted, > and work of further improvements after that. I asked Alexandre to wait until I had more time to understand/test this patch. It seems you've introduced a problem with scaling (see attached test program and screenshot). I think that MeasureString is working correctly in this case, and DrawString/MeasureCharacterRanges are wrong. This sort of problem would be less likely if the logic were in gdip_format_string.

Aug. 27, 2012

Re: Unused msvcp100 functions?

by Piotr Caban

On 08/27/12 02:02, Francois Gouget wrote: > There are a lot of msvcp100 functions that look like they are unused: > > * In string.c all of the MSVCP__String_base_*(), > MSVCP_basic_string_*(), MSVCP_basic_string_wchar_*() and > MSVCP_char_traits_*() functions, > basic_string_w?char_replace_helper(). > > * In locale.c _Locinfo__Locinfo_ctor_bstr(), > codecvt_{short,wchar}__Id_func(), collate_{char,short}__Getcat(), > various ctype_*() functions, etc. > > * In ios.c, the basic_istream_*() and basic_ostream_*() functions, > ios_base_Index_func() and ios_base_Sync_func(). > > * In math.c a lot of std_Ctraits_{double,float,long}_*() functions. > > Is it just that the spec file needs to catch up or that they will be > used soon? All of this functions are probably not going to be used. I was not removing them to make syncing between msvcp90 and msvcp100 easier. Currently files in these dlls are almost identical. Feel free to remove unused functions.

Aug. 27, 2012

Re: kernel32: Handle neutral locale names better in GetLocaleInfoEx

by Nikolay Sivov

On 8/27/2012 07:20, Dmitry Timoshkov wrote: > Hi, > > Are you sure that GetLocaleInfo can't handle these cases on its own? I already added a test for that - for neutral LCID for English for example it still returns en-US as locale name and the rest of the locale entries I tested are from US locale as well. Regarding GetLocaleInfoEx - for neutral names it returns neutral locale name for LOCALE_SNAME index, however the rest of the data is still non-neutral. This mapping applies to LocaleNametoLCID too, it returns non-neutral LCID for neutral names.

Aug. 27, 2012

Re: [3/3] gdiplus: get_log_fontW helper requires a valid graphics object.

by Vincent Povirk

>> > + GdipFree(backup); >> >> I think you want GdipDeletePath. > > Other places of GdipAddPathString implementation need this fixed as well then. Nope, the existing use of GdipFree on backup is correct because the extra data associated with it has been copied to the original path (which had its data freed). Not the clearest way of doing things but it works. >> This seems very convoluted. Couldn't we just skip the size conversion >> in get_log_fontW when graphics is NULL? Any cases where the scaling >> would produce a size other than the em size need to be fixed in >> GdipAddPathString anyway. > > GdipAddPathString already creates an HDC to select hfont into it, so using > graphics object created from it seems pretty straightforward. Fair enough. On closer inspection, it looks like the behavior should be the same as before, so it doesn't really matter. I just prefer less memory management, all other things being equal.

Aug. 27, 2012

Re: msxml3: Implement xmldecl-version property for a reader

by Marvin

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 http://testbot.winehq.org/JobDetails.pl?Key=21252 Your paranoid android. === W2KPROSP4 (32 bit saxreader) === saxreader.c:2365: Test failed: got 0x80040154, expected 0x00000000 saxreader: unhandled exception c0000005 at 00443BC3 === WXPPROSP3 (32 bit saxreader) === saxreader.c:2365: Test failed: got 0x80040154, expected 0x00000000 saxreader: unhandled exception c0000005 at 00443BC3 === W2K3R2SESP2 (32 bit saxreader) === saxreader.c:2365: Test failed: got 0x80040154, expected 0x00000000 saxreader: unhandled exception c0000005 at 00443BC3 === WVISTAADM (32 bit saxreader) === saxreader.c:2365: Test failed: got 0x80040154, expected 0x00000000 saxreader: unhandled exception c0000005 at 00443BC3 === W2K8SE (32 bit saxreader) === saxreader.c:2365: Test failed: got 0x80040154, expected 0x00000000 saxreader: unhandled exception c0000005 at 00443BC3 === W7PRO (32 bit saxreader) === saxreader.c:2365: Test failed: got 0x80040154, expected 0x00000000 saxreader: unhandled exception c0000005 at 00443BC3 === W7PROX64 (32 bit saxreader) === saxreader.c:2365: Test failed: got 0x80040154, expected 0x00000000 saxreader: unhandled exception c0000005 at 00443BC3 === TEST64_W7SP1 (32 bit saxreader) === saxreader.c:2365: Test failed: got 0x80040154, expected 0x00000000 saxreader: unhandled exception c0000005 at 00443BC3 === W7PROX64 (64 bit saxreader) === saxreader.c:2365: Test failed: got 0x80040154, expected 0x00000000 Timeout === TEST64_W7SP1 (64 bit saxreader) === saxreader.c:2365: Test failed: got 0x80040154, expected 0x00000000 Timeout

Aug. 27, 2012

Re: [3/3] gdiplus: get_log_fontW helper requires a valid graphics object.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > > + GdipFree(backup); > > I think you want GdipDeletePath. Other places of GdipAddPathString implementation need this fixed as well then. > This seems very convoluted. Couldn't we just skip the size conversion > in get_log_fontW when graphics is NULL? Any cases where the scaling > would produce a size other than the em size need to be fixed in > GdipAddPathString anyway. GdipAddPathString already creates an HDC to select hfont into it, so using graphics object created from it seems pretty straightforward. -- Dmitry.

Aug. 27, 2012

Re: [3/3] gdiplus: get_log_fontW helper requires a valid graphics object.

by Vincent Povirk

> + GdipFree(backup); I think you want GdipDeletePath. This seems very convoluted. Couldn't we just skip the size conversion in get_log_fontW when graphics is NULL? Any cases where the scaling would produce a size other than the em size need to be fixed in GdipAddPathString anyway.

Aug. 27, 2012

Re: kernel32: Handle neutral locale names better in GetLocaleInfoEx

by Dmitry Timoshkov

Hi, Are you sure that GetLocaleInfo can't handle these cases on its own? -- Dmitry.

Aug. 27, 2012

Unused msvcp100 functions?

by Francois Gouget

There are a lot of msvcp100 functions that look like they are unused: * In string.c all of the MSVCP__String_base_*(), MSVCP_basic_string_*(), MSVCP_basic_string_wchar_*() and MSVCP_char_traits_*() functions, basic_string_w?char_replace_helper(). * In locale.c _Locinfo__Locinfo_ctor_bstr(), codecvt_{short,wchar}__Id_func(), collate_{char,short}__Getcat(), various ctype_*() functions, etc. * In ios.c, the basic_istream_*() and basic_ostream_*() functions, ios_base_Index_func() and ios_base_Sync_func(). * In math.c a lot of std_Ctraits_{double,float,long}_*() functions. Is it just that the spec file needs to catch up or that they will be used soon? I attached a more precise list of the suspects. I did not actually verify that all of them are unused but based on the ones I looked at it seems to be the case. If they are indeed unused and will remain so I can submit a patch to remove them. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.

Aug. 27, 2012

Re: msvcr100: Add wmemmove_s and wmemcpy_s

by Dan Kegel

On Sun, Aug 26, 2012 at 1:29 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: >> But msvcr100's wmemmove_s/wmemcpy_s are different; they >> do not change errno. Tests in my patch confirm this. > > They do set errno, the tests are broken. Aw, foo. Thanks, resent with fixes.

Aug. 26, 2012

Re: About WineHQ Wiki

by Kyle Auble

Sorry if my replies come in large batches, I'm subscribed to the mailing list digest. Sun, 26 Aug 2012 10:08, Cheer Xiao wrote: > Hi all, > I'm a MoinMoin contributor, one of MoinMoin's participating students > in this year's Summer of Code. > 2012/8/26 Kyle Auble <randomidman48(a)yahoo.com>: >> Sat, 25 Aug 2012 14:44, Oleg Yarigin wrote: >>> When I edited pages in the WineHQ Wiki, I notised, its markup lankuage >>> isn`t so good as MediaWiki`s one. How do you think about moving the Wiki >>> into MediaWiki engine? Besides, moving each language section of the Wiki >>> into separated subdomain (like in Wikipedia) would be a good idea too. >> There are some pluggable parsers for Moinmoin, and there may be one >> that allows MediaWiki syntax. After going through and checking, >> categorizing, and editing so many pages, I definitely agree with your >> suggestion that each language be given a domain, instead of one flat >> namespace. Then maybe just add a single common "translation" menu to >> the side toolbar? > Indeed there is a MediaWiki parser[1]. > Also, take a look at MoinMoin 2.0[2]. It has multiple markups support > out of the box (including mediawiki of course). You can even mix them > in a single wiki instance - this is not necessarily a good idea, but > it helps when you have to migrate some content from another wiki by > hand. ... > Feature requests are welcome, but be noted that MoinMoin 2.0 is the > current development version (it's not a development "branch" since the > codebase is almost a total rewrite) and quite likely the feature you > want is already there (or a TODO). :) Hello, I'm glad to hear there's already a line of communication. Allowing people to use MediaWiki syntax will probably be a big plus. There have been performance problems, but I noticed both the Ubuntu and Moinmoin wikis are pretty snappy so I'm thinking it's due to a strained server and using an old version of Moinmoin (although the SystemInfo macro seems to be disabled, I ran across version info somewhere, and I think Wine Wiki is running Moinmoin 1.5 or 1.6). I'm not sure if other problems I've noticed have been fixed in v1.8 or 1.9 so I would have to try out those versions before checking against v2.0. One thing I have done is written up some python code to help convert HTML tables to Moinmoin ones. I checked in Moinmoin's script market, but could only find full-blown page converters, and their output was kind of messy. I probably got carried away, but I'll attach it to http://wiki.winehq.org/WineStatus because I'm using it to move WineHQ's static status pages to the wiki. I guess that would make it LGPL so if you want to salvage a few parts from it or have me submit it to your utility marketplace, just let me know. Sun, 26 Aug 2012 16:07, Andre Hentschel wrote: > Further it seems a bit more complicated with Wine, the moinmoin wiki is sponsored by http://lattica.com/ (whatever > sponsored means, didn't find further information) and the code > is not accessable via a wine git repo (maybe it should be in tools.git, website.git or its own). This also leads to the > fact that we still have no new wiki theme years after the > theme change on the website. > Now that we upgraded the Forum engine we (we as in laxdragon xD) could maybe do something about the wiki, it > needs love. > It seems Kyle is doing a good job at the content, but the content is not everything. Thank you for the compliment. I am actually planning on doing more coding soon, but besides ramping up, I though cleaning up the wiki some first would let me see where the different parts of the project are. Applying the theme from the rest of the WineHQ is on both the WikiToDo and my own list (no guarantees about how long I would take though). Sun, 26 Aug 2012 22:46, Cheer Xiao wrote: > And yes, as I noted in a previous post moin2 is *not* production-ready > yet and I don't suggest you jump ship now. :) > What I do strongly suggest, however, is that you upgrade to moin1.9 > first, since 1) there has been many security fixes[1] which are not > backported to old versions, and 2) upgrade to moin2 will only be > supported from moin1.9. Helping to upgrade the wiki is on my list somewhere between finishing a first round of polishing content and trying a couple of patches to Wine itself. Although the maintainer would actually have to deploy it, I could test and work some of the kinks out of the upgrade using a local install. Dimi Paun put a lot of work into setting up the wiki in the first place and is the maintainer at lattica. From the git logs and mail list, it seems like he has been really busy with other things for a while. At times, Jeremy Newman has raised the possibility of moving the wiki to WineHQ: http://www.winehq.org/pipermail/wine-devel/2006-June/048712.html I remember stumbling across another email too, but I can't find it right now. If it's still a possibilty, I think the first step would be somehow setting up datadumps so we could start on the upgrade. If there is already a feature for admins to do that, maybe Dimi could start putting a daily/weekly tarball on WineHQ's FTP site. If it requires a custom patch though, I could look into doing that too. -Kyle

Aug. 26, 2012

Re: po: Update German translation

by Julian Rüger

I'm very sorry for sending another private mail to the list... When I chose "Answer to sender" my Mailclient asked if I wanted to send a private mail, but the sender is wine-devel. Damn. Am Sonntag, den 26.08.2012, 17:47 +0200 schrieb Julian Rüger: > Hi André, > > war ich zu langsam? ;) > > Das Komma ist an der Stelle grammatikalisch falsch, glaube ich. > "Die verbundenen Controller" sollten auch Plural bleiben. Mein Vorschlag > wäre irgendwie so etwas: > > "Nach dem De-/Aktivieren eines Gerätes wird die Liste der verbundenen > Controller bis zum Neustart dieses Applets nicht [mehr] aktualisiert." > > Viele Grüsse, > Julian > > Am Samstag, den 25.08.2012, 13:40 +0200 schrieb André Hentschel: > > > "After disabling or enabling a device, the connected joysticks won't be " > > "updated here until you restart this applet." > >-msgstr "" > >+msgstr "Nach dem deaktivieren oder aktivieren eines Gerätes, wird der " > >+"verbundene Controller hier bis zum Neustart des Applets nicht mehr " > >+"aktualisiert."

Aug. 26, 2012

Re: po: Update German translation

by Julian Rüger

Hi André, war ich zu langsam? ;) Das Komma ist an der Stelle grammatikalisch falsch, glaube ich. "Die verbundenen Controller" sollten auch Plural bleiben. Mein Vorschlag wäre irgendwie so etwas: "Nach dem De-/Aktivieren eines Gerätes wird die Liste der verbundenen Controller bis zum Neustart dieses Applets nicht [mehr] aktualisiert." Viele Grüsse, Julian Am Samstag, den 25.08.2012, 13:40 +0200 schrieb André Hentschel: > "After disabling or enabling a device, the connected joysticks won't be " > "updated here until you restart this applet." >-msgstr "" >+msgstr "Nach dem deaktivieren oder aktivieren eines Gerätes, wird der " >+"verbundene Controller hier bis zum Neustart des Applets nicht mehr " >+"aktualisiert."

Aug. 26, 2012

Re: winhttp: disable TLSv1.1/1.2 by default

by Marcus Meissner

On Sun, Aug 26, 2012 at 11:50:15AM +0900, Hiroshi Miura wrote: > > Windows 7 disables TLSv1.1/1.2 by default. > This patch intend to behave same as Windows. Please do not... The newer TLSv1.x fix some shortcomings of the older TLS versions. Is there a specific problem you see? Otherwise, I object. Ciao, MArcus > Signed-off-by: Hiroshi Miura <miurahr(a)linux.com> > --- > dlls/winhttp/net.c | 74 > ++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 74 insertions(+) > > > > diff --git a/dlls/winhttp/net.c b/dlls/winhttp/net.c > index 5ec4e1a..03cf9b7 100644 > --- a/dlls/winhttp/net.c > +++ b/dlls/winhttp/net.c > @@ -52,6 +52,7 @@ > #include "winbase.h" > #include "winhttp.h" > #include "wincrypt.h" > +#include "winreg.h" > > #include "winhttp_private.h" > > @@ -109,8 +110,10 @@ MAKE_FUNCPTR( SSL_load_error_strings ); > MAKE_FUNCPTR( SSLv23_method ); > MAKE_FUNCPTR( SSL_CTX_free ); > MAKE_FUNCPTR( SSL_CTX_new ); > +MAKE_FUNCPTR( SSL_CTX_ctrl ); > MAKE_FUNCPTR( SSL_new ); > MAKE_FUNCPTR( SSL_free ); > +MAKE_FUNCPTR( SSL_ctrl ); > MAKE_FUNCPTR( SSL_set_fd ); > MAKE_FUNCPTR( SSL_connect ); > MAKE_FUNCPTR( SSL_shutdown ); > @@ -408,12 +411,66 @@ static int netconn_secure_verify( int preverify_ok, X509_STORE_CTX *ctx ) > } > return ret; > } > + > +static long get_tls_option(void) { > + long tls_option; > + DWORD type, val, size; > + HKEY hkey,tls12_client,tls11_client; > + LONG res; > + const WCHAR Schannel_Prot[] = { /* SYSTEM\\CurrentControlSet\\Control\\SecurityProviders\\SCANNEL\\Protocols */ > + 'S','Y','S','T','E','M','\\', > + 'C','u','r','r','e','n','t','C','o','n','t','r','o','l','S','e','t','\\', > + 'C','o','n','t','r','o','l','\\', > + 'S','e','c','u','r','i','t','y','P','r','o','v','i','d','e','r','s','\\', > + 'S','C','H','A','N','N','E','L','\\', > + 'P','r','o','t','o','c','o','l','s',0 }; > + const WCHAR TLS12_Client[] = {'T','L','S',' ','1','.','2','\\','C','l','i','e','n','t',0}; > + const WCHAR TLS11_Client[] = {'T','L','S',' ','1','.','1','\\','C','l','i','e','n','t',0}; > + const WCHAR DisabledByDefault[] = {'D','i','s','a','b','l','e','d','B','y','D','e','f','a','u','l','t',0}; > + > + tls_option = SSL_OP_NO_SSLv2; /* disable SSLv2 for security reason, and secur32/Schannel(GnuTLS) don't support it */ > + res = RegOpenKeyExW(HKEY_LOCAL_MACHINE, > + Schannel_Prot, > + 0, KEY_READ, &hkey); > + if (res != ERROR_SUCCESS) { > + tls_option |= SSL_OP_NO_TLSv1_2; > + tls_option |= SSL_OP_NO_TLSv1_1; > + goto end; > + } > + if (RegOpenKeyExW(hkey, TLS12_Client, 0, KEY_READ, &tls12_client) == ERROR_SUCCESS) { > + size = sizeof(DWORD); > + if (RegQueryValueExW(tls12_client, DisabledByDefault, NULL, &type, (LPBYTE) &val, &size) || type != REG_DWORD) { > + tls_option |= SSL_OP_NO_TLSv1_2; > + } else { > + tls_option |= val?SSL_OP_NO_TLSv1_2:0; > + } > + RegCloseKey(tls12_client); > + } else { > + tls_option |= SSL_OP_NO_TLSv1_2; > + } > + if (RegOpenKeyExW(hkey, TLS11_Client, 0, KEY_READ, &tls11_client) == ERROR_SUCCESS) { > + size = sizeof(DWORD); > + if (RegQueryValueExW(tls11_client, DisabledByDefault, NULL, &type, (LPBYTE) &val, &size) || type != REG_DWORD) { > + tls_option |= SSL_OP_NO_TLSv1_1; > + } else { > + tls_option |= val?SSL_OP_NO_TLSv1_1:0; > + } > + RegCloseKey(tls11_client); > + } else { > + tls_option |= SSL_OP_NO_TLSv1_1; > + } > + RegCloseKey(hkey); > + > +end: > + return tls_option; > +} > #endif > > BOOL netconn_init( netconn_t *conn, BOOL secure ) > { > #if defined(SONAME_LIBSSL) && defined(SONAME_LIBCRYPTO) > int i; > + long tls_option; > #endif > > conn->socket = -1; > @@ -453,8 +510,10 @@ BOOL netconn_init( netconn_t *conn, BOOL secure ) > LOAD_FUNCPTR( SSLv23_method ); > LOAD_FUNCPTR( SSL_CTX_free ); > LOAD_FUNCPTR( SSL_CTX_new ); > + LOAD_FUNCPTR (SSL_CTX_ctrl); > LOAD_FUNCPTR( SSL_new ); > LOAD_FUNCPTR( SSL_free ); > + LOAD_FUNCPTR( SSL_ctrl ); > LOAD_FUNCPTR( SSL_set_fd ); > LOAD_FUNCPTR( SSL_connect ); > LOAD_FUNCPTR( SSL_shutdown ); > @@ -494,11 +553,20 @@ BOOL netconn_init( netconn_t *conn, BOOL secure ) > LOAD_FUNCPTR( sk_num ); > #undef LOAD_FUNCPTR > > +#define pSSL_CTX_set_options(ctx,op) \ > + pSSL_CTX_ctrl((ctx),SSL_CTRL_OPTIONS,(op),NULL) > +#define pSSL_set_options(ssl,op) \ > + pSSL_ctrl((ssl),SSL_CTRL_OPTIONS,(op),NULL) > + > pSSL_library_init(); > pSSL_load_error_strings(); > > method = pSSLv23_method(); > ctx = pSSL_CTX_new( method ); > + > + tls_option = get_tls_option(); > + pSSL_CTX_set_options(ctx, tls_option); > + > if (!pSSL_CTX_set_default_verify_paths( ctx )) > { > ERR("SSL_CTX_set_default_verify_paths failed: %s\n", pERR_error_string( pERR_get_error(), 0 )); > @@ -676,12 +744,18 @@ BOOL netconn_connect( netconn_t *conn, const struct sockaddr *sockaddr, unsigned > BOOL netconn_secure_connect( netconn_t *conn, WCHAR *hostname ) > { > #ifdef SONAME_LIBSSL > + long tls_option; > + > if (!(conn->ssl_conn = pSSL_new( ctx ))) > { > ERR("SSL_new failed: %s\n", pERR_error_string( pERR_get_error(), 0 )); > set_last_error( ERROR_OUTOFMEMORY ); > goto fail; > } > + > + tls_option = get_tls_option(); > + pSSL_set_options(conn->ssl_conn, tls_option); > + > if (!pSSL_set_ex_data( conn->ssl_conn, hostname_idx, hostname )) > { > ERR("SSL_set_ex_data failed: %s\n", pERR_error_string( pERR_get_error(), 0 )); > > >

Aug. 26, 2012

Re: About WineHQ Wiki

by Cheer Xiao

2012/8/26 André Hentschel <nerv(a)dawncrow.de>: > Am 26.08.2012 07:16, schrieb Cheer Xiao: >> 2012/8/26 Cheer Xiao <xiaqqaix(a)gmail.com>: >>> ... snip ... >>> Try out MoinMoin 2.0 at this minefield[5]. The last Summer of Code[6] >>> saw a few interesting enhancements like greatly improved themes, >>> support for blog and ticket system (disclaimer: ticket system is my >>> project), but the test site has not been updated yet. I have talked to >>> the admin on #moin-dev, and I'll report back when it has been updated. >>> >> >> The test site [1] was just updated, please give it a try :) After >> registering you may want to try out the new "foobar" theme. The theme >> setting can be accessed by clicking "settings" at top and then "Wiki >> Appearance Settings" tab, or directly via this URL[2]. > > Looks good (i also like the foobar theme), but sometimes weird. To add a new page i had to click through some sites first, to confirm it i had to click OK at the top(!?) > and there were no preview option... > Then i copied the "source" of a wiki entry from wine into it and viewed the result, all listings and tables work fine but links like: > [http://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=commit&s=+ARM ARM commits] > are not recognized, so i'm rather scared of upgrading or did i missed something? > (http://test.moinmo.in/ARM) > The markup syntax has changed a bit, and now you have to say [[http://www.example.com|example]] (double brackets, required bar). Single brackets are gone since some 1.x version I think. And yes, as I noted in a previous post moin2 is *not* production-ready yet and I don't suggest you jump ship now. :) What I do strongly suggest, however, is that you upgrade to moin1.9 first, since 1) there has been many security fixes[1] which are not backported to old versions, and 2) upgrade to moin2 will only be supported from moin1.9. Instructions on upgrading are available in the moin1.9 source tree[2]; also check out the moin1.9 installation doc[3]. If you encounter any problem during the upgrade, feel free to ask on #moin channel on freenode. > Further it seems a bit more complicated with Wine, the moinmoin wiki is sponsored by http://lattica.com/ (whatever sponsored means, didn't find further information) and the code > is not accessable via a wine git repo (maybe it should be in tools.git, website.git or its own). This also leads to the fact that we still have no new wiki theme years after the > theme change on the website. > > Now that we upgraded the Forum engine we (we as in laxdragon xD) could maybe do something about the wiki, it needs love. > It seems Kyle is doing a good job at the content, but the content is not everything. Looking forward to good news. 1. http://moinmo.in/SecurityFixes 2. http://hg.moinmo.in/moin/1.9/file/0e58d9bcd3bd/docs/ 3. http://master19.moinmo.in/InstallDocs -- Regards, Cheer Xiao

Aug. 26, 2012

Re: About WineHQ Wiki

by André Hentschel

Am 26.08.2012 07:16, schrieb Cheer Xiao: > 2012/8/26 Cheer Xiao <xiaqqaix(a)gmail.com>: >> ... snip ... >> Try out MoinMoin 2.0 at this minefield[5]. The last Summer of Code[6] >> saw a few interesting enhancements like greatly improved themes, >> support for blog and ticket system (disclaimer: ticket system is my >> project), but the test site has not been updated yet. I have talked to >> the admin on #moin-dev, and I'll report back when it has been updated. >> > > The test site [1] was just updated, please give it a try :) After > registering you may want to try out the new "foobar" theme. The theme > setting can be accessed by clicking "settings" at top and then "Wiki > Appearance Settings" tab, or directly via this URL[2]. Looks good (i also like the foobar theme), but sometimes weird. To add a new page i had to click through some sites first, to confirm it i had to click OK at the top(!?) and there were no preview option... Then i copied the "source" of a wiki entry from wine into it and viewed the result, all listings and tables work fine but links like: [http://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=commit&s=+ARM ARM commits] are not recognized, so i'm rather scared of upgrading or did i missed something? (http://test.moinmo.in/ARM) Further it seems a bit more complicated with Wine, the moinmoin wiki is sponsored by http://lattica.com/ (whatever sponsored means, didn't find further information) and the code is not accessable via a wine git repo (maybe it should be in tools.git, website.git or its own). This also leads to the fact that we still have no new wiki theme years after the theme change on the website. Now that we upgraded the Forum engine we (we as in laxdragon xD) could maybe do something about the wiki, it needs love. It seems Kyle is doing a good job at the content, but the content is not everything. -- Best Regards, André Hentschel

Aug. 26, 2012

Re: msvcr100: Add wmemmove_s and wmemcpy_s

by Alexandre Julliard

Dan Kegel <dank(a)kegel.com> writes: > I asked Alexandre what > http://source.winehq.org/patches/data/88732 > needed before it could be reviewed. He said it needed to adapt > to the recent parameter checking changes. I see that > when he took my patch > http://www.winehq.org/pipermail/wine-patches/attachments/20120728/bea2581d/… > and committed it as > http://source.winehq.org/git/wine.git/patch/49560458426cf25b6a36bbf9bad35aa… > he could remove a few assignments to *MSVCRT__errno() > because MSVCRT_CHECK_PMT now does that for you. > > But msvcr100's wmemmove_s/wmemcpy_s are different; they > do not change errno. Tests in my patch confirm this. So > changing msvcr100's CHECK_PMT macro to assign to errno > doesn't seem appropriate. They do set errno, the tests are broken. Check how it's done in msvcr90. -- Alexandre Julliard julliard(a)winehq.org

Aug. 26, 2012

Re: About WineHQ Wiki

by Cheer Xiao

2012/8/26 Cheer Xiao <xiaqqaix(a)gmail.com>: > ... snip ... > Try out MoinMoin 2.0 at this minefield[5]. The last Summer of Code[6] > saw a few interesting enhancements like greatly improved themes, > support for blog and ticket system (disclaimer: ticket system is my > project), but the test site has not been updated yet. I have talked to > the admin on #moin-dev, and I'll report back when it has been updated. > The test site [1] was just updated, please give it a try :) After registering you may want to try out the new "foobar" theme. The theme setting can be accessed by clicking "settings" at top and then "Wiki Appearance Settings" tab, or directly via this URL[2]. Your are welcome to report bugs at the issue tracker[3], but the obvious bugs should be already there. PS. Currently the hashed password is publicly accessible, so be sure to use a weak password.) 1. http://test.moinmo.in/ 2. http://test.moinmo.in/%2Busersettings#ui 3. https://bitbucket.org/thomaswaldmann/moin-2.0/issues -- Regards, Cheer Xiao

Aug. 26, 2012

Re: [3/3] gdiplus: Make GdipMeasureCharacterRanges/GdipMeasureString/GdipDrawString add extra space around the text.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > > IMHO the whole "resolution-independent" term in that article is a pure > > speculation to justify inventing and adding new shiny technology to Windows. > > s/n/tt If there are only cosmetic objections, I'd like to see this patch accepted, and work of further improvements after that. -- Dmitry.

Aug. 26, 2012

Re: About WineHQ Wiki

by Cheer Xiao

Hi all, I'm a MoinMoin contributor, one of MoinMoin's participating students in this year's Summer of Code. 2012/8/26 Kyle Auble <randomidman48(a)yahoo.com>: > Sat, 25 Aug 2012 14:44, Oleg Yarigin wrote: >> When I edited pages in the WineHQ Wiki, I notised, its markup lankuage >> isn`t so good as MediaWiki`s one. How do you think about moving the Wiki >> into MediaWiki engine? Besides, moving each language section of the Wiki >> into separated subdomain (like in Wikipedia) would be a good idea too. > > I've been working a lot on the wiki recently, and I actually brought up > something similar in this thread: > http://www.winehq.org/pipermail/wine-devel/2012-July/096198.html > While I'm busy with other things right now, I wanted to discuss this in more > detail in the near future, particularly how it ties into possibly migrating the > entire site over to a CMS. > > > The Moinmoin syntax was new to me too, but after using it a little, I don't > mind it too much. There are definitely a few missing features and rough > edges compared to MediaWiki. However, and this is just my impression, I > think MediaWiki has really evolved to fit Wikipedia's needs. I'm not sure how > well it integrates (style-wise at least) if you don't run your entire site off of it, > and while I haven't actually looked at MediaWiki's code, I've heard that it can > be really tricky to setup, maintain, and reprogram. > > > There are some pluggable parsers for Moinmoin, and there may be one > that allows MediaWiki syntax. After going through and checking, > categorizing, and editing so many pages, I definitely agree with your > suggestion that each language be given a domain, instead of one flat > namespace. Then maybe just add a single common "translation" menu to > the side toolbar? > Indeed there is a MediaWiki parser[1]. Also, take a look at MoinMoin 2.0[2]. It has multiple markups support out of the box (including mediawiki of course). You can even mix them in a single wiki instance - this is not necessarily a good idea, but it helps when you have to migrate some content from another wiki by hand. A namespace branch is also under development. [3] Another enhancement that might intereset you: the storage layer has been greatly enhanced, you can now use almost arbitrary databases as the storage in case you are worried about possible performance issue with the directory-based storage; [4] It's not production-ready yet, but it's definitely worth waiting for. :) > I've come to the opinion that we should probably stick with Moinmoin, and > migrate to a new engine other than MediaWiki only if there are strong > reasons. What might be best is if we actually got in touch with some of the > Moinmoin developers and put in some feature requests. Helping with the > wiki's engine is on my list so I'd like to hear some more opinions. > Feel free to join #moin and #moin-dev channels on freenode. Feature requests are welcome, but be noted that MoinMoin 2.0 is the current development version (it's not a development "branch" since the codebase is almost a total rewrite) and quite likely the feature you want is already there (or a TODO). :) Try out MoinMoin 2.0 at this minefield[5]. The last Summer of Code[6] saw a few interesting enhancements like greatly improved themes, support for blog and ticket system (disclaimer: ticket system is my project), but the test site has not been updated yet. I have talked to the admin on #moin-dev, and I'll report back when it has been updated. 1. http://www.moinmo.in/MediaWiki 2. http://www.moinmo.in/MoinMoin2.0 3. http://www.moinmo.in/MoinMoin2.0/Namespaces 4. http://www.moinmo.in/MoinMoin2.0#Storage_Layers:_stores.2C_backends.2C_midd… 5. http://test.moinmo.in/ 6. http://www.moinmo.in/GoogleSoc2012 -- Regards, Cheer Xiao

Aug. 26, 2012

Re: About WineHQ Wiki

by Kyle Auble

Sat, 25 Aug 2012 14:44, Oleg Yarigin wrote: > When I edited pages in the WineHQ Wiki, I notised, its markup lankuage > isn`t so good as MediaWiki`s one. How do you think about moving the Wiki > into MediaWiki engine? Besides, moving each language section of the Wiki > into separated subdomain (like in Wikipedia) would be a good idea too. I've been working a lot on the wiki recently, and I actually brought up something similar in this thread: http://www.winehq.org/pipermail/wine-devel/2012-July/096198.html While I'm busy with other things right now, I wanted to discuss this in more detail in the near future, particularly how it ties into possibly migrating the entire site over to a CMS. The Moinmoin syntax was new to me too, but after using it a little, I don't mind it too much. There are definitely a few missing features and rough edges compared to MediaWiki. However, and this is just my impression, I think MediaWiki has really evolved to fit Wikipedia's needs. I'm not sure how well it integrates (style-wise at least) if you don't run your entire site off of it, and while I haven't actually looked at MediaWiki's code, I've heard that it can be really tricky to setup, maintain, and reprogram. There are some pluggable parsers for Moinmoin, and there may be one that allows MediaWiki syntax. After going through and checking, categorizing, and editing so many pages, I definitely agree with your suggestion that each language be given a domain, instead of one flat namespace. Then maybe just add a single common "translation" menu to the side toolbar? I've come to the opinion that we should probably stick with Moinmoin, and migrate to a new engine other than MediaWiki only if there are strong reasons. What might be best is if we actually got in touch with some of the Moinmoin developers and put in some feature requests. Helping with the wiki's engine is on my list so I'd like to hear some more opinions. -Kyle

Aug. 26, 2012

re: msvcr100: Add wmemmove_s and wmemcpy_s

by Dan Kegel

I asked Alexandre what http://source.winehq.org/patches/data/88732 needed before it could be reviewed. He said it needed to adapt to the recent parameter checking changes. I see that when he took my patch http://www.winehq.org/pipermail/wine-patches/attachments/20120728/bea2581d/… and committed it as http://source.winehq.org/git/wine.git/patch/49560458426cf25b6a36bbf9bad35aa… he could remove a few assignments to *MSVCRT__errno() because MSVCRT_CHECK_PMT now does that for you. But msvcr100's wmemmove_s/wmemcpy_s are different; they do not change errno. Tests in my patch confirm this. So changing msvcr100's CHECK_PMT macro to assign to errno doesn't seem appropriate. So, is there still anything that needs changing?

Aug. 25, 2012

Re: Question about some Linux integration

by Oleg Yarigin

25.08.2012 14:42, GOUJON Alexandre пишет: > I can't help you about the other points but as every project, answers > you are looking for lies in the source code. > See http://source.winehq.org/ident?i=wine_server_call for instance. I searched through the source with Notepad++, but I found nothing, so I asked there. Thank you a lot, Alexandre! --- Oleg

Aug. 25, 2012

About WineHQ Wiki

by Oleg Yarigin

Hi to all! When I edited pages in the WineHQ Wiki, I notised, its markup lankuage isn`t so good as MediaWiki`s one. How do you think about moving the Wiki into MediaWiki engine? Besides, moving each language section of the Wiki into separated subdomain (like in Wikipedia) would be a good idea too. --- Oleg

Aug. 25, 2012

Re: Question about some Linux integration

by GOUJON Alexandre

On 08/25/2012 12:28 PM, Oleg Yarigin wrote: > <snip> > And an off-top question: where is wine_server_call realisation defined? I can't help you about the other points but as every project, answers you are looking for lies in the source code. See http://source.winehq.org/ident?i=wine_server_call for instance.

Aug. 25, 2012

Question about some Linux integration

by Oleg Yarigin

Hi! I have an idea to move some Wine parts into Linux subsystems. For instance, Wine apps windows and window content can be drawn with Desktop Manager via USER32.DLL opposite of using Wine Server. Similar thing can be with clipboard. I understand, it`s a big work, what is must to be started with an EXE loader. So I have a few questions before I can start: 1. Does Wine loader have any mechanism for loading .so files. 2. May I move all loader stuff from NTDLL to the loader. Is it rational? I asked, becouse there are a lot of stuff, that can be unloaded after program loading. And an off-top question: where is wine_server_call realisation defined? --- Oleg

Aug. 25, 2012

Re: [1/16] po: Update Russian translation

by Oleg Yarigin

Nikolay, Can you tell me, why these line of patches is applied very slow? I prepared a patch file, which contains improvements by our dialog, but I can`t apply it until my another patches are applied. --- Oleg

Aug. 25, 2012

Re: [1/16] po: Update Russian translation

by Nikolay Sivov

On 8/25/2012 09:43, Oleg Yarigin wrote: > 24.08.2012 12:20, Nikolay Sivov пишет: >> On 8/24/2012 10:13, Oleg Yarigin wrote: >>> >>> >>> "To install a new program from a floppy disk, CD-ROM drive, or your >>> hard " >>> "drive, click Install." >>> msgstr "" >>> -"Чтобы установить программу с CD-ROM, дискеты или жёсткого диска, >>> нажмите " >>> -"Установить." >>> +"Для установки программы с компакт- или жёсткого диска нажмите >>> «Установить»." >> You only need to fix quotation marks in original string, the variant you >> proposed doesn't say what English string is saying. > I translated so because, I hope, "floppy disc" term is obsolete > nowadays (nobody has it). > This is not up to translator to alter a meaning of original text just cause some words in it are not used frequently enough these days than they used to. > >>> #: appwiz.rc:62 >>> -msgid "" >>> -"The following software can be automatically removed. To remove a >>> program or " >>> -"to modify its installed components, select it from the list and >>> click Modify/" >>> -"Remove." >>> -msgstr "" >>> -"Перечисленные программы можно автоматически удалить. Чтобы удалить >>> программу " >>> -"или изменить состав установленных компонентов, выберите её в >>> списке и " >>> +msgid "The following software can be automatically removed. To remove >>> a " >>> +"program or to modify its installed components, select it from the >>> list and " >>> +"click Modify/Remove." >>> +msgstr "Перечисленные программы могут быть удалены. Для удаления " >>> +"или изменения состава установленных компонентов, выберите их в >>> списке и " >>> "нажмите кнопку Изменить/Удалить." >> Again, don't alter original meaning, no reason to remove 'automatically' >> here. > What does it mean: "можно автоматически удалить"? It doesn`t sound > correct becouse auto-removing (in the text) and user-aided one (in > mean of a phrase "можно удалить") are mutual exclusive. It means that there's an uninstaller of some sort that could be used to uninstall a program. Uninstall doesn't mean removing files, it could be a lot more. So user can manually undo what's done by installer (and he's not supposed to do that) or automatically undo these changes going through uninstallation procedure. >>> #: appwiz.rc:35 shell32.rc:141 shell32.rc:238 regedit.rc:122 >>> winefile.rc:104 >>> msgid "Name" >>> -msgstr "Имя" >>> +msgstr "Название" >> That's questionable. If you really want to change that it will need to >> depend on context I guess. > I think, "Имя" is used for, em, "animate objects"; against "Название" > is used for "inanimate objects". That's not true. It's more general than that, it's more like "identifier" actually. And nobody says "название файла", that sounds strange at least.

Aug. 25, 2012

Re: [1/16] po: Update Russian translation

by Oleg Yarigin

25.08.2012 11:50, Nikolay Sivov пишет: > On 8/25/2012 09:43, Oleg Yarigin wrote: >> 24.08.2012 12:20, Nikolay Sivov пишет: >>> On 8/24/2012 10:13, Oleg Yarigin wrote: >>>> >>>> >>>> "To install a new program from a floppy disk, CD-ROM drive, or your >>>> hard " >>>> "drive, click Install." >>>> msgstr "" >>>> -"Чтобы установить программу с CD-ROM, дискеты или жёсткого диска, >>>> нажмите " >>>> -"Установить." >>>> +"Для установки программы с компакт- или жёсткого диска нажмите >>>> «Установить»." >>> You only need to fix quotation marks in original string, the variant you >>> proposed doesn't say what English string is saying. >> I translated so because, I hope, "floppy disc" term is obsolete >> nowadays (nobody has it). >> > This is not up to translator to alter a meaning of original text just > cause some words in it are not > used frequently enough these days than they used to. Well, in this case I`ll improve it to "... с дискеты, компакт- ...". >> What does it mean: "можно автоматически удалить"? It doesn`t sound >> correct becouse auto-removing (in the text) and user-aided one (in >> mean of a phrase "можно удалить") are mutual exclusive. > It means that there's an uninstaller of some sort that could be used to > uninstall a program. Uninstall doesn't mean removing files, it could be > a lot more. So user can manually undo what's done by installer (and he's > not supposed to do that) or automatically undo these changes going > through uninstallation procedure. In this case we need to change this phrase, becouse it messed everybody I asked. What is in Windows there (for reference)? >>>> #: appwiz.rc:35 shell32.rc:141 shell32.rc:238 regedit.rc:122 >>>> winefile.rc:104 >>>> msgid "Name" >>>> -msgstr "Имя" >>>> +msgstr "Название" >>> That's questionable. If you really want to change that it will need to >>> depend on context I guess. >> I think, "Имя" is used for, em, "animate objects"; against "Название" >> is used for "inanimate objects". > That's not true. It's more general than that, it's more like > "identifier" actually. And nobody says "название файла", that > sounds strange at least. Oh, I forgot about it. But there is an "Имя" column in Windows Explorer (in Windows 7 at least), so I don`t know what is correct.

Aug. 25, 2012

Re: [1/16] po: Update Russian translation

by Oleg Yarigin

24.08.2012 12:20, Nikolay Sivov пишет: > On 8/24/2012 10:13, Oleg Yarigin wrote: >> >> >> "To install a new program from a floppy disk, CD-ROM drive, or your >> hard " >> "drive, click Install." >> msgstr "" >> -"Чтобы установить программу с CD-ROM, дискеты или жёсткого диска, >> нажмите " >> -"Установить." >> +"Для установки программы с компакт- или жёсткого диска нажмите >> «Установить»." > You only need to fix quotation marks in original string, the variant you > proposed doesn't say what English string is saying. I translated so because, I hope, "floppy disc" term is obsolete nowadays (nobody has it). >> #: appwiz.rc:62 >> -msgid "" >> -"The following software can be automatically removed. To remove a >> program or " >> -"to modify its installed components, select it from the list and >> click Modify/" >> -"Remove." >> -msgstr "" >> -"Перечисленные программы можно автоматически удалить. Чтобы удалить >> программу " >> -"или изменить состав установленных компонентов, выберите её в списке и " >> +msgid "The following software can be automatically removed. To remove >> a " >> +"program or to modify its installed components, select it from the >> list and " >> +"click Modify/Remove." >> +msgstr "Перечисленные программы могут быть удалены. Для удаления " >> +"или изменения состава установленных компонентов, выберите их в >> списке и " >> "нажмите кнопку Изменить/Удалить." > Again, don't alter original meaning, no reason to remove 'automatically' > here. What does it mean: "можно автоматически удалить"? It doesn`t sound correct becouse auto-removing (in the text) and user-aided one (in mean of a phrase "можно удалить") are mutual exclusive. >> #: appwiz.rc:76 >> msgid "The following information can be used to get technical >> support for %s:" >> -msgstr "" >> -"Указанная информация может быть использована для получения >> технической " >> +msgstr "Указанная информация может быть использована для получения >> технической " >> "поддержки приложения %s:" > Nothing changed here. I thout the first empty line is obsolete, exclude console "table-layout" output. >> #: appwiz.rc:35 shell32.rc:141 shell32.rc:238 regedit.rc:122 >> winefile.rc:104 >> msgid "Name" >> -msgstr "Имя" >> +msgstr "Название" > That's questionable. If you really want to change that it will need to > depend on context I guess. I think, "Имя" is used for, em, "animate objects"; against "Название" is used for "inanimate objects". >> #: avifil32.rc:33 >> msgid "Wine AVI-default-filehandler" >> -msgstr "Обработчик по умолчанию avi-файлов в Wine" >> +msgstr "Обработчик avi-файлов по умолчанию в Wine" > This alters a meaning a bit, now what you did means that there're some > default avi-files in Wine. > I wrote so becouse "Обработчик avi-файлов по умолчанию" in my opinion is more correct when "Обработчик по умолчанию avi-файлов", because this style is used in Windows. But I don`t know, where "в Wine" need to be, really. Thank you a lot for your critique. If we willn`t go to one opinion, I`m ready to undo these edits. --- Oleg.

Aug. 25, 2012

Re: [1/16] po: Update Russian translation

by Oleg Yarigin

24.08.2012 11:19, Dmitry Timoshkov пишет: > These new translations look at least questionable to say the least. > Pardon, what does it mean? Do you mean, my patches have no any mistake opposite of previous tries? --- Oleg.

Aug. 24, 2012

Re: advapi32/tests: Skip a couple of registry tests on NT4 to avoid crashing it.

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > I know it's bad form to test for the Windows version but I'm not sure > what other check would be relevant here. I think we can safely ignore such old versions at this point. -- Alexandre Julliard julliard(a)winehq.org

Aug. 24, 2012

Re: [3/3] gdiplus: Make GdipMeasureCharacterRanges/GdipMeasureString/GdipDrawString add extra space around the text.

by Vincent Povirk

> IMHO the whole "resolution-independent" term in that article is a pure > speculation to justify inventing and adding new shiny technology to Windows. s/n/tt

Aug. 24, 2012

Re: [3/3] gdiplus: Make GdipMeasureCharacterRanges/GdipMeasureString/GdipDrawString add extra space around the text.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > >> I don't think we should make MeasureString/DrawString > >> resolution-independent because that also makes native's text > >> incredibly ugly, and would greatly increase the complexity of > >> gdip_format_string. > > > > That sounds like a pure guess, not related to my patches. > > Nope, I read about it here: http://support.microsoft.com/kb/307208 > > And since it's the rationale for the padding and the reason we can't > duplicate native's measurements exactly, I think it's relevant to the > discussion. IMHO the whole "resolution-independent" term in that article is a pure speculation to justify inventing and adding new shiny technology to Windows. GDI32 does all its rendering in "resolution-independent" manner just fine for a very long time already. -- Dmitry.

Aug. 24, 2012

Re: [3/3] gdiplus: Make GdipMeasureCharacterRanges/GdipMeasureString/GdipDrawString add extra space around the text.

by Vincent Povirk

>> I don't think we should make MeasureString/DrawString >> resolution-independent because that also makes native's text >> incredibly ugly, and would greatly increase the complexity of >> gdip_format_string. > > That sounds like a pure guess, not related to my patches. Nope, I read about it here: http://support.microsoft.com/kb/307208 And since it's the rationale for the padding and the reason we can't duplicate native's measurements exactly, I think it's relevant to the discussion.

Aug. 24, 2012

Re: [3/3] gdiplus: Make GdipMeasureCharacterRanges/GdipMeasureString/GdipDrawString add extra space around the text.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > > For instance accoding to the tests MeasureCharacterRanges adds extra space > > only to X, while GdipMeasureString and GdipDrawString also add extra space > > to Height and Width of the bounding rectangle. > > That doesn't sound inconsistent to me, it's just that those functions > are measuring different things. CharacterRanges tells you where the > individual characters are (and is resolution-dependent as I understand > it), while MeasureString/DrawString only give information about full > lines and are resolution-independent (they may have to cut into the > padding depending on the hinting at that resolution, but users of > these functions can ignore that and assume the entire line will scale > to any resolution). > > Probably the callback just needs another argument specifying where the > first character is. (For tabs we may need a position for subsequent > characters as well, or multiple callbacks for a single line.) That's the whole reason of my comment: "at the moment I don't see how gdip_format_string() can be used to do this in one place, but if somebody has an idea how to do that - patches are welcome." Right now I just want to implement correct behaviour to make the tests pass, nothing more. Any optimizations, simplifications, or even redesign could be done later. > I don't think we should make MeasureString/DrawString > resolution-independent because that also makes native's text > incredibly ugly, and would greatly increase the complexity of > gdip_format_string. That sounds like a pure guess, not related to my patches. -- Dmitry.

Aug. 24, 2012

Re: [3/3] gdiplus: Make GdipMeasureCharacterRanges/GdipMeasureString/GdipDrawString add extra space around the text.

by Vincent Povirk

> For instance accoding to the tests MeasureCharacterRanges adds extra space > only to X, while GdipMeasureString and GdipDrawString also add extra space > to Height and Width of the bounding rectangle. That doesn't sound inconsistent to me, it's just that those functions are measuring different things. CharacterRanges tells you where the individual characters are (and is resolution-dependent as I understand it), while MeasureString/DrawString only give information about full lines and are resolution-independent (they may have to cut into the padding depending on the hinting at that resolution, but users of these functions can ignore that and assume the entire line will scale to any resolution). Probably the callback just needs another argument specifying where the first character is. (For tabs we may need a position for subsequent characters as well, or multiple callbacks for a single line.) I don't think we should make MeasureString/DrawString resolution-independent because that also makes native's text incredibly ugly, and would greatly increase the complexity of gdip_format_string.

Aug. 24, 2012

Re: [3/3] gdiplus: Make GdipMeasureCharacterRanges/GdipMeasureString/GdipDrawString add extra space around the text.

by Dmitry Timoshkov

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Vincent Povirk <madewokherd(a)gmail.com> wrote: > > > > These APIs use different logic for adding extra space, so at the moment > > > I don't see how gdip_format_string() can be used to do this in one place, > > > but if somebody has an idea how to do that - patches are welcome. > > > > That is highly unlikely, particularly given that > > MeasureCharacterRanges is the accepted practice for highlighting parts > > of a string. > > For instance accoding to the tests MeasureCharacterRanges adds extra space > only to X, while GdipMeasureString and GdipDrawString also add extra space > to Height and Width of the bounding rectangle. GdipMeasureString and GdipDrawString add extra space to Y too. -- Dmitry.

Aug. 24, 2012

Re: [3/3] gdiplus: Make GdipMeasureCharacterRanges/GdipMeasureString/GdipDrawString add extra space around the text.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > > These APIs use different logic for adding extra space, so at the moment > > I don't see how gdip_format_string() can be used to do this in one place, > > but if somebody has an idea how to do that - patches are welcome. > > That is highly unlikely, particularly given that > MeasureCharacterRanges is the accepted practice for highlighting parts > of a string. For instance accoding to the tests MeasureCharacterRanges adds extra space only to X, while GdipMeasureString and GdipDrawString also add extra space to Height and Width of the bounding rectangle. > You should make sure you do your tests so the size in pixels is the em > size of the font, or at least at a consistent size between them, as > native may cut into the padding if hinting makes the characters > proportionally larger (this is the point of having the padding, but > for the record I think it is behavior that we shouldn't try to > duplicate). That's an implementation detail, and my patch has nothing to do with that. > Do you have a visual test program for this? I'd like to see something > that draws a string overlayed with the measurements, to confirm that > the functions are not consistent on Windows (or, if they are, confirm > that they are consistent with your patch). If not, I'll write one and > send you the source code. I have an application which makes a havy use of all of this. > + /* FIXME: GenericTypographic format prevents extra margins */ > > Since no margins is the current behavior, won't that cause a > regression? It should be fairly easy to include that exception. > > Then again, I think I've heard reports that GenericTypographic doesn't work. GenericTypographic does work in my tests, but since it's currently completely ignored anyway I decided to leave it alone. Once these patches are in I'll add support for this case later. -- Dmitry.

Aug. 24, 2012

Re: [3/3] gdiplus: Make GdipMeasureCharacterRanges/GdipMeasureString/GdipDrawString add extra space around the text.

by Vincent Povirk

> These APIs use different logic for adding extra space, so at the moment > I don't see how gdip_format_string() can be used to do this in one place, > but if somebody has an idea how to do that - patches are welcome. That is highly unlikely, particularly given that MeasureCharacterRanges is the accepted practice for highlighting parts of a string. You should make sure you do your tests so the size in pixels is the em size of the font, or at least at a consistent size between them, as native may cut into the padding if hinting makes the characters proportionally larger (this is the point of having the padding, but for the record I think it is behavior that we shouldn't try to duplicate). Do you have a visual test program for this? I'd like to see something that draws a string overlayed with the measurements, to confirm that the functions are not consistent on Windows (or, if they are, confirm that they are consistent with your patch). If not, I'll write one and send you the source code. + /* FIXME: GenericTypographic format prevents extra margins */ Since no margins is the current behavior, won't that cause a regression? It should be fairly easy to include that exception. Then again, I think I've heard reports that GenericTypographic doesn't work.

Aug. 24, 2012

Re: configure --with-osmesa fails to link

by Peter Urbanec

On 24/08/12 18:17, Alexandre Julliard wrote: > libOSMesa should be built without shared-glapi, we can't use it > otherwise. I rebuilt media-libs/mesa-8.1_rc1_pre20120814 without shared-glapi, but even then I get link errors during configure. Seems to be a missing dependency on C++ runtime. I've had to resort to the attached hack to get configure for wine64 to complete on Gentoo x64. I'm not submitting this as a patch, because I'm not anywhere near sure whether this is the right way of actually solving the underlying issue. Unfortunately, I can't configure wine32, even with this hack, because the 32-bit packages for 64-bit Gentoo are supplied as pre-compiled binaries and osmesa is disabled in those. Can I build wine64 --with-osmesa and WoW wine32 --without-mesa and still expect things to work? Best regards, Peter Urbanec

Aug. 24, 2012

Re: quartz/tests: Use proper method macros

by Marvin

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 http://testbot.winehq.org/JobDetails.pl?Key=21196 Your paranoid android. === WNT4WSSP6 (32 bit memallocator) === memallocator.c:34: Test failed: Unable to create memory allocator 80040154

Aug. 24, 2012