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

Re: [PATCH 1/3] gameux: Add definitions of resource identifiers to header file

by Mariusz Pluciński

W dniu 18.08.2010 19:34, GOUJON Alexandre pisze: > On 08/18/2010 07:06 PM, Mariusz Pluciński wrote: >> Can I do it by passing __LINE__ macro as parameter to my _validate* >> functions? > > Some tests already use __LINE__ as a parameter. > See > http://source.winehq.org/git/wine.git/?a=blob;f=dlls/advapi32/tests/cred.c#… > > and > http://source.winehq.org/git/wine.git/?a=blob;f=dlls/advapi32/tests/cred.c#… > > for instance. > Thanks for these examples. I though about little different solution, but this looks really easier than my ideas.

Aug. 18, 2010

Re: [PATCH 1/3] gameux: Add definitions of resource identifiers to header file

by GOUJON Alexandre

On 08/18/2010 07:06 PM, Mariusz Pluciński wrote: > Can I do it by passing __LINE__ macro as parameter to my _validate* > functions? Some tests already use __LINE__ as a parameter. See http://source.winehq.org/git/wine.git/?a=blob;f=dlls/advapi32/tests/cred.c#… and http://source.winehq.org/git/wine.git/?a=blob;f=dlls/advapi32/tests/cred.c#… for instance.

Aug. 18, 2010

Re: [PATCH 1/3] gameux: Add definitions of resource identifiers to header file

by Mariusz Pluciński

W dniu 18.08.2010 18:09, Vincent Povirk pisze: > I think it would be helpful if you passed a string description to your > _validate functions so that in case of failure, you can tell where the > original call to _validateGameRegistryKey was, instead of just the > line containing the ok() call. Can I do it by passing __LINE__ macro as parameter to my _validate* functions?

Aug. 18, 2010

Re: [PATCH 3/3] gameux/tests: verifying registry values created by GameExplorer

by Mariusz Pluciński

W dniu 18.08.2010 18:28, Andrew Eikum pisze: >> This result is strange, cause routine modified by this patch (called >> test_add_remove_game ) is not even called on these operating systems - >> and test added by my previous patch demonstrates it (and it succeeded). >> Did I something wrong? I cannot imagine how it could fail when previous >> test was succeeded. > > You can see the error message dialog in the screenshots on the testbot > result webpage. In this case, you've got missing exports, > ConvertSidToSidStringW and RegGetValueW. Some solutions are to make > those into function pointers (and skip appropriately if they're > missing), use the A versions if they exist, or use a different function > that exists on more platforms. > > Andrew > I understand. Thank you very much for the explanation. I did not know, that new code can interfere in any way on systems where it is never called. W dniu 18.08.2010 18:33, Vincent Povirk pisze: > Oh. > > Personally, I would ignore failures on operating systems< Vista, > since gameux won't be present and the tests would not normally be run. > OK, I'll see if my patch is accepted despite of these results. If not, I'll modify it, to make it calling these routines through pointers.

Aug. 18, 2010

Re: [PATCH 3/3] gameux/tests: verifying registry values created by GameExplorer

by Vincent Povirk

> You can see the error message dialog in the screenshots on the testbot > result webpage. In this case, you've got missing exports, > ConvertSidToSidStringW and RegGetValueW. Some solutions are to make those > into function pointers (and skip appropriately if they're missing), use the > A versions if they exist, or use a different function that exists on more > platforms. Oh. Personally, I would ignore failures on operating systems < Vista, since gameux won't be present and the tests would not normally be run.

Aug. 18, 2010

Re: [PATCH 3/3] gameux/tests: verifying registry values created by GameExplorer

by Andrew Eikum

> This result is strange, cause routine modified by this patch (called > test_add_remove_game ) is not even called on these operating systems - > and test added by my previous patch demonstrates it (and it succeeded). > Did I something wrong? I cannot imagine how it could fail when previous > test was succeeded. You can see the error message dialog in the screenshots on the testbot result webpage. In this case, you've got missing exports, ConvertSidToSidStringW and RegGetValueW. Some solutions are to make those into function pointers (and skip appropriately if they're missing), use the A versions if they exist, or use a different function that exists on more platforms. Andrew

Aug. 18, 2010

Re: [PATCH 3/3] gameux/tests: verifying registry values created by GameExplorer

by Vincent Povirk

