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

Xinput / DirectInput xbox360 controller support
by Roderick Colenbrander June 18, 2010

June 18, 2010

Hi all, I'm interested in adding Xbox 360 controller support to Wine. For people who don't know how this works and what's so special I will first give a small introduction. The Xbox 360 controller is a normal USB device which you can use from 'xinput*.dll' (typically xinput1_3.dll is used). The xinput API is very easy (and it is the same what is used on the Xbox360) and in total it exports a handful of functions. Basically there is a call to query the capabilities, a call to poll which button was pressed and a call to 'set the controller to a certain state' (rumble stuff) and a few other not so important calls. The dll can ONLY be used for xbox 360 compatible controllers and other controllers should use dinput. In Wine we have a stubbed xinput implementation. Last year Michael Gruber submitted a number of patches which added implementations for most calls but the code wasn't added. I tested his XInput code on current Wine and it actually works well in DirectX SDK examples including force feedback! After he submitted the code there was a short discussion on wine-devel but then it stopped. Michael his xinput code directly interfaces with the Linux input event interface. It was asked whether XInput can't be layered on top of DirectInput but that's not possible since DirectInput doesn't expose all the needed functionality (it doesn't support the Xbox360 force feedback). The other way around is also not possible because XInput is only for Xbox 360 controllers/joysticks while DirectInput also supports keyboard and mouse. I'm wondering how to proceed with XInput. My main issue is the 'joystick access part'. Would it be fine to directly access the controller from Xinput (so we would need multiple hardware backends later on). Code size won't be a problem though since XInput doesn't support much functionality at all (the current mostly working version is less than 500 lines of code; half of that is for the Linux backend). One small issue is though that DirectInput and XInput might have to cooperate since typically games use DirectInput to enumerate all joysticks, see for instance http://msdn.microsoft.com/en-us/library/ee417014%28VS.85%29.aspx Roderick

4 6

Help with simple winelib dll
by Seth Burleigh June 18, 2010

June 18, 2010

Im attempting to build a dll which a windows program running under wine can dynamically load. The dll will be a wrapper around a linux library. In preparation ive tried to follow the instructions here http://www.winehq.org/docs/winelib-guide/bindlls with a simple example but have not succeeded. Below is the contents of the files in my directory and the commands i executed. Can anyone help out? Thanks! MyLinuxFunc.c int MyLinuxFunc(int a,int b) { return a+b; } ----------------------------- MyLinuxFunc.h int MyLinuxFunc(int,int); ----------------------------- libMyLinuxFunc.so ----------------------------- MyWin.dll.spec 2 stdcall MyWinFunc (long long) MyProxyWinFunc ----------------------------- MyWin.c #include <MyLinuxFunc.h> #include <windef.h> int WINAPI MyProxyWinFunc (int a,int b) { return MyLinuxFunc(a,b); } ----------------------------- winemaker . --nosource-fix --dll --single-target MyWin --nomfc -I"." -L"." -iMyLinuxFunc make winegcc -o MyWin.so MyLinuxFunc.o MyWin.o -L. -lMyLinuxFunc MyWin.o: In function `MyProxyWinFunc': MyWin.c:(.text+0x20): undefined reference to `MyLinuxFunc' /usr/lib/wine/libwinecrt0.a(exe_main.o): In function `main': (.text+0xa0): undefined reference to `WinMain' collect2: ld returned 1 exit status winegcc: i486-linux-gnu-gcc failed make: *** [MyWin.so] Error 2

4 7

Brazilian Portuguese translation of winecfg
by Gustavo June 18, 2010

June 18, 2010

Hello, I've updated the translation of winecfg in Brazilian Portuguese. Making comparisons, I also noted that the "Windows Version" (Versão do Windows) drop-down menu disappeared and the Browse... (Localização:) text in the Drives was cut to half when you execute wine with LANG="pt_PT.UTF-8" (the Portuguese from Portugal). I've managed to fix that as well. So I sent two separate patches: one with the Brazilian translation and another with the Portuguese fixes. Let me know if I did anything wrong. Gustavo Henrique Milaré

1 1

Re: comctl32: Update English resource
by Juan Lang June 18, 2010

June 18, 2010

