April 2010 - Wine-Devel - list.winehq.org

Re: shell32: add configure option --disable-unixfs
by Alexandre Julliard April 29, 2010

April 29, 2010

Dan Kegel <dank(a)kegel.com> writes: > Fixes http://bugs.winehq.org/show_bug.cgi?id=22450 There's no reason to do that in configure. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: ws2_32: negate return value of SIOCATMARK (try 2)
by Mike Kaplinskiy April 29, 2010

April 29, 2010

2010/4/28 André Hentschel <nerv(a)dawncrow.de>: > confirmed by Mike Kaplinskiy > > try 1 was on 4th November 2009 > > --- > dlls/ws2_32/socket.c | 16 ++++++++++++++-- > dlls/ws2_32/tests/sock.c | 2 +- > 2 files changed, 15 insertions(+), 3 deletions(-) > > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > index e6a6973..62598d2 100644 > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -2800,8 +2800,20 @@ int WINAPI WS_ioctlsocket(SOCKET s, LONG cmd, WS_u_long *argp) > return 0; > > case WS_SIOCATMARK: > - newcmd=SIOCATMARK; > - break; > + fd = get_sock_fd( s, 0, NULL ); > + if (fd != -1) > + { > + if( ioctl(fd, newcmd, (char*)argp ) == 0 ) > + { > + release_sock_fd( s, fd ); > + /* return value must be inverted here */ > + *argp = !*argp; > + return 0; > + } > + SetLastError((errno == EBADF) ? WSAENOTSOCK : wsaErrno()); > + release_sock_fd( s, fd ); > + } > + return SOCKET_ERROR; > > case WS_FIOASYNC: > WARN("Warning: WS1.1 shouldn't be using async I/O\n"); > diff --git a/dlls/ws2_32/tests/sock.c b/dlls/ws2_32/tests/sock.c > index 88b62e3..7a7c688 100644 > --- a/dlls/ws2_32/tests/sock.c > +++ b/dlls/ws2_32/tests/sock.c > @@ -2486,7 +2486,7 @@ static void test_ioctlsocket(void) > > ret = ioctlsocket(sock, SIOCATMARK, &arg); > if(ret != SOCKET_ERROR) > - todo_wine ok(arg, "expected a non-zero value\n"); > + ok(arg, "expected a non-zero value\n"); > } > > static int drain_pause=0; > -- > > Best Regards, André Hentschel > > > > Hey André, I don't think we should rush this. The documentation says that the return values are basically opposites, but I think we need more tests with actual OOB data and different settings of SO_OOBINBLINE. MSDN has far too little information about SIOCATMARK and some things they say don't make a lot of sense. Mike.

2 1

Re: winex11: use XkbKeycodeToKeysym when using XKB
by Alexandre Julliard April 29, 2010

April 29, 2010

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > @@ -609,6 +609,11 @@ extern HMODULE x11drv_module; > extern BYTE key_state_table[256]; > extern POINT cursor_pos; > > +#ifdef HAVE_XKB > +#define XKeycodeToKeysym(dpy,kc,i) \ > + ( use_xkb ? XkbKeycodeToKeysym(dpy, kc, 0, i) : XKeycodeToKeysym(dpy, kc, i) ) > +#endif > + That would make the code very confusing. You should define some explicit inline function instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/3] mshtml: Added support for accessing select options by index.
by testbot＠testbot.winehq.org April 29, 2010

