May 2011 - Wine-Devel - list.winehq.org

Re: gdi32: Handle pre-Unicode symbol TTFs with symbols at U+00XX.
by Alexandre Julliard May 10, 2011

May 10, 2011

"Konstantin L. Metlov" <metlov(a)fti.dn.ua> writes: > Commit 834378183ad2dffa84fab63b080c31241ac33cba handles the case when glyph is in the U+F0XX range differently > from the original patch. The commit (as I've just tested) does not fix the problem with special symbols in > KOMPAS 3D CAD, which original patch fixed. With this patch I propose to revert the changes of commit > 834378183ad2dffa84fab63b080c31241ac33cba and apply the original patch instead. The original patch was ugly. There's no reason to test for all the conditions twice. If my version doesn't fix your issue please address that without reintroducing the previous ugliness. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ddraw: Fix filtering of enumerated display modes by bits per pixel
by Stefan Dösinger May 10, 2011

May 10, 2011

On Monday 09 May 2011 20:55:21 Ričardas Barkauskas wrote: > + modes16bpp_cnt = 0; > + U2(ddsd.ddpfPixelFormat).dwRBitMask = 0x0000; > + U3(ddsd.ddpfPixelFormat).dwGBitMask = 0x0000; > + U4(ddsd.ddpfPixelFormat).dwBBitMask = 0x0000; Please add an additional test that passes in non-null flags that don't match standard R5G6B5. > + if ((DDSD->dwFlags & DDSD_PIXELFORMAT) && (DDSD- >u4.ddpfPixelFormat.dwFlags & DDPF_RGB) ) > + if(pixelformat.u1.dwRGBBitCount != DDSD- >u4.ddpfPixelFormat.u1.dwRGBBitCount) continue; For the fun of it you could see what happens when you pass a non-RGB format(e.g. a DDPF_YUV or DDPF_BUMPDUDV one) to EnumPixelFormat, but that's not really a requirement for me. Afaics the DDPF_RGB check is needed anyway to enumerate 8 bit palettized formats properly. A YUV primary format may even make sense. A BUMPDUDV one not really.

2 2

Re: [PATCH try6] wininet: Added support for persistent HTTP connections
by Marvin May 10, 2011

May 10, 2011

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=10825 Your paranoid android. === W7PROX64 (64 bit protocol) === protocol.c:972: Test failed: unexpected call ReportResult protocol.c:977: Test failed: hrResult = 00000000, expected: 80004004 protocol.c:2690: Test failed: Read failed: 00000001

1 0

Re: comctl32/listview: Make edit box handle available from LVN_ENDLABELEDIT notification
by Vitaliy Margolen May 10, 2011

May 10, 2011

On 05/09/2011 01:09 AM, Nikolay Sivov wrote: > Fix for http://bugs.winehq.org/show_bug.cgi?id=25908 > There are 3 separate changes in this patch: > - BOOL bSame; > + BOOL same; Variable name rename. The actual fix with new test. > + ok(g_editbox_disp_info.item.pszText != NULL, "got %p\n", g_editbox_disp_info.item.pszText); Btw it's nice to print what did you expected back. > + ok(!IsWindow(hwndedit), "Expected Edit window to be freed\n"); I'm not so sure you can rely on system not allocating any more windows with the same handle. This is a race condition. > - /* WM_COMMAND with EN_KILLFOCUS isn't forwared to parent */ > + /* WM_COMMAND with EN_KILLFOCUS isn't forwarded to parent */ A typo fix. Vitaliy.

3 3

Re: kernel32: Implement CreateSymbolicLinkA/W by reusing a modified IoCreateSymbolicLink
by Vitaliy Margolen May 10, 2011

May 10, 2011

On 05/09/2011 04:02 PM, André Hentschel wrote: > Also for http://bugs.winehq.org/show_bug.cgi?id=27108 I'm afraid that according to msdn kernel32's CreateSymbolicLink has absolutely nothing to do with ntdll's NtCreateSymbolicLinkObject. Other then similar name. The kernel32's creates file system symlinks (for files) and reparse points (for directories). Ntdll's NtCreateSymbolicLinkObject creates object manager's symlinks only. At leas in Wine they don't apply to file systems. Vitaliy.

1 0

Re: kernel32: Implement CreateSymbolicLinkA/W by reusing a modified IoCreateSymbolicLink
by Juan Lang May 9, 2011

May 9, 2011

Hi André, + NtCreateSymbolicLinkObject( &handle, STANDARD_RIGHTS_REQUIRED | 0x1 /* SYMBOLIC_LINK_ALL_ACCESS */, + &attr, &targetstr ); + RtlFreeUnicodeString(&linkstr); + RtlFreeUnicodeString(&targetstr); + /* FIXME: store handle somewhere */ + return handle != INVALID_HANDLE_VALUE; Your fixme already indicates you need to do something different: you're introducing a handle leak. Since the caller has no access to it, what's its use? Simply close it. Also, rather than test the handle value, NtCreateSymbolicLinkObject already has a more direct way to return success: its return value. I'd suggest you use that instead. Finally, any reason you don't call CreateSymbolicLinkW from CreateSymbolicLinkA? This is the usual way we implement things, and avoids having to fix two places if one turns out to be incorrect. Thanks, --Juan

1 0

Re: ddraw: Fix filtering of enumerated display modes by bits per pixel
by Marvin May 9, 2011

May 9, 2011

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=10820 Your paranoid android. === W7PROX64 (64 bit ddrawmodes) === Timeout

1 0

Re: [PATCH 1/2] mountmgr: Populate HKLM\HARDWARE\DEVICEMAP\Scsi here instead of in kernel32. (try 5)
by Vitaliy Margolen May 9, 2011

May 9, 2011

On 05/09/2011 07:42 AM, Charles Davis wrote: > Try 5: Get the value of "DeviceName" from mountmgr instead of making one up. > Try 4: Fix unused variable warning. > Try 3: Add support for IDE drives. > Try 2: Don't depend on the SCSI generic driver on Linux. > - RtlCreateUnicodeStringFromAsciiz( &nameW, "FirstBusTimeScanInMs" ); > + static const WCHAR bus_scan_timeW[] = {'F','i','r','s','t','B','u','s','S','c','a','n','T','i','m','e','I','n','M','s',0}; These do not match. > > + if (devtype) > + { > + if (!(type = p_libhal_device_get_property_string( ctx, udi, "storage.drive_type",&error ))) > + *devtype = ~0; > + else if (!strcmp( type, "disk" ) || !strcmp( type, "floppy" )) > + *devtype = 0x00; > + else if (!strcmp( type, "tape" )) > + *devtype = 0x01; > + else if (!strcmp( type, "cdrom" )) > + *devtype = 0x05; > + else if (!strcmp( type, "raid" )) > + *devtype = 0x0C; > + else > + *devtype = ~0; > + } Please don't use magic numbers here. Also these numbers are wrong. From winbase.h: #define DRIVE_UNKNOWN 0 #define DRIVE_NO_ROOT_DIR 1 #define DRIVE_REMOVABLE 2 #define DRIVE_FIXED 3 #define DRIVE_REMOTE 4 /* Win32 additions */ #define DRIVE_CDROM 5 #define DRIVE_RAMDISK 6 Missing "DeviceName"="Cdrom0" for cdroms. Also names of devices do not match. This can potentially break some software: -"Identifier"="ATA Hitachi HDS72202JKAO" +"Identifier"="ATA Hitachi HDS72202" -"Identifier"="ATA WDC WD7500AAKS-030.0" +"Identifier"="ATA WDC WD7500AAKS-0" -"Identifier"="SAMSUNG DVDWBD SH-B083L SB01" +"Identifier"="SAMSUNG DVDWBD SH-B083L" Vitaliy.

2 1

Re: [PATCH try5] wininet: Added support for persistent HTTP connections
by Alexandre Julliard May 9, 2011

May 9, 2011

Jacek Caban <jacek(a)codeweavers.com> writes: > + FreeLibrary(WININET_hModule); > + return ERROR_SUCCESS; It can still crash here. > +static void delayed_collect_connections(void) > +{ > + static const WCHAR wininet_dllW[] = {'w','i','n','i','n','e','t','.','d','l','l',0}; > + > + if(collector_running) > + return; > + > + if(!LoadLibraryW(wininet_dllW)) > + return; You probably don't want that inside the lock. Also GetModuleHandleEx is probably better. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH try5] wininet: Added support for persistent HTTP connections
by Marvin May 9, 2011

May 9, 2011

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=10813 Your paranoid android. === W2K3R2SESP2 (32 bit protocol) === protocol.c:972: Test failed: unexpected call ReportResult protocol.c:977: Test failed: hrResult = 00000000, expected: 80004004 protocol.c:2690: Test failed: Read failed: 00000001

2 1