Hi Ken, +LANGUAGE LANG_ENGLISH, SUBLANG_ENGLISH_CAN + +IDD_TBCUSTOMIZE DIALOG DISCARDABLE 10, 20, 357, 125 +STYLE DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU +CAPTION "Customize Toolbar" +FONT 8, "MS Shell Dlg" +BEGIN + DEFPUSHBUTTON "&Close", IDCANCEL,308,6,44,14 + PUSHBUTTON "R&eset", IDC_RESET_BTN,308,23,44,14 + PUSHBUTTON "&Help", IDC_HELP_BTN,308,40,44,14 + PUSHBUTTON "Move &Up", IDC_MOVEUP_BTN,308,74,44,14 + PUSHBUTTON "Move &Down", IDC_MOVEDN_BTN,308,91,44,14 + LTEXT "A&vailable buttons:", -1,4,5,84,10 + LISTBOX IDC_AVAILBTN_LBOX,4,17,120,100, LBS_NOTIFY | LBS_OWNERDRAWFIXED | LBS_HASSTRINGS | LBS_NOINTEGRALHEIGHT | LBS_DISABLENOSCROLL | WS_BORDER | WS_VSCROLL | WS_HSCROLL | WS_TABSTOP + PUSHBUTTON "&Add ->", IDOK, 131, 42, 44, 14 + PUSHBUTTON "<- &Remove", IDC_REMOVE_BTN,131,62,44,14 + LTEXT "&Toolbar buttons:", -1,182,5,78,10 + LISTBOX IDC_TOOLBARBTN_LBOX, 182,17,120,100,LBS_NOTIFY | LBS_OWNERDRAWFIXED | LBS_HASSTRINGS | LBS_NOINTEGRALHEIGHT | LBS_DISABLENOSCROLL | WS_BORDER | WS_VSCROLL | WS_HSCROLL | WS_TABSTOP +END I don't understand why you would want to create multiple "translations" when their content is identical. If it's because the statistics you're generating claim a particular variant of English is incomplete, then you should fix the tool you're using to generate the statistics: unless there's an actual difference between American English and the variant, there's no need for a translation. --Juan

3 3

Brazilian Portuguese translation
by Gustavo June 17, 2010

June 17, 2010

Hello, I can see that the Brazilian translation is bad, so I'm translating winecfg. I followed the instruction in the wiki [1] to create a .po file. At first I tried to recover from the file Pt.rc rc2po -t En.rc Pt.rc Pt.po but I didn't have much luck, no existing translations are shown. Adding the options --lang=LANG_PORTUGUESE --sublang=SUBLANG_PORTUGUESE_BRAZILIAN or even just --lang=LANG_PORTUGUESE fails to create the file. Not much of a problem, I started from scratch. The problem is, when I use the .po file to create the .rc file po2rc --lang=LANG_PORTUGUESE --sublang=SUBLANG_PORTUGUESE_BRAZILIAN -t En.rc Pt.po Pt.rc only Brazilian Portuguese entries are created, and the Pt.rc file had "Portuguese Portuguese" entries as well. What should I do? Gustavo. [1] http://wiki.winehq.org/Translating

3 4

Re: usp10/tests: having numbers in the ScriptStringXtoCP tests causes unpredictable behavior
by lats June 17, 2010

June 17, 2010

When does this unpredictability occur? The tests have always run ok for me.

2 1

wined3d: Add NPOT quirk for GeforceFX 5200
by Roderick Colenbrander June 17, 2010

June 17, 2010

1 0

Re: msvcrt/tests: Re-order tests to work around weird win_skip failure bug. (try 2)
by Alexandre Julliard June 17, 2010

June 17, 2010

Alexander Scott-Johns <alexander.scott.johns(a)googlemail.com> writes: > Try 2: Re-order function bodies as well. > > From a51f6b7f855ccb1d9252a3d5e2698cdbe73ad053 Mon Sep 17 00:00:00 2001 > From: Alexander Scott-Johns <alexander.scott.johns(a)googlemail.com> > Date: Fri, 11 Jun 2010 14:13:52 +0100 > Subject: msvcrt/tests: Re-order tests to work around weird win_skip failure bug. > > Paul Vriens found which test caused the breakage. There's no need to reorder the functions, but there's a need to understand why that test is breaking win_skip. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/2]kernel32/tests: Test the collation table much more
by Alexandre Julliard June 17, 2010

June 17, 2010

André Hentschel <nerv(a)dawncrow.de> writes: > I added some ranges to test, so it is easy extensible That's still not a very convincing test... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: (resend) usp10/tests: Windows 95 does not set invalid glyphs to 0 but instead 0x80
by testbot＠testbot.winehq.org June 17, 2010

