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

Re: New winetricks-alpha 20110306: new game Crysis 2 Demo and seven others, new dll dinput, lots of bug fixes; ie8 now works

by Vitaliy Margolen

On 03/06/2011 10:53 PM, Dan Kegel wrote: > Do you think people just load dlls at random, and then complain when they > break things? Reading forum indicates lots do. Most people still think that if they use more native dlls Wine will work better. > You may have a point there, but increasingly, users don't > play around with individual DLLs, they expect canned recipes for whole games, > so maybe fewer people will try it than you think. That's why users use windows. They still think it can do everything as-is... > Would it help if I put a warning on the verb? I think it's a good idea to warn them about consequences of using native dinput. > Or do you think that having it at all is a bad idea? If so, > you probably think that about a lot of winetricks verbs. Not really. If users want to experiment with stuff - it's up to them. Wine is OSS after all. If some one wants to shoot themselves in a foot we can show 100 different ways to do it. But they still have to pull the trigger. > Are there others in particular that you have seen cause grief? Mostly complete DX. Users install that and expect Wine to have flawless d3d, including Intel/ATI GPUs. Vitaliy

March 7, 2011

Re: [1/5] msi/tests: Check the result of get_system_dirs and get_user_dirs.

by Marvin

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=9724 Your paranoid android. === WNT4WSSP6 (32 bit install) === install.c:5967: Test failed: Per-user icon file isn't where it's expected (C:\WINNT\Profiles\Default User\Application Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)

March 7, 2011

Re: [PATCH] NTDLL atom.c documentation.

by Max TenEyck Woodbury

On 03/06/2011 02:45 PM, Nikolay Sivov wrote: > > What's a point to make such changes in a first place? I don't see how > it's useful to have automatically extracted partially filled function > names from sources (if it's a purpose of these documentation headers of > course). You always have sources, everything that might be useful for > development is in as code or comments for not-so-obvious parts. > > What is really helpful for documenting behaviour that isn't documented > officially is writing test cases to show bugs or to prevent regressions. What are you saying? I can't quite figure out your point. There were no summaries for these functions before, mostly for technical reasons, and this particular set is _not_ documented by Microsoft. Juan Lang's point was about the quality of the source I was using to check on the absence of documentation. I'm not sure that the limited use I was making of that source would have the impact predicted, but I'm willing to use another source if there is one available. Your comments don't address that issue. There are already test cases that define what the functions do, so that is not the issue here. What is not currently being tested is the behavior of the Microsoft code when it is being abused. In particular, I see where passing pointers that cause faults can create problems and have noted those places. Someone needs to look at those notes and decide if they represent things that need testing. I suspect that they represent very low priority issues. I am noting where tests do and do not exist for particular entry points, so that can't be your point. I've been reading other peoples code for _decades_. This particular set of code is fairly clear with only a few arcane points, mostly to do with 'integral' atoms. The notes I've added bring out this issue somewhat more strongly than the code does. That should provide a clue to why some of the minor twists in the code are there. Maybe I'll see your point in the morning... Max

March 7, 2011

Re: New winetricks-alpha 20110306: new game Crysis 2 Demo and seven others, new dll dinput, lots of bug fixes; ie8 now works

by Dan Kegel

On Sun, Mar 6, 2011 at 9:47 PM, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > On 03/06/2011 10:36 PM, Dan Kegel wrote: >> Why, do you think adding it was a mistake? > > Because native dinput can only fix 1-2 open bugs, but break lots more: > - No mouse warping (as already mentioned) > - No joystick support It'll only break things if people use it, and I don't expect them to use it unless they're playing the one or two games that need it. Do you think people just load dlls at random, and then complain when they break things? You may have a point there, but increasingly, users don't play around with individual DLLs, they expect canned recipes for whole games, so maybe fewer people will try it than you think. Would it help if I put a warning on the verb? Or do you think that having it at all is a bad idea? If so, you probably think that about a lot of winetricks verbs. Are there others in particular that you have seen cause grief? - Dan

March 7, 2011

