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

Re: [05/11] windowscodecs: Add support for more types of IFD fields. Resend.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > > + case IFD_BYTE: > > + case IFD_SBYTE: > > + if (count == 1) > > + { > > + item->value.u.bVal = *(BYTE *)&value; > > + break; > > + } > > + FIXME("loading multiple byte fields is not implemented\n"); > > + break; > > This seems to contradict the endianness support. Are you really supposed > to byte-swap arrays of bytes? It doesn't matter at this point. I'm planning to add a test for endianness handling in IFD reader, if this is proved to be wrong the fix will be trivial. Please consider accepting the patch as is. -- Dmitry.

June 15, 2012

RFC: comdlg32: Fix null lpstrFile uses in FILEDLG95_OnOpen

by Bruno Jesus

Hi, I have written a patch to fix bug 17229 and would like to request help to complete the test part. The test creates a common dialog and select a filename (file does not need to exist), it was copied from other tests in the same file (comdlg32/tests/filedlg.c). It's not possible to have a default file name because lpstrFile is used to do this and it's NULL. To fill a filename in the common dialog control that appears I have used EnumChildWindows to find the textbox and set the filename in it. The main problem is how to detect that a HWND is a textbox? Currently I'm sending SetWindowText to every control and that does work but I think the patch may be rejected by that. The patch can be downloaded at: https://testbot.winehq.org/JobDetails.pl?Key=19074 The problem is in the line 56. Thanks in advance, Bruno

June 15, 2012

Re: [PATCH] sfnt2fnt: Fix broken .fon files on !x86 architectures

by Hilko Bengen

* Alexandre Julliard: > endian.h is not portable, you should use the endianness defines from > the Wine headers instead. So, do I need to define my own htobe16 and htobe32 functions or macros based on whether WORDS_BIGENDIAN is defined or not? -Hilko

June 14, 2012

Re: [PATCH 1/4] hhctrl.ocx: Add HTML to Unicode decoding capability (try 4).

by Erich E. Hoover

On Thu, Jun 14, 2012 at 11:47 AM, Erich E. Hoover <ehoover(a)mines.edu> wrote: > ... > I can't think of any other way they'd be doing it... It honestly blew > me away to see that screenshot, I wouldn't have thought to implement > it that way in a million years. The bug submitter was using xchm, so for completeness I ran the example CHM file on XP and I see the exact same behavior (http://bugs.winehq.org/attachment.cgi?id=40547) If you can think of another way you'd like me to approach this bug then let me know. Erich

June 14, 2012

Re: [PATCH (try2)] winepulse.drv: Add PulseAudio driver

by Rosanne DiMesio

On Thu, 14 Jun 2012 13:00:33 -0500 Andrew Eikum <aeikum(a)codeweavers.com> wrote: > On Wed, Jun 13, 2012 at 09:02:33PM +0200, Alexandre Julliard wrote: > > > > It doesn't work here, it's apparently using the driver even though > > PulseAudio is not running on this box: > > > > I've tried this on two operating systems, one with libpulse 2.0 and > one with libpulse 1.1, and I can't reproduce it. It always works > correctly. > A forum user reported this behavior with the Ubuntu 12.04 wine1.5 packages, which are apparently only available with the winepulse patch. http://forum.winehq.org/viewtopic.php?t=15747 -- Rosanne DiMesio <dimesio(a)earthlink.net>

June 14, 2012

Re: [PATCH (try2)] winepulse.drv: Add PulseAudio driver

by Alexandre Julliard

Andrew Eikum <aeikum(a)codeweavers.com> writes: > Also, I should change this to load libpulse at runtime instead of > compile time, right? It works fine as-is, except it prints a > load_builtin_dll err. I'll do that for the next version of the patch. Failing to load when libpulse is missing is fine, there's no need to load it dynamically. -- Alexandre Julliard julliard(a)winehq.org

June 14, 2012

Re: [PATCH (try2)] winepulse.drv: Add PulseAudio driver

by Andrew Eikum

On Wed, Jun 13, 2012 at 09:02:33PM +0200, Alexandre Julliard wrote: > Andrew Eikum <aeikum(a)codeweavers.com> writes: > > > The configure.ac changes and parts of the driver itself were written by > > Maarten Lankhorst. > > It doesn't work here, it's apparently using the driver even though > PulseAudio is not running on this box: > I've tried this on two operating systems, one with libpulse 2.0 and one with libpulse 1.1, and I can't reproduce it. It always works correctly. Also, I should change this to load libpulse at runtime instead of compile time, right? It works fine as-is, except it prints a load_builtin_dll err. I'll do that for the next version of the patch. > ../../../tools/runtest -q -P wine -M amstream.dll -T ../../.. -p amstream_test.exe.so amstream.c && touch amstream.ok > err:pulse:AudioClient_Initialize PulseAudio no longer running? > err:quartz:DSoundRender_create Cannot create Direct Sound object (88890010) > fixme:ole:CoCreateInstance no instance created for interface {56a86895-0ad4-11ce-b03a-0020af0ba770} of class {79376820-07d0-11cf-a24d-0020afd79767}, hres is 0x88890010 > amstream.c:274: Test failed: IAMMultiMediaStream_AddMediaStream returned: 88890010 > > -- > Alexandre Julliard > julliard(a)winehq.org

June 14, 2012

Re: [PATCH 1/4] hhctrl.ocx: Add HTML to Unicode decoding capability (try 4).

by Erich E. Hoover

On Thu, Jun 14, 2012 at 11:44 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > ... > Wow, is Windows really doing it this way? That's a good contestant for > the Most Stupid Win32 API Behavior award. I can't think of any other way they'd be doing it... It honestly blew me away to see that screenshot, I wouldn't have thought to implement it that way in a million years. Erich

June 14, 2012

Re: [PATCH 1/4] hhctrl.ocx: Add HTML to Unicode decoding capability (try 4).

by Alexandre Julliard

"Erich E. Hoover" <ehoover(a)mymail.mines.edu> writes: > On Thu, Jun 14, 2012 at 11:22 AM, Alexandre Julliard > <julliard(a)winehq.org> wrote: >> ... >> >> I don't see why you'd want to use ANSI code pages for this, since they >> will be converted to Unicode anyway. > > It's important to use the ANSI code page because of the way the > characters are handled internally (you can see this in part 4). If > you just convert the characters straight to unicode then ê will > become "ê" instead of "ę" in the Polish (?) code page (similar > behavior in other code pages). You can see an example in the > screenshot from Bug #27767 : > http://bugs.winehq.org/attachment.cgi?id=35529 . If you converted > straight to Unicode then you'd need to convert it a second time to get > the proper character, unless I'm missing something. Wow, is Windows really doing it this way? That's a good contestant for the Most Stupid Win32 API Behavior award. -- Alexandre Julliard julliard(a)winehq.org

June 14, 2012

Re: [05/11] windowscodecs: Add support for more types of IFD fields. Resend.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -650,30 +672,43 @@ static HRESULT load_IFD_entry(IStream *input, const struct IFD_entry *entry, > SWAP_ULONG(count); > type = entry->type; > SWAP_USHORT(type); > + item->value.vt = tag_to_vt(type); > value = entry->value; > SWAP_ULONG(value); > > switch (type) > { > + case IFD_BYTE: > + case IFD_SBYTE: > + if (count == 1) > + { > + item->value.u.bVal = *(BYTE *)&value; > + break; > + } > + FIXME("loading multiple byte fields is not implemented\n"); > + break; This seems to contradict the endianness support. Are you really supposed to byte-swap arrays of bytes? -- Alexandre Julliard julliard(a)winehq.org

June 14, 2012