June 17, 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=2742 Your paranoid android. === WVISTAADM (32 bit usp10) === usp10.c:1395: Test failed: ScriptStringFree should return E_INVALIDARG or E_FAIL not 00000000 === W2K8SE (32 bit usp10) === usp10.c:1395: Test failed: ScriptStringFree should return E_INVALIDARG or E_FAIL not 00000000

1 0

Re: usp10/tests: Windows 95 does not set invalid glyphs to 0 but instead 0x80
by testbot＠testbot.winehq.org June 17, 2010

June 17, 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=2739 Your paranoid android. === WVISTAADM (32 bit usp10) === usp10.c:1395: Test failed: ScriptStringFree should return E_INVALIDARG or E_FAIL not 00000000 === W2K8SE (32 bit usp10) === usp10.c:1395: Test failed: ScriptStringFree should return E_INVALIDARG or E_FAIL not 00000000

1 0

Re: [PATCH] winspool/tests: Handle the Windows bug in GetPrinterDataEx
by testbot＠testbot.winehq.org June 17, 2010

June 17, 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=2720 Your paranoid android. === WINEBUILD (build) === Can't determine base name

1 0

Re: PGO and wine
by Peter Davies June 17, 2010

June 17, 2010

On 16 June 2010 02:37, Dan Kegel <dank(a)kegel.com> wrote: > But does PGO improve performance measurably? > Probably, to test it I need a program that runs wine like a typical program, that I can run autonomously. Anyone have any ideas? Peter

5 4

wrong link between bug and AppDB
by wylda＠volny.cz June 16, 2010

June 16, 2010

Hi, i just made a mistake and linked bug 9264 with http://appdb.winehq.org/objectManager.php?sClass=version&iId=20179. But i wanted to link 19264 instead of 9264. What are the correct steps to fix this mistake? -- Kaspersky Internet Security 2010 + Kaspersky Mobile Security jen za 1199,-Kč. Ochraňte svůj počítač i mobil před zneužitím či ztrátou dat. Kupte si 2 produkty za cenu jednoho. www.kaspersky.cz

2 1

Re: [PATCH] ntdll: The FPU control word for newly created threads is 0x27f.
by Alexandre Julliard June 16, 2010

June 16, 2010

Henri Verbeet <hverbeet(a)codeweavers.com> writes: > diff --git a/dlls/ntdll/thread.c b/dlls/ntdll/thread.c > index 36f1499..0d383bd 100644 > --- a/dlls/ntdll/thread.c > +++ b/dlls/ntdll/thread.c > @@ -384,6 +384,7 @@ static void start_thread( struct startup_info *info ) > thread_data->pthread_id = pthread_self(); > > signal_init_thread( teb ); > + signal_init_thread_fpu(); > server_init_thread( func ); > pthread_sigmask( SIG_UNBLOCK, &server_block_set, NULL ); This should be done inside signal_init_thread(), that's already meant for platform-specific setup, there's no need to add a separate entry point. Also you may want to do an fninit if new threads are not supposed to inherit FPU state. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH] ntdll: The FPU control word for newly created threads is 0x27f.
by Henri Verbeet June 16, 2010

June 16, 2010

I forgot to mention this, but this fixes a regression introduced by commit e6611e22fb037a879205f1330d1a3485f9f18705.

1 0

Re: [RESEND 2] Changes to enable the use of gcov and PGO
by Alexandre Julliard June 16, 2010

June 16, 2010

Peter Davies <ultratwo(a)gmail.com> writes: > @@ -72,7 +72,7 @@ MAKECTESTS = $(TOOLSDIR)/tools/make_ctests$(TOOLSEXT) > WRC = $(TOOLSDIR)/tools/wrc/wrc$(TOOLSEXT) > WMC = $(TOOLSDIR)/tools/wmc/wmc$(TOOLSEXT) > WIDL = $(TOOLSDIR)/tools/widl/widl$(TOOLSEXT) > -WINEGCC = $(TOOLSDIR)/tools/winegcc/winegcc $(TARGETFLAGS) -B$(TOOLSDIR)/tools/winebuild --sysroot=$(TOPOBJDIR) @UNWINDFLAGS@ > +WINEGCC = $(TOOLSDIR)/tools/winegcc/winegcc $(TARGETFLAGS) -B$(TOOLSDIR)/tools/winebuild --sysroot=$(TOPOBJDIR) @UNWINDFLAGS@ $(LDFLAGS) LDFLAGS are already passed to winegcc where appropriate. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: Anotated 'make test' log
by Max TenEyck Woodbury June 16, 2010