Re: New winetricks-alpha 20110306: new game Crysis 2 Demo and seven others, new dll dinput, lots of bug fixes; ie8 now works

by Vitaliy Margolen

On 03/06/2011 10:36 PM, Dan Kegel wrote: > Why, do you think adding it was a mistake? Because native dinput can only fix 1-2 open bugs, but break lots more: - No mouse warping (as already mentioned) - No joystick support Vitaliy.

March 7, 2011

Re: New winetricks-alpha 20110306: new game Crysis 2 Demo and seven others, new dll dinput, lots of bug fixes; ie8 now works

by Dan Kegel

On Sun, Mar 6, 2011 at 9:27 PM, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > On 03/06/2011 09:58 PM, Dan Kegel wrote: >> >> dinput: new verb by Shannon, for winehq bug 21159 > > You realize that most games that don't have bug 6971 (and don't warp mouse > themselves) will have it with native dinput? I don't expect that verb to get used much, but it was needed for Rayman 2, http://bugs.winehq.org/show_bug.cgi?id=21159 (That game doesn't use the mouse.) Why, do you think adding it was a mistake? - Dan

March 7, 2011

Re: New winetricks-alpha 20110306: new game Crysis 2 Demo and seven others, new dll dinput, lots of bug fixes; ie8 now works

by Vitaliy Margolen

On 03/06/2011 09:58 PM, Dan Kegel wrote: > dinput: new verb by Shannon, for winehq bug 21159 You realize that most games that don't have bug 6971 (and don't warp mouse themselves) will have it with native dinput? Vitaliy.

March 7, 2011

New winetricks-alpha 20110306: new game Crysis 2 Demo and seven others, new dll dinput, lots of bug fixes; ie8 now works

by Dan Kegel

Another fortnight, another Winetricks. Version 20110306-alpha has a slightly cleaned up gui, a handful of bugfixes and sha1sum updates, eight new games (crysis2_demo_mp, diablo2, dragonage, masseffect2_demo, penpenxmas, rayman2_demo, sammax301_demo, and secondlife), one new dll (dinput), and one new setting (vd=640x480). It removes ie68, which is no longer needed, now that ie8 works. It isolates all apps in their own wineprefix by default now, not just games. The option --isolate-games is gone, and a new option --no-isolate was added. And finally, it's not quite as slow at putting up menus. Also, there's some real doc at http://winetricks.org for end users as well as for developers. Download url: http://winetricks.org/winetricks-alpha svn repository / bug tracker: http://winetricks.org Changes since 20110222: Update disk space & time install requirements diablo2: waiting for updater window isn't enough, you have to wait for it to say it's finished! Cope with empty USERNAME, which happens when using startx. hegemony_gold: updated sha1sum Added 'folder' verb to open current wineprefix with xdg-open Show title of installed app rather than absolute path in comment at top, give example of how to install all prereqs firefox: update to 3.6.15, fix system menu. corefonts: Trebuc filenames have mixed case. Fixes bug winezeug-203. Install apps and benchmarks into their own prefixes, too. Show prefix name uniformly in window title. Move ie to dlls, call dlls 'Windows dlls or components'. Add option --no-isolate-games, make --isolate-games the default annihilate: actually ask permission before annihilating the wineprefix. gta_vc: ported, updated. Better fix for bug winezeug-25, should fix new bug winezeug-229 w_download: fix progress indicator gui for locales that use , as a decimal separator. Pointed out by kmiksi. Fixes bug winezeug-232. Add a paragraph at the top about what tools this script uses. Cleaned up comments at top. Moved version ID to very top. vc2005trial: update workarounds for wine-1.3.15 Last changeset was missing wildcards on two patterns Speed up common case of w_pathconv -u 3x by writing it in shell. Suggestion by Christian Storgaard. rayman2_demo: new verb. Based on a patch by Shannon. Make --optout take effect earlier. winetricks_stats_init: always quote W_CACHE dinput: new verb by Shannon, for winehq bug 21159 vd=640x480: new verb, by Shannon diablo2: ported and updated. (Next up: diablo2bc, battle chest version.) crysis2_demo_mp: fix non-q mode, use SetWinDelay to simplify. Patch by Phil. W_CACHE_WIN should just be a drive letter and colon in wine penpenxmas: new verb (based on a patch by Manpreet Sangha) crysis2_demo_mp: new verb by Austin sammax301_demo: new verb by Phil secondlife: ported and updated w_download: autohotkey's download server doesn't like curl's user agent, so use a more common one masseffect2_demo: partly fix windows install. (Clicks still not working.) w_mount: Port support for windows mounts of iso volumes. winetricks_read_volume_name: hexdump is not portable, use od instead w_read_key: create directory before storing key sims3: update to latest version, mention drm problem as showstopper masseffect2: mark as broken drm. masseffect2, masseffect2_demo: move workaround descriptions into w_workaround arg. masseffect2_demo: port verb firefox4: updated to beta12 dragonage: ported verb. Flickers terribly in movies for me :-( osmos_demo: bug 24416 fixed in 1.3.8 w_warn: in -q mode, time out after 5 seconds. Get rid of debug print. sims3: if we want menus to work, we have to install dotnet20. Move sudo detect after gui detect; fixes running winetricks-alpha from system menu ie68: no longer needed, now that ie8 works w_warn: text passed to zenity must be escaped ie8: make -q not fail install test. Fix --gui option, which was ignored because variable was reset after option was processed winetricks_set_wineprefix: Comment out debug print annihilate: only delete .desktop files. Use localized name for Desktop directory. Move silent option to top level menu ie8: set TabProcGrowth=0 to avoid hang. Fixes winezeug bug 159. Thanks to MatthiasLichter. Fix running on cygwin (W_DRIVE_C was wrong)

