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

Re: wined3d: Add surface conversion function from WINED3DFMT_YUY2 to WINED3DFMT_B8G8R8X8_UNORM (try 2)
by Stefan Dösinger 12 Feb '10

12 Feb '10

> + dst_line[x] = 0xff000000 > + | cliptobyte((c2 + r2) >> 8) << 16 /* red */ > + | cliptobyte((c2 + g2) >> 8) << 8 /* green */ > + | cliptobyte((c2 + b2) >> 8); /* blue */ I'm not sure if 0xff is the correct value for the X channel, but technically it shouldn't really matter since the X is ignored. Is there a specific reason why you set it to 0xff? Otherwise the patch looks ok to me, but I think Henri might want to take a look at it as well before it is committed.

1 0

Student Interested in Contributing to Wine
by Michael Griepentrog 12 Feb '10

12 Feb '10

Hi, I'm interested in contributing to Wine, and I'm posting here for guidance on how to get started. I'll start off with a bit about myself: I'm currently a senior majoring in Computer Science at the University of Wisconsin - Madison and will be graduating in May. Most of my upper-level coursework has pertained to operating systems and networking, but I also have experience with OpenGL and Cocoa/Objective-C. I haven't really contributed to any other projects, so this is both new and foreign to me. I'm primarily interested in improving the Wine experience on OS X. I read pages from http://wiki.winehq.org/MacOSX, but I'm not sure how much of that reflects the current direction of Wine development on Mac. What are the immediate needs for improving Wine on OS X? Off hand, I know Wine doesn't compile on Snow Leopard as a 64-bit binary (http://forum.winehq.org/viewtopic.php?p=31321) but it seems like this issue isn't limited to OS X. I'm also curious about the status of the Quartz driver, and if it's something that is still being pursued. Creating a binary distributable also seems like something that should be addressed, but I understand that isn't necessarily easy given how applications are "installed" on OS X. So whatever the current direction is for the OS X port, I would like to get involved in making it better. I look forward to hearing what suggestions you have for me. Thanks, Michael Griepentrog

2 1

Re: New Spanish translations [1/4]: dlls/hhctrl.ocx
by Paul Vriens 12 Feb '10

12 Feb '10

On 02/11/2010 02:36 PM, José Manuel Ferrer Ortiz wrote: > As requested, I'll resend these patches, splitting them one message per > module. This way it looks a lot more professional :D > > I've also fixed a few things that were wrong or could be better: > - Switched to UTF-8 encoding, and added the required 'pragma'. > - Changed language to SUBLANG_NEUTRAL. > > Thank you, Nikolay, for making me aware of these mistakes. > > Regards, > José Manuel > > Hi José, Your patches don't apply. See: http://source.winehq.org/patches/ I've spotted two issues: 1. Patches should be generated from the top-level. 2. As these are new files you also need changes to the corresponding Makefile.in file. -- Cheers, Paul.

2 2

Re: oldconfig.c: produce DEVICEMAP//SERIALCOMM entries
by James Mckenzie 12 Feb '10

12 Feb '10

Alexandre Julliard wrote at Feb 12, 2010 5:00 AM (Arizona Time Zone) about Re: oldconfig.c: produce DEVICEMAP//SERIALCOMM entries > >A C Hurst <A.Hurst(a)sheffield.ac.uk> writes: > >> Fixes bug 11811 [http://bugs.winehq.org/show_bug.cgi?id=11811] and its duplicates. >> This patch sent some time back (over a year) was ignored/lost in noise. >> Could someone review please? > >It has already been explained that this belongs in mountmgr, and should >be based on the actual devices as reported by HAL. It should also create >the corresponding NT devices and symlinks. > Alexandre: libhal does not work on Macs and I don't think it works on Sparc based equipment. How would this work for MacOSX/Solaris? James McKenzie

2 1

Re: rpcrt4: Add tests for multi-dimensional conformant arrays.
by Paul Vriens 12 Feb '10

12 Feb '10

On 02/11/2010 05:18 PM, Huw Davies wrote: > + ptr = NdrSimpleStructMarshall(&StubMsg, (unsigned char *)&memsrc, > +&fmtstr_complex_array[32] ); Hi Huw, This particular test crashes on Win9x, WinMe and NT4. They all show: ndr_marshall.c:1973: Test failed: length 96 just before the crash so maybe that would be our means to bail out? -- Cheers, Paul.

2 2

AppDB: add graphic card info field?
by burp＠nurfuerspam.de 12 Feb '10