The testbot gives weird results at times. I wouldn't worry about it. 2010/8/18 Mariusz Pluciński <vshader(a)gmail.com>: > W dniu 18.08.2010 17:49, (Marvin) pisze: >> >> 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=4540 >> >> Your paranoid android. >> >> >> === W98SE (32 bit gameexplorer) === >> Failure running script in VM: Exceeded timeout limit of 315 sec >> >> === W2KPROSP4 (32 bit gameexplorer) === >> Timeout >> >> === WXPPROSP3 (32 bit gameexplorer) === >> Timeout >> > > This result is strange, cause routine modified by this patch (called > test_add_remove_game ) is not even called on these operating systems - and > test added by my previous patch demonstrates it (and it succeeded). Did I > something wrong? I cannot imagine how it could fail when previous test was > succeeded. > > >

Aug. 18, 2010

Re: [PATCH 3/3] gameux/tests: verifying registry values created by GameExplorer

by Mariusz Pluciński

W dniu 18.08.2010 17:49, (Marvin) pisze: > 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=4540 > > Your paranoid android. > > > === W98SE (32 bit gameexplorer) === > Failure running script in VM: Exceeded timeout limit of 315 sec > > === W2KPROSP4 (32 bit gameexplorer) === > Timeout > > === WXPPROSP3 (32 bit gameexplorer) === > Timeout > This result is strange, cause routine modified by this patch (called test_add_remove_game ) is not even called on these operating systems - and test added by my previous patch demonstrates it (and it succeeded). Did I something wrong? I cannot imagine how it could fail when previous test was succeeded.

Aug. 18, 2010

Re: [PATCH 1/3] gameux: Add definitions of resource identifiers to header file

by Vincent Povirk

> @@ -32,7 +33,6 @@ > > #include "wine/test.h" > > - > static void test_create(BOOL* gameExplorerAvailable, BOOL* gameExplorer2Available) > { > HRESULT hr; Don't put formatting changes in functional patches, please. I think it would be helpful if you passed a string description to your _validate functions so that in case of failure, you can tell where the original call to _validateGameRegistryKey was, instead of just the line containing the ok() call.

Aug. 18, 2010

Re: [PATCH 5/6] gameux: Add initial implementation of IGameExplorer2::CheckAccess method

by Mariusz Pluciński

