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