June 16, 2010

Dan wrote: > OK. I'd suggest starting by looking at > http://bugs.winehq.org/show_bug.cgi?id=15435 > "Wine logs too verbose, quieter fixme's needed" and sending > in a patch to make one of the overly-verbose fixme's a bit > quieter. Thanks. I'll look at it. > Also, check your mail system; I can't email to you directly, > it bounces. And that's going to be a problem communicating > with other developers. A system disk failed this past weekend and I've been trying to get everything back up. I got test messages through starting about two hours ago. I've been checking the mailing list archive. (Yes, messages do not get properly threaded that way.) I'm also in the process of reinstalling much software. That machine is not very fast... - Max

1 1

Re: [2/9] setupapi: Validate the cabinet filename parameter in SetupIterateCabinetA.
by Alexandre Julliard June 16, 2010

June 16, 2010

Andrew Nguyen <anguyen(a)codeweavers.com> writes: > --- > dlls/setupapi/setupcab.c | 7 ++- > dlls/setupapi/tests/Makefile.in | 1 + > dlls/setupapi/tests/setupcab.c | 121 +++++++++++++++++++++++++++++++++++++++ > 3 files changed, 128 insertions(+), 1 deletions(-) > create mode 100644 dlls/setupapi/tests/setupcab.c It doesn't work here: wine: Unhandled page fault on write access to 0x6864dd7b at address 0x686a1c89 (thread 003a), starting debugger... Unhandled exception: page fault on write access to 0x6864dd7b in 32-bit code (0x686a1c89). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:686a1c89 ESP:0032f6e0 EBP:0032fa68 EFLAGS:00010246( R- -- I Z- -P- ) EAX:6864dd7b EBX:686b2cfc ECX:00000000 EDX:00000024 ESI:6865d68f EDI:0032f838 Stack dump: 0x0032f6e0: 0032f93c 6864dd7b 0032f838 0032fa4c 0x0032f6f0: 686a14e0 00000000 0032f724 ffffffff 0x0032f700: 0032fa40 0032f9e4 0032f768 7bc70be0 0x0032f710: 0000000e 00000002 00000001 0032f93c 0x0032f720: 00110060 acabfeed 00121100 00000000 0x0032f730: 00000000 00038080 2e366338 00706d74 Backtrace: =>0 0x686a1c89 SetupIterateCabinetA+0xc9(CabinetFile="", Reserved=0, MsgHandler=0x6864b9a0, Context=0x0(nil)) [/home/julliard/wine/wine/dlls/setupapi/setupcab.c:588] in setupapi (0x0032fd38) 1 0x6864bd95 test_invalid_parametersA+0x384() [/home/julliard/wine/wine/dlls/setupapi/tests/setupcab.c:108] in setupapi_test (0x0032fd88) 2 0x6864df0e run_test+0x14d(name=<is not available>) [/home/julliard/wine/wine/dlls/setupapi/tests/../../../include/wine/test.h:557] in setupapi_test (0x0032fe48) 3 0x6864e0e2 main+0x131(argc=<couldn't compute location>, argv=<couldn't compute location>) [/home/julliard/wine/wine/dlls/setupapi/tests/../../../include/wine/test.h:607] in setupapi_test (0x0032fe90) 4 0x6864e27c __wine_spec_exe_entry+0x7b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in setupapi_test (0x0032fea8) 5 0x7b854ebc call_process_entry+0xb() in kernel32 (0x0032fee8) 6 0x7b85756b start_process+0x5a(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/kernel32/process.c:996] in kernel32 (0x0032fef8) 7 0x7bc71a40 call_thread_func+0xb() in ntdll (0x0032ffc8) 8 0x7bc71c10 call_thread_entry_point+0x6f(entry=0x7b857510, arg=0x7ffdf000) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2466] in ntdll (0x0032ffe8) 9 0x7bc4d5ca start_process+0x29(kernel_start=0x7b857510) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2612] in ntdll (0x00000000) 0x686a1c89 SetupIterateCabinetA+0xc9 [/home/julliard/wine/wine/dlls/setupapi/setupcab.c:588] in setupapi: movb $0x0,0x0(%eax) 588 *p = '\0'; -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ntdll: try to not raise exceptions when checking for atl thunks
by Alexandre Julliard June 16, 2010

June 16, 2010