Hello W dniu 16.08.2010 10:00, Mariusz Pluciński pisze: > --- > dlls/gameux/gameexplorer.c | 7 +++++-- > 1 files changed, 5 insertions(+), 2 deletions(-) > > This is patch I sent to wine-patches yesterday. It was marked as "Pending". I know that what I sent is not proper solution. But as I wrote in FIXME, it's in my opinion impossible to implement it properly, cause from what I know Wine does not support parental control. So, instead of doing real check, my function simply always grants access. My question is: what should I do with it? It cannot be left stub, as there's already bug caused by this (bug #23850). And probably every game which uses Game Explorer will behave that same. Should I write test case to demonstrate that native works that same in most cases?

Aug. 18, 2010

Re: [PATCH 1/1] d3dx9: Add tests for FVF <-> declaration conversion.

by Alexandre Julliard

Misha Koshelev <misha680(a)gmail.com> writes: > +#define VDECL_CHECK(fcall) \ > + if(fcall != S_OK) \ > + trace(" Test failed on line #%d\n", __LINE__); > + > +#define VDECL_CHECK_FAIL(fcall) \ > + if(fcall != E_FAIL) \ > + trace(" Test failed on line #%d\n", __LINE__); That's ugly. If the goal is to print the line number, you should pass it to the test function. -- Alexandre Julliard julliard(a)winehq.org

Aug. 18, 2010

Re: [PATCH 3/3] gameux/tests: verifying registry values created by GameExplorer

by testbot＠testbot.winehq.org

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=4540 Your paranoid android. === W98SE (32 bit gameexplorer) === Failure running script in VM: Exceeded timeout limit of 315 sec === W2KPROSP4 (32 bit gameexplorer) === Timeout === WXPPROSP3 (32 bit gameexplorer) === Timeout

Aug. 18, 2010

Re: [PATCH 1/2] ntdll: Implement RtlIpv4AddressToString / RtlIpv4AddressToStringEx [try 3]

by Alexandre Julliard

Detlef Riekenberg <wine.dev(a)web.de> writes: > + in = *pin; What is this for? -- Alexandre Julliard julliard(a)winehq.org

Aug. 18, 2010

Re: Wine64 debugger

by Peter Urbanec

On 18/08/10 01:51, Marcus Meissner wrote: > On Wed, Aug 18, 2010 at 01:00:35AM +1000, Peter Urbanec wrote: >> I'm seeing crashes in FindNextFileW/FindNextFileA due to what >> looks like a 64 bit HANDLE value being truncated to 32 bits. > > Check if your code uses "int" in its FindNextFile or findfirst things. I had a good look at the wine source code as well as those parts of the application source code that I can get access to and it all looks good as far as correctly using HANDLE type to store HANDLE values. Unfortunately, the application in question also makes use of FLEXlm libraries from Macrovision and these binary blobs appear to be buggy. All the symptoms point to the FLEXlm code storing the 64-bit HANDLE value in a 32-bit int - this is evidenced by sign extension on some of the values. Of course, the initial cause and the issues with the debugger are essentially unrelated. I have sent some sample test binaries to Eric, to reproduce the debugger issue. The buggy Win64 application is another story. It looks like Win64 must most of the time return HANDLE values that fit within 31 bits, because from what I hear, Windows users go through thousands of invocations of this app without seeing any issues. I wonder if there is a way of making wine allocate the memory for the object pointed to by the HANDLE somewhere in the lower part of the address space. That ought to mitigate this particular application bug and bring the compatibility a little closer to what's observed under Win64.

Aug. 18, 2010

have all MCI tests in winmm/tests/ or distributed across mci*/tests/?

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, although my patch creates mcicda/tests/ I'd like to query whether it would make more sense to have all mci tests grouped in winmm/tests/. Pro: + Future fixes to winmm/mci.c would affect winmm/tests/*.c only. E.g. when I'll make "stop all" work I'd have to touch mcicda/tests/mcicda.c as well to eliminate the todo_wine there. Same when I'll patch mciparse to accept [TT:]MM:SS:FF format. + When Maarten will write mciqtz tests, perhaps resources could be reused to execute mciavi tests as well (the file creation code need not be duplicated). Similar tests could be written for: "open foo.avi" (mciavi) and "open foo.avi type mpegvideo" (mciqtz) or "open foo.wav" (micwave) and "open foo.wav type mpegvideo" although there's some difference in behaviour. + The functions test_notification could be in one file only, not repeated. I can rewrite my current mcicda/tests/mcicda.c patch to live in winmm/tests/. What do you think? Jörg Höhle

Aug. 18, 2010

Re: [PATCH] advapi32: Add magic codes to HCRYPTKEY and HCRYPTHASH.

by Austin Lund

On 18 August 2010 20:44, GOUJON Alexandre <ale.goujon(a)gmail.com> wrote: > On 08/18/2010 12:22 PM, Hans Leidekker wrote: >> >> They are often built from four character ascii strings to help find out >> where the structures come from. I don't know why this one was chosen >> but I guess you could use something like 0xA39E741E and 0xA39E741D. >> > > Yep, there are some magic values at http://en.wikipedia.org/wiki/Hexspeak > FYI, MAGIC_CRYPTPROV comes from the following commit > http://source.winehq.org/git/wine.git/?a=commitdiff;h=44cb0906da3dddbca1fe6… > None of that answers the "why" question except perhaps the part about unaligned pointer values which isn't really relevant for modern architectures. I'll wait for any further feedback, try something like above and resubmit tomorrow.

Aug. 18, 2010

Re: wldap32: Fix handling of zero timeout value in ldap_search_extW. (try 2)

by Hans Leidekker

On Wed, 2010-08-18 at 13:41 +0200, testbot(a)testbot.winehq.org wrote: > 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=4530 > > Your paranoid android. > > > === W2KPROSP4 (32 bit parse) === > parse.c:101: Test failed: ldap_search_extW failed 0x00000034 > parse.c:105: Test failed: ldap_search_extW failed 0x00000051 0x34 == LDAP_UNAVAILABLE, likely caused by a network problem.

Aug. 18, 2010

Re: wldap32: Fix handling of zero timeout value in ldap_search_extW. (try 2)

by testbot＠testbot.winehq.org

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=4530 Your paranoid android. === W2KPROSP4 (32 bit parse) === parse.c:101: Test failed: ldap_search_extW failed 0x00000034 parse.c:105: Test failed: ldap_search_extW failed 0x00000051

Aug. 18, 2010

Re: [4/5] msi: Handle signature filenames in short|long notation.

by testbot＠testbot.winehq.org

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=4528 Your paranoid android. === W7PROX64 (32 bit package) === package.c:8348: Test failed: Expected "C:\Program Files\VMware\VMware Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\", got "C:\Program Files (x86)\VMware\VMware Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\" === W7PROX64 (64 bit package) === package.c:8385: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8396: Test failed: Expected "C:\winetest\", got "" package.c:8407: Test failed: Expected "C:\winetest\", got "" package.c:8457: Test failed: Expected "C:\winetest\FileName3.dll", got "" package.c:8468: Test failed: Expected "C:\winetest\FileName5.dll", got "" package.c:8477: Test failed: Expected "C:\", got "" package.c:8483: Test failed: Expected "C:\winetest\", got "" package.c:8504: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8513: Test failed: Expected "C:\winetest\FileName1", got ""

Aug. 18, 2010

Re: [3/5] msi/tests: Skip SourceDir tests on win9x.

by testbot＠testbot.winehq.org

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=4527 Your paranoid android. === W2K3R2SESP2 (32 bit install) === Timeout

Aug. 18, 2010

Re: Wine64 debugger

by Eric Pouech

the assertion `addr->Mode == AddrModeFlat' failed is likely an address returned by dbghelp which is not properly initialized. Could you send me off line the .exe (and associated DLL if any) so that I can check it TIA 2010/8/17 Peter Urbanec <winehq.org(a)urbanec.net> > > Hi, > > I'm trying to get a fairly complex Win64 application to work with wine. I'm > seeing crashes in FindNextFileW/FindNextFileA due to what looks like a 64 > bit HANDLE value being truncated to 32 bits. I thought that I would employ > winedbg to help me, but I can't get very far. I don't have any luck with > winedbg even on a simple x64 Win32 app. > > For my simplified test, I used MSVC2005 to generate an x64 executable > created from the standard MSVC2005 template Win32 application. This is a > simple app that just creates an empty window. As simple as one could get for > a Win32 test and it executes correctly when run as "./wine Test1.exe". When > I try to execute this test app under winedbg, I get an assert failure: > > ./wine winedbg Test1.exe > WineDbg starting on pid 001a > ./programs/winedbg/memory.c:37: be_cpu_linearize: Assertion `addr->Mode == > AddrModeFlat' failed. > wine: Assertion failed at address 0x7fec2fa657c5 (thread 0009), starting > debugger... > Unhandled exception: assertion failed in 64-bit code (0x00007fec2fa657c5). > > Any ideas about why I can not use winedbg to run Win32 x64 code? > > Thanks, > > Peter Urbanec > > > > > > > -- -- Eric Pouech

Aug. 18, 2010

Re: [2/5] msi/tests: Use HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE for registry tests.

by testbot＠testbot.winehq.org

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=4526 Your paranoid android. === W2K3R2SESP2 (32 bit install) === Timeout

Aug. 18, 2010

Re: [PATCH] advapi32: Add magic codes to HCRYPTKEY and HCRYPTHASH.

by GOUJON Alexandre

On 08/18/2010 12:22 PM, Hans Leidekker wrote: > They are often built from four character ascii strings to help find out > where the structures come from. I don't know why this one was chosen > but I guess you could use something like 0xA39E741E and 0xA39E741D. > Yep, there are some magic values at http://en.wikipedia.org/wiki/Hexspeak FYI, MAGIC_CRYPTPROV comes from the following commit http://source.winehq.org/git/wine.git/?a=commitdiff;h=44cb0906da3dddbca1fe6…

Aug. 18, 2010

Re: [1/5] msi/tests: Fix some WoW64 test failures.

by testbot＠testbot.winehq.org

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=4525 Your paranoid android. === W7PROX64 (32 bit package) === package.c:8329: Test failed: Expected "C:\Program Files\VMware\VMware Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\", got "C:\Program Files (x86)\VMware\VMware Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\" === W7PROX64 (64 bit package) === package.c:8366: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8377: Test failed: Expected "C:\winetest\", got "" package.c:8388: Test failed: Expected "C:\winetest\", got "" package.c:8438: Test failed: Expected "C:\winetest\FileName3.dll", got "" package.c:8449: Test failed: Expected "C:\winetest\FileName5.dll", got "" package.c:8458: Test failed: Expected "C:\", got "" package.c:8464: Test failed: Expected "C:\winetest\", got "" package.c:8485: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8494: Test failed: Expected "C:\winetest\FileName1", got ""

Aug. 18, 2010

Re: [PATCH] advapi32: Add magic codes to HCRYPTKEY and HCRYPTHASH.

by Hans Leidekker

On Wed, 2010-08-18 at 20:02 +1000, Austin Lund wrote: > On 18 August 2010 18:34, Hans Leidekker <hans(a)codeweavers.com> wrote: > > On Wed, 2010-08-18 at 10:14 +1000, Austin Lund wrote: > > > >> #define MAGIC_CRYPTPROV 0xA39E741F > >> +#define MAGIC_CRYPTKEY 0xA39E741F > >> +#define MAGIC_CRYPTHASH 0xA39E741F > > > > The app might pass a crypto handle of the wrong type, so it would be > > better to use different magic values. > > > > Are there any rules to these magic values? Why was 0xA39E741F chosen? They are often built from four character ascii strings to help find out where the structures come from. I don't know why this one was chosen but I guess you could use something like 0xA39E741E and 0xA39E741D.

Aug. 18, 2010

kernel32/tests: GetVolumeInformationA X: succeeds iff drive's default dir is root. (try 2)

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, please consider that patch, submitted on the 3rd of August, for inclusion. Tests pass on native w95,w98,w2k,xp,7. Greg Geldorp went into the extra effort to instrument the testbot machines (NT upto 7, not win9X) http://www.winehq.org/pipermail/wine-devel/2010-August/085919.html with a second drive to validate my new tests, avoiding the volume.c:345: Tests skipped: Please re-run from another device than C: of a normal testbot run, such that the GetVolumeInformation tests are not skipped when started from drive E: >In short: everything passes. Thank you, Jörg Höhle

Aug. 18, 2010

Re: [PATCH] advapi32: Add magic codes to HCRYPTKEY and HCRYPTHASH.

by Austin Lund

On 18 August 2010 18:34, Hans Leidekker <hans(a)codeweavers.com> wrote: > On Wed, 2010-08-18 at 10:14 +1000, Austin Lund wrote: > >> #define MAGIC_CRYPTPROV 0xA39E741F >> +#define MAGIC_CRYPTKEY 0xA39E741F >> +#define MAGIC_CRYPTHASH 0xA39E741F > > The app might pass a crypto handle of the wrong type, so it would be > better to use different magic values. > Are there any rules to these magic values? Why was 0xA39E741F chosen?

Aug. 18, 2010

Re: wldap32: Fix handling of zero timeout value in ldap_search_extW.

by testbot＠testbot.winehq.org

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=4524 Your paranoid android. === W98SE (32 bit parse) === parse.c:108: Test failed: ldap_search_extW failed 0x00000059 === WNT4WSSP6 (32 bit parse) === parse.c:108: Test failed: ldap_search_extW failed 0x00000059

Aug. 18, 2010

Re: [PATCH] advapi32: Add magic codes to HCRYPTKEY and HCRYPTHASH.

by Hans Leidekker

On Wed, 2010-08-18 at 10:14 +1000, Austin Lund wrote: > #define MAGIC_CRYPTPROV 0xA39E741F > +#define MAGIC_CRYPTKEY 0xA39E741F > +#define MAGIC_CRYPTHASH 0xA39E741F The app might pass a crypto handle of the wrong type, so it would be better to use different magic values.

Aug. 18, 2010

Re: [PATCH 2/3] winex11.drv: set global key state

by Vitaliy Margolen

On 08/16/2010 01:06 PM, Rafał Miłecki wrote: > It's prehistoric thread already, but issue still isn't solved. I > wanted to rework that old patch but I noticed set_key_state was > already changed and it doesn't change single key state, but instead > sets whole array at every call. > > This was I can not use set_key_state handler to update my > "global_keystate" array, as I have no idea which key actually has been > changed. > > Do you see some nice solution for this problem? You can send the whole array (256 bytes isn't all that much, but on every key event - an overkill). Or you can send changes only all at once (comparing arrays isn't all that hard). Lastly you can use Xi2 to receive all key changes, however this won't pick up any injected key events (this is how it works in Wine anyway, so not a big loss of functionality). Vitaliy.

Aug. 18, 2010

Re: winex11.drv: Fix uninitialised values. (valgrind) (try 2)

by Austin English

On Tue, Aug 10, 2010 at 4:28 PM, Dan Kegel <dank(a)kegel.com> wrote: > That's for http://bugs.winehq.org/show_bug.cgi?id=20335 , right? > > Alexandre's reply to that was > "It sounds like it's hashing padding bytes. Probably should be reported to the > X.org folks." FWIW, I reported it here: https://bugs.freedesktop.org/show_bug.cgi?id=29600 -- -Austin

Aug. 17, 2010

Re: Should we expect Liberation fonts to be installed?

by Juan Lang

>> Is there a meaningful difference in the two licenses for fonts? LGPL >> is necessary for code, which gets loaded at runtime to a closed-source >> executable, but fonts contain no code, and thus aren't loaded. > > A good point, but I'm not qualified to answer that. I suspect that the > SFC would be able to answer it, if it's a serious consideration. > > FWIW, a couple links: > http://www.gnu.org/licenses/gpl-faq.html#FontException > http://www.gnu.org/licenses/license-list.html#Fonts > > and the actual license: > http://git.fedorahosted.org/git/?p=liberation-fonts.git;a=blob_plain;f=sour… The actual license contains the font exception. IANAL, but that would appear to resolve any transitive license problem that might otherwise arise from including Liberation fonts. --Juan

Aug. 17, 2010

Re: Should we expect Liberation fonts to be installed?

by Austin English

On Tue, Aug 17, 2010 at 10:38 AM, Juan Lang <juan.lang(a)gmail.com> wrote: >>> Along those lines, the hard drive space is cheap on this one. Seems >>> like Wine packagers could just include the fonts and install them >>> locally in c:\windows\fonts. >> >> The Liberation fonts are GPL licensed, Wine is LGPL. > > Is there a meaningful difference in the two licenses for fonts? LGPL > is necessary for code, which gets loaded at runtime to a closed-source > executable, but fonts contain no code, and thus aren't loaded. A good point, but I'm not qualified to answer that. I suspect that the SFC would be able to answer it, if it's a serious consideration. FWIW, a couple links: http://www.gnu.org/licenses/gpl-faq.html#FontException http://www.gnu.org/licenses/license-list.html#Fonts and the actual license: http://git.fedorahosted.org/git/?p=liberation-fonts.git;a=blob_plain;f=sour… -- -Austin

Aug. 17, 2010

Re: Wine64 debugger

by David Laight

On Tue, Aug 17, 2010 at 05:51:55PM +0200, Marcus Meissner wrote: > > The Wine code is correct as-is, but perhaps the Windows win64 code generates > only handles with 32bit. That it very likely. There are windows #defines/inline functions that convert HANDLE <=> long. Remember there are some functions that return handles as long (not void *) Also, when the windows kernel generates a HANDLE it is unlikely to know whether the app is 32bit or 64bit - so will only generate 32bit values. I also remember reading somewhere that the kernel handle table is limited to 2^24 entries - even in 64bit mode. David -- David Laight: david(a)l8s.co.uk

Aug. 17, 2010

Re: Wine64 debugger

by Marcus Meissner

On Wed, Aug 18, 2010 at 01:00:35AM +1000, Peter Urbanec wrote: > Hi, > > I'm trying to get a fairly complex Win64 application to work with > wine. I'm seeing crashes in FindNextFileW/FindNextFileA due to what > looks like a 64 bit HANDLE value being truncated to 32 bits. I > thought that I would employ winedbg to help me, but I can't get very > far. I don't have any luck with winedbg even on a simple x64 Win32 > app. Check if your code uses "int" in its FindNextFile or findfirst things. I fixed ioquake3 for this for instance. The Wine code is correct as-is, but perhaps the Windows win64 code generates only handles with 32bit. Ciao, Marcus

Aug. 17, 2010

Re: Should we expect Liberation fonts to be installed?

by Juan Lang

>> Along those lines, the hard drive space is cheap on this one. Seems >> like Wine packagers could just include the fonts and install them >> locally in c:\windows\fonts. > > The Liberation fonts are GPL licensed, Wine is LGPL. Is there a meaningful difference in the two licenses for fonts? LGPL is necessary for code, which gets loaded at runtime to a closed-source executable, but fonts contain no code, and thus aren't loaded. --Juan

Aug. 17, 2010

Wine64 debugger

by Peter Urbanec

Hi, I'm trying to get a fairly complex Win64 application to work with wine. I'm seeing crashes in FindNextFileW/FindNextFileA due to what looks like a 64 bit HANDLE value being truncated to 32 bits. I thought that I would employ winedbg to help me, but I can't get very far. I don't have any luck with winedbg even on a simple x64 Win32 app. For my simplified test, I used MSVC2005 to generate an x64 executable created from the standard MSVC2005 template Win32 application. This is a simple app that just creates an empty window. As simple as one could get for a Win32 test and it executes correctly when run as "./wine Test1.exe". When I try to execute this test app under winedbg, I get an assert failure: ./wine winedbg Test1.exe WineDbg starting on pid 001a ./programs/winedbg/memory.c:37: be_cpu_linearize: Assertion `addr->Mode == AddrModeFlat' failed. wine: Assertion failed at address 0x7fec2fa657c5 (thread 0009), starting debugger... Unhandled exception: assertion failed in 64-bit code (0x00007fec2fa657c5). Any ideas about why I can not use winedbg to run Win32 x64 code? Thanks, Peter Urbanec

Aug. 17, 2010

Re: kernel32: add stub for SetFileValidData

by Alexandre Julliard

Austin English <austinenglish(a)gmail.com> writes: > @@ -1001,6 +1001,16 @@ error: > } > > /*********************************************************************** > + * SetFileValidData (KERNEL32.@) > + */ > +BOOL WINAPI SetFileValidData( HANDLE hFile, LONGLONG ValidDataLength ) > +{ > + FIXME("stub: %p, %llu\n", hFile, ValidDataLength); You can't use %ll formats. -- Alexandre Julliard julliard(a)winehq.org

Aug. 17, 2010

Re: user32, GetUserObjectInformation implementation with index=UOI_USER_SID (try2, resend)

by Alexandre Julliard

Wolfgang Schwotzer <wolfgang.schwotzer(a)gmx.net> writes: > New patch after rebase. > Always checks return values. > Tested with Polar Protrainer 5, updater.exe > From dcb91595b33513f8df2cf4d439221d3143c8fac1 Mon Sep 17 00:00:00 2001 > From: Wolfgang Schwotzer <wolfgang.schwotzer(a)gmx.net> > Date: Sat, 24 Jul 2010 17:12:05 +0200 > Subject: GetUserObjectInformation UOI_USER_SID (try 2) This should be retrieved from the server, based on the object security token or something along those lines. -- Alexandre Julliard julliard(a)winehq.org

Aug. 17, 2010

Re: shdocvw: Remove useless menu separator

by Alexander Nicolaysen Sørnes

Tirsdag 17 august 2010 01:42:21 skrev Frédéric Delanoy : > On Mon, Aug 16, 2010 at 23:28, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: > > Not sure if it's useless. I thing it's intended to separate the static > > part of the menu (Add to favorites) from the dynamically generated > > list of favorite items that follows (which isn't implemented yet). > > In that case, shouldn't the menu separator also be auto-generated when > the list of (>=1) favorite items is generated? > How about when there's no favorite at all? > Separators should only be used to separate non-empty "sections" IMO; > otherwise they just look out of place. > > Frédéric Ideally, there would be a single grayed menu item with the text "(empty)" after the separator if no Favorites are present. This would should users where they are supposed to find favorites, and is also what native IE does. Anyway, I think this patch should be discarded. Alexander

Aug. 17, 2010

Re: [PATCH 1/4] msvcp90: Added allocator<char> 64-bit exports

by Alexandre Julliard

Piotr Caban <piotr(a)codeweavers.com> writes: > @@ -35,6 +35,12 @@ char* __stdcall MSVCP_allocator_char_address(void *this, char *ptr) > return ptr; > } > > +/* ?address@?$allocator(a)D@std@@QEBAPEADAEAD(a)Z */ > +char* __cdecl MSVCP64_allocator_char_address(void *this, char *ptr) > +{ > + return MSVCP_allocator_char_address(this, ptr); > +} > + stdcall and cdecl are equivalent on 64-bit, so you don't need the extra wrappers. -- Alexandre Julliard julliard(a)winehq.org

Aug. 17, 2010

Re: avifil32: Fix EditStreamSetInfo wine checks [try 2]

by Alexandre Julliard

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > +#define TEST_SETINFO_(m) \ > + hres = EditStreamSetInfo(stream, &info, sizeof(AVISTREAMINFO) ); \ > + ok( hres == 0, "got 0x%08X, expected 0\n", hres); \ > + hres = AVIStreamInfo(stream, &info2, sizeof(AVISTREAMINFO) ); \ > + ok( hres == 0, "got 0x%08X, expected 0\n", hres); \ > + ok( info2.m == info.m, "EditStreamSetInfo did not update "#m" parameter\n" ); > + > +#define TEST_SETINFO(m) \ > + info.m++; \ > + TEST_SETINFO_(m); \ > + \ > + info.m = 0; \ > + TEST_SETINFO_(m); Please avoid that sort of macros. Add a helper function if necessary, or just spell things out explicitly. -- Alexandre Julliard julliard(a)winehq.org

Aug. 17, 2010

Re: iPod synced with iTunes v7.6!

by Damjan Jovanovic

When Wine supports kernel USB drivers, it might be something to try. I plan to continue my work on that - some time. IIRC usbaapl.sys uses usbstor.sys, so we'd have to write a version of that for Wine as well. Damjan Jovanovic On Tue, Aug 17, 2010 at 12:33 PM, Ben Peddell <klightspeed(a)netspace.net.au> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 15/08/2010 4:28 PM, Russ Mannex wrote: >> Hello Maarten! >> >> I read your post on the WineHQ site. I was wondering if you know whether >> I am attempting something that simply will not work yet. I am running >> iTunes 7.7.1 on Wine 1.1.42. These are running on Ubuntu 10.04. iTunes >> is not showing my iPod. I have tried setting an autodetect drive E: to >> /media/IPOD, but iTunes seems to not see it there. Any help will be >> greatly appreciated, even if the answer is "will not work." Thanks. > > Apple iTunes uses a kernel-mode device driver (usbaapl.sys) to talk to > the iPod. It'd be a project all of its own (perhaps bigger than trying > to make a native clone) to try to get iTunes to talk to the iPod under Wine. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkxqZWwACgkQTHDAI68NsukS+ACgkRjYFLQB1XOtSH1N3mFOqOX+ > m58AoIees4mig4aU1StBaZHy4vbytr+g > =Ez7t > -----END PGP SIGNATURE----- > > >

Aug. 17, 2010

Re: iPod synced with iTunes v7.6!

by Ben Peddell

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/08/2010 4:28 PM, Russ Mannex wrote: > Hello Maarten! > > I read your post on the WineHQ site. I was wondering if you know whether > I am attempting something that simply will not work yet. I am running > iTunes 7.7.1 on Wine 1.1.42. These are running on Ubuntu 10.04. iTunes > is not showing my iPod. I have tried setting an autodetect drive E: to > /media/IPOD, but iTunes seems to not see it there. Any help will be > greatly appreciated, even if the answer is "will not work." Thanks. Apple iTunes uses a kernel-mode device driver (usbaapl.sys) to talk to the iPod. It'd be a project all of its own (perhaps bigger than trying to make a native clone) to try to get iTunes to talk to the iPod under Wine. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxqZWwACgkQTHDAI68NsukS+ACgkRjYFLQB1XOtSH1N3mFOqOX+ m58AoIees4mig4aU1StBaZHy4vbytr+g =Ez7t -----END PGP SIGNATURE-----

Aug. 17, 2010

Re: [PATCH 1/5] wined3d: separate driver info from GPU info

by Henri Verbeet

On 17 August 2010 03:52, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > --- > dlls/wined3d/directx.c | 276 +++++++++++++++++++++------------------ > dlls/wined3d/wined3d_private.h | 14 ++ > 2 files changed, 163 insertions(+), 127 deletions(-) > This will return inconsistent driver version numbers for Vista, Win7 and 95/98/NT4.

Aug. 17, 2010

Re: [PATCH 1/6] winealsa.drv: Init mixer on cards with a single Mic control, like snd_usb_audio mics (try 2)

by sudemon

On 03.08.2010 04:36, Jeff Cook wrote: > What compiler are you running? It works fine for me and I don't see > any errors or warnings. I also don't see any errors or warnings. Аfter 6120d7cc14522983fbc38026ab4fcb6e4a68cdf0 commit - my games just crash on start without errors (windows version is win98). Found by Regression test (16 august master VS wine-1.3.0). After this commands games don't crash: $ git bisect reset $ git show 6120d7cc14522983fbc38026ab4fcb6e4a68cdf0 | patch -p1 -R

Aug. 17, 2010

Re: Should we expect Liberation fonts to be installed?

by Austin English

On Mon, Aug 9, 2010 at 10:59 PM, Brian Vincent <brian.vincent(a)gmail.com> wrote: > Along those lines, the hard drive space is cheap on this one. Seems > like Wine packagers could just include the fonts and install them > locally in c:\windows\fonts. The Liberation fonts are GPL licensed, Wine is LGPL. -- -Austin

Aug. 17, 2010

Re: [2/2] gdiplus: Implement multi-frame image loading.

by testbot＠testbot.winehq.org

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=4486 Your paranoid android. === WVISTAADM (32 bit image) === No test summary line found

Aug. 17, 2010

Re: shdocvw: Remove useless menu separator

by Frédéric Delanoy

On Mon, Aug 16, 2010 at 23:28, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: > Not sure if it's useless. I thing it's intended to separate the static > part of the menu (Add to favorites) from the dynamically generated > list of favorite items that follows (which isn't implemented yet). In that case, shouldn't the menu separator also be auto-generated when the list of (>=1) favorite items is generated? How about when there's no favorite at all? Separators should only be used to separate non-empty "sections" IMO; otherwise they just look out of place. Frédéric

Aug. 16, 2010

Re: shdocvw: Remove useless menu separator

by Octavian Voicu

Not sure if it's useless. I thing it's intended to separate the static part of the menu (Add to favorites) from the dynamically generated list of favorite items that follows (which isn't implemented yet). Octavian

Aug. 16, 2010