February 2012 - Wine-devel - list.winehq.org

Re: Alexandre Julliard : gdi32: Avoid overflows for invalid coordinates in line clipping.
by Charles Davis 22 Feb '12

22 Feb '12

On Feb 22, 2012, at 1:27 PM, Alexandre Julliard wrote: > --- a/dlls/gdi32/dibdrv/objects.c > +++ b/dlls/gdi32/dibdrv/objects.c > @@ -372,7 +372,8 @@ static inline DWORD calc_outcode(const POINT *pt, const RECT *clip) > int clip_line(const POINT *start, const POINT *end, const RECT *clip, > const bres_params *params, POINT *pt1, POINT *pt2) > { > - int m, n; > + > + INT64 m, n; /* 64-bit to avoid overflows (FIXME: find a more efficient way) */ What about MulDiv()? As I recall, this is the sort of situation for which it was designed. Or is that not efficient? Chip

2 1

Re: po: Spanish translation update for appwiz.rc and comdlg32.rc
by Francois Gouget 22 Feb '12

22 Feb '12

On Wed, 22 Feb 2012, Eduardo Garcia wrote: > This is the first patch of a series of patches aiming to update and complete > the Spanish interface in current Wine. This patch covers appwiz.rc and > comdlg32.rc. Cool. Thanks! I noticed some issues though: msgid "Publisher:" -msgstr "Editor:" +msgstr "Fabricante" You should not remove the colon here. msgctxt "Saturation" msgid "&Sat:" -msgstr "&Sat.:" +msgstr "&Saturaci??n:" msgctxt "Luminance" msgid "&Lum:" -msgstr "&Lum.:" +msgstr "&Luminancia:" These two are likely to be too long, hence why it's truncated. -#, fuzzy msgid "Files of type:" -msgstr "Archivos de &tipo:" +msgstr "&Tipo de archivo:" Apparently that one is not meant to have a key shortcut. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The greatest programming project of all took six days; on the seventh day the programmer rested. We've been trying to debug the *&^%$#@ thing ever since. Moral: design before you implement.

1 0

Re: po: fixed remaining Slovenian true positives in the winepo error report
by Francois Gouget 22 Feb '12

22 Feb '12

On Wed, 22 Feb 2012, Jaka Kranjc wrote: [...] > > Also in my previous email I forgot to mention that the /Unix line is > > missing from both start.exe usage strings, not just the one I mentionned > > before. Hopefully you will have noticed that already. > Too bad, I missed it. The two usage strings are identical though, so why not > split the formalities away after the strings are thawed? Translators that > don't use tools with translation memory will just have more work this way. That's what should happen eventually. In fact start's messages need a thorough rework because it's a pain to work with right now. Also there's probably improvements to be made for all command line tools with regards to line wrapping. But it's going to take some work and that will all have to wait after the 1.4 release as we are in a string freeze right now. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, it's computer science.

2 1

winealsa.drv patch to enum all software devices from .asoundrc
by Joerg-Cyril.Hoehle＠t-systems.com 22 Feb '12

22 Feb '12

Hi, There's no $HOME/.asoundrc on any of my systems, yet I'd like to use "plug:dmix" with Wine, e.g. on systems with PulseAudio installed. I can use speaker-test -Dplug:dmix with no trouble. Will your patch make that appear in the list? Нискородов Серёжа wrote: >To check whether the device is a hardware, I can call a function >snd_pcm_type. But first I need to get handle of pcm device using the >snd_pcm_open. Okay, but then I have to cancel calling the function >alsa_try_open and rewrite checking availability of the device to not >to opening it twice. Avoiding snd_pcm_open is important. Right now, we already have tests that fail randomly because unfriendly devices like PulseAudio cling to the underlying resource ("hw:0") for a couple of seconds, preventing Wine from inspecting it (bug #28048), causing Wine IIRC to eliminate "hw:0" from the list of available devices. :-( That is not satisfying at all. Perhaps one easy shoot at it would be to access "default" last? That's still much like crossing fingers. Thank you, Jörg Höhle

5 27

Re: [PATCH] README: updated Linux and FreeBSD kernels
by Francois Gouget 22 Feb '12

22 Feb '12

On Wed, 22 Feb 2012, Marcus Meissner wrote: > --- > README | 13 ++++++------- > 1 files changed, 6 insertions(+), 7 deletions(-) > > diff --git a/README b/README > index baa6ab3..0cbb047 100644 > --- a/README > +++ b/README > @@ -29,7 +29,7 @@ especially the wealth of information found at http://www.winehq.org. > To compile and run Wine, you must have one of the following: > > Linux version 2.0.36 or above > - FreeBSD 6.3 or later > + FreeBSD 8.0 or later [...] > FreeBSD info: > - Wine will generally not work properly on versions before FreeBSD > - 6.3 or 7.0, and FreeBSD 6.3 has additional patches available. See > - http://wiki.freebsd.org/Wine for more information. > + Wine will generally not work properly on versions before FreeBSD 8.0. > + See http://wiki.freebsd.org/Wine for more information. Is there a reason why Wine won't work right on FreeBSD 7.0? Winetest seems mostly ok. http://test.winehq.org/data/f43f37d3613db57c732196f88e1225191cd62c30/index_… -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm

2 1

Re: gdi32: pOS2->xAvgCharWidth can be negative however tmAvgCharWidth needs a positive value
by Dmitry Timoshkov 21 Feb '12

21 Feb '12

Aric Stewart <aric(a)codeweavers.com> wrote: > - TM.tmAveCharWidth = (pFT_MulFix(pOS2->xAvgCharWidth, x_scale) + 32) >> 6; > + TM.tmAveCharWidth = (pFT_MulFix(abs(pOS2->xAvgCharWidth), x_scale) + 32) >> 6; Did you test what Windows does in that case? -- Dmitry.

2 8

Re: kernel32/tests: DeviceIoControl: verify IOCTL_DVD_READ_STRUCTURE outputs same buffer as IOCTL_SCSI_PASS_THROUGH_DIRECT f
by Marvin 21 Feb '12

21 Feb '12

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=17047 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: kernel32/tests: DeviceIoControl.IOCTL_DVD_READ_STRUCTURE.DvdPhysicalDescriptor: check output buffer byte order (try 6)
by Marvin 21 Feb '12

21 Feb '12

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=17046 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

[PATCH] mmdevapi: Fix exclusive test.
by Joerg-Cyril.Hoehle＠t-systems.com 21 Feb '12

21 Feb '12

Maarten, what does the patch fix? I did leave nChannels equal to what GetMixFormat returns based on the following reasoning: - It'll probably suggest a mono format on an old machine that handles mono only, so leave as is. - It may suggest 6 channels on a 5:1 card (we had a few such reports on test.winehq.org) so presumably, exclusive mode on such machines would accept 6 channels too, so keep it. Why do you force 2 channels? There's one fix that I envision: the old WAVE_FORMAT_PCM should only be used with mono or stereo, says MSDN. I used it to avoid having to deal with a channel mask. So for 5:1, it would be preferable to keep WAVE_FORMAT_EXTENSIBLE and simply switch pwfx to linear 16bit PCM instead of FLOAT. IIRC, MSDN advises to try out exclusive mode with both WAVE_FORMAT_PCM and FORMAT_EX, arguing that some devices recognize one but not the other format... (what a mess!) Thank you, Jörg Höhle

1 0

Re: [2/2] winefile: Get rid of _wsplitpath duplication
by Alexandre Julliard 21 Feb '12

21 Feb '12

André Hentschel <nerv(a)dawncrow.de> writes: > @@ -1,10 +1,9 @@ > EXTRADEFS = -D__WINE__ > MODULE = winefile.exe > -APPMODE = -mwindows -municode > +APPMODE = -mwindows -municode -mno-cygwin You can't do that, winefile wants Unix filesystem calls. -- Alexandre Julliard julliard(a)winehq.org

1 0