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

re: Have there been any problems with Wine on GCC 4.7?
by Dan Kegel 24 Jul '12

24 Jul '12

Groveling around, I found a few possibilities: backtraces broken on gcc 4.7 http://bugs.winehq.org/show_bug.cgi?id=26791 ICE when compiling: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641056 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640864 https://bugs.launchpad.net/ubuntu/+source/gcc-4.6/+bug/842012 needs-new-prelink-to-avoid-crash-with -g option: http://bugs.winehq.org/show_bug.cgi?id=30862 steam overlays: http://bugs.winehq.org/show_bug.cgi?id=22053 enabling -fomit-frame-pointer by default breaks Wine: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46468 gcc shouldn't assume that the stack is aligned: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838 wine's conformance test kernel32/thread.ok always fails/crashes on ubuntu 11.10: https://bugs.launchpad.net/ubuntu/+source/wine1.3/+bug/872063 http://wiki.winehq.org/GccVersions might be a place to record this kind of stuff, but it's outdated. There are some known fixes, possibly related to the above problems, e.g. http://bugs.winehq.org/show_bug.cgi?id=27692 http://bugs.winehq.org/show_bug.cgi?id=28753 http://bugs.winehq.org/show_bug.cgi?id=23137 And then there's debian's "wine uses an old gcc" bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654742

1 0

Re: kernel32: Reimplement GetLogicalDrives using the mountmgr
by Alexandre Julliard 23 Jul '12

23 Jul '12

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > Previous approach was patch #88280 > --- > dlls/kernel32/volume.c | 18 +++--------------- > 1 file changed, 3 insertions(+), 15 deletions(-) > > diff --git a/dlls/kernel32/volume.c b/dlls/kernel32/volume.c > index 8377e41..57453bb 100644 > --- a/dlls/kernel32/volume.c > +++ b/dlls/kernel32/volume.c > @@ -1435,27 +1435,15 @@ DWORD WINAPI QueryDosDeviceA( LPCSTR devname, LPSTR target, DWORD bufsize ) > */ > DWORD WINAPI GetLogicalDrives(void) > { > - const char *config_dir = wine_get_config_dir(); > - struct stat st; > - char *buffer, *dev; > DWORD ret = 0; > + WCHAR drive; > int i; > > - if (!(buffer = HeapAlloc( GetProcessHeap(), 0, strlen(config_dir) + sizeof("/dosdevices/a:") ))) > - { > - SetLastError( ERROR_NOT_ENOUGH_MEMORY ); > - return 0; > - } > - strcpy( buffer, config_dir ); > - strcat( buffer, "/dosdevices/a:" ); > - dev = buffer + strlen(buffer) - 2; > - > for (i = 0; i < 26; i++) > { > - *dev = 'a' + i; > - if (!stat( buffer, &st )) ret |= (1 << i); > + drive = 'A'+i; > + if (get_mountmgr_drive_type(&drive) != DRIVE_UNKNOWN) ret |= (1 << i); > } That's very inefficient. There are better way of enumerating drives, check for instance QueryDosDevice. -- Alexandre Julliard julliard(a)winehq.org

2 4

Query MediaType of SD-Cards using IOCTL_GET_DISK_DRIVE_GEOMETRY
by Eduard Hasenleithner 23 Jul '12

23 Jul '12

