September 2010 - Wine-Devel

Re: [setupapi] added tests of SetupDiGetINFClassA
by testbot＠testbot.winehq.org Sept. 4, 2010

Sept. 4, 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=5023 Your paranoid android. === WNT4WSSP6 (32 bit devinst) === No test summary line found === W2K3R2SESP2 (32 bit devinst) === devinst.c:1465: Test failed: expected error ERROR_INSUFFICIENT_BUFFER, got 87 === WVISTAADM (32 bit devinst) === devinst.c:1465: Test failed: expected error ERROR_INSUFFICIENT_BUFFER, got 87 === W2K8SE (32 bit devinst) === devinst.c:1465: Test failed: expected error ERROR_INSUFFICIENT_BUFFER, got 87 === W7PRO (32 bit devinst) === devinst.c:1465: Test failed: expected error ERROR_INSUFFICIENT_BUFFER, got 87 devinst.c:1476: Test failed: expected error RPC_S_INVALID_STRING_UUID, got 87 === W7PROX64 (32 bit devinst) === devinst.c:1465: Test failed: expected error ERROR_INSUFFICIENT_BUFFER, got 87 devinst.c:1476: Test failed: expected error RPC_S_INVALID_STRING_UUID, got 87 === W7PROX64 (64 bit devinst) === devinst.c:1465: Test failed: expected error ERROR_INSUFFICIENT_BUFFER, got 87 devinst.c:1476: Test failed: expected error RPC_S_INVALID_STRING_UUID, got 87

1 0

Wine Introduction Page
by James McKenzie Sept. 4, 2010

Sept. 4, 2010

I was just going over this page and found a few things that I don't know about but have questions on for building Wine on the Mac: The lowest MacOSX version that Wine will build on from the native package is stated to be 10.4 (Tiger). Is this still true? The lowest XCode required is 2.4. Apple stopped supporting this a long time ago. I had XCode 2.5 for Tiger. Can anyone update these? James McKenzie

2 1

Wine Gecko 1.1.0 RC1
by Jacek Caban Sept. 4, 2010

Sept. 4, 2010