March 7, 2011

Re: d3dcompiler_41: reflection interface.

by Rico Schüller

Am 04.03.2011 12:39, schrieb Alexandre Julliard: > Rico Schüller<kgbricola(a)web.de> writes: > >> DEFINE_GUID is used twice (dlls/dxguid/dx10guid.c and >> dlls/d3dcompiler_41/reflection.c) which could be bad. But the define >> was removed from the d3d11shader.h from ms, so it isn't officially >> available anymore. Should that be in a separate header to reduce >> redundancy or is the usage of both defines fine here? > There's no reason to have it in dxguid. > Ah ok, I got a linker error, but a #include "initguid.h" fixed it. So the problem is solved. Thanks for the hint. The reflection 11 (version 41) isn't available in the native dxguid.lib, so it has nothing to do there. Cheers Rico

March 6, 2011

Re: [PATCH] NTDLL atom.c documentation.

by Nikolay Sivov

On 3/6/2011 22:34, Max TenEyck Woodbury wrote: > On 03/06/2011 10:34 AM, Juan Lang wrote: >> Hi Max, >> + * >> http://www.geoffchappell.com/studies/windows/win32/ntdll/history/names40.htm >> >> Please don't link to his site. As I said in an unrelated message to >> wine-patches last week, he used disassembly when performing his >> analysis: >> http://www.geoffchappell.com/viewer.htm?doc=notes/index.htm >> >> I wouldn't want to endorse such an effort implicitly by linking to >> him: future Wine developers could be misled. >> >> Thanks, >> --Juan >> > The list of entry point names and the version history is all I am > interested in and I believe that does not require disassembly, but if > you can point me at another source for that information, I will be > glad to use that instead. What's a point to make such changes in a first place? I don't see how it's useful to have automatically extracted partially filled function names from sources (if it's a purpose of these documentation headers of course). You always have sources, everything that might be useful for development is in as code or comments for not-so-obvious parts. What is really helpful for documenting behaviour that isn't documented officially is writing test cases to show bugs or to prevent regressions. > Max >

March 6, 2011

Re: [PATCH] NTDLL atom.c documentation.

by Max TenEyck Woodbury

