April 2011 - Wine-Devel - list.winehq.org

Re: Project: x86 to ARM binary translator

by Alexandre Julliard

Yale Zhang <yzhang1985(a)gmail.com> writes: > 2. What's the best design: whole system VM (qemu) or process VM (qemu & > wine)? > > Process VM: > > + easier to incorporate 3D acceleration at API level > + uses less memory > + better performance (e.g. no need for MMU translation when accessing > memory) > + much better integration with host OS > - needs to maintain custom Windows API implementation (Wine) > > Whole system VM: > > + simpler, more unified to implement > + much better support for apps that are dependent on new, proprietary, > obscure Windows libraries, interfaces (moot because Office, Matlab, etc > will soon be available for ARM) > > Given the aims of only running legacy applications and games, it seems a > foregone conclusion that Wine's process VM approach is best. Comments? I think you underestimate the complexity of doing the emulation at the API level. You should first make it work by running the whole process under the emulator; once you get this right, then you can start thinking about running some parts natively. -- Alexandre Julliard julliard(a)winehq.org

April 2, 2011

Re: Why do the wintab32 tests load the dll at runtime?

by Francois Gouget

On Thu, 31 Mar 2011, John Klehm wrote: > On Thu, Mar 31, 2011 at 5:27 AM, Francois Gouget <fgouget(a)free.fr> wrote: > > > > The subject says it all. > > Why do the wintab32 tests load the dll at runtime instead of simply > > linking with wintab32.dll? > > It was to make it easier when the dll wasn't around. I pretty sure > wintab32 is not included by default with XP. Ok. I'll keep it as is then. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ If you think the whole world revolves around you, quit staring at the GPS display while driving.

April 2, 2011

Re: ntdll: Remove more path trailing chars.

by Nikolay Sivov

