June 2010 - Wine-devel - list.winehq.org

RE: msxml3: Avoid SysStringLen() testing for an empty string in ::createNode()
by Greg Geldorp 14 Jun '10

14 Jun '10

> From: Reece Dunn <msclrhd(a)googlemail.com> > > msxml3 is not present on NT4, so CLSID_XMLHTTPRequest is not > registered. This does not fail on the test page, as the msxml3 tests > are skipped when msxml3.dll is not present. > > It would probably be better to issue a win_skip in this instance, but > it is not relevant to your change. TestBot uses a different algorithm to check if a test should be skipped. Winetest.exe checks the name of the test and obtains the name of the DLL being tested from that (msxml3_test.exe => msxml3.dll). If that DLL is not present, winetest.exe skips the test. TestBot checks the import table of the test executable, and if any of the statically imported DLLs are missing it skips the test. In this case, msxml3.dll is not statically linked, so it will not be skipped by TestBot on NT4. TestBot should probably check the test name too. Ge.

1 0

Two enhancement requests for winetricks
by Joerg-Cyril.Hoehle＠t-systems.com 14 Jun '10

14 Jun '10

Hi, Jan Hoogenraad wrote: >Each debugging request for wine states that I should remove all winetricks. AppDB should request something similar: minimal use of winetricks. >However I have no way to tell, and no way to safely remove them. IMHO one solution to your problem is to learn to use different .wine prefixes. Both developers and AppDB users want a repeatable process to make the app run (or crash). If you install all your software into a single .wine hierarchy (like you'd do on MS-Windows), then you cannot tell anyone what you did to make the app work in Wine. All you have is "I started with Wine-0.9.48, upgraded to wine-1.1.6 at some time, now to wine-1.2rc2, used "winetricks X" and Y, perhaps I used "winetricks directx" but I can't remember for sure, I installed apps A, B and C (they may have installed more components) and I edited the registry a few times. Given all that, app Z works fine in on my machine." This is a mess much like a typical MS-Windows installation. With Wine, you can do better than that. What people want to hear from you is as follows: - Create a fresh .wine prefix with wine-X.Y; - Install Indeo Video codecs via "winetricks indeo" because I found out that the app expects them but does not install them itself; - Install the app from CD; - From a DirectX install into a separate .wine-* prefix, solely copy d3dx9_36.dll into system32/ (or the app's directory) - Change setting Y in winecfg, e.g. native d3dx9_36; - App Z works (or crashes like that ...). That is a minimal instruction set. I have like a dozen .wine-* directory hierarchies. I never use .wine itself except for regression testing, such that I can rm -rf ~/.wine and create a fresh one at any time. That's why I don't need an uninstaller. rm -rf ~/.wine-xyz or rm -rf ~/wineapps/... *is* the uninstaller (.wine-xyz/drive_c/Programs/Apps/ symlinks to $HOME/wineapps such that the apps live independently on a particular .wine prefix). Regards, Jörg Höhle

3 2

Re: [PATCH 4/6] shdocvw: Silence QueryService traces in non-interactive runs.
by testbot＠testbot.winehq.org 14 Jun '10

14 Jun '10

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=2620 Your paranoid android. === W98SE (32 bit webbrowser) === webbrowser.c:1216: Test failed: unexpected call UpdateUI webbrowser.c:295: Test failed: unexpected nsCmdID 21 webbrowser.c:239: Test failed: unexpected call QueryStatus_STOP === WNT4WSSP6 (32 bit webbrowser) === webbrowser.c:2479: Test failed: CoCreateInterface failed: 80040154 webbrowser.c:2479: Test failed: CoCreateInterface failed: 80040154 === W2KPROSP4 (32 bit webbrowser) === Timeout === W2K8SE (32 bit webbrowser) === webbrowser.c:1216: Test failed: unexpected call UpdateUI webbrowser.c:295: Test failed: unexpected nsCmdID 21 webbrowser.c:239: Test failed: unexpected call QueryStatus_STOP webbrowser.c:1216: Test failed: unexpected call UpdateUI webbrowser.c:295: Test failed: unexpected nsCmdID 21 webbrowser.c:239: Test failed: unexpected call QueryStatus_STOP webbrowser.c:295: Test failed: unexpected nsCmdID 28

1 0

Re: msxml3: Avoid SysStringLen() testing for an empty string in ::createNode()
by testbot＠testbot.winehq.org 13 Jun '10

13 Jun '10

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=2617 Your paranoid android. === WNT4WSSP6 (32 bit domdoc) === domdoc.c:2743: Test failed: CoCreateInstance(CLSID_XMLHTTPRequest) should have succeeded instead of failing with 0x80040154

3 2

Re: [1/4] Riched20:Moved-code-to-update-wrap-position-to-ME_WrapTextParagraph
by Austin English 13 Jun '10

13 Jun '10

On Sun, Jun 13, 2010 at 1:02 PM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > This is patch 1/4 to implement EM_FORMATRANGE. This patch does not change > any of the code but moves code from ME_WrapMarkedParagraphs to > ME_WrapTextParagraph. > > The bug report #6254, which this is a solution to is marked as needed for > Wine 1.2 > > Thanks to Dylan Smith who helped segegrate and clean up the original code > proposed by Tony Rollo and further worked on by Lei Zhang and myself. You forgot the patch. -- -Austin

2 1

Re: msi: Print more information on error
by Alexandre Julliard 13 Jun '10

13 Jun '10

André Hentschel <nerv(a)dawncrow.de> writes: > i had that case with > err:msi:ACTION_CallDllFunction GetProcAddress for function L"findApplications" in dll L"C:\\users\\dawncrow\\Temp\\msi94eb.tmp" failed > so you see that just the function is not info enough. I don't see that. The name of the temp file is not meaningful. -- Alexandre Julliard julliard(a)winehq.org

1 0

Anotated 'make test' log
by Max TenEyck Woodbury 13 Jun '10

13 Jun '10

I'm trying to get a start on helping with wine development. I'm still in the process of reading the developer's guide, and I think I am making progress on that. As a test of my understanding, I started to annotate the output of 'make -k test'. I'd like your opinion on the usefulness of this. A few reservations: * I started from the top of the log. If I continue, I will be selecting sections that I find interesting. * I am not going to produce patches until someone says that the annotations are going in the right direction. This will change when I become more familiar with the community's opinion of my efforts. ../../../tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p advapi32_test.exe.so cred.c && touch cred.ok Note: This test is expected to produce 2 error reports call is pCredReadA(TEST_TARGET_NAME, -1, 0, &cred) implementation at dll/advavi32/cred.c - CredReadA parameter names: TargetName, Type, Flags, *Credentials conversion to CreadReadW implementation at same - CredReadW fixme:cred:CredReadW unhandled type -1 Fixup: Convert 'if (Type != CRED_TYPE_GENERIC && Type != CRED_TYPE_DOMAIN_PASSWORD)' to a switch(case?) with all known types enumerated. Put unimplemented types at the end with a 'fixup' then fall through to the default case which sets the error code and fails. Note: In other words, don't request fixup for improper type codes. call is pCredReadA(TEST_TARGET_NAME, CRED_TYPE_GENERIC, 0xdeadbeef, &cred) see above for details fixme:cred:CredReadW unhandled flags 0xdeadbeef Fixup: Get a list of all known flags. Build a mask for all of them. Check for any unknown flags set and issue a warning if there are any. Build a mask of all implemented flags (currently none) and issue a fixme if any of those are set. Note: In other words, don't request fixup for undefined flags set. Question: Should this be an failure exit? Alternatively, should there be a list of flags that, if set trigger a failure exit? Note: Only fail if the flags indicate an option that can not be ignored. Note: No sucess tests. Note: Possible memory leak of returned credentials buffers? call is pCredWriteA(&new_cred, 0) implementation at same - CredWriteA parameter names: Credential, Flags new_cred.UserName = 'winetest' new_cred.TargetName = TEST_TARGET_NAME conversion to CredWriteW implementation at same - CredWriteW err:cred:CredWriteW bad username L"winetest" Note: This is an expected error. Note: Should it mention 'syntax' since it is checking for \ and @? Note: No bad flags test - Fixup per CredReadW above. Note: No bad type test - Fixup per CredReadW above. call is pCredWriteA(&new_cred, 0) see above for details. new_cred.UserName = NULL err:cred:CredWriteW bad username (null) Note: This is an expected error. Note: No sucess tests. Note: Possible memory leak of returned credentials buffers? call is pCredDeleteA(TEST_TARGET_NAME, -1, 0) implementation at same - CredDeleteA parameter names: TargetName, Type, Flags conversion to CredDeleteW fixme:cred:CredDeleteW unhandled type -1 Fixup: see CredReadA above call is pCredDeleteA(TEST_TARGET_NAME, CRED_TYPE_GENERIC, 0xdeadbeef) se above for details. fixme:cred:CredDeleteW unhandled flags 0xdeadbeef fixup: see CreadReadA above Note: No sucess tests. Note: Test order is questionable. A better order would be Write, Read then Delete with tests that are expected to succeed added. call is pCredReadDomainCredentialsA(&info, 0, &count, &creds implementation at same - CredReadDomainCredentialsA parameter names: TargetInformation, Flags, *Size, **Credentials conversion to CredReadDomainCredentialsW fixme:cred:CredReadDomainCredentialsW (0x15ddf8, 0x0, 0x33fd18, 0x33fc4c) stub Fixup: No suggestion

1 0

re: WINE and demoscene products
by Dan Kegel 12 Jun '10

12 Jun '10

Yeah, that's pretty cool. I ran Lifeforce as a demo at several talks last year, it was very convincing. (Although, frankly, running retail DVD-ROM games on day of beta or release is an even more convincing feat if we can pull it off.) As somebody else pointed out, there are already appdb entries for quite a few demos: http://appdb.winehq.org/objectManager.php?sClass=category&iId=95 It'd be nice if someone filled in any missing ones there. (I'm not sure how much overlap there is between demos and real games, but the idea of a really small graphical app is appealing, one would expect they'd be easier to diagnose?) - Dan

2 1

Three year sever outstanding bug requiring minor fix
by velociraptor Genjix 12 Jun '10

12 Jun '10

Hey, Please look into this issue, http://bugs.winehq.org/show_bug.cgi?id=15118 It seems like a fairly trivial fix which renders this application useless. A detailed description of the implementation needed is provided in that ticket. Thank you _________________________________________________________________ http://clk.atdmt.com/UKM/go/197222280/direct/01/ Do you have a story that started on Hotmail? Tell us now

5 4

snoop,relay,trace
by Hin-Tak Leung 12 Jun '10

12 Jun '10

I am thinking of going barbaric and doing WINEDEBUG=+relay,+snoop,+trace to see how mt.exe get the wrong image size in http://bugs.winehq.org/show_bug.cgi?id=22812 and just grep for the wrong/right sizes (0x "2b000", "176128", 0x "2b200", "176640" ) to see where mt gets it from but none turn up. Since it is a relatively simple command line I thought that would work. or is there any other WINEDEBUG= is worth trying? Also I am thinking since the image size is normally padded to 0x1000, (and it says so), so a PE with an image size that looks like NNNNN200 is automatically wrong, is that correct?

1 0