On 03/06/2011 10:34 AM, Juan Lang wrote: > Hi Max, > + * http://www.geoffchappell.com/studies/windows/win32/ntdll/history/names40.htm > > Please don't link to his site. As I said in an unrelated message to > wine-patches last week, he used disassembly when performing his > analysis: > http://www.geoffchappell.com/viewer.htm?doc=notes/index.htm > > I wouldn't want to endorse such an effort implicitly by linking to > him: future Wine developers could be misled. > > Thanks, > --Juan > The list of entry point names and the version history is all I am interested in and I believe that does not require disassembly, but if you can point me at another source for that information, I will be glad to use that instead. Max

March 6, 2011

Re: [PATCH] NTDLL atom.c documentation.

by Juan Lang

Hi Max, + * http://www.geoffchappell.com/studies/windows/win32/ntdll/history/names40.htm Please don't link to his site. As I said in an unrelated message to wine-patches last week, he used disassembly when performing his analysis: http://www.geoffchappell.com/viewer.htm?doc=notes/index.htm I wouldn't want to endorse such an effort implicitly by linking to him: future Wine developers could be misled. Thanks, --Juan

March 6, 2011

Re: d3dx9_36 [patch 2/3, resend]: Add tests for D3DXcreateTeapot

by Marvin

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=9720 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

March 6, 2011

Re: d3dx9_36 [patch 1/3, resend]: Add tests for D3DXCreateBox

by Marvin

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=9719 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

March 6, 2011

Re: USB Osciloscope

by James McKenzie

On 3/1/11 5:09 PM, Archie Robertson wrote: > I have a USB osciloscope (Link Instruments DSO 8002) that I am quite > motivated to get working in wine. I have followed the instructions to > install the USB patches. The osciloscope software works fine in demo > mode, but it still cannot find the device. I have spent some time > messing around with this, but I am new to wine, so I am a little lost. > I am a half decent c programmer, so If somebody could point me in the > right direction I should be able to get this working. > There is a page on USB support on the Wine Wiki. Please feel free to read through it. Note that the last time I tried to get to the page with the USB patches, it was not available. Others here have expressed their willingness to improve USB non-storage device support. This has been a tough problem to solve. James McKenzie

March 6, 2011

Re: urlmon/tests: Add a '\n' to an ok() call.

by Marvin

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=9680 Your paranoid android. === WVISTAADM (32 bit url) === url.c:1535: Test failed: unexpected call OnProgress_SENDINGREQUEST

March 5, 2011

Re: olefont - fixed initial cyLogical value in IFont constructor. fixed get_Size to return same value as Window. (try 2)

by Marvin

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=9673 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

March 5, 2011

re: WineHQ Bug 26271

by Dan Kegel

Dmitry Timoshkov wrote: > Are you going to encourage packagers to include whatever patches > they deem to be "an important feature" for the users, and still claim > that provide an official Wine binary package? There's a middle ground: ship both vanilla and patched wine, and make vanilla the default. I can even imagine distros packaging them up so they can both be installed at the same time. For instance, vanilla wine might be /usr/bin/wine as usual, but one patched for bug 6971 might be /usr/libexec/wine/wine-1.3-hotfix-6971/bin/wine. The patched one would be buried (kind of like gcc's internal files are buried) so they're easy for frontends like winetricks to use when present, but hard for casual users to accidentally use. Bug 6971 is the only one that comes to mind immediately as worth the effort, as it makes many games unplayable ( http://appdb.winehq.org/viewbugs.php?bug_id=6971 ). It occurs to me that fixing or providing a hotfix for this one bug, would get rid of most of PlayOnLinux's incentive to provide their own patched builds of wine. - Dan

March 4, 2011

Re: ws2_32: sendmsg on OS/X and BSD returns EMSGSIZE error for size 0

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > Looks like WS2_ConnectEx is at fault. > > It is being called with a sendBuf of NULL which results in n_iovecs > and first_iovec being set to 0 resulting in a len of 0. Most likely it shouldn't be trying to send anything in that case. -- Alexandre Julliard julliard(a)winehq.org

March 4, 2011

Re: ws2_32: sendmsg on OS/X and BSD returns EMSGSIZE error for size 0

