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