On 4/2/2011 10:51, Vincent Pelletier wrote: > Add tests via FindFirstFileA. > Fixes bug 22635. > --- > dlls/kernel32/tests/file.c | 119 ++++++++++++++++++++++++++++++++++++++++++++ > dlls/ntdll/path.c | 8 +++- > 2 files changed, 126 insertions(+), 1 deletions(-) > > diff --git a/dlls/kernel32/tests/file.c b/dlls/kernel32/tests/file.c > index 4e8136a..dae8eee 100644 > --- a/dlls/kernel32/tests/file.c > +++ b/dlls/kernel32/tests/file.c > @@ -2164,6 +2164,125 @@ static void test_FindFirstFileA(void) > err = GetLastError(); > ok ( handle == INVALID_HANDLE_VALUE, "FindFirstFile on %s should Fail\n", buffer2 ); > ok ( err == ERROR_PATH_NOT_FOUND, "Bad Error number %d\n", err ); > + > + /* try FindFirstFileA on "test-dir" with forbidden chars */ > + CreateDirectoryA("test-dir", NULL); > + _lclose(_lcreat("test-file", 0)); > + > +#define FindFirstFileA_ok(value, caption, todo) { \ > + if(todo) { \ > + todo_wine ok(value, caption);\ > + } else { \ > + ok(value, caption);\ > + } \ > + } > + > +#define test_FindFirstFileA_with(x, y, todo) { \ > + handle = FindFirstFileA(x,&data);\ > + if (y) { \ > + FindFirstFileA_ok( \ > + handle != INVALID_HANDLE_VALUE, \ > + "FindFirstFile on "x" should succeed\n", \ > + todo);\ > + } else { \ > + FindFirstFileA_ok( \ > + handle == INVALID_HANDLE_VALUE, \ > + "FindFirstFile on "x" should fail\n", \ > + todo);\ > + } \ > + if (handle != INVALID_HANDLE_VALUE) \ > + ok( FindClose(handle) == TRUE, "Failed to close handle "x"\n"); \ > + } > + > + /* Disallowed chars being ignored: */ > + test_FindFirstFileA_with("test-dir/.", 1, 0); > + test_FindFirstFileA_with("test-dir\\.", 1, 0); > + test_FindFirstFileA_with("test-dir<.", 1, 0); > + test_FindFirstFileA_with("test-dir< ", 1, 0); > + test_FindFirstFileA_with("test-dir>.", 1, 0); > + test_FindFirstFileA_with("test-dir> ", 1, 0); > + test_FindFirstFileA_with("test-dir\".", 1, 0); > + test_FindFirstFileA_with("test-dir\" ", 1, 0); > + test_FindFirstFileA_with("test-dir/>", 1, 0); > + test_FindFirstFileA_with("test-dir/<", 1, 0); > + test_FindFirstFileA_with("test-dir/\"", 1, 0); > + test_FindFirstFileA_with("test-dir<>", 1, 0); > + test_FindFirstFileA_with("test-dir<<", 1, 0); > + test_FindFirstFileA_with("test-dir<\"", 1, 0); > + test_FindFirstFileA_with("test-dir>>", 1, 0); > + test_FindFirstFileA_with("test-dir><", 1, 0); > + test_FindFirstFileA_with("test-dir>\"", 1, 0); > + test_FindFirstFileA_with("test-dir\">", 1, 0); > + test_FindFirstFileA_with("test-dir\"<", 1, 0); > + test_FindFirstFileA_with("test-dir\"\"", 1, 0); > + test_FindFirstFileA_with("test-dir\\<", 1, 0); > + test_FindFirstFileA_with("test-dir\\>", 1, 0); > + test_FindFirstFileA_with("test-dir\\\"", 1, 0); > + /* But space prevents forward& back slashes from being stripped */ > + test_FindFirstFileA_with("test-dir<", 0, 1); > + test_FindFirstFileA_with("test-dir/ ", 0, 0); > + test_FindFirstFileA_with("test-dir/ .", 0, 0); > + test_FindFirstFileA_with("test-dir/. ", 0, 1); > + test_FindFirstFileA_with("test-dir\\ ", 0, 0); > + test_FindFirstFileA_with("test-dir\\ .", 0, 0); > + test_FindFirstFileA_with("test-dir\\. ", 0, 1); > + test_FindFirstFileA_with("test-dir/. ", 0, 1); > + test_FindFirstFileA_with("test-dir\\. ", 0, 1); > + /* But forward& back slashes are not tolerated on a file */ > + test_FindFirstFileA_with("test-file/>", 0, 1); > + test_FindFirstFileA_with("test-file/<", 0, 1); > + test_FindFirstFileA_with("test-file/\"", 0, 1); > + test_FindFirstFileA_with("test-file<>", 1, 0); > + test_FindFirstFileA_with("test-file<<", 1, 0); > + test_FindFirstFileA_with("test-file<\"", 1, 0); > + test_FindFirstFileA_with("test-file>>", 1, 0); > + test_FindFirstFileA_with("test-file><", 1, 0); > + test_FindFirstFileA_with("test-file>\"", 1, 0); > + test_FindFirstFileA_with("test-file\">", 1, 0); > + test_FindFirstFileA_with("test-file\"<", 1, 0); > + test_FindFirstFileA_with("test-file\"\"", 1, 0); > + test_FindFirstFileA_with("test-file\\<", 0, 1); > + test_FindFirstFileA_with("test-file\\>", 0, 1); > + test_FindFirstFileA_with("test-file\\\"", 0, 1); > + /* Even when many */ > + test_FindFirstFileA_with("test-dir\"\"\"\"\"", 1, 0); > + test_FindFirstFileA_with("test-dir<<<><><>\"\"\"\"<<<>", 1, 0); > + /* But only in the end of path */ > + test_FindFirstFileA_with("test-/>dir", 0, 0); > + test_FindFirstFileA_with("/>test-dir", 0, 0); > + test_FindFirstFileA_with(">test-dir", 0, 0); > + test_FindFirstFileA_with(">>test-dir", 0, 0); > + test_FindFirstFileA_with(">test->dir", 0, 0); > + test_FindFirstFileA_with("><test->dir", 0, 0); > + test_FindFirstFileA_with("<test->dir", 0, 0); > + test_FindFirstFileA_with("<\"test->dir", 0, 0); > + > + /* Slash after ignored chars is not ignored: */ > + test_FindFirstFileA_with("test-dir//", 0, 0); > + test_FindFirstFileA_with("test-dir</", 0, 0); > + test_FindFirstFileA_with("test-dir>/", 0, 0); > + test_FindFirstFileA_with("test-dir\"/", 0, 0); > + test_FindFirstFileA_with("test-dir\\", 0, 0); > + test_FindFirstFileA_with("test-dir\\\\", 0, 0); > + test_FindFirstFileA_with("test-dir\\/", 0, 0); > + test_FindFirstFileA_with("test-dir/\\", 0, 0); > + > + /* Disalowed chars being preserved: */ > + test_FindFirstFileA_with("test-dir/:", 0, 0); > + test_FindFirstFileA_with("test-dir/|", 0, 0); > + > + /* Slashes converted to backslashes */ > + test_FindFirstFileA_with("test-dir/", 0, 0); > + test_FindFirstFileA_with("./test-dir", 1, 0); > + test_FindFirstFileA_with("./test-dir/", 0, 0); > + test_FindFirstFileA_with("test-dir\\", 0, 0); > + test_FindFirstFileA_with(".\\test-dir", 1, 0); > + test_FindFirstFileA_with(".\\test-dir\\", 0, 0); > + > +#undef test_FindFirstFileA_with > +#undef FindFirstFileA_ok > + DeleteFileA("test-file"); > + RemoveDirectoryA("test-dir"); > } Please use table for test data and put your macro body in a loop.