April 29, 2010

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=1828 Your paranoid android. === W98SE (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found

2 1

Re: [PATCH 1/2] user32: convert screen coordinates for send WM_SIZING message (resend)
by Alexandre Julliard April 29, 2010

April 29, 2010

Konstantin Kondratyuk <kondratyuk(a)etersoft.ru> writes: > @@ -2575,11 +2576,24 @@ void WINPOS_SysCommandSizeMove( HWND hwnd, WPARAM wParam ) > if(!iconic && !DragFullWindows) draw_moving_frame( hdc, &sizingRect, thickframe ); > capturePoint = pt; > > + /* convert to screen coordinates */ > + if(parent) > + { > + POINT* p = (POINT*) &newRect; > + ClientToScreen( parent, p ); > + ClientToScreen( parent, ++p ); > + converted = TRUE; > + } > + > /* determine the hit location */ > if (hittest >= HTLEFT && hittest <= HTBOTTOMRIGHT) > wpSizingHit = WMSZ_LEFT + (hittest - HTLEFT); > SendMessageW( hwnd, WM_SIZING, wpSizingHit, (LPARAM)&newRect ); > > + /* convert back to client coordinates id needed */ > + if(converted) > + MapWindowPoints( 0, parent, (POINT*)&newRect, 2 ); > + You should be using MapWindowPoints for the first case too, and there's no need for that extra boolean variable. -- Alexandre Julliard julliard(a)winehq.org

1 0

winmm/tests: Silence test about play from 0 to 0 not immediately stopped.
by Joerg-Cyril.Hoehle＠t-systems.com April 29, 2010

April 29, 2010

Hi, This intermittent failure seems independent on all the other intermittent failures so let's silence it. Experiments with Sleep() were unsuccessful to quiet it. I'm wondering whether it only happens on vmware. Another possible explanation that needs more testing is that it might behave like MCI_CUE: the player starts, does not send a notification (since it's still running) and is waiting for another, "real", command. But then, repeatable behaviour would be expected. Regards, Jörg Höhle

1 0

Re: [1/6] msi: Fix some test failures on Windows.
by testbot＠testbot.winehq.org April 29, 2010

April 29, 2010

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=1817 Your paranoid android. === W7PROX64 (32 bit package) === package.c:7603: Test failed: Expected "C:\winetest\FileName1", got "" package.c:7609: Test failed: Expected "C:\winetest\FileName2", got "" package.c:7615: Test failed: Expected "C:\winetest\FileName3", got "" package.c:7627: Test failed: Expected "C:\winetest\FileName5", got "" package.c:7633: Test failed: Expected "C:\winetest\", got "" package.c:7639: Test failed: Expected "C:\winetest\", got "" package.c:7655: Test failed: Expected "C:\winetest\FileName8.dll", got "" package.c:7666: Test failed: Expected "C:\winetest\FileName10.dll", got "" package.c:11655: Test failed: Expected "{0BE69954-7B96-4254-93F8-567F63E9B7B4}", got "apple" package.c:11682: Test failed: Expected first 3 chars of "{0BE69954-7B96-4254-93F8-567F63E9B7B4}", got "apple" package.c:11692: Test failed: Expected first 37 chars of "{0BE69954-7B96-4254-93F8-567F63E9B7B4}", got "apple" package.c:11702: Test failed: Expected "{0BE69954-7B96-4254-93F8-567F63E9B7B4}", got "apple" package.c:11734: Test failed: Expected "{0BE69954-7B96-4254-93F8-567F63E9B7B4}", got "apple" === W7PROX64 (64 bit package) === package.c:8212: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8223: Test failed: Expected "C:\winetest\", got "" package.c:8234: Test failed: Expected "C:\winetest\", got "" package.c:8284: Test failed: Expected "C:\winetest\FileName3.dll", got "" package.c:8295: Test failed: Expected "C:\winetest\FileName5.dll", got "" package.c:8304: Test failed: Expected "C:\", got "" package.c:8310: Test failed: Expected "C:\winetest\", got "" package.c:8331: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8340: Test failed: Expected "C:\winetest\FileName1", got ""

1 0

Re: [PATCH] kernel32: lstrlen does not call SetLastError.
by testbot＠testbot.winehq.org April 29, 2010

April 29, 2010

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=1815 Your paranoid android. === W98SE (32 bit string) === string.c:41: Test failed: Expected 0xdeadbeef, got 0x00000057 string.c:47: Test failed: Expected 0xdeadbeef, got 0x00000057 string.c:53: Test failed: Expected 0xdeadbeef, got 0x00000057 string.c:59: Test failed: Expected 0xdeadbeef, got 0x00000057

2 1

New SCSI Driver for Mac OS X
by Charles Davis April 29, 2010

April 29, 2010

Hi, A while ago on this list, I was talking about implementing SCSI support on Mac OS X in Wine, and we all agreed the best way to do that would be to have a custom driver that provides an IOCTL interface. I've attached the driver (which is now finished) here. I've tested it on my system, and it works with this small test program that's also attached. But I want to make sure it's totally stable before I start working on the Wine side. So if you've got a Mac, and you're feeling brave, feel free to install my driver and run my test program. Extract the archive, then cd to the directory inside: tar jxf ExtMediaBSDClient.tar.bz2 cd ExtMediaBSDClient Install the extension to /Library/Extensions: cp -r ExtMediaBSDClient.kext /Library/Extensions If you're feeling really brave, you can install it to /System/Library/Extensions (and then it will be loaded on boot): cp -r ExtMediaBSDClient.kext /System/Library/Extensions The driver bundle has to be owned by root and belong to the wheel group, so make sure it does before trying to load it: sudo chown -R root:wheel /path/to/ExtMediaBSDClient.kext You can load the driver with the kextload command: kextload /path/to/ExtMediaBSDClient.kext You can verify that the driver loaded by running: kextstat | grep "ExtMediaBSDClient" Once it's loaded, all SCSI disks that are inserted afterward will accept the IOCTL. All disks that were inserted before won't however. To make sure a disk is using my driver, run the ioreg tool (it's part of Xcode) and look for "ExtMediaBSDClient": ioreg | grep "ExtMediaBSDClient" To test it, run the program 'ExtMediaTest' that I included. Pass it the filename of a device file for the disk (it should be one of the raw device files, e.g. /dev/rdisk1 instead of /dev/disk1) on which you want to test this: ./ExtMediaTest /path/to/device/file If it works, the program will print some of the INQUIRY data for that disk to the Terminal. If it doesn't work, it will print an error to the Terminal (and the driver will have logged something in the kernel log; see the Console app), or worse, the kernel will panic. (If it says "Inappropriate ioctl for device", that probably means it's not using my driver. Try ejecting the disk and reinserting it. And if it says the device is busy, try the program on one of the slices, e.g. /dev/rdisk1s1 instead of /dev/rdisk1.) If anything goes wrong (error messages, kernel panics, etc.), I want to know about it. If you get an error, paste the whole error message. If it's from ExtMediaTest, show me the lines in the kernel log that came from the driver (they have "ExtMediaBSDClient" or some such in them). If the kernel panics, attach the panic log. Also, tell me which version of Mac OS X you're using (so I know which KernelDebugKit to use). As soon as I verify that the driver works well, I'm going to start submitting patches to implement support for it in Wine. Chip

