Re: [1/2] dinput: Do not close device upon Unacquire
Vincent Pelletier wrote: > This fixes force feedback effects in MS Flight Sim 2000: it releases the > device after uploading effects, reaquires it later and try to update effects. > This fails, because linux requires all access to be done from a single file > descriptor. > > It doesn't feel right to open a device without ever closing it... But I could > not find any "dealloc" method. > This patch is not correct. The device can get removed, opened by other application, etc. You can't open it during the creating and keep it open all that time. The more correct way to do it would be to re-upload all the state changes on acquire. Vitaliy.
Re: dinput: Add effect gain support
On Mon, Jan 19, 2009 at 12:52 PM, Vincent Pelletier wrote: > dinput: Add effect gain support > > -- > Vincent Pelletier > Vincent, This patch is ok as far as it goes, but not completely correct. Firstly, SetParameters needs to apply the parameters to effects while they are playing, not just store them. Existing parameters are all part of the effect structure, so that is taken care of automatically. Since gain is handled by a different mechanism, you also need to handle the while-playing case (unless DIEP_NODOWNLOAD is specified). This probably means you need to implement GetEffectStatus, since you won't want to apply the gain unless the effect is playing. Secondly, the kernel's ff.txt suggests that evdev handles the gain globally for the device. Since the DirectInput definition of gain is per-effect rather than per-device, you should also test what happens when you set the gain differently in two simultaneously-playing effects on the same device. If Windows mixes them (i.e. truly applies the gain per-effect) then we need to come up with some logic to do the same (probably by scaling the effect envelope or magnitude, depending on the effect type, and keeping it updated when the user modifies the scaled parameters). Thirdly, SetParameters still has a comment that says gain and sample periods aren't supported. Please update any applicable comments when you update the code - outdated comments are worse than no comments at all. Regards, Daniel Remenak
Re: Support for Dragon NS in Wine
>On Tue, Jan 20, 2009 at 3:23 PM, Jeff Zaroyko wrote: >> While I don't own any NS product, two open bugs to come to mind for NS >> 8, one affecting the installer but with a workaround, bug 15708 and >> the other a user has reported a regression bug 16248 but was not >> interested in running a regression test. >> >> http://bugs.winehq.org/show_bug.cgi?id=15708 >> http://bugs.winehq.org/show_bug.cgi?id=16248 > >I think those were both for NS 7, not 8... >A full list of NS bugs is at >http://bugs.winehq.org/buglist.cgi?quicksearch=Dragon+Naturally+Speaking >Looks like 9 is happier than 10...? I have 7, 8, 9, 9.5 and 10 here. I'll test a couple tonight, maybe 7 and 8, on today's git. Here's what I remember. 7 worked great right out of the box at one time, with all-native code. 8 is virtually the same product as 7. Ditto worked great. (Nobody bought 8 much because it was the same engine as 7.) 9.0 worked pretty good out of the box with a couple of glitches. 9.5 does not install, and works not at all, except for one lucky man who developed a workaround that doesn't always work. (9.5 replaced 9.0 as "version 9," and 9.0 is no longer sold, at least in the US.) 10.0 installs well and runs pretty well for 10 minutes, then nasty crashes happen. Wine support has been given primarily for the two cheapest "consumer" versions, Standard and Preferred. Very few people have asked about Professional, and I don't know of anyone who has tried to make Professional 8 run with wine. Susan
Re: Support for Dragon NS in Wine
On Tue, Jan 20, 2009 at 3:23 PM, Jeff Zaroyko wrote: > While I don't own any NS product, two open bugs to come to mind for NS > 8, one affecting the installer but with a workaround, bug 15708 and > the other a user has reported a regression bug 16248 but was not > interested in running a regression test. > > http://bugs.winehq.org/show_bug.cgi?id=15708 > http://bugs.winehq.org/show_bug.cgi?id=16248 I think those were both for NS 7, not 8... A full list of NS bugs is at http://bugs.winehq.org/buglist.cgi?quicksearch=Dragon+Naturally+Speaking Looks like 9 is happier than 10...?
Re: $200 bid for autocad support
Dan Kegel ha scritto: > http://www.rentacoder.com/RentACoder/misc/BidRequests/ShowBidRequest.asp?lngBidRequestId=1087309&txtFromURL=AId_512725 > > Someone's got to break the bad news to him about the likely cost... > > > Uh... maybe he forgot some nulls on the end... :-)
Re: Support for Dragon NS in Wine
On Wed, Jan 21, 2009 at 7:47 AM, Dan Kegel wrote: > On Tue, Jan 20, 2009 at 12:44 PM, Steven Druker wrote: >> I deeply appreciate your endeavors to broaden the number of Windows-based >> applications that will run on Linux via Wine. Your Feb. '08 message >> indicated that while you had achieved significant progress for Dragon NS, it >> was not yet fully functional. Since then has more progress been made? I'm >> particularly interested in whether the professional versions of NS 8 as well >> as 10 are fully supported now. > > I don't know about fully supported, but Susan Craigin's been > using NS 9 and 10 continuously, and she could say more > about how well they work. (I think 8 might have some flaws > that make it less usable on wine.) Susan? > - Dan > Hi While I don't own any NS product, two open bugs to come to mind for NS 8, one affecting the installer but with a workaround, bug 15708 and the other a user has reported a regression bug 16248 but was not interested in running a regression test. -Jeff http://bugs.winehq.org/show_bug.cgi?id=15708 http://bugs.winehq.org/show_bug.cgi?id=16248
$200 bid for autocad support
http://www.rentacoder.com/RentACoder/misc/BidRequests/ShowBidRequest.asp?lngBidRequestId=1087309&txtFromURL=AId_512725 Someone's got to break the bad news to him about the likely cost...
Re: Fix wine-bugs mailing list traffic message.
Ok, I did not know there was a CVS/GIT cleanup. Maybe the message is irrelevant anyway. Best regards Christoph Korn Jerome Leclanche schrieb: > It's not hundreds / day (as it's been the past few days due to the > CVS/GIT cleanup), but it's definitely not 10/day either. I would say > 60-70 per day is common, but I don't run statistics (nor try to). > > On Tue, Jan 20, 2009 at 5:26 PM, Francois Gouget wrote: >> On Tue, 20 Jan 2009, Christoph Korn wrote: >> >>> Only a small fix. >>> >>> I subscribed to the wine-bugs mailing list because it was listed as >>> medium traffic. But I got hundreds of mails in about two hours or so. >> Usually it's a medium traffic mailing list (I believe), but occasionally >> (2/3 times a year) someone does a big cleanup touching hundreds of bugs >> and that's when you get a lot of emails... >> >> -- >> Francois Gouget http://fgouget.free.fr/ >> If it stinks, it's chemistry. If it moves, it's biology. >> If it does not work, It's computer science. >> >> >> > > >
Re: Support for Dragon NS in Wine
On Tue, Jan 20, 2009 at 12:44 PM, Steven Druker wrote: > I deeply appreciate your endeavors to broaden the number of Windows-based > applications that will run on Linux via Wine. Your Feb. '08 message > indicated that while you had achieved significant progress for Dragon NS, it > was not yet fully functional. Since then has more progress been made? I'm > particularly interested in whether the professional versions of NS 8 as well > as 10 are fully supported now. I don't know about fully supported, but Susan Craigin's been using NS 9 and 10 continuously, and she could say more about how well they work. (I think 8 might have some flaws that make it less usable on wine.) Susan? - Dan
Re: AppDB: Rating / Patching
On Wed, 21 Jan 2009, Paul TBBle Hampson wrote: [...] > What about apps that fail to include a necessary third-party library? > > If I understand the AppDB comments and followed the IRC discussion > correctly, Warcraft 3's latest patch (1.22) was built with a newer > Visual Studio and so requires new Visual C runtimes, while previous > versions did not. And the patcher doesn't install these runtimes. If you don't need to manually install the third-party library on a stock installation of the application's officially supported Windows platform (e.g. Wow on Windows XP), then you should not need to manually install it in Wine. If you do, then that application cannot be rated platinum. -- Francois Gouget http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.
Re: wineg++ compile error
--- On Tue, 20/1/09, Rino Farina wrote: > Right, I wasn't able to find iostream among the > available headers > (remember, I'm not linking yet). > > Stefan, are you suggesting that I install microsofts > tool-chain and > compile the code with the ms compiler? Sounds reasonable. > I'm not sure > what you mean by PE .exe, though. I have no need to link to > Linux > libraries, other than this is a pure windows codebase and > some of the > libraries referenced are not available in winelib/msvcrt. In that case you might be happier switching to mingw gcc/g++ - either running it under wine, or as a cross-compiler. It has all the iostreams stuff, instead of wineg++ . the
re: QT4 applications not receiving clicks
louis wrote: > I may have uncovered a bug in which grandchild HWNDs do not receive > mouse-down events. Cool... think you can come up with a conformance test that demonstrates the bug? That might be the best way to answer your questions. - Dan
Re: AppDB: Rating / Patching
On Tue, Jan 20, 2009 at 12:39:25PM +1100, Ben Klein wrote: > 2009/1/20 : >> Similarly, AppDB might prevent Gold or Silver ratings depending on >> qualitative aspects of the steps needed to make an app work: >> - need for known distributable third party libraries (e.g. codecs, >> Quicktime) >> (not provided with the application's installer) > This is already covered in the current "Gold" rating description. If > the application requires such 3rd-party libraries that are *not > normally present* on Windows (e.g. codecs, Quicktime), then it should > ship with them. If the shipped 3rd-party libraries do not install for > whatever reason, it's not a Platinum app. What about apps that fail to include a necessary third-party library? If I understand the AppDB comments and followed the IRC discussion correctly, Warcraft 3's latest patch (1.22) was built with a newer Visual Studio and so requires new Visual C runtimes, while previous versions did not. And the patcher doesn't install these runtimes. Assuming the above is correct (if I'm wrong, take it as a hypothetical) then would that rate as Platinum if it's otherwise perfect? I'm of the opinion that it does, on the grounds that Wine itself is working fine, the problem is actually an upstream bug. The maintainer of the relevant AppDB page (or at least the author of one of the notes on that page, I presume the maintainer does that) does not. -- --- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) paul.hamp...@pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.5/au/ --- pgpjXBVBE3Yo5.pgp Description: PGP signature
QT4 applications not receiving clicks
Hi, I'm looking at a WINE issue in which some QT-based software isn't getting mouse clicks. The program in question is a VST plug-in. The plug-in, in our host, creates its UI in a child window. Now, in QT, HWNDs are created several layers deep-- seemingly one HWND per widget (QWidget), and then a few others like "QEventDispatcher". I think in doing this, I may have uncovered a bug in which grandchild HWNDs do not receive mouse-down events. To summarize before I dive into the details: On these mouse-down events, WINE attempts to bring the HWND to the front, but fails because the HWND in question is not a top-level window or a top-level window's child and subsequently eats the message. Now for the gory details. Let's start at process_mouse_messages in user32/message.c. If the event in question is a button-down event, WINE tries to activate the window it's for. In the switch statement near the bottom of the function, there is a case MA_ACTIVATE. This calls FOCUS_MouseActivate which in turn calls set_foreground_window (both in user32/focus.c). Jump to the wineserver's set_foreground_window function (in server/queue.c). There is a line which reads: if (is_top_level_window( req->handle ) && . . . ) What this is_top_level_window function says (in server/window.c) is to return true only if the HWND is_desktop_window or a child of the desktop window. is_desktop_window says to return true if there is no parent (because "only desktop windows have no parent"). So, if the HWND has no parent or is the parent of a window with no parent, WINE deems the window top level and the HWND receives the click. If this test fails, set_foreground_window returns an error and causes process_mouse_messages to eat the click instead of passing it on. So, I have a couple questions about WINE operation. My first question is whether the click really should be passed on even if WINE can't bring the HWND to the front in this case. My second question is whether the top-level window test works as expected-- my instinct was that the top-level window is just a window without a parent and that the check might not need to involve the desktop. Thanks, Louis Gorenfeld Muse Research
Re: Fix wine-bugs mailing list traffic message.
It's not hundreds / day (as it's been the past few days due to the CVS/GIT cleanup), but it's definitely not 10/day either. I would say 60-70 per day is common, but I don't run statistics (nor try to). On Tue, Jan 20, 2009 at 5:26 PM, Francois Gouget wrote: > On Tue, 20 Jan 2009, Christoph Korn wrote: > >> Only a small fix. >> >> I subscribed to the wine-bugs mailing list because it was listed as >> medium traffic. But I got hundreds of mails in about two hours or so. > > Usually it's a medium traffic mailing list (I believe), but occasionally > (2/3 times a year) someone does a big cleanup touching hundreds of bugs > and that's when you get a lot of emails... > > -- > Francois Gouget http://fgouget.free.fr/ > If it stinks, it's chemistry. If it moves, it's biology. > If it does not work, It's computer science. > > > -- J. Leclanche Adys
Re: shell32: initial stub for SHGetImageList
Aric Stewart wrote: > While early versions of shell32 in XP this is true, in later versions > of XP's shell32 and in Vista this api is accessible by name. > > How should we do that then? > > -aric > > Nikolay Sivov wrote: >> Aric Stewart wrote: >>> --- >>> dlls/shell32/shell32.spec |1 + >>> dlls/shell32/shellord.c |6 ++ >>> 2 files changed, 7 insertions(+), 0 deletions(-) >>> >>> >>> >>> >>> >>> >> Should be -noname. >> >> > Yes, checking PSDK 6.1 it's in shell32.lib. If so it's correct, sorry for noise.
Re: shell32: initial stub for SHGetImageList
While early versions of shell32 in XP this is true, in later versions of XP's shell32 and in Vista this api is accessible by name. How should we do that then? -aric Nikolay Sivov wrote: > Aric Stewart wrote: >> --- >> dlls/shell32/shell32.spec |1 + >> dlls/shell32/shellord.c |6 ++ >> 2 files changed, 7 insertions(+), 0 deletions(-) >> >> >> >> >> > Should be -noname. > >
Re: Today's git does not compile
On Tue, Jan 20, 2009 at 9:10 AM, Susan Cragin wrote: > At least, it doesn't for me... > > O2 -o wowthunk.o wowthunk.c > ../../tools/winebuild/winebuild -D_REENTRANT -fPIC --as-cmd "as" -o > relay16asm.o --relay16 > ../../tools/wmc/wmc -i -U -H /dev/null -o nls/winerr_deu.mc.rc > nls/winerr_deu.mc > ../../tools/wmc/wmc -i -U -H /dev/null -o nls/winerr_enu.mc.rc > nls/winerr_enu.mc > ../../tools/wmc/wmc -i -U -H /dev/null -o nls/winerr_fra.mc.rc > nls/winerr_fra.mc > ../../tools/wmc/wmc -i -U -H /dev/null -o nls/winerr_kor.mc.rc > nls/winerr_kor.mc > ../../tools/wmc/wmc -i -U -H /dev/null -o nls/winerr_nor.mc.rc > nls/winerr_nor.mc > ../../tools/wrc/wrc --nostdinc -I. -I. -I../../include -I../../include > -D__WINESRC__ -D_KERNEL32_ -fokernel.res kernel.rc > Source: �̤� a2 cc a4 eb > Unicode: 5341 6708 > Back: �Q�� a4 51 a4 eb > nls/cht.nls:84:16: Error: String �̤� does not convert identically to Unicode > and back in codepage 950. Try using a Unicode string instead > make[2]: *** [kernel.res] Error 1 > make[2]: Leaving directory `/home/susan/wine/dlls/kernel32' > make[1]: *** [kernel32] Error 2 > make[1]: Leaving directory `/home/susan/wine/dlls' > make: *** [dlls] Error 2 > su...@ubuntu:~/wine$ > > > > > > Looks like Alexandre already committed a fix: http://source.winehq.org/git/wine.git/?a=commitdiff;h=6d0a0fb1820d80cd2b3fd643973329561848e8c1 -- -Austin
Re: shell32: initial stub for SHGetImageList
Aric Stewart wrote: > --- > dlls/shell32/shell32.spec |1 + > dlls/shell32/shellord.c |6 ++ > 2 files changed, 7 insertions(+), 0 deletions(-) > > > > > Should be -noname.
Re: Fix wine-bugs mailing list traffic message.
On Tue, 20 Jan 2009, Christoph Korn wrote: > Only a small fix. > > I subscribed to the wine-bugs mailing list because it was listed as > medium traffic. But I got hundreds of mails in about two hours or so. Usually it's a medium traffic mailing list (I believe), but occasionally (2/3 times a year) someone does a big cleanup touching hundreds of bugs and that's when you get a lot of emails... -- Francois Gouget http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.
CVS/GIT removal
All CVS/GIT versions have been moved. Whoever's got bugzilla admin privileges, please delete that version. -- -Austin
Today's git does not compile
At least, it doesn't for me... O2 -o wowthunk.o wowthunk.c ../../tools/winebuild/winebuild -D_REENTRANT -fPIC --as-cmd "as" -o relay16asm.o --relay16 ../../tools/wmc/wmc -i -U -H /dev/null -o nls/winerr_deu.mc.rc nls/winerr_deu.mc ../../tools/wmc/wmc -i -U -H /dev/null -o nls/winerr_enu.mc.rc nls/winerr_enu.mc ../../tools/wmc/wmc -i -U -H /dev/null -o nls/winerr_fra.mc.rc nls/winerr_fra.mc ../../tools/wmc/wmc -i -U -H /dev/null -o nls/winerr_kor.mc.rc nls/winerr_kor.mc ../../tools/wmc/wmc -i -U -H /dev/null -o nls/winerr_nor.mc.rc nls/winerr_nor.mc ../../tools/wrc/wrc --nostdinc -I. -I. -I../../include -I../../include -D__WINESRC__ -D_KERNEL32_ -fokernel.res kernel.rc Source: �̤� a2 cc a4 eb Unicode: 5341 6708 Back: �Q�� a4 51 a4 eb nls/cht.nls:84:16: Error: String �̤� does not convert identically to Unicode and back in codepage 950. Try using a Unicode string instead make[2]: *** [kernel.res] Error 1 make[2]: Leaving directory `/home/susan/wine/dlls/kernel32' make[1]: *** [kernel32] Error 2 make[1]: Leaving directory `/home/susan/wine/dlls' make: *** [dlls] Error 2 su...@ubuntu:~/wine$
Re: wineg++ compile error
2009/1/21 Rino Farina : > I'm not sure what you mean by PE .exe, though PE is Microsoft's standard executable format for Windows programs, in contrast to ELF, which is the standard Linux executable format.
Re: wineg++ compile error
Right, I wasn't able to find iostream among the available headers (remember, I'm not linking yet). Stefan, are you suggesting that I install microsofts tool-chain and compile the code with the ms compiler? Sounds reasonable. I'm not sure what you mean by PE .exe, though. I have no need to link to Linux libraries, other than this is a pure windows codebase and some of the libraries referenced are not available in winelib/msvcrt. Thanks, Rino On Mon, Jan 19, 2009 at 11:37 PM, Damjan Jovanovic wrote: > On Tue, Jan 20, 2009 at 2:23 AM, Stefan Dösinger > wrote: >>> Yeah, it looks like there's some conflict with iostream and msvcrt: >>> http://www.mail-archive.com/wine-devel@winehq.org/msg08834.html >>> >>> I'm trying to follow the recommendations, but without much luck. >> Maybe try to use the iostream implementation from msvcrt(not sure how to do >> that, though - I never used winelib myself) >> >> Is there any reason why you have to compile the app using winelib? Unless >> you want to link against Linux libraries in your app there is no advantage >> over compiling the application as a PE .exe file(same performance, same >> runtime requirements etc). If you compile it as native .exe you avoid all >> the issues where Linux headers collide with Windows headers. >> > > I thought that Wine's msvcrt didn't have any iostreams yet (#11910, #6457)? > > Damjan > > >
Support of native Windows drivers for USB tokens
On Tuesday 07 October 2008 15:02:23 Alexandre Julliard wrote: > Your design needs a lot more thought. You can't add all these > Wine-specific modules, or make winedevice special-case usb devices, or > poll the server for the add_device request like you do. All this needs > to be properly integrated in the existing infrastructure. I made big changes in the design since previous version. Now there are no new wine-specific modules and wineserver is not used for calling AddDevice. All drivers are running in a single winedevice process. ftp://ftp.etersoft.ru/pub/people/amorozov/0001-Add-support-of-native-Windows-drivers-for-USB-tokens.txt ftp://ftp.etersoft.ru/pub/people/amorozov/0002-Re-generate-some-files.txt Second patch was generated with tools/make_requests && autoheader After applying these patches should run tools/make_makefiles. For using native USB driver should copy HKLM\System\CurrentControlSet\Enum\USB\Vid_&Pid_ and HKLM\System\CurrentControlSet\Services\ from Windows registry. The driver should be put in the directory specified by HKLM\System\CurrentControlSet\Services\\ImagePath. Also you need to have permissions to read/write to USB device.
Re: How to distinct different behavior of IE versions
On Tuesday 20 January 2009 01:53:27 Thomas Heckel wrote: > The relevant test case "static void test_HttpSendRequestW(int port)" > checked in 3 days ago from Hans Leidekker as commit > 667e48286e25c56bca98a135db62d723b74ef89e looks for the HTTP header > "UA-CPU: x86". But this string is only supported from IE 7 up. It makes > sense that this test has to fail on machines with no IE 7+ installed. > > But how to tackle such things in a test case? Take care of different > windows versions is used in various test cases. Can the IE version be > found out with a similar mechanism? Or should a test case just ignore > such nuances from internet explorer? Just try different headers until you find one that works for both IE6 and IE7. -Hans
Re: How to distinct different behavior of IE versions
2009/1/20 Thomas Heckel : > Hi, > > I'm new to the wine development and interested in some bug hunting to > gain better compatibility on windows. Just for starts I looked a little > bit onto test.winehq.org and there especially why wininet:http was > passing on some windows systems and on some failing with > "http.c:1837: Test failed: got 12150 expected ERROR_IO_PENDING". > 12150 is defined in include/winhttp.h as ERROR_WINHTTP_HEADER_NOT_FOUND. > > The occurence is dependent on the version of the wininet.dll. If it is > 6.xxx the test fails. If the dll is 7.xxx the test passes. > > The relevant test case "static void test_HttpSendRequestW(int port)" > checked in 3 days ago from Hans Leidekker as commit > 667e48286e25c56bca98a135db62d723b74ef89e looks for the HTTP header > "UA-CPU: x86". But this string is only supported from IE 7 up. It makes > sense that this test has to fail on machines with no IE 7+ installed. > > But how to tackle such things in a test case? Take care of different > windows versions is used in various test cases. Can the IE version be > found out with a similar mechanism? Or should a test case just ignore > such nuances from internet explorer? In this case (as the test is not requiring that specific header), you can choose a different header that satisfies the requirement of the test that works with the different versions of IE. Alternatively, if this behaviour is on >= IE7, you could check for the ERROR_WINHTTP_HEADER_NOT_FOUND return and issue a wine_skip (there are examples of this in other tests). - Reece
How to distinct different behavior of IE versions
Hi, I'm new to the wine development and interested in some bug hunting to gain better compatibility on windows. Just for starts I looked a little bit onto test.winehq.org and there especially why wininet:http was passing on some windows systems and on some failing with "http.c:1837: Test failed: got 12150 expected ERROR_IO_PENDING". 12150 is defined in include/winhttp.h as ERROR_WINHTTP_HEADER_NOT_FOUND. The occurence is dependent on the version of the wininet.dll. If it is 6.xxx the test fails. If the dll is 7.xxx the test passes. The relevant test case "static void test_HttpSendRequestW(int port)" checked in 3 days ago from Hans Leidekker as commit 667e48286e25c56bca98a135db62d723b74ef89e looks for the HTTP header "UA-CPU: x86". But this string is only supported from IE 7 up. It makes sense that this test has to fail on machines with no IE 7+ installed. But how to tackle such things in a test case? Take care of different windows versions is used in various test cases. Can the IE version be found out with a similar mechanism? Or should a test case just ignore such nuances from internet explorer? Thanks in advance Thomas