April 2, 2011

Re: ntdll: Remove more path trailing chars.

by Marvin

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=10288 Your paranoid android. === WNT4WSSP6 (32 bit file) === file.c:2261: Test failed: FindFirstFile on test-dir// should fail file.c:2262: Test failed: FindFirstFile on test-dir</ should fail file.c:2263: Test failed: FindFirstFile on test-dir>/ should fail file.c:2264: Test failed: FindFirstFile on test-dir"/ should fail file.c:2267: Test failed: FindFirstFile on test-dir\/ should fail file.c:2275: Test failed: FindFirstFile on test-dir/ should fail file.c:2277: Test failed: FindFirstFile on ./test-dir/ should fail

April 2, 2011

Re: kernel32: add test for FindFirstFileA with a path ending with "/>"

by Vincent Pelletier

Le samedi 02 avril 2011 00:18:16, Austin English a écrit : > Your patch changelog is misleading. You're not just adding tests, but > fixing the bug. Either send the tests as a single patch and the fix > separately(and removing any todo_wine()'s that it fixes) or change the > summary to describe the fix. Woops, indeed. This, and I should rebase to remote before sending. -- Vincent Pelletier

April 2, 2011

Re: Project: x86 to ARM binary translator

by Charles Davis

On 4/1/11 6:19 PM, Yale Zhang wrote: > Fellow developers, > > I'm thinking of starting a VM project to allow running x86 Windows apps > on ARM Android. This will obviously involve binary translation. I've > read about QEMU's tiny code generator and think for a usable experience, > the intermediate micro-op representation will have to be abandoned, and > use a more efficient, though less portable x86 to ARM translator. I also > saw some Google SOC project that tried to incorporate LLVM into QEMU, > but with disastrous slow down if done naively. I still think it's worth > to do so, but lots of care will need to be done to only optimize code > that needs it like Sun's HotSpot Java compiler does. > > Questions: > > 1. How useful would this be and how much interest? > > Obviously, this will be a huge project, and I just want to gauge the > interest before I jump in. Microsoft will be releasing Windows for ARM > soon, so there will be no need to worry about > running Office, Matlab, Visual C++, etc on ARM, leaving only legacy > applications and games to benefit from binary translation. I'm mostly > interested in seeing some 3D games run on my > Xoom. > > 2. What's the best design: whole system VM (qemu) or process VM (qemu & > wine)? > > Process VM: > > + easier to incorporate 3D acceleration at API level > + uses less memory > + better performance (e.g. no need for MMU translation when accessing > memory) > + much better integration with host OS > - needs to maintain custom Windows API implementation (Wine) > > Whole system VM: > > + simpler, more unified to implement > + much better support for apps that are dependent on new, proprietary, > obscure Windows libraries, interfaces (moot because Office, Matlab, > etc will soon be available for ARM) > > Given the aims of only running legacy applications and games, it seems a > foregone conclusion that Wine's process VM approach is best. Comments? > > > 3. Will Wine ever incorporate binary translation? > > My proposed design will obviously use Wine's implementation of the > Windows API, which is huge. I'm not sure how disruptive of a change > binary translation will be to Wine. > > If Wine does incorporate binary translation, maybe they can change > the name to Wine Is Now an Emulator > > > If your're interested in this project, please reply. I'm not competent enough to mentor you, but, being a Mac user, I have a story to tell you. It's about a version of Wine that did incorporate binary translation: Darwine. Darwine was separate from mainline Wine; it incorporated QEMU directly and used it to translate x86 to PowerPC code. In a faraway time when Macs used PowerPC CPUs, Darwine allowed x86 Windows apps to run on Mac OS X. Now that Macs aren't built PowerPC chips anymore, Darwine has been abandoned. You might consider using it as a starting point, though. I switched over to the Mac platform (from Windows) in 2007, well after the PPC->x86 transition began, so I never needed Darwine. I did hear however that Darwine had major problems getting good performance (just as you surmised). You might have better luck rolling your own x86->ARM translator after all. That said, I'm also an LLVM guy, so I hear things like people proposing to modify LLVM's JITter to be adaptive (i.e. to heavily optimize heavy-traffic areas only), just as you propose. If that goes through, you might have better luck integrating LLVM into QEMU (again), then basing your project off of Darwine. Chip