Markus Amsler <markus.amsler(a)oribi.org> writes: > + * Windows checks the following conditions before emulating an ATL thunk: > + * - DEP policy allows emulating > + * - thunk has memory type MEM_PRIVATE and is readable > + * - jmp func is executable > + * - thunk signature (movl, jmp) matches > + * - a "secret" flag is set: > + * The flag gets set before calling WndProc and cleared after WndProc > + * or a thunk was emulated. > + * In Windows XP SP 3 this flag is located at TEB+0xfb4. > */ Where does that information come from? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: kernel32: stop CopyFile from overwriting a file with itself
by Alexandre Julliard June 16, 2010

June 16, 2010

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > + if (h2 != INVALID_HANDLE_VALUE) > + { > + BY_HANDLE_FILE_INFORMATION info2; > + if (GetFileInformationByHandle( h2, &info2 )) > + { > + if (info.dwVolumeSerialNumber == info2.dwVolumeSerialNumber && > + info.nFileIndexLow == info2.nFileIndexLow && > + info.nFileIndexHigh == info2.nFileIndexHigh) The volume serial number is not the appropriate check. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: usp10/tests: having numbers in the ScriptStringXtoCP tests causes unpredictable behavior
by testbot＠testbot.winehq.org June 16, 2010

June 16, 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=2695 Your paranoid android. === WVISTAADM (32 bit usp10) === usp10.c:1395: Test failed: ScriptStringFree should return E_INVALIDARG or E_FAIL not 00000000 === W2K8SE (32 bit usp10) === usp10.c:1395: Test failed: ScriptStringFree should return E_INVALIDARG or E_FAIL not 00000000 === W7PROX64 (64 bit usp10) === usp10.c:1395: Test failed: ScriptStringFree should return E_INVALIDARG or E_FAIL not 00000000

1 0

Re: winex11.drv: Post a WM_SYSCOMMAND SC_CLOSE when the Window Manager asks to close a window
by Vitaliy Margolen June 16, 2010

June 16, 2010

On 06/15/2010 05:36 AM, Paul Chitescu wrote: > Changelog: > winex11.drv: Post a WM_SYSCOMMAND SC_CLOSE when the Window Manager asks to > close a window > + GetCursorPos( &pt ); > + PostMessageW( hwnd, WM_SYSCOMMAND, SC_CLOSE, MAKELPARAM( pt.x, pt.y ) ); You can't do that. Cursor can be anywhere, even outside Wine when WM decides to remove Wine's window. According to MSDN (which means it requires validation) you can pass either -1 or 0 for lparam here. Otherwise I think WM_SYSCOMMAN should be the correct behavior. Vitaliy.

1 0

Re: [PATCH] winspool: Return ERROR_MORE_DATA, when the app probe for the needed buffersize [BUG 19624]
by testbot＠testbot.winehq.org June 16, 2010

June 16, 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=2686 Your paranoid android. === WINEBUILD (build) === Can't determine base name

1 0

Re: propsys: mention that the functions are stubs
by James Mckenzie June 15, 2010

June 15, 2010

Hans Leidekker <hans(a)codeweavers.com> wrote: > >On Tue, 2010-06-15 at 10:25 +0200, Francois Gouget wrote: > >> Just to confirm what André said, if the FIXME does not contain the word >> 'stub', then apistats has no way to know it's a (pseudo-)stub. > >Wouldn't it be sufficient for our purposes to just count every first >fixme in a WINAPI function as a stub? As it is now there's a large >percentage of fixmes that don't include the 'stub' keyword. > I tend to disagree. Stubs should be identified, if possible, for each call. Some calls will not activate a specific sequence of FIXMEs and in some cases, users have become confused as they don't have the technical knowledge to determine why their program is failing. > >> I would further argue that even a human reading the log would have no >> way to know as quite a few implemented functions still dump their parameters. >> So even for humans it's better to add 'stub' to the FIXME message. > >I'd say we need turn those into traces and add fixmes for the >unimplemented parts, if needed. > This actually might be better, but don't TRACES only appear if you are running in debug mode? We do want to inform our user base that a failure happened due to partially implemented code rather than give them the impression that we don't care or only implement code to make certain programs work (hacky code...) Note: This is only a statement of opinion, not a request for direction within the project. If a fixme had 'stub' that means that we have implemented code to 'fake' windows functionality, whereas a real fixme means there is a problem with the code and it needs to be corrected. James McKenzie

2 1