12 Feb '10

Hi, currently the AppDB test results include (besides the obvious wine related fields) only the distribution as distinguishing attribute for a test(er). Now, my view point is the game(r) perspective. Maybe that's far too narrow, but still... Many times I looked at test results and wished to see which graphic card and driver/version was used for the test for obvious reasons: - Owners of NVidia cards with binary drivers are quite often not seeing the same set of bugs as owners of ATI cards with binary drivers - Owners of the same card are quite often having very different results with different driver versions, and it happened multiple times that an older version was working where a newer wasn't (though the other way around is naturally more common...) Recently this has become even worse IMO due to people trying to play games with the open source stack on ATI cards which is a completely different experience angle. An example for the matter is Runes of Magic: The game doesn't work on ATI cards at all, on older NVidia cards there's a workaround by disabling the GLSL shader, on newer NVidia cards it works also with GLSL shader. Most recent test results are all silver/gold/platinum based on NVidia cards, looking at the full history there's a nice spectrum of garbage/bronze (ATI) alternating with silver/gold/platinum (NVidia). As an average user, this tends to be quite confusing if you don't look at the details. This is *not* just a matter of bugs, but also of features: World of Warcraft on ATI/Catalyst wasn't showing an indoor map for about 2 years (no pbuffers in ATI drivers), while the feature was fine on NVidia, while OpenGL hardware cursor is still available on neither card (missing feature of WoW's OpenGL backend). (TLDR starts here >>) How are the chances that a patch to include graphics chip, driver name and version into test results would be accepted? Or would it be more welcome to split affected applications into versions by graphic card/driver? (I.e.: Runes of Magic: 2.x on ATI/Catalyst, World of Warcraft: 3.3.x on Intel/OpenSource, ...) Cheers, $B1 $28 -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

1 0

Re: [msi/tests] Fix a test failure on Win9x/WinMe
by Hans Leidekker 12 Feb '10

12 Feb '10

On Friday 12 February 2010 12:15:48 Paul Vriens wrote: > Changelog > Fix a test failure on Win9x/WinMe Can you find the string "msi test font" anywhere in the registry after running that test? -Hans

2 1

Re: [PATCH] shell32/tests: add tests for the parser of SHELLEXECUTEINFO.lpFile (resend)
by Paul Vriens 12 Feb '10

12 Feb '10