April 2, 2011

Project: x86 to ARM binary translator

by Yale Zhang

Fellow developers, I'm thinking of starting a VM project to allow running x86 Windows apps on ARM Android. This will obviously involve binary translation. I've read about QEMU's tiny code generator and think for a usable experience, the intermediate micro-op representation will have to be abandoned, and use a more efficient, though less portable x86 to ARM translator. I also saw some Google SOC project that tried to incorporate LLVM into QEMU, but with disastrous slow down if done naively. I still think it's worth to do so, but lots of care will need to be done to only optimize code that needs it like Sun's HotSpot Java compiler does. Questions: 1. How useful would this be and how much interest? Obviously, this will be a huge project, and I just want to gauge the interest before I jump in. Microsoft will be releasing Windows for ARM soon, so there will be no need to worry about running Office, Matlab, Visual C++, etc on ARM, leaving only legacy applications and games to benefit from binary translation. I'm mostly interested in seeing some 3D games run on my Xoom. 2. What's the best design: whole system VM (qemu) or process VM (qemu & wine)? Process VM: + easier to incorporate 3D acceleration at API level + uses less memory + better performance (e.g. no need for MMU translation when accessing memory) + much better integration with host OS - needs to maintain custom Windows API implementation (Wine) Whole system VM: + simpler, more unified to implement + much better support for apps that are dependent on new, proprietary, obscure Windows libraries, interfaces (moot because Office, Matlab, etc will soon be available for ARM) Given the aims of only running legacy applications and games, it seems a foregone conclusion that Wine's process VM approach is best. Comments? 3. Will Wine ever incorporate binary translation? My proposed design will obviously use Wine's implementation of the Windows API, which is huge. I'm not sure how disruptive of a change binary translation will be to Wine. If Wine does incorporate binary translation, maybe they can change the name to Wine Is Now an Emulator If your're interested in this project, please reply.

April 2, 2011

Re: kernel32: add test for FindFirstFileA with a path ending with "/>"

by Marvin

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=10286 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

April 1, 2011

Re: kernel32: add test for FindFirstFileA with a path ending with "/>"

by Austin English

On Fri, Apr 1, 2011 at 23:14, Vincent Pelletier <plr.vincent(a)gmail.com> wrote: > Fixes bug 22635. > --- > dlls/kernel32/tests/file.c | 119 > ++++++++++++++++++++++++++++++++++++++++++++ > dlls/ntdll/path.c | 8 +++- > 2 files changed, 126 insertions(+), 1 deletions(-) Your patch changelog is misleading. You're not just adding tests, but fixing the bug. Either send the tests as a single patch and the fix separately(and removing any todo_wine()'s that it fixes) or change the summary to describe the fix. -- -Austin

April 1, 2011

Re: msvcp90: Implement basic_string and cstring versions of basic_string::find.

by Marvin

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=10285 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

April 1, 2011