August 2006 - Wine-devel - list.winehq.org

Re: msi: Inform the user with an error message when the MSI file path is invalid
by Alexandre Julliard 24 Aug '06

24 Aug '06

"James Hawkins" <truiken(a)gmail.com> writes: > This fixes bug 4404 and matches native behavior. As an aside, is it a > legal problem if our message matches native exactly? I personally > can't see why it would be a problem (interface vs. implementation, > this is User Interface), but I can always change it if it's a problem. It's better not to use the exact same messages, since it's not required for compatibility. Particularly in this case, since you know that the error is that the file does not exist, there's no reason to tell people to "contact the application vendor"... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msi: Fix strings with lengths that are exact multiples of 2^16.
by Alexandre Julliard 24 Aug '06

24 Aug '06

Mike McCormack <mike(a)codeweavers.com> writes: > if ( datasize != offset ) > - ERR("string table load failed! (%08x != %08lx)\n", datasize, offset ); > + { > + ERR("string table load failed! (%08x != %08lx), please report\n", datasize, offset ); > + ExitProcess(1); > + } Surely it could fail more nicely than by killing the whole process... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msi: remove limit on number of handles (take 3)
by Alexandre Julliard 24 Aug '06

24 Aug '06

"Dan Kegel" <dank(a)kegel.com> writes: > @@ -66,18 +67,29 @@ MSIHANDLE alloc_msihandle( MSIOBJECTHDR > > EnterCriticalSection( &MSI_handle_cs ); > > + if (msihandletable == NULL) > + { > + msihandletable_size = 256; > + msihandletable = msi_alloc_zero( > + msihandletable_size*sizeof(msi_handle_info)); > + } > + > /* find a slot */ > - for(i=0; i<MSIMAXHANDLES; i++) > + for(i=0; i<msihandletable_size; i++) > if( !msihandletable[i].obj ) > break; > - if( (i>=MSIMAXHANDLES) || msihandletable[i].obj ) > - goto out; > + if( i==msihandletable_size ) > + { > + msihandletable_size *= 2; > + msihandletable = msi_realloc_zero(msihandletable, > + msihandletable_size*sizeof(msi_handle_info)); > + } You should check for allocation failures and fail gracefully instead of crashing. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: replace fchmod() with chmod()
by Alexandre Julliard 24 Aug '06

24 Aug '06

"Steven Edwards" <winehacker(a)gmail.com> writes: > Detlef sent this in a while back and I think it slipped through the que. > > Changelog: > Detlef Riekenberg wine.dev at web.de > - tools/winedump: replace fchmod() with chmod() The right way to make that code portable is to get rid of the shell script. -- Alexandre Julliard julliard(a)winehq.org

1 0

Regression with 'explorer' starting automatically by 'Process Explorer'
by Paul Vriens 24 Aug '06

24 Aug '06

Hi, normally when I start Process Explorer it automatically launches the 'explorer' process. With the latest git 'explorer' crashes. Regression testing showed that this is most likely due to the XEmbed patch: http://source.winehq.org/git/?p=wine.git;a=commit;h=60a97505a63e5102f239d0d… Debug output: 000b:trace:x11drv:X11DRV_CreateBitmap (0x28c) 16x16 24 bpp 000b:trace:x11drv:X11DRV_GetBitmapBits (bmp=0x28c, buffer=0x16c1a4, count=0x300) 0009:trace:x11drv:X11DRV_SetWindowPos hwnd 0x1003a, after (nil), swp 0,0 391x17 flags 00000014 0009:trace:x11drv:SWP_DoWinPosChanging hwnd 0x1003a, after (nil), swp 0,0 391x17 flags 00001814 0009:trace:x11drv:SWP_DoWinPosChanging current (0,0)-(391,17) style 500000c2 new (0,0)-(391,17) 0009:trace:x11drv:X11DRV_set_window_pos win 0x1003a window (0,0)-(391,17) client (0,0)-(391,17) style 500000c2 0009:trace:x11drv:X11DRV_SetWindowPos status flags = 1807 000b:trace:x11drv:X11DRV_CreateBitmap (0x298) 15x15 24 bpp 000b:trace:x11drv:X11DRV_GetBitmapBits (bmp=0x298, buffer=0x16c122, count=0x2b2) 000b:trace:x11drv:X11DRV_set_window_pos win 0x10052 window (0,0)-(26,45) client (0,0)-(26,45) style 04c00000 000b:trace:x11drv:systray_dock_window Docking tray icon 0x10052 000b:trace:x11drv:X11DRV_SetWindowPos hwnd 0x10052, after (nil), swp 1025,769 0x0 flags 00000005 000b:trace:x11drv:SWP_DoWinPosChanging hwnd 0x10052, after (nil), swp 1025,769 0x0 flags 00001805 000b:trace:x11drv:SWP_DoWinPosChanging current (0,0)-(26,45) style 04c00000 new (1025,769)-(1051,814) 000b:trace:x11drv:SWP_DoOwnedPopups (0x10052) hInsertAfter = (nil) 000b:trace:x11drv:X11DRV_set_window_pos win 0x10052 window (1025,769)-(1051,814) client (1025,769)-(1051,814) style 04c00000 000b:trace:x11drv:X11DRV_sync_window_position setting win 3e00002 pos 1028,791,20x20 after 3 changes=f 000b:trace:x11drv:X11DRV_SetWindowPos status flags = 0801 000b:trace:x11drv:X11DRV_CreateBitmap (0x2a8) 32x32 1 bpp 000b:trace:x11drv:X11DRV_SetBitmapBits (bmp=0x2a8, bits=0x15b760, count=0x80) 000b:trace:x11drv:X11DRV_CreateBitmap (0x2a4) 32x32 24 bpp 000b:trace:x11drv:X11DRV_SetBitmapBits (bmp=0x2a4, bits=0x16c3e0, count=0xc00) 000b:trace:x11drv:X11DRV_set_window_pos win 0x10052 window (0,0)-(26,45) client (0,0)-(26,45) style 04c00000 000b:trace:x11drv:X11DRV_sync_window_position setting win 3e00002 pos 3,22,20x20 after 3 changes=3 000b:trace:x11drv:X11DRV_CreateWindow hwnd 0x10052 cs 0,0 26x45 000b:trace:x11drv:X11DRV_set_window_pos win 0x10052 window (0,0)-(26,45) client (3,22)-(23,42) style 04c00000 000b:trace:x11drv:X11DRV_sync_window_position setting win 3e00002 pos 3,22,20x20 after 3 changes=40 000b:trace:x11drv:X11DRV_CreateWindow win 0x10052 window 0,0,26,45 client 3,22,23,42 whole 3,22,23,42 X client 0,0,20,20 xwin 3e00002 000b:trace:x11drv:X11DRV_ShowWindow hwnd=0x10052, cmd=8, wasVisible 0 000b:trace:x11drv:X11DRV_SetWindowPos hwnd 0x10052, after (nil), swp 0,0 0x0 flags 00000053 000b:trace:x11drv:SWP_DoWinPosChanging hwnd 0x10052, after (nil), swp 0,0 0x0 flags 00001853 000b:trace:x11drv:SWP_DoWinPosChanging current (0,0)-(26,45) style 04c00000 new (0,0)-(26,45) 000b:trace:x11drv:SWP_DoOwnedPopups (0x10052) hInsertAfter = (nil) 000b:trace:x11drv:X11DRV_set_window_pos win 0x10052 window (0,0)-(26,45) client (3,22)-(23,42) style 14c00000 000b:trace:x11drv:X11DRV_sync_window_position setting win 3e00002 pos 3,22,20x20 after 3 changes=40 000b:trace:x11drv:X11DRV_set_window_pos mapping win 0x10052 000b:trace:x11drv:systray_dock_window Docking tray icon 0x10052 000b:trace:x11drv:X11DRV_SetWindowPos hwnd 0x10052, after (nil), swp 1025,769 0x0 flags 00000005 000b:err:syslevel:_CheckNotSysLevel Holding lock 0x603ef040 level 2 000b:trace:seh:raise_exception code=80000003 flags=0 addr=0x77a5fc40 000b:trace:seh:raise_exception eax=00000044 ebx=77a83f64 ecx=602daa80 edx=00000044 esi=7ffdc044 edi=00000000 000b:trace:seh:raise_exception ebp=0034e2b8 esp=0034e290 cs=0073 ds=007b es=007b fs=003b gs=0033 flags=00000206 000b:trace:seh:call_stack_handlers calling handler at 0x77a05ec8 code=80000003 flags=0 wine: Unhandled exception 0x80000003 at address 0x77a5fc40 (thread 000b), starting debugger... 000b:trace:seh:start_debugger Starting debugger "winedbg --auto 10 64" WineDbg starting on pid 0xa 000b:trace:seh:call_stack_handlers handler at 0x77a05ec8 returned 1 000d:fixme:ntdll:NtDeviceIoControlFile Unsupported ioctl 8335000c (device=8335 access=0 func=3 method=0) 0009:trace:seh:raise_exception code=c000013a flags=0 addr=0x7bfff400 0009:trace:seh:raise_exception eax=00000003 ebx=00000007 ecx=0033e2ec edx=00000008 esi=0033e2ec edi=7ffdc000 0009:trace:seh:raise_exception ebp=0033e300 esp=0033e2b8 cs=0073 ds=007b es=007b fs=003b gs=0033 flags=00000293 0009:trace:seh:call_stack_handlers calling handler at 0x441d00 code=c000013a flags=0 [paul(a)penguin latest]$ _CheckNotSysLevel () at /wine/wine-git/dlls/kernel/syslevel.c:178 0x77a5fc41 _CheckNotSysLevel+0x41 [/wine/wine-git/dlls/kernel/syslevel.c:178] in kernel32: addl $36,%esp 178 } Modules: Module Address Debug info Name (46 modules) ELF 101000-16f000 Deferred libfreetype.so.6 ELF 175000-190000 Deferred ld-linux.so.2 ELF 192000-1b7000 Deferred libm.so.6 ELF 1b9000-1bd000 Deferred libdl.so.2 ELF 1bf000-1d2000 Deferred libz.so.1 ELF 1d4000-1da000 Deferred libxdmcp.so.6 ELF 1dc000-1df000 Deferred libxau.so.6 ELF 222000-232000 Deferred libxext.so.6 ELF 23a000-25b000 Deferred libexpat.so.0 ELF 25d000-266000 Deferred libxrender.so.1 ELF 2c2000-2c4000 Deferred libnvidia-tls.so.1 ELF 2cb000-2e1000 Deferred libnsl.so.1 ELF 4e8000-4ec000 Deferred libcap.so.1 ELF 4ee000-561000 Deferred libdbus-1.so.2 ELF 74e000-752000 Deferred libxrandr.so.2 ELF 7bd000-7c2000 Deferred libxxf86vm.so.1 ELF 7da000-7df000 Deferred libxfixes.so.3 ELF 927000-931000 Deferred libxcursor.so.1 ELF adf000-c12000 Deferred libc.so.6 ELF c9b000-ca5000 Deferred libhal.so.1 ELF ca8000-da5000 Deferred libx11.so.6 ELF da7000-dbb000 Deferred libpthread.so.0 ELF dbd000-dfa000 Deferred libfontconfig.so.1 ELF 41b4000-49cb000 Deferred libglcore.so.1 ELF 49cd000-4a5c000 Deferred libgl.so.1 ELF 78d5000-78ef000 Deferred libice.so.6 ELF 7915000-791e000 Deferred libsm.so.6 ELF 60000000-60111000 Deferred libwine.so.1 ELF 6025c000-602dc000 Deferred ntdll<elf> \-PE 60270000-602dc000 \ ntdll ELF 602dc000-602f3000 Deferred explorer<elf> \-PE 602e0000-602f3000 \ explorer ELF 602f3000-60429000 Deferred user32<elf> \-PE 60310000-60429000 \ user32 ELF 60429000-604b9000 Deferred gdi32<elf> \-PE 60440000-604b9000 \ gdi32 ELF 604b9000-604ff000 Deferred advapi32<elf> \-PE 604c0000-604ff000 \ advapi32 ELF 6055d000-605e0000 Deferred winex11<elf> \-PE 60570000-605e0000 \ winex11 ELF 60fcc000-60fe8000 Deferred imm32<elf> \-PE 60fd0000-60fe8000 \ imm32 ELF 778e0000-778eb000 Deferred libnss_files.so.2 ELF 779da000-77adf000 Stabs kernel32<elf> \-PE 779f0000-77adf000 \ kernel32 ELF 7bf00000-7bf03000 Deferred <wine-loader> Threads: process tid prio (all id:s are in hex) 0000000a (D) c:\windows\system32\explorer.exe 0000000c 0 0000000b 0 <== Any idea where to start looking? Cheers, Paul. P.S. I write 'most likely due' as I've seen several cases of different results when bisecting.

2 5

Default background erase code does not respect WM_CLIPSIBLINGS
by Troy Rollo 24 Aug '06

24 Aug '06

The attached program demonstrates a bug in the default background-erase code in send_erase (dlls/user/painting.c). The code includes a top level window with WS_CLIPCHILDREN | WS_CLIPSIBLINGS, and two overlapping child windows - one that draws nothing and has a white background (first child), and the other being a standard drop-down list (second child). When the window is first created the second child is completely visible, having drawn over the first child. Click anywhere in the grey area of the window and the second child disappears. Click again and only half of it reappears (you may see the other half reappear briefly but be overwritten by the first child). The second child is correctly redrawn if you cover the window and expose it again. Under Windows, the same code results in the second window (being at the top of the Z order) appearing intact on the second click. This looks like one of those cases where there are probably a lot of wrong ways to fix it and only one right way, and so needs to be fixed by somebody familiar with the code involved. -- Troy Rollo - wine(a)troy.rollo.name

1 0

Re: msi: Add an initial implementation of the PathEdit control
by Mike McCormack 24 Aug '06

24 Aug '06

James Hawkins wrote: > @@ -65,6 +65,7 @@ struct msi_control_tag > float progress_current; > float progress_max; > WCHAR name[1]; > + DWORD attributes; You shouldn't add members after name[1], as the string in name[] will overwrite them. > + sz = 0x20; > + buf = msi_alloc( sz*sizeof(WCHAR) ); > + while( buf ) > + { > + r = GetWindowTextW( control->hwnd, buf, sz ); > + if( r < (sz-1) ) > + break; > + sz *= 2; > + buf = msi_realloc( buf, sz*sizeof(WCHAR) ); > + } There's already code to get the window text in msi_dialog_edit_handler(), so please factor it out into a new function rather than copying it. (maybe LPWSTR msi_get_window_text(HWND)?) > + LPCWSTR prop; > + prop = (LPWSTR)MSI_RecordGetString( rec, 9 ); You shouldn't need a cast here... Mike

2 1

Re: msi: Add Set/GetLastError to the property tests
by Alexandre Julliard 23 Aug '06

23 Aug '06

"James Hawkins" <truiken(a)gmail.com> writes: > @@ -2087,33 +2087,44 @@ static void test_getproperty(void) > ok( hPackage != 0, " Failed to create package\n"); > > /* set the property */ > + SetLastError(0xdeadbeef); > r = MsiSetProperty(hPackage, "Name", "Value"); > ok( r == ERROR_SUCCESS, "Expected ERROR_SUCCESS, got %d\n", r); > + ok( GetLastError() == 0xdeadbeef, "Expected 0xdeadbeef, got %ld\n", GetLastError()); In general, testing that last error isn't set on success is not useful, unless you really have an app that depends on it. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: comdlg: Send missing CDN_FOLDERCHANGE (resend 2)
by Alexandre Julliard 23 Aug '06

23 Aug '06

"Renu Rajput" <renu.rajput(a)gmail.com> writes: > diff -urN OldDir/dlls/comdlg32/filedlg.c NewDir/dlls/comdlg32/filedlg.c > --- OldDir/dlls/comdlg32/filedlg.c 2006-08-10 18:45:12.000000000 +0530 > +++ NewDir/dlls/comdlg32/filedlg.c 2006-08-11 16:09:32.000000000 +0530 > @@ -2011,7 +2011,10 @@ > IPersistFolder2_Release(ppf2); > if( ! COMDLG32_PIDL_ILIsEqual(pidlCurrent, fodInfos->ShellInfos.pidlAbsCurrent)) > { > - IShellBrowser_BrowseObject(fodInfos->Shell.FOIShellBrowser, > pidlCurrent, SBSP_ABSOLUTE); > + if (SUCCEEDED(IShellBrowser_BrowseObject(fodInfos->Shell.FOIShellBrowser, > pidlCurrent, SBSP_ABSOLUTE))) > + { > + SendCustomDlgNotificationMessage(hwnd, CDN_FOLDERCHANGE); > + } > } > else if( nOpenAction == ONOPEN_SEARCH ) There's no point in sending a (corrupted) inline version of the patch plus another one as attachment, all it does is prevent the patch from being applied. Please send only one instance of the patch, in a non-corrupted format. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msi: remove limit on number of handles
by Michael Stefaniuc 23 Aug '06

23 Aug '06

Dan Kegel wrote: > Changelog: > msi: remove limit on number of handles > > handle.c | 30 +++++++++++++++++++++++------- > msipriv.h | 1 - > 2 files changed, 23 insertions(+), 8 deletions(-) > > > ------------------------------------------------------------------------ > > diff --git a/dlls/msi/handle.c b/dlls/msi/handle.c > index 1cd82b3..79664f5 100644 > @@ -66,18 +67,29 @@ MSIHANDLE alloc_msihandle( MSIOBJECTHDR > > EnterCriticalSection( &MSI_handle_cs ); > > + if (msihandletable == NULL) > + { > + /* start table off small to avoid hiding resize bugs */ > + msihandletable_size = 1; Isn't this very small start value something to be used only for debugging while one writes the resizing code? For "production" I would use a value that is big enough to handle the common case (handles at least 50% of the real life cases). As the old MSIMAXHANDLES was good enough for a whole lot of programs i would define that as common case to save me work of finding what the common case is. > + msihandletable = msi_alloc_zero(1*sizeof(msi_handle_info)); > + } > + bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

3 2