Hi I'm trying to use the TANITA Bodyvision software (http://www.tanita.co.uk/index.php?id=158) under wine. The software is supposed to read its data from an SD-Card. But under wine it cannot find the SD card. I managed to find out what it takes so that the software finds the SD card. Please see the attached small sample to see how the software iterates the drive letters, and how it determines a eligibile media using (data.MediaType == RemovableMedia). The reasons why this does not work are manyfold. Here are some events which happen when inserting the card. * The drive is reported using udisks. This creates a symlink in dosdevices to the raw block device /dev/sdf * The partition /dev/sdf1 is mounted automatically in /media/XXXX-YYYY * /dev/sdf and /dev/sdf1 are not user read/writable. * wine creates a drive letter symlink for /dev/sdf * no symlink is created for /media/XXXX-YYYY * When you open wine explorer, the drive does not show up in the drive list This means that the drive letter assigned for the sd card will not be returned in GetLogicalDrives(). When the symlink to the mountpoint is added manually, following output is produced: DbgPrint says: Drive f fixme:ntdll:server_ioctl_file Unsupported ioctl 70000 (device=7 access=0 func=0 method=0) DbgPrint says: DeviceIoControl failed When get_dos_device is made to unconditionally return STATUS_BAD_DEVICE_TYPE, the ioctl is properly delivered to harddisk_ioctl DeviceIoControl succeeds: DbgPrint says: Drive f DbgPrint says: Removable: 0 But still, the device is reported as non-removable. The reason for this is probably that udisks reports /dev/sdf as removable, but not its partition /dev/sdf1. Is it worth for working on patches for these issues, or is this completely impossible with the current architecture? Eduard

3 7

Re: [1/2] msvcrt: added wmemcpy_s and wmemmove_s
by Alexandre Julliard 23 Jul '12

23 Jul '12

Dan Kegel <dank(a)kegel.com> writes: > Next patch will expose them for msvcr100. > > From 357c45971e1315e8f6cd1f9feac65cf96a006a41 Mon Sep 17 00:00:00 2001 > From: Dan Kegel <dank(a)kegel.com> > Date: Fri, 20 Jul 2012 10:39:32 -0700 > Subject: [PATCH 1/2] msvcrt: add wmemcpy_s and wmemmove_s > > --- > dlls/msvcrt/heap.c | 29 ++++++++++++++++++++++++ > dlls/msvcrt/msvcrt.spec | 2 + > dlls/msvcrt/tests/misc.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 85 insertions(+), 0 deletions(-) You shouldn't need to put that in msvcrt. Also please check the parameters correctly like every other _s function does. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: Dmitry Timoshkov : gdiplus: GdipMeasureString operates internally in pixels but in/ out rectangles are in device units.
by Vincent Povirk 23 Jul '12

23 Jul '12

> gdiplus: GdipMeasureString operates internally in pixels but in/out rectangles are in device units. I still don't understand this patch. Your subject implies that device units and pixels are not the same thing, but my understanding is that except for metafile HDCs (which we don't handle correctly anyway, and I suspect native doesn't either), they are. You're scaling sizes based on graphics->unit. Yet the conversion in get_graphics_transform (which we were already using in GdipMeasureString to convert between world and device units, indirectly through GdipTransformPoints) already takes graphics->unit into account. So I'm concerned that the original conversion apparently wasn't sufficient, and that you've added more code instead of fixing it. And I'm still concerned about whether the sizes returned by GdipMeasureString will match the size of the strings rendered by GdipDrawString with this patch applied.

2 6

Re: [1/6] windowscodecs: Add support for generating WICBitmapPaletteTypeFixedHalftone27 palette.
by Vincent Povirk 23 Jul '12

23 Jul '12

Series looks good to me.

1 0

Re: [PATCH 4/4] mshtml: Added IHTMLFrameBase::frameBorder implementation
by Marvin 23 Jul '12

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

1 0

Re: [PATCH 4/4] vbscript: Added select case statement tests
by Marvin 23 Jul '12

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

1 0

Re: atl80: Implement AtlGetVersion - try2
by Dmitry Timoshkov 23 Jul '12

23 Jul '12

Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > +WINAPI DWORD AtlGetVersion(void* pReserved) That's a somewhat strange choice for the placement of a calling convention specifier. Also it shouldn't be too hard to avoid a hungarian style named variable, and placing '*' properly. -- Dmitry.

2 2

Re: configure.ac: Always treat char as signed char on ARM
by Alexandre Julliard 23 Jul '12

23 Jul '12

André Hentschel <nerv(a)dawncrow.de> writes: > Problem: > On ARM the default "char" is "unsigned char" for performance reasons, > Wine uses "char" expecting the x86 default (signed char). In general there's no such expectation in Wine. If there are places that expect char to be signed, they are bugs that should be fixed. -- Alexandre Julliard julliard(a)winehq.org

1 0