by Aric Stewart

Looks like WS2_ConnectEx is at fault. It is being called with a sendBuf of NULL which results in n_iovecs and first_iovec being set to 0 resulting in a len of 0. I see no evidence of checking for this case along that codepath. -aric On 3/4/11 10:47 AM, Alexandre Julliard wrote: > Aric Stewart<aric(a)codeweavers.com> writes: > >> @@ -1781,6 +1781,9 @@ static int WS2_send( int fd, struct ws2_async *wsa ) >> wsa->iovec[wsa->first_iovec].iov_len -= n; >> } >> } >> + /* BSD and OS/X return EMSGSIZE if hdr.msg_iovlen is 0 */ >> + else if ( hdr.msg_iovlen == 0&& errno == EMSGSIZE) >> + ret = 0; > > This should never happen. We should always have at least one iov at that > point, the callers should make sure of that. >

March 4, 2011

Re: ws2_32: sendmsg on OS/X and BSD returns EMSGSIZE error for size 0

by Aric Stewart

I was seeing this coming through WS2_async_send. I will investigate and give you a better code path that is resulting in this. -aric On 3/4/11 10:47 AM, Alexandre Julliard wrote: > Aric Stewart<aric(a)codeweavers.com> writes: > >> @@ -1781,6 +1781,9 @@ static int WS2_send( int fd, struct ws2_async *wsa ) >> wsa->iovec[wsa->first_iovec].iov_len -= n; >> } >> } >> + /* BSD and OS/X return EMSGSIZE if hdr.msg_iovlen is 0 */ >> + else if ( hdr.msg_iovlen == 0&& errno == EMSGSIZE) >> + ret = 0; > > This should never happen. We should always have at least one iov at that > point, the callers should make sure of that. >

March 4, 2011

Re: ws2_32: sendmsg on OS/X and BSD returns EMSGSIZE error for size 0

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -1781,6 +1781,9 @@ static int WS2_send( int fd, struct ws2_async *wsa ) > wsa->iovec[wsa->first_iovec].iov_len -= n; > } > } > + /* BSD and OS/X return EMSGSIZE if hdr.msg_iovlen is 0 */ > + else if ( hdr.msg_iovlen == 0 && errno == EMSGSIZE) > + ret = 0; This should never happen. We should always have at least one iov at that point, the callers should make sure of that. -- Alexandre Julliard julliard(a)winehq.org

March 4, 2011

Re: wininet(5/6): Obey cache directives and flags regarding caching

by Alexandre Julliard

Juan Lang <juan.lang(a)gmail.com> writes: > From 13fce7b5e1efa74219d334bbce6661bd49a00601 Mon Sep 17 00:00:00 2001 > From: Juan Lang <juan.lang(a)gmail.com> > Date: Wed, 2 Mar 2011 10:41:12 -0800 > Subject: [PATCH 08/19] Obey cache directives and flags regarding caching It fails here: ../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p urlmon_test.exe.so protocol.c && touch protocol.ok protocol.c:661: Test failed: expected ReportProgress_CACHEFILENAMEAVAILABLE Also the url.c test hangs forever. -- Alexandre Julliard julliard(a)winehq.org

March 4, 2011

Re: d3dcompiler_41: reflection interface.

by Alexandre Julliard

Rico Schüller <kgbricola(a)web.de> writes: > DEFINE_GUID is used twice (dlls/dxguid/dx10guid.c and > dlls/d3dcompiler_41/reflection.c) which could be bad. But the define > was removed from the d3d11shader.h from ms, so it isn't officially > available anymore. Should that be in a separate header to reduce > redundancy or is the usage of both defines fine here? There's no reason to have it in dxguid. -- Alexandre Julliard julliard(a)winehq.org

March 4, 2011

Re: wininet: Implement FindNextUrlCacheEntryW

by Alexandre Julliard

Juan Lang <juan.lang(a)gmail.com> writes: > Brought to you by copy and paste. There's no reason to duplicate all that code. -- Alexandre Julliard julliard(a)winehq.org

March 4, 2011