4 13

X11 keyboard detection bitrot on Linux?
by Joerg-Cyril.Hoehle＠t-systems.com April 28, 2010

April 28, 2010

Hi, Perhaps there's some bitrot that affects the handling of alt/altGr keys on Linux? Using WINEDEBUG=+keyboard on Macos yields exepected results. The 3rd and 4th characters (|\ etc.) below show what's obtained when pressing the alt key: trace:key:X11DRV_KEYBOARD_DetectLayout mismatch for keycode 34, got 7/|\ trace:key:X11DRV_KEYBOARD_DetectLayout mismatch for keycode 36, got 8({ trace:key:X11DRV_KEYBOARD_DetectLayout mismatch for keycode 58, got <>?? trace:key:X11DRV_KEYBOARD_DetectLayout mismatch for keycode 73, got ,,.. On Linux instead: warn:keyboard:X11DRV_KEYBOARD_DetectLayout 7 keysyms per keycode not supported, set to 4 trace:key:X11DRV_KEYBOARD_DetectLayout mismatch for keycode 16, got 7/7/ trace:key:X11DRV_KEYBOARD_DetectLayout mismatch for keycode 17, got 8(8( None of the {[]}\ keys reached via AltGr-7/8/9/0 on the German keyboard is printed by the keyboard detection code. This causes warnings for all keyboards (not printed by default) because none matches, which presumably was not the case back when that code was written. What has changed? Regards, Jörg Höhle

3 2