HI all, (If you're not interested in details, please read the last paragraph). It's been over year since the last Gecko update. A lot has happen since then. I've been planning to update our build a bit later, with Firefox 4 codebase, but plans have changed. We had some serious problems with previous build (like bug 22157 and bug 24059, both should be fixed in the new build). Also there is *a lot* happening in Mozilla world. With upcoming Firefox 4, the backward compatibility is no longer supported and the code is changing with an impressive speed. I try to follow these changes, but I need a good solid base so that I can take care of our needs in Mozilla. This build is based on Firefox 4 beta 4 (that is expected to be released this week). It goes with massive improvements, but it's less interesting here. We finally have sane building procedure. Thanks to mingw-w64 project, we no longer have to maintain our own fixes to headers and libraries. Also I've fixed a bug so that moztools is no longer needed for crosscompiling. It means that we no longer need any binary files, which should make open source fanatics (in a good sense) happy. Well... almost. We still need to create .cab file, which I do via Filzip on Windows. That's something we can work around. We use .cab files, because that's the only archive format that Wine can deal with. We can teach Wine to use other formats, which would finally make it possible for Wine packagers to do their own builds, if they like. The new Gecko is also the first to support Win64. Not all tests pass yet, but failing ones are due to missing DispCallFunc implementation for Win64, so it's not a Gecko problem. It's not yet fully tested and I need help with this. I'd appreciate any help with testing. Almost all changes required by the new Gecko were possible to be committed to current Wine. The attached patch contains remaining bits. All you need to test it is current Wine Git (must be today's or later), the attached patch and a new Gecko build. You can find new builds [1] and win64 build [2]. Put .cab files according to generic instructions [3] (obviously with different file names due to different Gecko versions). Please let me know of any regressions. Thanks, Jacek [1] http://gerwazy.lo3.wroc.pl/~jcaban/wine_gecko-1.1.0-rc1-x86.cab [2] http://gerwazy.lo3.wroc.pl/~jcaban/wine_gecko-1.1.0-rc1-x86_64.cab [3] http://wiki.winehq.org/Gecko

4 7

New winetricks 20100904: lots of little fixes. New verbs comdlg32.ocx, vcrun2010
by Dan Kegel Sept. 4, 2010

Sept. 4, 2010

Another fortnight, another Winetricks. Online as always at http://kegel.com/wine/winetricks or http://winezeug.googlecode.com (Bug reports to the issue tracker at the above URL, please.) Winetrickstest really paid off this time... it caught three problems before release. Changes: Dan Kegel: update shockwave sha1sum stop using busted sourceforge mirror revert change that broke dinput8 (unfixed issue 149) use XDG_CACHE_HOME. Fixes issue 124. fix checksum on macosx (thanks to slevytam for logs) add catchall dll-disabling verb, foo=disabled remove fakeie6, it hasn't been needed for a long time. Fred Joseph Ladd: nicer title and text for zenity dialog fix typo, misc string fixes (issue 146) add comdlg32.ocx add vcrun2010 add ISBn for 'Portable Shell Programming'. Austin English: add xapofx as a synonym to xact. (Issue 133) delete .Net registry keys before installing .Net. (Issue 158) remove ancient Mono versions add a synonym for wsh56js (jscript) Andrew Nguyen: add support for new gecko for wine-1.3.2 and up. (Note: gecko-dbg might not be happy yet, it fails winetrickstest.)

1 0

Re: [PATCH 7/7] CMD: Change the parameterization to be correct
by testbot＠testbot.winehq.org Sept. 4, 2010

Sept. 4, 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=5018 Your paranoid android. === WNT4WSSP6 (32 bit) === batch.c:185: Test failed: unexpected char 0x43 position 0 in line 59 (got 'CD:''', wanted 'CD:'@pwd@'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 60 (got 'CD:''', wanted 'CD:'@pwd@\testdir'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 61 (got 'CD end:''', wanted 'CD end:'@pwd@\testdir'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 62 (got 'C:\winetest\testdir', wanted 'CD:'@pwd@'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 63 (got 'CD end:''', wanted 'CD:'@pwd@\testdir'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 64 (got 'C:\winetest\testdir', wanted 'CD end:'@pwd@'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 65 (got 'CD end:''', wanted 'CD:'@pwd@'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 66 (got 'C:\winetest\testdir', wanted 'CD:'@pwd@\testdir'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 67 (got 'CD end:''', wanted 'CD end:'@pwd@'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 68 (got 'C:\winetest\testdir', wanted 'CD:'@pwd@'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 69 (got 'CD end:''', wanted 'CD:'@pwd@\testdir'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 70 (got 'C:\winetest\testdir', wanted 'CD end:'@pwd@'') batch.c:185: Test failed: unexpected char 0x2d position 0 in line 71 (got '-----------Testing parameterization -----------', wanted 'CD:'@pwd@'') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 72 (got 'p1: '1'', wanted 'CD:'@pwd@\testdir'') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 73 (got 'p2: ''', wanted 'CD end:'@pwd@'') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 74 (got 'p3: ''', wanted '-----------Testing parameterization -----------') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 76 (got 'p2: '2'', wanted 'p2: ''') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 80 (got 'p3: '3'', wanted 'p3: ''') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 81 (got 'p1: '"b"'', wanted 'p1: '1'') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 82 (got 'p2: ''', wanted 'p2: '2'') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 83 (got 'p3: ''', wanted 'p3: '3'') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 84 (got 'p1: 'a"b"c'', wanted 'p1: '"b"'') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 87 (got 'p1: '"a"bc'', wanted 'p1: 'a"b"c'') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 90 (got 'p1: 'a'', wanted 'p1: '"a"bc'') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 91 (got 'p2: 'bc'', wanted 'p2: ''') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 93 (got 'p1: '"a=bc d'', wanted 'p1: 'a'') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 94 (got 'p2: ''', wanted 'p2: 'bc'') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 96 (got 'p1: 'a""b'', wanted 'p1: '"a=bc d'') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 99 (got 'p1: 'a'', wanted 'p1: 'a""b'') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 100 (got 'p2: 'b'', wanted 'p2: ''') batch.c:185: Test failed: unexpected char 0x69 position 0 in line 102 (got 'if exist test failed', wanted 'p1: 'a'') batch.c:196: Test failed: unexpected end of output in line 102, missing p2: 'b'

1 0

re: Opinions on priority for an enhancement that Dan suggested some time ago?
by Dan Kegel Sept. 4, 2010

Sept. 4, 2010

Tom Spear wrote: > I believe it would be prudent to have some warning appear when > certain native dll's are missing which required by the app being > run, and which we do not implement builtins for. I suppose a +winediag message might be appropriate for some commonly-needed DLLs. Probably there'd be a table of which DLLs to warn for. Nobody has hooked +winediag up to any flag-the-user system yet, but that's what I had in mind in http://bugs.winehq.org/show_bug.cgi?id=657#c39 I'm more focused on the idea of reducing the need for native DLLs than making it easy to install them. (Um, well, except for winetricks, which seems good enough for the moment.)

1 0

Re: [PATCH 6/7] CMD: Current directory needs saving in the environment even for cmd /c
by testbot＠testbot.winehq.org Sept. 4, 2010

Sept. 4, 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=5017 Your paranoid android. === WNT4WSSP6 (32 bit batch) === batch.c:185: Test failed: unexpected char 0x43 position 0 in line 59 (got 'CD:''', wanted 'CD:'@pwd@'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 60 (got 'CD:''', wanted 'CD:'@pwd@\testdir'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 61 (got 'CD end:''', wanted 'CD end:'@pwd@\testdir'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 62 (got 'C:\winetest\testdir', wanted 'CD:'@pwd@'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 63 (got 'CD end:''', wanted 'CD:'@pwd@\testdir'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 64 (got 'C:\winetest\testdir', wanted 'CD end:'@pwd@'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 65 (got 'CD end:''', wanted 'CD:'@pwd@'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 66 (got 'C:\winetest\testdir', wanted 'CD:'@pwd@\testdir'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 67 (got 'CD end:''', wanted 'CD end:'@pwd@'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 68 (got 'C:\winetest\testdir', wanted 'CD:'@pwd@'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 69 (got 'CD end:''', wanted 'CD:'@pwd@\testdir'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 70 (got 'C:\winetest\testdir', wanted 'CD end:'@pwd@'') batch.c:196: Test failed: unexpected end of output in line 70, missing CD:'@pwd@'

1 0

Re: [PATCH 5/7] CMD: Add support for echo "on"
by testbot＠testbot.winehq.org Sept. 4, 2010

Sept. 4, 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=5016 Your paranoid android. === WNT4WSSP6 (32 bit) === batch.c:188: Test failed: unexpected end of output in line 53, expected 0x30

1 0

Opinions on priority for an enhancement that Dan suggested some time ago?
by Tom Spear Sept. 4, 2010

Sept. 4, 2010

Hi all, so it has been a long time since I have posted here. Much has changed; I now have 3 little ones. :-) Anyways, right to the point: I stumbled on an old bug of mine this evening while doing some long overdue mailbox maintenance. Bug 657: http://bugs.winehq.org/show_bug.cgi?id=657 Dan made a very good point back in 2007 that I believe now is the right time to possibly look at beginning an implementation of: [1] To summarize: Similar to the way that we now have a popup about wine-gecko missing, I believe it would be prudent to have some warning appear when certain native dll's are missing which required by the app being run, and which we do not implement builtins for. Similarly, I feel that it would be prudent for warnings to appear if certain linux shared objects are missing. More to the point is that there are quite a number of DLL's which won't be implemented soon, if ever, but yet we support running wine from the GUI both through shortcuts, and through binfmt_misc, thereby completely bypassing any hope of a user ever seeing some pretty critical errors that may occur. These errors could, if popped up on their screen, prevent a bunch of duplicates from appearing in Bugzilla, because the user can google for the error and be directed directly to a bug which someone else made, as opposed to not seeing anything and having no idea what to try googling for other than "app x does this +wine" As an example on the shared object side, on FC13 x86_64, using the rpm from the yum repo that RH provides, I can install wine, but since there is no RPM dependency currently for OpenAL (i686), I get "no such file/directory" warnings about the OpenAL shared objects when running certain programs (specifically, World of Warcraft and Starcraft II). Now granted the fact that OpenAL is not installed is, debatibly something to take up with the wine packager for RedHat and derivatives; I wanted to point out that with the way wine is at present, if I didn't run wine from a console, I would never have known that, and probably would still not have working sound, because there is nothing that says "Hey! You're missing OpenAL!" I'd like to hear opinions from others about what it might take, time-wise, if someone were to start now, to have something like this implemented. And also what kind of a priority this type of thing should have. Sure it is an enhancement, and so is naturally lower priority than, say a segfault in ntdll, but (imho) it's a pretty critical enhancement that is (again, imho) long overdue. Thoughts? Questions? [1] http://bugs.winehq.org/show_bug.cgi?id=657#c37 Also see comments of his below #37. Thanks Tom

1 0

Re: [PATCH 4/7] CMD: echo command needs to ignore whitespace
by testbot＠testbot.winehq.org Sept. 4, 2010

Sept. 4, 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=5015 Your paranoid android. === WNT4WSSP6 (32 bit) === batch.c:188: Test failed: unexpected end of output in line 51, expected 0x30

1 0

Re: [PATCH 3/7] CMD: cmd /c cannot use argv/argc to walk the arguments
by testbot＠testbot.winehq.org Sept. 4, 2010

Sept. 4, 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=5014 Your paranoid android. === WNT4WSSP6 (32 bit) === batch.c:188: Test failed: unexpected end of output in line 49, expected 0x30

1 0

Re: [PATCH 2/7] CMD: echo.word should echo back the word without the . [bug21130]
by testbot＠testbot.winehq.org Sept. 4, 2010

Sept. 4, 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=5013 Your paranoid android. === WNT4WSSP6 (32 bit) === batch.c:188: Test failed: unexpected end of output in line 49, expected 0x30

1 0

Re: [PATCH 1/7] CMD : Correct support for cmd.exe /C string [bug 21927]
by testbot＠testbot.winehq.org Sept. 4, 2010

Sept. 4, 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=5012 Your paranoid android. === WNT4WSSP6 (32 bit) === batch.c:188: Test failed: unexpected end of output in line 47, expected 0x30

1 0

Please report mcicda (CDROM audio) test results
by Joerg-Cyril.Hoehle＠t-systems.com Sept. 3, 2010

Sept. 3, 2010

Saulius, Saulius Krasuckas wrote: >It would be nice to indicate disks containing tracks of different types >(sessions) in the log and to extract some info from the data track. >Drive info would be also interesting to see in the log. It is on purpose that I did not write too specific info to the log. I don't want logs posted to the Internet to contain (too much) sensitive information, violating your privacy. No CDDB ID. >Then we would know for sure :) As far as MCICDA is concerned, it doesn't look like it knows about multi-sessions. All it offers is to play music. Therefore the mcicda tests is not the right place to look for a disc utility that'll show you information about your drive and disc. >me_s2-clean-updated/winmm:mcicda.html Ah, that's you, good to know. You can help me debug the ME-only errors in winmm:midi midioutXyz returns rc=MMSYSERR_INVALPARAM Paul Vriens found out that the binary he compiled does not produce such errors on WinMe, while testbot's binary does. What about your machine? In testbot job #4990, you'll find a MSVC compiled 150KB binary. Please run the MIDI tests with it on your WinME machine. wintest.exe midi Non-ME output is: midi.c:298: Test failed: no PARAM error, now setting BytesRecorded too large testbot would instead trigger ok(0,"PARAM error, setting BytesRecorded\n"); Thank you, Jörg Höhle

2 1

kernel32: Add tests for SetHandleCount + make tests pass for winversions >WINNT
by Louis Lenders Sept. 3, 2010

Sept. 3, 2010

Hi Juan, >Since we don't have the same limitation in Wine, >applications can call it or not, but it won't have any effect. Hence >maintaining a version-dependent external behavior, while not behaving >differently internally, doesn't make sense to me. Ok, thanks for the info, then i'll just let it return 'count', that should be ok then for apps that use this function (and fixes the bug for Street Fighter). I'll send a new patch tomorrow.

1 0

Script for finding references to stub functions
by Dan Kegel Sept. 3, 2010

Sept. 3, 2010

I threw together a perl script this morning to scan a wineprefix for references to MS dlls. It's at http://code.google.com/p/winezeug/source/browse/trunk/mscodescan.pl It's pretty crufty, but might still be handy. For a working install of Sam and Max episode 304 (with native vcrun80 installed), it outputs Found 24 bundled MS modules: ./windows/winsxs/x86_Microsoft.VC80.OpenMP_1fc8b3b9a1e18e3b_8.0.50727.4053_x-ww_e79c4723/vcomp.dll ./windows/winsxs/x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.4053_x-ww_e6967989/msvcr80.dll ... ./windows/winsxs/x86_Microsoft.VC80.MFC_1fc8b3b9a1e18e3b_8.0.50727.4053_x-ww_b77cec8e/mfc80u.dll ./windows/system32/xinput9_1_0.dll ./windows/system32/xinput1_1.dll ./windows/system32/d3dx9_27.dll ./windows/system32/xinput1_2.dll ./windows/system32/d3dx9_41.dll ./windows/system32/xinput1_3.dll ./Program Files/Telltale Games/Sam and Max - The Devil's Playhouse/Beyond the Alley of the Dolls/QtCore4.dll imports following stub symbols: msvcp80:??0?$basic_string(a)DU?$char_traits(a)D@std@@V?$allocator(a)D@2@@std@@QAE(a)PBDI@Z ... msvcp80:?uncaught_exception(a)std@@YA_NXZ ./Program Files/Telltale Games/Sam and Max - The Devil's Playhouse/Beyond the Alley of the Dolls/QtWebKit4.dll imports following stub symbols: msvcp80:?max@?$numeric_limits(a)I@std@@SAIXZ msvcp80:?quiet_NaN@?$numeric_limits(a)N@std@@SANXZ msvcp80:_FInf msvcp80:_Inf msvcp80:_Nan ./Program Files/Telltale Games/Sam and Max - The Devil's Playhouse/Beyond the Alley of the Dolls/QtGui4.dll imports following stub symbols: msvcr80:?_type_info_dtor_internal_method(a)type_info@@QAEXXZ msvcr80:_crt_debugger_hook ./Program Files/Telltale Games/Sam and Max - The Devil's Playhouse/Beyond the Alley of the Dolls/QtCore4.dll imports following stub symbols: msvcr80:?_type_info_dtor_internal_method(a)type_info@@QAEXXZ msvcr80:_crt_debugger_hook msvcr80:_fseeki64 msvcr80:_ftelli64 msvcr80:_get_tzname msvcr80:_localtime64_s msvcr80:_putenv_s msvcr80:_wassert msvcr80:getenv_s ./Program Files/Telltale Games/Sam and Max - The Devil's Playhouse/Beyond the Alley of the Dolls/QtNetwork4.dll imports following stub symbols: msvcr80:?_type_info_dtor_internal_method(a)type_info@@QAEXXZ msvcr80:_crt_debugger_hook ./Program Files/Telltale Games/Sam and Max - The Devil's Playhouse/Beyond the Alley of the Dolls/QtWebKit4.dll imports following stub symbols: msvcr80:?_type_info_dtor_internal_method(a)type_info@@QAEXXZ msvcr80:_crt_debugger_hook msvcr80:_localtime64_s

1 0

Re:kernel32: Add tests for SetHandleCount + make tests pass for winversions >WINNT
by Louis Lenders Sept. 3, 2010

Sept. 3, 2010

>It's pretty unlikely that count would be larger than 0xffffffff. I agree, but i thought we should mimic Windows-behaviour, and the tests showed that such large values are at least allowed. If this value is too large could you suggest another one? > Also I don't think we need a version check. The check is there as the tests show that there is a difference between ver < win98 and ver > WINNT. I don't know if there a are applications that depend on this difference really. Anyway, i could return something like min(65536,count) for all versions, is that ok? (i'll strip out the tests then, as they won't be passing then anymore)

3 2

Re: [PATCH 3/3] winmm: Implement MCIERR_DUPLICATE_ALIAS and MCIERR_DEVICE_OPEN.
by testbot＠testbot.winehq.org Sept. 3, 2010

Sept. 3, 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=4989 Your paranoid android. === W98SE (32 bit mci) === mci.c:903: Test failed: not enough time elapsed 58ms

1 0

Re: [PATCH 2/3] winmm: GetDeviceID only considers a single name per entry.
by testbot＠testbot.winehq.org Sept. 3, 2010

Sept. 3, 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=4988 Your paranoid android. === W98SE (32 bit mci) === mci.c:1001: Test failed: mci pause wait returned MMSYSERR 5 mci.c:1015: Test failed: mci pause (space) wait returned MMSYSERR 5 mci.c:1018: Test failed: mci pause wait returned MMSYSERR 5 mci.c:1032: Test failed: Expect message 0004 from play (aborted by close)

1 0

Re: [1/4] urlmon: Implemented IUriBuilder_{Get/Set}Fragment
by Jacek Caban Sept. 3, 2010

Sept. 3, 2010

Hi Thomas, On 9/3/10 1:19 AM, Thomas Mullaly wrote: > --- > dlls/urlmon/tests/uri.c | 22 ++++++++++++- > dlls/urlmon/uri.c | 80 > ++++++++++++++++++++++++++++++++++++++++++---- > 2 files changed, 93 insertions(+), 9 deletions(-) > +static HRESULT setup_builder_properties(UriBuilder*builder, const Uri* uri) { + if(uri->fragment_start> -1) { + builder->fragment = heap_alloc((uri->fragment_len+1)*sizeof(WCHAR)); + if(!builder->fragment) + return E_OUTOFMEMORY; + + memcpy(builder->fragment, uri->canon_uri+uri->fragment_start, uri->fragment_len*sizeof(WCHAR)); + builder->fragment[uri->fragment_len] = '\0'; + builder->fragment_len = uri->fragment_len; + } + + return S_OK; +} I don't think it's a good idea. It should be possible to avoid fetching all URI properties here. You can do it, eg. on demand, when you get a call to GetFragment and the fragment is not everwriten by SetFragment call. Thinking about it, the way these APIs work suggests that Uri object should store null-terminated properties that we could return here, but it may be too far conclusion. Jacek

1 0

Fwd: [PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit.
by Joerg-Cyril.Hoehle＠t-systems.com Sept. 3, 2010

Sept. 3, 2010

Octavian, >I just looked in mmddk.h and they have this: >#define MCI_INTEGER64 13 It's good you found out about MCI_INTEGER64. Yet it's completely crazy because googling it yields 6 hits in total, all about Wine bug 22146. Bing shows nothing at all. How can such a name be that invisible? >So, do you want to fix your patches and send them, or do you want me >to continue working on this patch set? I'm fine if you do (as I've plenty of other patches in my queue) especially if you also fix the parser to handle MCI_HWND (another DWORD_PTR), which is the second half needed for 64bit as I mention in http://bugs.winehq.org/show_bug.cgi?id=22146#c12 GetDWORD also needs some change to be able to parse DWORD_PTR things, e.g. window handles. I've not yet written a single test for that (no mciavi tests). I'll send you all the MCI tests I have written ASAP. Even without written tests, one can use WINEDEBUG=+mci and analyse the parser logs for individual commands sent e.g. via the interactive MCI shell you'll find in http://bugs.winehq.org/show_bug.cgi?id=20232#c10 You obviously own a 64bit system so it's easier for you to test. I don't and had to beg. Regards, Jörg Höhle

2 3

Re: shell32/tests: Test that a folder can be named when clicking "Make New Folder"
by Frank Richter Sept. 3, 2010

Sept. 3, 2010

On 10.08.2010 20:22, Michael Mc Donnell wrote: > When a user clicks the "Make New Folder" button a new folder is created. > The name of the folder is selected, and the dialog box waits for the user > to either accept the name or type in a new one. The test types in a > new folder name and checks that the new folder gets that name. Also, you seem to emit “Alt+M” as part of the test. This is rather fragile, as the hotkey for “Make new folder” is most likely _not_ M on Windows or Wine translated to other than English. I believe the safe way to deal with that is to send a WM_COMMAND message with the ID of the “Make new folder” button. Wine test bot has a number of non-English VMs, so make sure you try your patches there. -f.r.

2 1

Re: [PATCH 1/3] winmm: Correctly parse the MCI Sysinfo command.
by testbot＠testbot.winehq.org Sept. 3, 2010

Sept. 3, 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=4987 Your paranoid android. === W98SE (32 bit mci) === mci.c:889: Test failed: not enough time elapsed 58ms mci.c:945: Test failed: mci status position: 58 mci.c:992: Test failed: mci pause wait returned MMSYSERR 5 mci.c:1006: Test failed: mci pause (space) wait returned MMSYSERR 5 mci.c:1009: Test failed: mci pause wait returned MMSYSERR 5 mci.c:1023: Test failed: Expect message 0004 from play (aborted by close)

1 0

Re: msvcrt:string Fix codepage table 1361 (Korean Johab) [try3]
by Alexandre Julliard Sept. 3, 2010

Sept. 3, 2010

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > @@ -1563,8 +1564,16 @@ sub HANDLE_FILE(@) > } > printf OUTPUT "#include \"wine/unicode.h\"\n\n"; > > + @lb_ranges = get_lb_ranges(); > + > + if( $codepage == 1361 ) > + { > + $lb_ranges[0] = 0x81; > + $lb_ranges[2] = 0xd8; > + } A quick test on Windows shows that this isn't correct as far as the kernel32 info is concerned. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [PATCH 4/6] gameux: add storing Title registry value
by Nikolay Sivov Sept. 3, 2010

Sept. 3, 2010

On 9/3/2010 13:25, Mariusz Pluciński wrote: > + hr = IXMLDOMElement_get_text(lpXMLElement,&bstrValue); > + if(SUCCEEDED(hr)) > + { > + nValueLen = SysStringLen(bstrValue)+1; > + > + GameData->sName = CoTaskMemAlloc(nValueLen*sizeof(WCHAR)); > + if(GameData->sName == NULL) > + hr = E_OUTOFMEMORY; > + > + if(SUCCEEDED(hr)) > + lstrcpynW(GameData->sName, bstrValue, nValueLen); > + > + SysFreeString(bstrValue); > + } Maybe it's better to store it as BSTR to avoid such checks/allocations.

1 0

Re: shell32: Import ole32 directly
by Alexandre Julliard Sept. 3, 2010

Sept. 3, 2010

André Hentschel <nerv(a)dawncrow.de> writes: > ole32 function CoTaskMemAlloc is already used in DLL_PROCESS_ATTACH > (SIC_Initialize -> SIC_IconAppend -> SHAlloc -> CoTaskMemAlloc) A better fix would be to avoid initializing unneeded stuff in process attach. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: kernel32: Add tests for SetHandleCount + make tests pass for winversions >WINNT
by Alexandre Julliard Sept. 3, 2010

Sept. 3, 2010

Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> writes: > @@ -1192,7 +1192,10 @@ BOOL WINAPI UnlockFileEx( HANDLE hFile, DWORD reserved, DWORD count_low, DWORD c > */ > UINT WINAPI SetHandleCount( UINT count ) > { > - return min( 256, count ); > + if (GetVersion() & 0x80000000) > + return min( 0x100, count ); > + else > + return min( 0xffffffff, count ); It's pretty unlikely that count would be larger than 0xffffffff. Also I don't think we need a version check. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: kernel32: add a stub for GetThreadUILanguage
by Dmitry Timoshkov Sept. 3, 2010

Sept. 3, 2010

Austin English <austinenglish(a)gmail.com> wrote: > +LANGID WINAPI GetThreadUILanguage( void ) > +{ > + FIXME(": stub, returning LOCALE_USER_DEFAULT.\n"); > + return LOCALE_USER_DEFAULT; > +} The API is supposed to return a language id, not the locale id. Calling GetUserDefaultUILanguage() may be what you need. -- Dmitry.

1 0

banning spammer from the forum
by Rosanne DiMesio Sept. 3, 2010

Sept. 3, 2010

Can someone with forum admin rights please ban user Eden1023? I've had to delete multiple spam posts by this user every day for the past few days. -- Rosanne DiMesio <dimesio(a)earthlink.net>

4 5

Re: [2/3] dsound/tests: Add IEEE float buffer tests
by testbot＠testbot.winehq.org Sept. 2, 2010

Sept. 2, 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=4950 Your paranoid android. === W98SE (32 bit dsound) === dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D407F4 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D554 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D56C 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D624 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D614 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D614 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D5F4 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D630 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D60C 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D628 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D628 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D628 00000000

1 0

RFC: Compiling as 16 bit
by Morten Rønne Sept. 2, 2010

Sept. 2, 2010

This is related to the creation of the DOS test programs for which I have sent another mail. But this is a more generic question relating to the fact that openwatcom is a 16 bit compiler while gcc (of course) is a 32 bit compiler. Currently this have lead me to drop the inclusion of the files windef.h and winbase.h, because the definitions created aren't of the correct size (int is 16 bit, not 32 bit and so on). I am looking for a way to change windef.h so that it will create the correct base types for both 16 and 32 bit compile. Openwatcom defines the symbol __I86__ while compiling for 16 bit, is it acceptable that I use that to create 16 bit types? It seems that _MSC_VER will change a few cases of int to long, but far from enough. Is _MSC_VER intended to be a 16 bit compile flag? Or should I use something else more wine like (e.g. __WINE_16BIT_COMPILE). Also compiling 16 bit give some errors in other include files (after I have defined proper sizes for the 16 bit compile) ../../../include/winnt.h(3529): Error! E1040: Field width too large #ifdef BITFIELDS_BIGENDIAN unsigned NameIsString:1; unsigned NameOffset:31; #else unsigned NameOffset:31; unsigned NameIsString:1; #endif As it can be seen the include file uses unsigned directly and not a type like DWORD or ULONG that would be a "safe" 32 bit. Would it be acceptable to change this and others to a "proper" type which I know to be size safe? Best Regards Morten Rønne

2 4

Re: [1/3] dsound: Add support for 32-bit IEEE float buffers
by Chris Robinson Sept. 2, 2010

Sept. 2, 2010

On Thursday, September 02, 2010 1:38:29 pm Owen Rudge wrote: > These patches add support to DirectSound that allow the conversion of > 32-bit IEEE float audio buffers to PCM. Some games (e.g., Call of Duty > 5) output their audio in this format, and media players such as > foobar2000 have support for it too. You'll probably want to make sure the float values are clamped between -1 and +1 before converting, otherwise they'll wrap and cause bad static noise.

1 0

Re: RFC: test of 16 bit wine (DOS)
by Dan Kegel Sept. 2, 2010

Sept. 2, 2010

On Thu, Sep 2, 2010 at 7:50 PM, Morten Rønne <morten.roenne(a)tdcadsl.dk> wrote: >> Oh, right, win16test's Makefile and probably its test.h are kind of >> simpleminded. >> You probably want to have just one 16 bit test app per dll. >> Hopefully the test cases from win16test will be a useful starting point >> aside from their wimpy build system. > > I would like to avoid the dll part as DOS doesn't know about that and > "simply" run the program directly with tools/run_test. You might have misunderstood. By DLL I just meant the part of Wine that you're testing. In the case of DOS, the tests should probably go in krnl386.exe16/tests. > I will make some tests to see what I can fit into the test system, so it > works the same way other tests do, but as a "standalone" test. Good. That's exactly what I did with win16test. The missing part is integrating into the Wine build sytem. - Dan

1 0

re: RFC: test of 16 bit wine (DOS)
by Dan Kegel Sept. 2, 2010

Sept. 2, 2010

Morten Rønne wrote: > I have been working on creating tests for the 16 bit implementation of wine Great! Have you seen http://code.google.com/p/win16test/ ? That's for Win16 binaries, not DOS, but it might have some similarities. For instance, it also uses openwatcom. I had trouble back then getting the Linux version of openwatcom to produce win16 binaries, so I used 'winetricks openwatcom' to install the windows version. - Dan

2 5

Please report mcicda (CDROM audio) test results
by Joerg-Cyril.Hoehle＠t-systems.com Sept. 2, 2010

Sept. 2, 2010

Hi, Wine's testbt job #4280 http://testbot.winehq.org/JobDetails.pl?Key=4280 contains both a patch and a binary for new MCICDA=MCI CD-audio tests. It already contains most of what I want in the initial release but would benefit from testing on a broad range of native MS systems. Please invoke it as: mcicda_test.exe mcicda (it generates many failures on Wine but I already wrote several patches to fix them.) Some failures are still possible as there are a few rough edges, e.g. mcicda.c:222: Test failed: info upc: 0=NOERROR mcicda.c:322: Test failed: PLAY data to 00291d10: MCIERR_OUTOFRANGE mcicda: 98 tests executed (0 marked as todo, 2 failures), 0 skipped. It skips tests if - there's no disk in drive; - there are no audio tracks; Untested: blank RW disk Questions: - Is this patch right in mcicda/tests/ or should it be part of winmm/tests/? - Which kind of tests should I restrict to WINETEST_INTERACTIVE mode only? People may start to complain in the near future that running the Wine testsuite starts spinning their CD-ROM and even play music. (like somebody observed that the MIDI testsuite plays a few notes). Thank you for your contributions, Jörg Höhle

5 12

Re: winmm/tests: Share common function dbg_mcierr.
by testbot＠testbot.winehq.org Sept. 2, 2010

Sept. 2, 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=4939 Your paranoid android. === W98SE (32 bit mci) === mci.c:613: Test failed: Expect message 0001 from play to 250 wait notify mci.c:620: Test failed: got 0004 instead of MCI_NOTIFY_xyz 0000 from command after close

1 0

Our wiki disallows chinese text?
by Dan Kegel Sept. 2, 2010

Sept. 2, 2010

The chap I mentioned earlier is starting off by trying to translate wiki pages into Chinese. http://wiki.winehq.org/FrontPage now has a Chinese entry at the bottom, but there's a hitch: when I try putting a bit of chinese text into http://wiki.winehq.org/Chinese the wiki refuses to save it, saying Sorry, can not save page because "葡" is not allowed in this wiki Is that because we don't have anyone who can monitor the wiki for chinese spam? How can we allow creation of Chinese pages? - Dan

3 2

Re: [PATCH 5/6] winmm/tests: MCI_STATUS returns DWORD_PTR, unlike other commands.
by testbot＠testbot.winehq.org Sept. 2, 2010

Sept. 2, 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=4901 Your paranoid android. === W98SE (32 bit mci) === mci.c:714: Test failed: Expect message 0001 from play to 250 wait notify mci.c:721: Test failed: got 0004 instead of MCI_NOTIFY_xyz 0000 from command after close mci.c:782: Test failed: not enough time elapsed 58ms mci.c:838: Test failed: mci status position: 58

2 1

Mono integration, and when do we ship Mono with Wine?
by Vincent Povirk Sept. 2, 2010

Sept. 2, 2010

Dan Kegel recently listed this as a possible 1.4 goal: > Mono integration similar to the current Gecko integration He may have meant one or both of the following things: 1. A more-or-less complete mscoree.dll that works based on the mono embedding api, as well as replacements for all the utilities that ship with .NET. 2. A wine-mono package similar to the current wine-gecko package to be installed automatically in new prefixes. I am making very slow progress with 1. I believe the current major shortcomings are functions that create COM wrappers for managed objects (ClrCreateManagedInstance and DllGetClassObject) and functions that search for and load different .NET versions (I believe these will be needed so that the managed objects we create will load and function properly). Mono already provides COM wrappers, so all we have to do is create the objects and pass COM wrappers to applications. I'm making this judgment based on the limited pool of mscoree bugs in the Wine bugzilla. I wish more people would file bugs when Mono doesn't work. I figure 2 can't be very technically difficult in and of itself, but when will we be ready to do that? What are the requirements? Do we want to go the "offer to download and install on first use" route first, and if so when will we be ready for that? Do those functions I mentioned earlier have to actually work first? The one hard requirement I have and have not met is that a working mono package can be built by me using only free software and that I can explain the build process to other people. I can do this for the core runtime and libraries, but I cannot do this for the gluezilla dependency. This gluezilla thing is sort of explained here: http://www.mono-project.com/WebBrowser Basically, .NET provides a web browser control, which Mono implements based on Gecko (or, optionally, WebKit). The official installer of Mono for Windows, which is what anyone who uses Mono in Wine uses, ships with Mozilla. It also ships with gluezilla, which is a C++ library that helps the managed code link Gecko. I don't think it'd be acceptable to leave out WebBrowser support. I am not currently able to create a Windows build of gluezilla or gecko using only free software. As I understand it, the official Windows build relies on Visual Studio. I do not know whether it's feasible for gluezilla to link to wine gecko, so that we don't have to install two versions of gecko. I also know that shipping gluezilla and gecko on Windows is wrong. Mono's wiki tells me that it's possible in .NET to access the underlying IE embedding objects through the winforms api, and those only exist if we're embedding IE. So the correct approach is to embed IE (in this case, Wine's IE replacement) by writing another WebBrowser backend. I don't know how hard that is. Maybe it'd make a good Summer of Code project? So, does anyone have other requirements, or thoughts on resolving the WebBrowser requirement?

5 4

Re: [5/5] msi/test: Add tests for 64-bit properties.
by testbot＠testbot.winehq.org Sept. 2, 2010

Sept. 2, 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=4928 Your paranoid android. === W7PROX64 (64 bit package) === package.c:8387: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8398: Test failed: Expected "C:\winetest\", got "" package.c:8409: Test failed: Expected "C:\winetest\", got "" package.c:8459: Test failed: Expected "C:\winetest\FileName3.dll", got "" package.c:8470: Test failed: Expected "C:\winetest\FileName5.dll", got "" package.c:8479: Test failed: Expected "C:\", got "" package.c:8485: Test failed: Expected "C:\winetest\", got "" package.c:8506: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8515: Test failed: Expected "C:\winetest\FileName1", got ""

1 0

Re: [PATCH 3/3] include: Add MCI_INTEGER64 and MCI_INTEGER3264 mci types. (try 2)
by Jacek Caban Sept. 2, 2010

Sept. 2, 2010

Hi Octavian, On 9/1/10 7:45 PM, Octavian Voicu wrote: > MCI_INTEGER64 is only defined for _WIN64 in DDK. > > MCI_INTEGER3264 is wine specific and will be needed because MCI_STATUS > return type is MCI_INTEGER64 in 64-bit winmm.dll, and MCI_INTEGER > in 32-bit winmm.dll. That's not a reason to add Wine-specific defines in public header. Jacek

3 3

Re: msvcrt:string Fix codepage table 1361 (Korean Johab) [try2]
by Alexandre Julliard Sept. 2, 2010

Sept. 2, 2010

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > @@ -1563,8 +1564,11 @@ sub HANDLE_FILE(@) > } > printf OUTPUT "#include \"wine/unicode.h\"\n\n"; > > + if( $codepage == 1361 ) { @lb_ranges = ( 0x81, 0xd3, 0xd8, 0xde, 0xe0, 0xf9 ); } > + else { @lb_ranges = get_lb_ranges(); } There's no reason to hardcode the whole thing. If some lead bytes aren't detected properly you can add just those. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 6/6] winmm/tests: Add MCI parser tests.
by testbot＠testbot.winehq.org Sept. 1, 2010

Sept. 1, 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=4902 Your paranoid android. === W98SE (32 bit mci) === mci.c:926: Test failed: mci status position: 128

1 0

Re: [PATCH 2/3] winmm: Replace command ids with symbolic constants in mci command resources.
by Octavian Voicu Sept. 1, 2010

Sept. 1, 2010

In order to prevent copy-paste errors, the changes were generated using the following script, executed from git root (there are two very long lines, might not work if they're wrapped): for i in MCI_OPEN MCI_CLOSE MCI_ESCAPE MCI_PLAY MCI_SEEK MCI_STOP MCI_PAUSE MCI_INFO MCI_GETDEVCAPS MCI_SPIN MCI_SET MCI_STEP MCI_RECORD MCI_SYSINFO MCI_BREAK MCI_SOUND MCI_SAVE MCI_STATUS MCI_CUE MCI_REALIZE MCI_WINDOW MCI_PUT MCI_WHERE MCI_FREEZE MCI_UNFREEZE MCI_LOAD MCI_CUT MCI_COPY MCI_PASTE MCI_UPDATE MCI_RESUME MCI_DELETE; do j=`egrep "^#define $i\\W" include/mmsystem.h | awk '{print $3}' | sed 's/0x0/0x00000/g'`; k=`echo $i | sed 's/MCI_//g'`; sed -i "s/${j}L, MCI_COMMAND_HEAD,/$i, 0, MCI_COMMAND_HEAD,/ig" dlls/mciavi32/mciavi_res.rc dlls/mciqtz32/mciavi_res.rc dlls/winmm/winmm_res.rc; done for i in MCI_CAPTURE MCI_MONITOR MCI_RESERVE MCI_SETAUDIO MCI_SIGNAL MCI_SETVIDEO MCI_QUALITY MCI_LIST MCI_UNDO MCI_CONFIGURE MCI_RESTORE; do j=`egrep "^#define $i\\W" include/digitalv.h | awk '{print $3}' | sed 's/0x0/0x00000/g'`; k=`echo $i | sed 's/MCI_//g'`; sed -i "s/${j}L, MCI_COMMAND_HEAD,/$i, 0, MCI_COMMAND_HEAD,/ig" dlls/mciavi32/mciavi_res.rc dlls/mciqtz32/mciavi_res.rc dlls/winmm/winmm_res.rc; done

1 0

Re: d3dx9: Implement D3DXFVFFromDeclarator. (try 2)
by Henri Verbeet Sept. 1, 2010

Sept. 1, 2010

On 1 September 2010 02:40, Misha Koshelev <misha680(a)gmail.com> wrote: > + while (texture <= 8) What is the "texture == 8" case for? Also, it seems to me FVFs require texcoords to be assigned to consecutive texture units.

2 1

Re: [PATCH 4/6] winmm/tests: Add a few Open/Close MCI tests.
by testbot＠testbot.winehq.org Sept. 1, 2010

Sept. 1, 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=4900 Your paranoid android. === W98SE (32 bit mci) === mci.c:637: Test failed: Expect message 0001 from play to 250 wait notify mci.c:644: Test failed: got 0004 instead of MCI_NOTIFY_xyz 0000 from command after close

1 0

Re: [PATCH 2/6] winmm: Close MCI device after immediate auto-open commands.
by testbot＠testbot.winehq.org Sept. 1, 2010

Sept. 1, 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=4899 Your paranoid android. === W98SE (32 bit mci) === mci.c:613: Test failed: Expect message 0001 from play to 250 wait notify mci.c:620: Test failed: got 0004 instead of MCI_NOTIFY_xyz 0000 from command after close

1 0

Re: [PATCH 1/6] winmm: MCI open always creates an alias for subsequent commands.
by testbot＠testbot.winehq.org Sept. 1, 2010

Sept. 1, 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=4898 Your paranoid android. === W98SE (32 bit mci) === mci.c:681: Test failed: not enough time elapsed 58ms mci.c:737: Test failed: mci status position: 58

1 0

Re: [PATCH] wined3d: Add missing ckey, fx, and pal directdraw caps.
by Stefan Dösinger Sept. 1, 2010

Sept. 1, 2010

Looks OK to me. (unless there are whitespace issues which I can't see in my current mail client) Am 01.09.2010 um 06:44 schrieb Octavian Voicu: > Fixes regression described in bug 24226. > --- > dlls/wined3d/directx.c | 7 ++++++- > 1 files changed, 6 insertions(+), 1 deletions(-) > > diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c > index 01b4e46..9e50f78 100644 > --- a/dlls/wined3d/directx.c > +++ b/dlls/wined3d/directx.c > @@ -4259,7 +4259,7 @@ static HRESULT WINAPI IWineD3DImpl_GetDeviceCaps(IWineD3D *iface, UINT Adapter, > int ps_selected_mode; > struct shader_caps shader_caps; > struct fragment_caps fragment_caps; > - DWORD ckey_caps, blit_caps, fx_caps; > + DWORD ckey_caps, blit_caps, fx_caps, pal_caps; > > TRACE_(d3d_caps)("(%p)->(Adptr:%d, DevType: %x, pCaps: %p)\n", This, Adapter, DeviceType, pCaps); > > @@ -4786,6 +4786,8 @@ static HRESULT WINAPI IWineD3DImpl_GetDeviceCaps(IWineD3D *iface, UINT Adapter, > WINEDDCAPS_COLORKEY | > WINEDDCAPS_COLORKEYHWASSIST | > WINEDDCAPS_ALIGNBOUNDARYSRC; > + pal_caps = WINEDDPCAPS_8BIT | > + WINEDDPCAPS_PRIMARYSURFACE; > > /* Fill the ddraw caps structure */ > pCaps->DirectDrawCaps.Caps = WINEDDCAPS_GDI | > @@ -4796,6 +4798,9 @@ static HRESULT WINAPI IWineD3DImpl_GetDeviceCaps(IWineD3D *iface, UINT Adapter, > WINEDDCAPS2_PRIMARYGAMMA | > WINEDDCAPS2_WIDESURFACES | > WINEDDCAPS2_CANRENDERWINDOWED; > + pCaps->DirectDrawCaps.CKeyCaps = ckey_caps; > + pCaps->DirectDrawCaps.FXCaps = fx_caps; > + pCaps->DirectDrawCaps.PalCaps = pal_caps; > pCaps->DirectDrawCaps.SVBCaps = blit_caps; > pCaps->DirectDrawCaps.SVBCKeyCaps = ckey_caps; > pCaps->DirectDrawCaps.SVBFXCaps = fx_caps; > -- > 1.7.0.4 > > >

1 0

Re: shell32: add stubbed SHGetKnownFolderPath
by Alexandre Julliard Sept. 1, 2010

Sept. 1, 2010

Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> writes: > @@ -111,3 +111,8 @@ typedef [v1_enum] enum tagSHCOLSTATE > } SHCOLSTATE; > > typedef DWORD SHCOLSTATEF; > + > +typedef GUID KNOWNFOLDERID; > + > +typedef KNOWNFOLDERID *REFKNOWNFOLDERID; This doesn't match the PSDK definitions. -- Alexandre Julliard julliard(a)winehq.org

1 0