Re: [PATCH] shell32/tests: add tests for the parser of SHELLEXECUTEINFO.lpFile (resend)
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 0x8000) // 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 || rc32 expected32)
+#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.
Re: Intercepting GDI calls
On Fri, Feb 12, 2010 at 8:01 AM, Charles Davis cda...@mymail.mines.edu wrote: Jui-Hao Chiang wrote: Hi, all: I am currently starting a project which tries to run a window application on one (source) machine, and display on another (destination) machine. Of course, the VNC or X11 forwarding technique can achieve the same goal, but I am trying to reduce the bandwidth by not transferring the video frame buffer but transfer the GDI function calls instead. Uhhh... That's kinda how X11 works. I mean, sending drawing and windowing calls as opposed to transferring the entire FB. What do you hope to accomplish with this? Given what I just told you, why won't X11 suffice? The way I can see is try to intercept all the calls inside gdi32.dll, and forward the calls and parameters to remote machine by using some RPC library, and then replay the GDI calls on the destination machine. However, I have two doubts: (1) It seems like the user32.dll is actually handling the window, menu, and cursor. That's right. Does the drawing of menu and cursor depends on user-level gdi32.dll? Yes it does. But bear in mind that gdi32 doesn't know how to draw menus and cursors, and other things. It only draws what you tell it to draw. You have to specify what you want to draw in terms of primitive shapes. That's what user32 does. or other kernel-level dlls? What kernel-level DLLs? Wine is entirely user mode. Don't let the presence of ntoskrnl.exe fool you; that's done in user mode, too :). (2) It seems that there is no corresponding win32k.sys implementation in wine, and the user-level GDI calls seems to be forwarded to winex11.drv, right? That's correct. (In the future, that might change, especially on a certain OS made by a company named after fruit. But rest assured, there's not going to be a win32k.sys implementation anytime soon.) I wander is there any good way or a place inside the source to do this kind of interception? If you really want to go through with this, what you want to do is write your own driver, similar to winex11.drv. In fact, I suggest using it as a base. Then you can forward the calls to some other machine (running Windows or some other OS) with RPC or some such mechanism. Chip I also agree that you are basically trying to duplicate X11. It is a lot of work to emulate all gdi32 / user32 calls yourself. Further I doubt you can achieve similar performance as X11. I would investigate in better X11 encryption methods. Have you thought about using NX server? It reduces bandwidth a lot compared to plain X11. Roderick
Student Interested in Contributing to Wine
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
Re: cmd: Add test for %~dp0 expansion (bug 21382)
Dan Kegel d...@kegel.com writes: --- /dev/null +++ b/programs/cmd/tests/test_dp0.cmd @@ -0,0 +1,10 @@ +...@echo off +echo Begin test for bug 21382 +rem On old wine, ~dp0 was always current directory rather than directory containing batch file +echo %~dp0 +mkdir dummydir +cd dummydir +echo %~dp0 +cd .. +rmdir dummydir +echo End test for bug 21382 diff --git a/programs/cmd/tests/test_dp0.cmd.out b/programs/cmd/tests/test_dp0.cmd.out new file mode 100644 index 000..8c38153 --- /dev/null +++ b/programs/cmd/tests/test_dp0.cmd.out @@ -0,0 +1,4 @@ +Begin test for bug 21382 +...@pwd@\ +...@pwd@\ +End test for bug 21382 Please don't create new files for every small test, this will become unmanageable very quickly. Unless there are reasons to split them, everything should go in a single .cmd file. Also don't use bug numbers, add some meaningful message instead. The code must be understandable without reference to bugzilla. -- Alexandre Julliard julli...@winehq.org
Re: rpcrt4: Add tests for multi-dimensional conformant arrays.
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.
Re: rpcrt4: Add tests for multi-dimensional conformant arrays.
On Fri, Feb 12, 2010 at 11:53:30AM +0100, Paul Vriens wrote: 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? Hi Paul, Yes, looks like it's broken on those platforms; the NdrSimpleStructMarshall call is crashing. Are you happy to send in a patch? Huw.
Re: oldconfig.c: produce DEVICEMAP//SERIALCOMM entries
A C Hurst a.hu...@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 Julliard julli...@winehq.org
Re: [PATCH] shell32/tests: add tests for the parser of SHELLEXECUTEINFO.lpFile (resend)
On 02/12/2010 12:39 PM, Ilya Basin wrote: Thanks for review. Not sending to wine-patches this time. New patch is in the bottom. What's better, to attach a generated patch or to use it as a message body? Depends on your mail client I guess. I usually attach but there are others who inline. PV Why is this necessary? /* ensure tmpdir is in %TEMP%: GetTempPath() can succeed even if TEMP is undefined */ But do your tests actually rely on %TEMP% being defined? Not having a TEMP (or TMP) will probably makes loads of tests fail and I doubt one has a valid config without those. Also when you sent a newer patch that has changes you should mark it as 'try x' instead of 'resend'. 'Resend' is used when you think the patch has been missed by AJ for example. -- Cheers, Paul.
Re: [msi/tests] Fix a test failure on Win9x/WinMe
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
Re: [msi/tests] Fix a test failure on Win9x/WinMe
On 02/12/2010 01:28 PM, Hans Leidekker wrote: 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 Wait, this is probably because you used W-functions (just spotted). The proper fix would probably be to change those 2 in A-ones. I'll have a look later today. This patch should be dismissed. -- Cheers, Paul.
AppDB: add graphic card info field?
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
Re: rpcrt4: Add tests for multi-dimensional conformant arrays.
On Fri, Feb 12, 2010 at 11:27:38AM +, Huw Davies wrote: On Fri, Feb 12, 2010 at 11:53:30AM +0100, Paul Vriens wrote: 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? Hi Paul, Yes, looks like it's broken on those platforms; the NdrSimpleStructMarshall call is crashing. Are you happy to send in a patch? Btw, I have a fix for the 64 bit failures. It'll conflict with your patch, so I'll send it after yours is committed. Huw.
Re: oldconfig.c: produce DEVICEMAP//SERIALCOMM entries
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.hu...@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
Re: oldconfig.c: produce DEVICEMAP//SERIALCOMM entries
James Mckenzie jjmckenzi...@earthlink.net writes: 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? Obviously, using whatever is the equivalent on those platforms, same way we do for disk devices. -- Alexandre Julliard julli...@winehq.org
Re: New Spanish translations [1/4]: dlls/hhctrl.ocx
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.
Re: New Spanish translations [1/4]: dlls/hhctrl.ocx
On 02/12/2010 04:41 PM, Paul Vriens wrote: 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. Just saw that your original patches where created from the top-level. I guess it's due to the patchwatcher site disliking non Git patches? -- Cheers, Paul.
Re: New Spanish translations [1/4]: dlls/hhctrl.ocx
Paul Vriens paul.vriens.w...@gmail.com writes: Just saw that your original patches where created from the top-level. I guess it's due to the patchwatcher site disliking non Git patches? Yes, the filtering script has some issues with non-git patches that only create new files. I put in some fixes, but using git patches when adding files is strongly recommended. -- Alexandre Julliard julli...@winehq.org
Re: Student Interested in Contributing to Wine
Hi Michael, On Fri, Feb 12, 2010 at 1:54 AM, Michael Griepentrog mgriepent...@wisc.edu wrote: 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. A quartz driver is far beyond the scope of a SoC project. Stay away from that. Otherwise, you might want to play around with Wine on MacOS yourself for a while, and get the hang of it. It becomes pretty clear pretty quickly that using a Windows app on MacOS doesn't feel much like a Mac app. Much of that we can't change, but some of it could be better. It looks and behaves more like a UNIX port, which of course it is, so if you can think of ways to improve it, that'll go some ways toward a credible application. There are probably a few open bugs about Wine on MacOS too, you might have a look at those. Good luck, --Juan
Re[2]: [PATCH] shell32/tests: add tests for the parser of SHELLEXECUTEINFO.lpFile (resend)
Thanks for review. Not sending to wine-patches this time. New patch is
in the bottom. What's better, to attach a generated patch or to use it
as a message body?
PV 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.
PV Hi Ilya,
PV As Wine doesn't do the right thing (according to your tests), all
PV failing Wine tests should be marked as such. We have a todo_wine
PV construct for that.
added 4 todo_wine's
PV We generally do not want any real version checking in the tests. Tests
PV should decide based on behavior on what platform they are.
added GetProcAddress(hkernel32, AttachConsole) to detect XP/2k3
removed special case when XP emulates 9x because can't do it without
using GetVersion().
+
+GetTempPathA(sizeof(fileA), fileA);
+shorttmpdir = tmpdir + strlen(fileA);
+
+/* ensure tmpdir is in %TEMP% */
+SetEnvironmentVariableA(TEMP, fileA);
PV Why is this necessary?
/* ensure tmpdir is in %TEMP%: GetTempPath() can succeed even if TEMP is
undefined */
+/* is SEE_MASK_DOENVSUBST default flag? Should only be when XP emulates
9x */
+{
PV Any particular reason for this indentation?
OK
---
dlls/shell32/tests/shlexec.c | 87 ++
1 files changed, 87 insertions(+), 0 deletions(-)
diff --git a/dlls/shell32/tests/shlexec.c b/dlls/shell32/tests/shlexec.c
index c673f0a..d575d22 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,88 @@ 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;
+
+HMODULE hkernel32 = GetModuleHandle(kernel32);
+BOOL isreallyXP2k3plus = NULL != GetProcAddress(hkernel32,
AttachConsole);
+
+GetTempPathA(sizeof(fileA), fileA);
+shorttmpdir = tmpdir + strlen(fileA);
+
+/* ensure tmpdir is in %TEMP%: GetTempPath() can succeed even if TEMP is
undefined */
+SetEnvironmentVariableA(TEMP, fileA);
+
+#define TEST_LPFILE_PARSED_OK_() (rc==expected || rc32 expected32)
+#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);
+todo_wine { 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) */
+if (isreallyXP2k3plus) {
+testfile = \\%s\\simple.shlexec\\;
+expected = 33; sprintf(fileA, testfile, tmpdir);
+rc=shell_execute(NULL, fileA, NULL, NULL);
+todo_wine { TEST_LPFILE_PARSED_OK(); }
+} else {
+win_skip(ShellExecute('\\command\\', ...) only works on XP/2k3 or
newer\n);
+}
+
+/* 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
(XP bug or real 95 or ME behavior ?) */
+testfile = %%TEMP%%\\%s\\simple.shlexec;
+expected = 2; sprintf(fileA, testfile, shorttmpdir);
+rc=shell_execute(NULL, fileA, NULL, NULL);
+todo_wine { TEST_LPFILE_PARSED_OK(); }
+
+/*
Re: wined3d: Add surface conversion function from WINED3DFMT_YUY2 to WINED3DFMT_B8G8R8X8_UNORM (try 2)
+dst_line[x] = 0xff00 +| 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.
Re: Re[2]: [PATCH] shell32/tests: add tests for the parser of SHELLEXECUTEINFO.lpFile (resend)
Ilya Basin basini...@gmail.com wrote at Feb 12, 2010 4:39 AM about Re[2]: [PATCH] shell32/tests: add tests for the parser of SHELLEXECUTEINFO.lpFile (resend) Thanks for review. Not sending to wine-patches this time. New patch is in the bottom. What's better, to attach a generated patch or to use it as a message body? Generated patch, if at all possible. That way we can use git apply to install. James McKenzie