On 02/11/2010 03:37 PM, Ilya Basin wrote: > Hi! This should expose this bug: > http://bugs.winehq.org/show_bug.cgi?id=19385 ( the 'wine start' > launcher does not open MS Office documents that have spaces in their > path ). Although the title is misleading, many other tickets are > marked as duplicates of it. > It's not about spaces. It's about sometimes unneeded parsing of > SHELLEXECUTEINFO.lpFile, trying to extract arguments from it. Why? > Or maybe some other part of wine relies on this behavior? > Tested on 98 se, 2k& xp. > > ...obvious mistakes become visible only after you hit the "send" > button. So I apologize beforehand. Hi Ilya, As Wine doesn't do the right thing (according to your tests), all failing Wine tests should be marked as such. We have a todo_wine construct for that. > > --- > dlls/shell32/tests/shlexec.c | 106 ++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 106 insertions(+), 0 deletions(-) > > diff --git a/dlls/shell32/tests/shlexec.c b/dlls/shell32/tests/shlexec.c > index c673f0a..fb5e6b7 100644 > --- a/dlls/shell32/tests/shlexec.c > +++ b/dlls/shell32/tests/shlexec.c > @@ -797,6 +797,10 @@ static const char* testfiles[]= > "%s\\test file.sde", > "%s\\test file.exe", > "%s\\test2.exe", > + "%s\\simple.shlexec", > + "%s\\drawback_file.noassoc", > + "%s\\drawback_file.noassoc foo.shlexec", > + "%s\\drawback_nonexist.noassoc foo.shlexec", > NULL > }; > > @@ -852,6 +856,107 @@ static filename_tests_t noquotes_tests[]= > {NULL, NULL, 0} > }; > > +static void test_lpFile_parsed(void) > +{ > + /* basename tmpdir */ > + const char* shorttmpdir; > + > + const char *testfile; > + char fileA[MAX_PATH]; > + > + int rc; > + int expected; > + > + BOOL iswin9x = FALSE; > + BOOL isreallyNT = FALSE; > + > + /* detect win ver */ > + { > + DWORD dwVersion = GetVersion(); > + DWORD dwWindowsMajorVersion = (DWORD)(LOBYTE(LOWORD(dwVersion))); > + DWORD dwMinorVersion = (DWORD)(HIBYTE(LOWORD(dwVersion))); > + DWORD dwBuild; > + > + if (dwVersion< 0x80000000) // Windows NT/2000, Whistler No C++ comments please. > + dwBuild = (DWORD)(HIWORD(dwVersion)); > + else if (dwWindowsMajorVersion< 4) // Win32s > + dwBuild = (DWORD)(HIWORD(dwVersion)& ~0x8000); > + else // Windows 95/98/Me > + { > + dwBuild = 0; > + iswin9x = TRUE; > + isreallyNT = NULL != GetModuleHandle("ntdll"); > + } > + } We generally do not want any real version checking in the tests. Tests should decide based on behavior on what platform they are. > + > + GetTempPathA(sizeof(fileA), fileA); > + shorttmpdir = tmpdir + strlen(fileA); > + > + /* ensure tmpdir is in %TEMP% */ > + SetEnvironmentVariableA("TEMP", fileA); Why is this necessary? > + > + #define TEST_LPFILE_PARSED_OK_() (rc==expected || rc>32&& expected>32) > + #define TEST_LPFILE_PARSED_OK() ok(TEST_LPFILE_PARSED_OK_(), "expected %s (%d), got %s (%d), lpFile: %s \n", expected==33 ? "success" : "failure", expected, rc> 32 ? "success" : "failure", rc, fileA) > + > + /* existing "drawback_file.noassoc" prevents finding "drawback_file.noassoc foo.shlexec" on wine */ > + testfile = "%s\\drawback_file.noassoc foo.shlexec"; > + expected = 33; sprintf(fileA, testfile, tmpdir); > + rc=shell_execute(NULL, fileA, NULL, NULL); > + TEST_LPFILE_PARSED_OK(); > + > + /* if quoted, existing "drawback_file.noassoc" not prevents finding "drawback_file.noassoc foo.shlexec" on wine */ > + testfile = "\"%s\\drawback_file.noassoc foo.shlexec\""; > + expected = 33; sprintf(fileA, testfile, tmpdir); > + rc=shell_execute(NULL, fileA, NULL, NULL); > + TEST_LPFILE_PARSED_OK(); > + > + /* error should be 2, not 31 */ > + testfile = "\"%s\\drawback_file.noassoc\" foo.shlexec"; > + expected = 2; sprintf(fileA, testfile, tmpdir); > + rc=shell_execute(NULL, fileA, NULL, NULL); > + TEST_LPFILE_PARSED_OK(); > + > + /* ""command"" not works on wine (and real win9x and w2k) */ > + testfile = "\"\"%s\\drawback_file.noassoc foo.shlexec\"\""; > + expected = iswin9x&& !isreallyNT || dllver.dwMajorVersion<= 5 ? 2 : 33; sprintf(fileA, testfile, tmpdir); > + rc=shell_execute(NULL, fileA, NULL, NULL); > + TEST_LPFILE_PARSED_OK(); > + > + /* nonexisting "drawback_nonexist.noassoc" not prevents finding "drawback_nonexist.noassoc foo.shlexec" on wine */ > + testfile = "%s\\drawback_nonexist.noassoc foo.shlexec"; > + expected = 33; sprintf(fileA, testfile, tmpdir); > + rc=shell_execute(NULL, fileA, NULL, NULL); > + TEST_LPFILE_PARSED_OK(); > + > + /* is SEE_MASK_DOENVSUBST default flag? Should only be when XP emulates 9x */ > + { Any particular reason for this indentation? -- Cheers, Paul.

2 2

Building list of great demos for Wine
by Dan Kegel 11 Feb '10

11 Feb '10

[Sent this to wine-users, but maybe wine-devel folks are more likely to give demos and need a list like this.] I'm putting together a list of impressive freely-downloadable demos (or apps) that run flawlessly under Wine. i.e. platinum (no hacks, patches, or recipes needed), high production values, and good enough to have gotten some notice and approval at Amazon, Wikipedia, or some other authoritative site. What I've got so far is at http://wiki.winehq.org/GreatDemos I'll keep plugging away at it, but it'd be great if other people could add known great demos there. Thanks! - Dan

5 7

Re: msxml3/tests: Some refcount tests
by Nikolay Sivov 11 Feb '10

11 Feb '10

Forget about it, not so useful yet but adds even more questions. Ref count still doesn't match anyway.

1 0